Enterprise authorization models need to outgrow org charts

At a glance

What this is: This is a guide to enterprise authorization models, showing how RBAC and ABAC handle access decisions and enforcement differently as organisations scale.

Why it matters: It matters because IAM teams need authorization structures that can adapt to growth, policy complexity, and changing hierarchies without creating role explosion or brittle custom logic.

By the numbers:

• Only 5.7% of organisations have full visibility into their service accounts.
• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface.
• 71% of NHIs are not rotated within recommended time frames, increasing the risk of compromise over time.
• 80% of identity breaches involved compromised non-human identities such as service accounts and API keys.

👉 Read Cerbos's guide to enterprise authorization models and RBAC vs ABAC

Context

Enterprise authorization is the layer that decides who can do what, then enforces the result in the application or platform. In this article, the primary problem is not basic access control but whether an authorization model can scale beyond departmental hierarchies without becoming brittle.

That matters for IAM because the same design pressure shows up across human access, workload access, and service identities. When access logic is copied from org charts, teams eventually inherit role sprawl, duplicated rules, and reimplementation work every time the business structure changes.

Key questions

Q: How should teams choose between RBAC and ABAC for enterprise authorization?

A: Use RBAC when access needs are stable, role boundaries are clear, and the organisation can accept coarser permissions. Use ABAC when access must vary by context such as location, time, business unit, or resource attributes. The decision should be driven by governance complexity and data quality, not by preference for a simpler-looking model.

Q: When does role-based access control become too rigid?

A: RBAC becomes too rigid when roles start multiplying to handle exceptions, geography, or temporary conditions. At that point, the role model no longer expresses durable job functions and begins to encode policy workarounds. That is usually the signal to shift context-specific decisions into attribute-based policy.

Q: How do teams avoid role explosion in enterprise authorization models?

A: Keep roles coarse and durable, and move exceptions into policies, attributes, or approval flows. Reduce role creation by designing around business tasks rather than reporting lines. Review role hierarchies regularly so inherited permissions do not accumulate faster than the organisation can govern them.

Q: What should security teams do when access rules depend on location or time?

A: Use attribute-based access control so the policy can evaluate context instead of forcing the organisation to create separate roles for every scenario. Ensure the underlying attributes are trustworthy, current, and consistently populated, because context-aware authorization is only as good as the data feeding it.

Technical breakdown

Decision and enforcement in authorization models

Authorization models separate two functions. Decision asks whether a subject may perform an action on an object, while enforcement applies the result by allowing, denying, or shaping the request flow. This distinction matters because the policy engine is not the application itself. In mature designs, the policy decision point evaluates context, and the policy enforcement point consumes that result consistently across APIs, UI flows, and services. When teams blur those layers, they hard-code business logic into applications and make future policy changes expensive.

Practical implication: Define where policy is decided and where it is enforced before you add more custom access logic.

RBAC, hierarchical RBAC, and role explosion

Role-based access control assigns permissions through named roles, which is simple until the role catalogue starts mirroring every team, exception, and edge case. Hierarchical RBAC reduces duplication by nesting child roles under parent roles, but it still depends on a stable organisational structure. If the business changes faster than the role model, the hierarchy becomes a maintenance burden. The core design flaw is coupling authorization to reporting lines rather than to durable business tasks and access intent.

Practical implication: Use RBAC for stable, clearly bounded job functions, but avoid making the role model a copy of the org chart.

ABAC and policy-based access decisions

Attribute-based access control evaluates a request using subject, action, object, and qualifying context such as location or time. That makes ABAC more flexible than role-only models because policy can express conditions without creating new roles for every variant. It is also more demanding to implement because the policy logic depends on accurate attributes and consistent evaluation. In practice, ABAC is strongest where access changes based on context, business unit, geography, or time-bound rules, and where static role definitions would become unmanageable.

Practical implication: Use ABAC when access must adapt to context and you can support the data quality and policy governance it requires.

NHI Mgmt Group analysis

Authorization models fail when teams confuse hierarchy with governance. This article shows that copying departmental structure into access control creates a model that looks orderly but does not age well. Governance should describe durable access intent, not mirror reporting lines that will inevitably change. The practical conclusion is that authorization design must start from business rules and policy logic, not from the organisation chart.

RBAC remains useful, but only where the business can tolerate role boundaries that are coarse by design. Core RBAC and hierarchical RBAC are efficient when access patterns are stable and the number of roles is constrained. Once the enterprise needs location, time, or exception-aware decisions, role multiplication becomes the hidden tax. The discipline is to treat RBAC as a boundary, not a default answer for every access problem.

ABAC is the right response to policy complexity, not a universal replacement for RBAC. The article correctly frames ABAC as context-aware and adaptable, but the real governance decision is whether the organisation can maintain reliable attributes and consistent policy evaluation. If those inputs are weak, the model becomes harder to operate than the problem it was meant to solve. Practitioners should match model complexity to the quality of their identity data and control ownership.

Fine-grained authorization is a governance capability, not just a development pattern. The useful part of the article is the recognition that policy evaluation and enforcement must scale with the enterprise, especially when custom logic is accumulating on top of legacy access systems. That means identity architects, security teams, and application teams need one common authorization strategy instead of isolated implementations. The practical takeaway is to manage authorization as a platform discipline.

Role explosion: When roles are used to encode every exception, the model stops describing access and starts describing exceptions. That creates brittle administration, weak auditability, and slow change. The implication is that teams should reserve roles for stable job functions and move contextual variance into policy.

From our research:

• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface, according to Ultimate Guide to NHIs.
• 71% of NHIs are not rotated within recommended time frames, which shows how quickly static control assumptions break down in production identity estates.
• For the broader control picture, see NHI Lifecycle Management Guide for the governance practices that keep authorization decisions tied to current access state.

What this signals

Role design is becoming an identity governance problem, not just an application architecture choice. As enterprises add more services, integrations, and contextual rules, the old habit of mapping permissions directly to org structure creates control drift. Teams should expect authorization reviews to become more about policy ownership, attribute quality, and exception handling than about role naming alone.

If the programme still relies on static role hierarchies, the next failure is usually not a breach but operational slowdown. Every new exception forces another manual branch, another duplicate permission set, or another fragile override that becomes hard to audit later.

Role explosion is the warning sign to watch for. Once that begins, the organisation is signalling that business context belongs in policy, while roles should stay limited to stable identity functions. That is where modern IAM programmes need to move next.

For practitioners

• Separate decision logic from enforcement points Map where policy is evaluated, where it is enforced, and where application code still contains ad hoc access checks. Replace duplicated decision logic with a single policy layer where possible, then keep enforcement consistent across APIs and user flows.
• Use RBAC only for stable job functions Keep roles aligned to durable duties such as finance, support, or administration, not to every team variant or temporary exception. If a role starts to encode context, location, or one-off approvals, move that variation into policy rather than creating another role.
• Introduce ABAC for contextual access rules Apply attribute-based rules when access depends on time, location, business unit, or resource sensitivity. Make sure the identity, resource, and environmental attributes are reliable before relying on them for decisions, otherwise the policy engine will produce inconsistent outcomes.
• Audit custom authorization logic in legacy systems Inventory where Active Directory, application code, and third-party libraries are all contributing access decisions. Identify duplicated logic, redundant role mappings, and any place where the business hierarchy has been hard-coded into permissions.

Key takeaways

• Enterprise authorization works best when it separates decision from enforcement instead of burying policy inside applications.
• RBAC is efficient for stable job functions, but hierarchical role models become brittle when they are forced to mirror organisational structure.
• ABAC handles contextual access better, provided the organisation can maintain trustworthy attributes and governance over policy changes.

Key terms

• Authorization Model: An authorization model is the structure an organisation uses to decide who can do what, and under which conditions. It combines decision logic with enforcement so access is granted or denied in a consistent way across applications and services.
• Role-Based Access Control: Role-based access control assigns permissions through named roles that represent job functions or responsibilities. It is simple to administer when access patterns are stable, but it becomes harder to manage if roles are used to encode every exception or business nuance.
• Attribute-Based Access Control: Attribute-based access control evaluates access using attributes attached to the subject, resource, action, and context. It supports fine-grained policy decisions, especially when location, time, or other environmental conditions change the correct answer.
• Policy Decision Point: A policy decision point is the component that evaluates a request against policy and returns allow or deny. It does not enforce access itself, but it provides the decision that enforcement points use to control the request path.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or governance in your organisation, it is worth exploring.

This post draws on content published by Cerbos: enterprise authorization models and access control design approaches. Read the original.