Access control models are not enough for modern identity governance

At a glance

What this is: This is a vendor-authored overview of four access control models and how they shape authorization, governance, and compliance outcomes.

Why it matters: It matters because IAM teams still need to connect access models to lifecycle controls, NHI governance, and review processes rather than treating model selection as a complete control strategy.

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.

👉 Read Zluri's guide to the four main access control models

Context

Access control is the mechanism that decides who or what can reach a resource, but model choice alone does not solve governance. In practice, discretionary, role-based, attribute-based, and policy-based access control each shift the decision point, while the real risk comes from how consistently those decisions are reviewed, revoked, and audited across the identity lifecycle.

For IAM and IGA teams, this is not just a human access problem. The same access control logic now has to hold up for service accounts, workload identities, and AI-enabled systems as well, which is why static permission models often fail when privilege sprawl, third-party access, and offboarding gaps are not tightly managed.

Key questions

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. The safest approach is to combine role, attribute, or policy logic with lifecycle controls, periodic review, and explicit revocation. That keeps permissions aligned to current business need instead of letting old entitlements accumulate across users, apps, and service accounts.

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. Even well-designed RBAC or PBAC policies can leave excessive permissions in place if offboarding, recertification, and exception management are weak. The control weakness is usually persistence, not the access model itself.

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. In reality, PBAC only improves control when policy definitions, attribute data, and enforcement logic are kept current. If those inputs drift, the organisation gains complexity without gaining reliable security or auditability.

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.

Technical breakdown

Discretionary access control and permission drift

Discretionary access control, or DAC, lets individual owners or leaders grant access directly. That flexibility is useful, but it also creates permission drift because access decisions spread across people rather than a central policy engine. In a growing environment, the result is inconsistent approvals, inherited rights, and unclear accountability when access changes over time. DAC can work for small, low-risk environments, but it becomes fragile when the number of users, applications, and shared resources rises. The control failure is not the model itself, but the absence of durable governance around who can change permissions and how those changes are reviewed.

Practical implication: restrict discretionary granting authority and back it with reviewable approval workflows for sensitive resources.

RBAC, ABAC, and policy-based access control

Role-based access control, or RBAC, assigns access by job function. Attribute-based access control, or ABAC, uses contextual signals such as location, device state, or resource attributes. Policy-based access control, or PBAC, then applies explicit policy logic to decide whether access should proceed. These models are often presented as a maturity ladder, but the important point is that they solve different parts of the problem. RBAC simplifies administration, ABAC adds context, and PBAC ties access decisions to enforceable governance rules. None of them is self-maintaining, and all of them depend on accurate identity data and current policy definitions.

Practical implication: map each sensitive entitlement to the simplest model that can enforce it, then validate the underlying attributes and policy inputs regularly.

Dynamic authorization and lifecycle enforcement

Dynamic authorization changes access decisions based on current conditions rather than static assignment alone. That is useful when access needs vary by session, task, or risk state, but it only works if lifecycle processes keep pace. Onboarding, mover events, offboarding, and periodic recertification remain the control layer that stops access from outliving its purpose. This is where many programmes break down: the access model may be technically sound, but the associated joiner-mover-leaver process is incomplete. The governance gap is not lack of sophistication, but lack of revocation discipline and evidence that privileges were actually removed when business need ended.

Practical implication: pair dynamic authorization with access review and revocation workflows so permissions do not persist after business need changes.

Threat narrative

Attacker objective: The objective is to turn routine authorization weakness into unauthorized access that broadens reach across systems and data.

1. entry: Access is introduced through over-broad permissions, stale role assignments, or owner-granted exceptions that bypass central governance.
2. escalation: The attacker or insider moves from one permitted resource to a wider set because privileges were inherited, excessive, or not revalidated.
3. impact: Sensitive data, administrative functions, or control plane access become reachable without a fresh authorization decision, enabling unauthorized modification or exfiltration.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• ASP.NET machine keys RCE attack — 3,000+ exposed ASP.NET machine keys enabled remote code execution.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

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.

Policy-based access control only works when policy quality is continuously governed. PBAC is often described as more flexible than RBAC because it can reflect current rules and business conditions, but that flexibility becomes a liability when policy definitions drift faster than review cycles. If the underlying policy logic is poorly curated, access becomes harder to explain and harder to audit. Practitioners should focus on policy lifecycle discipline, not just policy expression.

The real authorization problem is privilege persistence, not authorization theory. The article frames access control as a choice among models, but most security failures come from permissions that survive beyond their intended business purpose. That is especially true for service accounts, shared admin roles, and delegated access paths where no one revisits the original decision. Practitioners should measure how often access is removed, not just how access is granted.

Identity blast radius: Access control models become materially more important when a single over-assigned identity can touch many apps or data sets. The blast radius expands whenever entitlement sprawl, weak review cadence, or missing offboarding lets one account preserve too much reach. Practitioners should think in terms of how far one identity can move, not just how elegantly the policy is written.

Human IAM, NHI governance, and lifecycle controls are converging on the same failure pattern. The article is written in a human IT manager frame, but the underlying lesson applies across humans, service accounts, and automated identities: access models fail when lifecycle and evidence controls are weaker than the permissions they assign. Practitioners should align access decisions with lifecycle enforcement across every identity type they govern.

From our research:

• 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.
• For the broader lifecycle view, NHI Lifecycle Management Guide shows why provisioning, rotation, and offboarding have to be managed as one control chain.

What this signals

Identity blast radius: the access model you choose matters less than how far a single entitlement can spread before review or removal. If your programme still relies on manual cleanup, the control boundary will keep lagging the real identity surface, especially as service accounts and application roles multiply.

The governance signal is clear: most organisations still under-invest in removal discipline, and that gap is more damaging than the initial grant. When permissions persist past business need, access control starts to behave like a record-keeping exercise rather than an enforcement mechanism.

For teams modernising IAM, the next step is to align access policy with the lifecycle guidance in the Ultimate Guide to NHIs and the control patterns in OWASP Non-Human Identity Top 10.

For practitioners

• 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. Use access reviews to verify that the model used to grant access is still valid at the time of recertification.
• Limit discretionary granting authority Reserve DAC-style exceptions for low-risk resources and require reviewable approvals for privileged or shared access. Make sure the owner who can grant access is also visible in the audit trail, so accountability does not disappear when permissions change.
• Validate policy inputs before enforcing PBAC Check the quality of attributes, roles, and policy rules before using them to drive access decisions. If the input data is stale or inconsistent, policy-based controls can create a false sense of precision while preserving unsafe access.
• Measure revocation, not just provisioning Track how long it takes to remove access after role changes, vendor offboarding, or task completion. Use the delay between entitlement expiry and revocation as a governance metric, because that is where authorization models often fail in practice.

Key takeaways

• Access control models only reduce risk when they are paired with lifecycle enforcement and review.
• The biggest governance weakness is usually persistence of access, not the choice between DAC, RBAC, ABAC, or PBAC.
• IAM teams should measure revocation discipline and policy quality together, because that is where authorization succeeds or fails.

Key terms

• Discretionary Access Control: A model where access decisions are made by the resource owner or another delegated authority rather than by a central policy engine. It is flexible, but it can create inconsistent permissions if owners grant access without durable review, especially when many identities, applications, or exceptions are involved.
• Role-Based Access Control: An access model that assigns permissions according to job roles rather than individual requests. It simplifies administration and works well for common access patterns, but it still depends on accurate role design, timely offboarding, and periodic review to prevent role drift and privilege accumulation.
• Attribute-Based Access Control: An access model that evaluates user, resource, and environmental attributes before allowing access. It adds context such as location, device, or classification, but its accuracy depends on trustworthy attribute data and well-maintained policy logic, otherwise the control becomes difficult to explain or audit.
• Policy-Based Access Control: An access model that enforces explicit business or security policies when deciding whether access should be granted. It can be more adaptable than simple role mapping, but it only works as intended when policy definitions, inputs, and enforcement rules are continuously governed and kept current.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security 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 programme maturity, it is worth exploring.

This post draws on content published by Zluri: Security & Compliance 4 Types of Access Control. Read the original.