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.
Editorial analysis by NHI Mgmt Group, based on content published by Cerbos: “Designing an authorization model for an enterprise”.
Key questions
Q: What breaks when an authorization model cannot represent real organizational structure at scale?
A: The system starts forcing product decisions instead of reflecting business requirements.
Q: When should organisations move from RBAC to ABAC?
A: Move to ABAC when role alone no longer captures the access rule, such as ownership, time of day, or transaction amount.
Q: How do security teams know a role model is becoming unmanageable?
A: Common signs are role explosion, overlapping permissions, and repeated custom exceptions for the same business need.
Practitioner guidance
- Separate policy from enforcement Define who decides access and how the application enforces it as two distinct layers so policy changes do not require full application rewrites.
- Audit for org-chart coupling Review roles that were created only to mirror departments, reporting lines, or temporary team structures, then flag them for consolidation or redesign.
- Use RBAC where duties are stable Keep RBAC for recurring business functions with clear permission sets, but avoid using it for rapidly changing or highly contextual access decisions.
Bottom line: Enterprise authorization fails when access rules are treated as a replica of the organisation chart rather than a policy model.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 5 days ago by NHI Mgmt Group
12/06/2026 8:29 am
Org-chart replicas are a brittle authorization pattern: When access policy mirrors departmental structure too closely, the model inherits every organisational change. That may look tidy at first, but reorganisation turns into reimplementation, which is a governance failure rather than a tooling issue. The practical conclusion is that authorization should model business policy, not reporting lines.
A few things that frame the scale:
- 43% of security professionals are concerned about AI systems learning and reproducing sensitive information patterns from codebases, according to the State of Secrets in AppSec.
A question worth separating out:
Q: What should organisations do before rebuilding enterprise authorization rules?
A: Start by reviewing existing governance models and internal policies, then decide which access rules are truly stable and which depend on request context. That helps separate role-based access from policy-based access and avoids encoding temporary structure into the long-term model.
👉 Read our full editorial: Enterprise authorization models need to outgrow org charts
This post was modified 5 days ago by NHI Mgmt Group