Enterprise authorization models: where RBAC stops and ABAC starts

TL;DR: Enterprise authorization models separate decision from enforcement and increasingly need to move beyond org-chart replicas, because RBAC, hierarchical RBAC, and ABAC each solve different scaling problems in access control, according to Cerbos. The practical issue is not picking a fashionable model, but choosing one that survives organisational change without exploding roles or rework.

NHIMG editorial — based on content published by Cerbos: enterprise authorization models and access control design approaches

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.

Questions worth separating out

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.

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.

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.

Practitioner guidance

• 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.
• 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.
• Introduce ABAC for contextual access rules Apply attribute-based rules when access depends on time, location, business unit, or resource sensitivity.

What's in the full article

Cerbos's full guide covers the operational detail this post intentionally leaves for the source:

• Code-level examples of how RBAC is implemented with annotations, model-driven designs, and directory integration.
• Policy statement patterns for ABAC, including subject, action, object, and qualifying phrase examples.
• Comparison guidance for choosing between RBAC and ABAC in organisations with different scale and governance needs.
• Implementation notes for integrating authorization models with existing application stacks and identity systems.

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

Enterprise authorization models: where RBAC stops and ABAC starts?

Explore further

View Full Forum →  |  NHI Foundation Course →