RBAC (Role-Based Access Control): users inherit permissions through predefined roles. Easy to explain but it breaks when roles stop reflecting the real organisation — 'catch-all' roles emerge and accumulate more permissions than anyone actually needs.
What is authorization
Authorization is the process of deciding what an already-authenticated user, application or device is allowed to do. It is not the same as authentication: authentication answers "who are you", authorization answers "what can you do now that we know who you are". It materialises as granular permissions (what data you can read, what systems you can modify, what operations you can launch) and is implemented through models such as RBAC (role-based), ABAC (attribute-based) and ACL (access control lists). When authorization is weak or poorly maintained, the predictable outcomes are privilege escalation, exposure of sensitive data and lateral movement after an initial compromise.
Why it matters
Well-designed authorization is the main line of containment when a credential falls: if permissions are narrow, the blast radius is narrow. The least-privilege principle is the foundation of Zero Trust, network segmentation and access control, and it is almost always the first serious finding of any audit: de facto administrators who no longer perform that role, service accounts with inherited permissions, access paths that survived team changes. Regulation reinforces the point: ISO 27001 requires segregation of duties (SoD), NIS2 mandates periodic access reviews to critical information, and DORA requires governance of privileged access in essential financial services. For a CISO this means leaving behind the annual spreadsheet review and moving towards continuous audit, automated segregation of duties and contextual authorization (trusted device, location, calculated risk).
Key points
ABAC (Attribute-Based Access Control): decisions depend on attributes (department, time, location, device posture, calculated risk). Much finer than RBAC, but it requires a proper policy engine and good hygiene of identity data.
ReBAC and relational authorization: newer models (used in platforms such as OpenFGA or Zanzibar) express permissions as relationships between entities ('Ana is editor of project X'). A natural fit for SaaS applications with complex hierarchies of shared resources.
Least privilege in practice: it is not just reducing the initial role. It means revoking access after a role change, removing permissions from service accounts that are no longer used, and stopping administrators from doing everyday work with their privileged account.
Just-in-time (JIT) access and PAM: instead of keeping privileges permanently, they are elevated only during an audited window, with approval and automatic expiration. This drastically shrinks the exposure window if the credential is compromised.
Segregation of duties (SoD): the person who creates payments does not approve them, the person who provisions accounts does not review logs, the person who deploys to production does not control SIEM rules. It is implemented via conflict matrices and automated controls in the IdP.
Example: Privilege escalation from inherited authorization
A support technician has been with the company for four years. They started in systems engineering, moved to user support, and at each transition their account accumulated permissions: still in the Domain Admins group "just in case", read access to the customer database from a project that lasted two weeks, and credentials from the legacy backup system. A targeted phishing campaign compromises the account; within hours the attacker pivots to a domain controller, creates a backdoor using a service account that looks legitimate, and exfiltrates customer tables before the EDR flags the behaviour as anomalous.
The fix is not to blame the technician, it is to redesign the model. Roles are separated by real function (support can reset passwords but cannot touch GPOs, development reaches dev environments but not production, domain administration is only granted with reinforced MFA and a JIT window). A PAM solution records every privileged session, with dual approval for destructive operations. Every quarter, managers certify that their teams still need the access they have, and the SIEM alerts whenever someone exercises a permission they have not used for ninety days. At the next audit, effective permissions drop by more than a third without anyone losing the ability to do their job.
Common mistakes
- Assuming a compromised user can only cause damage with their visible privileges. If their account can edit a deployment script, change a GPO or read secrets from a vault, there is a path to escalation even without formal admin rights.
- Treating RBAC as a static system: defining roles once at IdP rollout and never revisiting them when the organisation changes. After two years the roles no longer reflect reality and nobody dares touch them for fear of breaking something.
- Not segregating critical duties: the same person who provisions accounts in AD can grant themselves permissions and clear audit events. Without automated SoD it is a gentlemen's agreement, not a control.
- Inherited permissions that are never revoked: role changes, partial departures, projects that end. Annual audit is too slow; inactivity-based removal and continuous certification are the minimum.
- Using service accounts as the easy path to 'just make it work': admin permissions granted to integrations that only need to read a single endpoint. When the integration is forgotten, the account lives on with its power intact.
Related services
This concept may be related to services such as:
Frequently asked questions
What is the difference between RBAC and ABAC?
RBAC assigns permissions through fixed roles (admin, editor, viewer). It is quick to roll out but context-blind: the same permission is granted at 10:00 from the office or at 03:00 from an unknown network. ABAC evaluates attributes (location, time, device posture, risk level) against a policy. It delivers much finer control, but it requires investment in a policy engine, attribute governance and clean identity data.
Why is segregation of duties (SoD) so important?
Because it neutralises the risk that a single person —whether by fraud or by error— completes a sensitive chain end to end. Whoever creates payments should not approve them, whoever provisions accounts should not modify the logs, whoever deploys to production should not control SIEM rules. ISO 27001 mandates it and DORA reinforces it for essential financial services. Without automation, SoD is an agreement; with conflict matrices in the IdP, it is a control.
How do you audit authorization in a large enterprise?
With Identity Governance tools: effective-permission reports by user and role, periodic certification (managers confirm their teams still need each access) and automated detection of SoD conflicts. The SIEM complements with alerts on anomalous access: permissions that have been dormant for months and are suddenly used, service accounts reaching resources outside their scope, ad-hoc escalations with no logged justification.
How does authorization relate to Zero Trust?
Zero Trust starts from "never trust, always verify", and translated to authorization it means every request is evaluated against the policy in force at that moment, not against a frozen role. In practice, Zero Trust pushes you towards contextual authorization (ABAC or ReBAC), just-in-time access and continuous review. Without fine-grained authorization, Zero Trust is only product marketing.