Notifications
Clear all
Topic starter
11/06/2026 11:41 pm
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
12/06/2026 8:29 am
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Enterprise authorization models need to outgrow org charts
