Notifications
Clear all
Topic starter
11/06/2026 10:57 pm
TL;DR: Access control models such as DAC, RBAC, ABAC, and PBAC can improve authorization discipline, but Zluri’s overview shows they still depend on correct policy design, lifecycle hygiene, and ongoing review to prevent over-access and compliance drift. The deeper issue is that access model choice does not remove governance debt when identities, apps, and entitlements keep expanding.
NHIMG editorial — based on content published by Zluri: Security & Compliance 4 Types of Access Control
By the numbers:
- Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
- 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface.
- Only 5.7% of organisations have full visibility into their service accounts.
Questions worth separating out
Q: How should security teams use access control models without creating entitlement sprawl?
A: Security teams should use access control models as decision frameworks, not as a substitute for governance.
Q: Why do access control models still fail in mature IAM programmes?
A: They fail when the programme focuses on granting access but not on removing it.
Q: What do teams get wrong about policy-based access control?
A: Teams often assume PBAC automatically produces better governance because it is more flexible.
Practitioner guidance
- Tie every access model to lifecycle controls Map RBAC, ABAC, and PBAC decisions to onboarding, mover, and offboarding workflows so entitlements are removed when business need ends.
- Limit discretionary granting authority Reserve DAC-style exceptions for low-risk resources and require reviewable approvals for privileged or shared access.
- Validate policy inputs before enforcing PBAC Check the quality of attributes, roles, and policy rules before using them to drive access decisions.
What's in the full article
Zluri's full article covers the operational detail this post intentionally leaves for the source:
- How Zluri positions DAC, RBAC, ABAC, and PBAC in a practical access management workflow.
- The product-oriented explanation of onboarding, access reviews, and remediation automation that sits behind the overview.
- The vendor's implementation framing for controlling app access, permissions, and review activity across an IGA environment.
👉 Read Zluri's guide to the four main access control models →
Access control models and the identity governance gap teams miss?
Explore further
12/06/2026 7:23 am
Access model selection is not the same thing as access governance. DAC, RBAC, ABAC, and PBAC describe how an entitlement is decided, but they do not guarantee that the entitlement will be removed, reviewed, or bounded over time. In identity programmes, the operational failure usually comes after the initial decision, when stale permissions and weak offboarding leave access in place longer than intended. Practitioners should treat model choice as only one layer of control design.
A few things that frame the scale:
- Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them, according to Ultimate Guide to NHIs.
- 71% of NHIs are not rotated within recommended time frames, increasing the risk of compromise over time.
A question worth separating out:
Q: Who is accountable when access decisions are delegated across roles and policies?
A: Accountability sits with the identity governance function, not with the model itself. DAC, RBAC, ABAC, and PBAC all need owners who can explain why access was granted, who can change it, and who confirms removal. Without that accountability chain, access control becomes a technical label rather than a governance control.
👉 Read our full editorial: Access control models are not enough for modern identity governance
