Access control models fall short for NHI governance at scale

At a glance

What this is: This is an explainer on DAC, RBAC, and ABAC that argues access control choice should match organisational scale, risk, and administrative complexity.

Why it matters: It matters because IAM teams managing human users, NHIs, and emerging autonomous workflows still have to govern privilege with models that were not designed for modern identity sprawl.

👉 Read StrongDM's guide to DAC, RBAC, and ABAC access control models

Context

Access control is the discipline of deciding who or what can reach a resource, under what conditions, and with what level of permission. In practice, the model you choose shapes how easily privileges can be granted, reviewed, and removed across human identities, service accounts, API-driven systems, and other NHIs.

The governance problem is not that DAC, RBAC, or ABAC are obsolete. It is that each assumes different levels of organisational control and different rates of change, and that becomes harder to manage as environments expand across cloud, databases, Kubernetes, and machine identities. Traditional PAM deployments also tend to expose the gap between policy intent and operational reality.

Key questions

Q: How should security teams choose between DAC, RBAC, and ABAC for access governance?

A: Choose the model that best matches how stable your identities, resources, and policies really are. DAC works when ownership is local and the environment is small. RBAC fits repeatable job functions. ABAC fits dynamic contexts, but only if attribute data is trustworthy and maintained. The best choice is the one your team can review and enforce consistently.

Q: Why do access control models break down as identity estates get more complex?

A: They break down when governance depends on manual upkeep that cannot keep pace with change. As teams add cloud services, platform privileges, service accounts, and exceptions, permissions become harder to keep current. The failure is usually not the model itself but the gap between policy design and operational maintenance.

Q: What do organisations get wrong about RBAC in large environments?

A: They often treat RBAC as a permanent simplification rather than a living design. In large environments, roles multiply, exceptions accumulate, and access reviews start certifying legacy structure instead of current need. RBAC fails when roles stop mapping cleanly to how work is actually done.

Q: How can teams tell whether ABAC is actually improving access control?

A: ABAC is working only when attribute data is current, complete, and consistently sourced across systems. If policies are precise but the underlying identity or resource attributes are stale, the control creates false confidence. Good ABAC should reduce manual exceptions and make policy decisions more explainable, not more opaque.

Technical breakdown

Discretionary access control and owner-managed permissions

DAC gives the resource owner or administrator direct discretion over who gets access. It typically uses access control lists to assign rights at the object level, which makes it simple and flexible for small environments. The trade-off is governance drift: access decisions become fragmented across many owners, and permissions can persist because no central lifecycle process revalidates them. In large environments, that decentralisation creates uneven enforcement and makes cleanup slow.

Practical implication: centralise review and offboarding checks around owner-managed permissions before they accumulate into unmanaged privilege.

RBAC versus ABAC in growing identity estates

RBAC assigns access through predefined job roles, while ABAC evaluates attributes such as location, device context, clearance, or resource type. RBAC scales better for predictable work, but it can become rigid when roles multiply. ABAC offers finer-grained policy control, but it requires accurate, continuously maintained attributes across identities and resources. Both models assume the organisation can keep the underlying catalogue clean enough for policy to remain trustworthy.

Practical implication: validate whether role design or attribute quality is the real constraint before adding more policy layers.

Why traditional PAM struggles with modern databases, cloud, and Kubernetes

PAM was built to control elevated human and administrative access, but modern infrastructure often spreads privilege across service accounts, tokens, secrets, and workload identities. That creates access paths that are harder to govern through manual approval alone, especially when systems need fast, repeated, or automated access. The result is a mismatch between the control plane and the identity surface. Governance must account for where standing privilege still exists and where access is being created outside the classic admin workflow.

Practical implication: map every privileged access path, not just the obvious admin accounts, before assuming PAM coverage is complete.

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 control failures in modern environments are usually lifecycle failures first, model failures second. DAC, RBAC, and ABAC all depend on someone keeping permissions current, but large identity estates make that upkeep uneven. When owners, admins, and platform teams all participate in access decisions, recertification and removal lag behind real usage. Practitioners should treat stale entitlement management as the underlying failure mode, not just a policy design issue.

RBAC is efficient only while roles remain stable enough to be meaningful. Once roles are proliferating to handle exceptions, growth, and cross-functional work, role logic starts to mirror the organisational chart rather than the actual access need. That is where RBAC becomes a maintenance problem, not a governance control. The implication is that teams must watch for role sprawl as a signal that access design no longer matches operating reality.

ABAC shifts the burden from permission lists to attribute integrity. That sounds more precise, but it only works if identity, resource, and environmental attributes are accurate and timely. If those inputs are stale or inconsistent, the policy engine produces confident but unreliable decisions. The practitioner conclusion is simple: policy sophistication does not compensate for weak identity data.

Traditional PAM gaps expose an identity blast radius problem. The article’s own warning about databases, cloud, Kubernetes, and more points to a control perimeter that no longer matches where privilege actually lives. Once elevated access is distributed across human and machine identities, a narrow PAM view misses the full blast radius. Teams should reframe privileged access as a cross-platform governance problem, not a vault problem.

Access control strategy should be chosen by operational variance, not by preference for a control label. DAC, RBAC, and ABAC each optimise for different levels of change and different governance costs. The discipline is to match the model to the identity surface, then test whether review, offboarding, and exception handling can keep pace. Practitioners should measure control durability, not just policy elegance.

From our research:

• 1 in 4 organisations are already investing in dedicated NHI security capabilities, with an additional 60% planning to do so within the next twelve months, according to The State of Non-Human Identity Security.
• Only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, which shows how quickly governance confidence falls behind operational complexity.
• For the wider control context, review Ultimate Guide to NHIs , Key Challenges and Risks for the visibility, sprawl, and over-privilege patterns that make rigid access models harder to sustain.

What this signals

Access-control model choice is becoming a programme design question, not an application preference. As environments mix human users, service identities, and high-change platform access, teams need a governance model that can survive real operating tempo. For many programmes, the pressure point will be whether role design, attribute quality, and privileged access review can all be sustained together. A useful next step is to align this work with the Ultimate Guide to NHIs and the OWASP Non-Human Identity Top 10.

Identity blast radius: this is the practical measure that matters when access paths spread across databases, cloud, and Kubernetes. If a team cannot see where standing privilege persists, it cannot judge whether its control model is actually reducing exposure. That is why access governance and infrastructure identity now have to be planned together, not sequenced separately.

The next governance maturity step is not simply more policy. It is better evidence of where access lives, who owns it, and how quickly it can be removed when work changes. Teams that can prove that across NHIs and human accounts will be better positioned to absorb platform growth without multiplying risk.

For practitioners

• Inventory access by control model Map where DAC, RBAC, and ABAC are actually used across applications, infrastructure, and identity platforms. Separate human access, service accounts, and privileged machine access so you can see where ownership, role assignment, or attributes are driving entitlement decisions.
• Audit role sprawl for RBAC decay Review whether roles still represent stable job functions or have become exception containers. Collapse duplicated roles, remove one-off entitlements, and check whether access reviews are certifying meaningful access or just preserving inherited role structure.
• Validate attribute quality before expanding ABAC Check whether the attributes used in policy decisions are current, authoritative, and consistently populated across systems. If device, location, or clearance data is unreliable, ABAC will create precise-looking decisions that do not reflect real governance conditions.
• Extend PAM coverage to non-obvious privileged paths Include databases, cloud control planes, Kubernetes, tokens, and service accounts in privileged access scoping. The goal is to identify where standing privilege survives outside classic admin workflows and close those paths with the same governance standard.

Key takeaways

• DAC, RBAC, and ABAC are different governance trade-offs, not interchangeable labels for access control.
• The main failure mode in large estates is stale ownership, role sprawl, or unreliable attributes, depending on the model in use.
• PAM coverage must extend beyond classic admin accounts if organisations want a realistic view of privileged access risk.

Key terms

• Discretionary Access Control: A model where the resource owner or administrator decides who gets access and at what level. It is flexible and easy to understand, but governance quality depends heavily on individual judgement and local discipline, which makes it harder to scale cleanly across large or fast-changing environments.
• Role-Based Access Control: A model that grants permissions according to organisational roles rather than per-user decisions. It reduces administrative effort when roles are stable, but it becomes brittle when exceptions, role sprawl, or frequent organisational change make the role catalogue drift away from real work.
• Attribute-Based Access Control: A policy model that decides access using attributes about the user, resource, and context. It can be more precise than role-based control, but it depends on reliable data and consistent policy inputs, otherwise the resulting decisions look exact while reflecting weak identity governance.
• Privileged Access Management: The governance layer used to control high-risk access such as administrative or elevated permissions. In modern environments it must cover more than human administrators, because privilege also lives in tokens, service accounts, cloud control planes, and other non-human identities that can bypass classic workflows.

Deepen your knowledge

Access control modelling for NHIs and privileged systems is covered in our NHI Foundation Level course, the industry's only accredited NHI security programme. If your programme is trying to govern databases, cloud, and Kubernetes access at the same time, this is a useful place to start.

This post draws on content published by StrongDM: 3 Types of Access Control: IT Security Models Explained. Read the original.