RBAC and access management: who may see what in a fiduciary system?

What is RBAC and where does ABAC differ?

Role-Based Access Control, RBAC for short, is the access-management model established since the 1990s. Instead of giving permissions to individual people, you define roles (apprentice, clerk, mandate manager, managing director), attach a bundle of rights to each role, and assign employees to one or more roles. On a personnel change the role changes, not the individual rights.

Attribute-Based Access Control (ABAC) goes one step further and decides based on attributes – time of day, location, client category, document confidentiality, device, network zone. Example: "Clerk Müller may read documents of category B-mandate, but only during office hours and only from the CH IP range." RBAC would be too rigid here; ABAC models the condition cleanly.

In practice, productive systems combine both. RBAC delivers the coarse structure (apprentice, clerk, mandate manager), ABAC the fine conditions (own clients only, business hours only, with two-factor only). The model is then called RBAC-ABAC hybrid and is in May 2026 a default option in practically every enterprise IAM system (Keycloak, Okta, Entra).

Three principles are not negotiable. Least privilege: every employee gets only the minimal rights for daily work, no more. Separation of duties: whoever books receipts does not approve them – four-eyes principle on critical steps. Need-to-know: anyone without an assignment to handle a client does not see that client data – not "out of curiosity" either.

Why it matters

Three legal anchors force clean access management. First, professional secrecy under Art. 321 SCC and BGFA: anyone working in a law firm or fiduciary practice may not share client data with uninvolved parties. "Uninvolved" includes internal employees without a mandate assignment. Without technically enforced client separation a single apprentice accidentally opening a file would be a criminal offender – and the firm is liable.

Second, revFADP: Art. 8 requires appropriate technical and organisational measures to protect personal data. An open file system without role separation is not appropriate. On data breaches a notification to the EDÖB is required under Art. 24 revFADP; without clean RBAC you cannot say which data went to whom.

Third, GeBüV and Art. 957a CO: every permission change on bookkeeping-relevant systems must be logged. Who extended "approve booking" to the apprentice on 12 March? Without an audit trail an auditor cannot trace this and management stands without proof.

Add the practical protection against insider threats. The Verizon DBIR 2026 lists 18 percent of all data incidents as insider-caused – through negligence or malicious intent. An employee who sees only their own clients can, even with malicious intent, do only limited damage.

What an RBAC setup looks like in a fiduciary SME

We walk through a concrete setup step by step. An 8-person fiduciary with 180 clients.

Role model: apprentice (read internal guides, read assigned clients without write), clerk (read and write assigned clients, no approval right), mandate manager (everything on the own mandate including approval), managing director (full access on all mandates plus user administration), external auditor (time-limited read access to one client).

Client separation: each client is assigned an ACL containing only the employees working on that mandate. Clerk Müller sees in their client list only their 25 assigned mandates – the other 155 do not exist for them. That is not "just greyed out" but technically enforced: a direct URL manipulation leading to a foreign client returns a 403 error.

Identity provider: in May 2026, the OSS recommendations are Authelia (Go, lightweight, good for small setups) and Authentik (Python, broader functionality, GUI administration). Both speak OIDC and SAML 2.0 and integrate with all common web applications. Keycloak from Red Hat is the enterprise OSS variant with full federation, IdP brokering and SCIM provisioning. In cloud, Okta and Microsoft Entra (formerly Azure AD) are standard, both with SCIM and Conditional Access.

SSO standards: SAML 2.0 is the older, robust standard for browser-based single sign-on. OIDC (OpenID Connect) is the modern, JSON-based variant and in May 2026 the preferred choice for new integrations. SCIM (System for Cross-domain Identity Management) automates user provisioning: when HR creates or removes an employee in the central system, SCIM propagates that change to all connected applications.

Multi-factor authentication: in May 2026 the absolute minimum standard for business-relevant systems is password plus hardware token (YubiKey, Titan Key) or TOTP via authenticator app. SMS as second factor is deprecated because SIM-swap attacks are documented in Switzerland. Phishing-resistant WebAuthn keys are the most robust variant.

Audit trail: every permission change is written with user, time, old and new value, executing account into an append-only table. Under Art. 957a CO this log must be kept for 10 years. The audit trail must be tamper-evident – either via hash chains (each entry contains the hash of the predecessor) or via WORM storage (S3 Object Lock, MinIO Object Lock).

Joiner-mover-leaver process: every personnel change follows a documented sequence. New employee (joiner): choose role, set up access, training. Move to another function (mover): withdraw old rights, assign new ones, transition time up to 30 days. Leaver: deactivate all access within 1 hour after leaving – on leaving day before 18:00 is mandatory. Quarterly access review: every mandate manager reviews the employees on their mandates.

RBAC implementation in 5 steps

1. 01Role inventory: list all employee classes with their typical tasks. Do not cut too finely – 4 to 6 roles are enough for an SME.
2. 02Permission catalogue: per role define the maximum necessary rights. Least privilege as guiding principle – when in doubt less.
3. 03Choose identity provider: Authelia or Authentik for small OSS setups, Keycloak for mid-size with federation, Okta or Entra for cloud standard. SSO via SAML 2.0 or OIDC.
4. 04Set up client ACL: every client gets a list of authorised employees. Technically enforced with 403 on URL manipulation.
5. 05Joiner-mover-leaver process plus audit trail: HR system triggers SCIM sync, every change is tamper-evident logged, quarterly access review by mandate managers.

When RBAC is mandatory

RBAC with client separation is mandatory in all businesses under professional secrecy: law firms, fiduciary, tax advice, medical practices, psychotherapy practices, notaries, asset managers. Here the law itself demands separation, not just good practice.

Also for all businesses processing especially protected personal data under Art. 5 revFADP – health, religious, ideological, political, trade-union views, social-assistance measures, criminal-prosecution data – RBAC with fine granularity is mandatory.

In the general SME area, RBAC is sensible from the moment more than three people work on a system. A two-person office with a central admin account may be acceptable. With four people the risks – accidental deletions, unintended changes, data-protection breaches – are high enough that role separation makes sense.

Business recommendation: a fiduciary office able to tell a client "your clerk sees only your data, no other employee has access" wins mandates against the competitor who cannot guarantee that. Clients in May 2026 increasingly ask explicitly.

Where RBAC is over-engineered

A one-person office without employees, pure family data without external clients, a hobby project with two friends – here RBAC is overhead without value. A central admin account with a long password and two-factor is enough.

The opposite mistake is also problematic: some SMEs implement a 12-role model with 80 fine-grained permissions for five employees. Nobody can keep that overview, new employees wait weeks for the right cut, and in practice everyone ends up "power user" because otherwise work stalls. That is worse than no RBAC because it gives a feeling of security without delivering it.

Rule of thumb: one role per employee class. An 8-person fiduciary typically needs 4 to 6 roles, not 12. Per role no more than 15 permissions; more is a hint that the role should be split or that ABAC would be the better choice.

Third pitfall: RBAC without joiner-mover-leaver. Anyone defining roles cleanly but not revoking access within hours has gained nothing – the employee terminated on Friday still has access on Monday. The process is as important as the model.

Trade-offs

FAQ

Related topics

Sources

1. NIST SP 800-162 – Guide to Attribute Based Access Control (ABAC) · 2026-03
2. BSI – IT-Grundschutz-Baustein ORP.4 Identitäts- und Berechtigungsmanagement · 2026-02
3. Verizon Data Breach Investigations Report 2026 · 2026-04
4. Authelia – official documentation · 2026-04
5. Authentik – official documentation · 2026-05
6. Keycloak – Server Administration Guide · 2026-04