Why does broken access control persist even when IAM policies exist?

Broken access control persists because policies are often static while infrastructure and identities are dynamic. A policy can exist and still fail if permissions are inconsistently enforced across systems, if temporary elevation becomes standing privilege, or if no one continuously checks the actual access an identity holds.

Why This Matters for Security Teams

broken access control persists because an IAM policy is only as effective as its enforcement points, its scope, and its lifecycle. Security teams often assume that a documented policy equals real restraint, but modern estates mix cloud consoles, CI/CD, SaaS, APIs, and service accounts that can bypass a clean-looking policy model. The result is a gap between intended access and actual access, especially when permissions are copied, inherited, or never removed. This is a core theme in the Ultimate Guide to NHIs and aligns with the control focus in the OWASP Non-Human Identity Top 10.

The problem is not the absence of policy. It is the drift between policy, identity sprawl, and operational reality. A privilege that was appropriate during onboarding can become excessive after a role change, an emergency change, or a temporary exception that quietly becomes standing access. NHIMG research shows that 97% of NHIs carry excessive privileges and only 20% of organisations have formal offboarding and revocation processes for API keys, which explains why access control failures keep recurring even in policy-rich environments.

In practice, many security teams discover broken access control only after an identity has already used access it was never meant to keep.

How It Works in Practice

Effective access control depends on continuous verification, not just policy creation. Mature programmes compare what the policy says against what each identity can actually do across platforms, then remove gaps as they appear. That means reviewing entitlement inheritance, temporary elevation, token scope, and direct grants in cloud IAM, Kubernetes, secrets managers, and application-layer authorisation. The NIST Cybersecurity Framework 2.0 reinforces the need to manage access as an operational control, while NHIMG guidance on the lifecycle processes for managing NHIs shows why offboarding and rotation are inseparable from access governance.

In practice, teams reduce broken access control by combining three layers:

• Policy definition that expresses least privilege, separation of duties, and approval paths.
• Runtime enforcement that checks the request, the identity, the resource, and the context before access is granted.
• Continuous entitlement review that finds stale permissions, shared secrets, and overbroad roles before they are exploited.

This is especially important for non-human identities because their access patterns are machine speed, not human speed. A service account, API key, or workflow token may be reused across environments, embedded in code, or granted broad read-write scope for convenience. The Top 10 NHI Issues highlights how excessive privileges and weak rotation practices turn policy into theatre when the identity estate is not continuously reconciled with actual use.

These controls tend to break down when cloud, SaaS, and CI/CD platforms each maintain their own permission model because inconsistent enforcement creates gaps that policy alone cannot close.

Common Variations and Edge Cases

Tighter access control often increases operational overhead, requiring organisations to balance reduced blast radius against slower delivery and more review work. That tradeoff becomes visible in environments with many ephemeral workloads, third-party integrations, or delegated administration, where rigid RBAC can create exceptions that eventually become permanent. Current guidance suggests that static role models are still useful for coarse-grained governance, but they are not sufficient on their own when identities are dynamic and permissions must change faster than human review cycles.

There is no universal standard for this yet, but best practice is evolving toward policy-as-code, runtime authorisation, and short-lived credentials rather than standing privilege. For teams managing secrets at scale, the operational issue is often not whether a policy exists, but whether a token, key, or certificate can still be used after the business reason for it has ended. NHIMG research also shows that 91.6% of secrets remain valid five days after notification, which illustrates how slow remediation makes access control failures persist even after they are detected.

Broken access control is most stubborn in hybrid estates where identities cross admin planes, application logic, and data services because no single control point sees the full picture.

Related resources from NHI Mgmt Group

• Why do non-human identities create compliance risk even when policies exist?
• Why do software signing controls fail even when policies exist?
• Why do outdated IGA systems create access risk even without a breach?
• When does role-based access control become too coarse for modern governance?