What breaks when access control is only documented and not enforced at runtime?

Why This Matters for Security Teams

Documentation alone does not stop misuse. If access control is written in a policy but never enforced at runtime, privileged identities can keep operating after a change in role, environment, or incident state. That gap turns every review into a hindsight exercise instead of a control. Current guidance on OWASP Non-Human Identity Top 10 treats this as a core failure mode because non-human identities are machine-speed actors, not occasional human users.

The risk is larger than missed paperwork. Runtime enforcement is what proves least privilege, revocation, and segmentation actually happened when systems were under load. Without it, teams may believe access is constrained while secrets, tokens, or service accounts remain broadly usable. NHIMG’s Ultimate Guide to NHIs notes that only 5.7% of organisations have full visibility into their service accounts, which shows how often policy and reality diverge. In practice, many security teams discover the gap only after a credential has already been used outside its intended scope, rather than through intentional enforcement testing.

How It Works in Practice

Effective access control has to move from document form to decision point form. That means the system making the request must be checked at runtime against policy, context, and identity posture before access is granted. For NHIs, that usually means linking workload identity, short-lived credentials, and policy-as-code so each call is evaluated in the moment, not assumed safe because a diagram says so.

Practitioners usually need three layers working together:

• Authentication that proves the workload or agent is what it claims to be, not just that a static secret exists.
• Authorisation that evaluates context such as target resource, environment, time, and task purpose.
• Continuous revocation or expiry so access stops when the task, session, or trust condition changes.

This is why runtime enforcement is central to zero trust and to the practical reading of Ultimate Guide to NHIs — Standards. A control like “service accounts must be approved” is not enough if the account can still call sensitive APIs after approval expires. Likewise, PCI DSS v4.0 expects access controls to be implemented and validated, not merely recorded. The operational translation is simple: the policy must be machine-enforceable, the decision must happen at request time, and the result must be logged in a way auditors can verify.

NHIMG’s 52 NHI Breaches Analysis repeatedly shows that abuse tends to follow long-lived access and weak revocation discipline, not just weak documentation. These controls tend to break down when legacy applications rely on embedded secrets because the application cannot easily present a fresh identity or request a new decision for each transaction.

Common Variations and Edge Cases

Tighter runtime enforcement often increases operational overhead, requiring organisations to balance control strength against application compatibility and incident-response speed. Best practice is evolving, and there is no universal standard for every environment. In highly distributed systems, some teams start with policy checks only on high-risk actions, then expand to all sensitive paths as confidence grows.

Edge cases matter. Long-running jobs, batch pipelines, and legacy integrations may fail if access is made too ephemeral without a replacement pattern such as token exchange, workload identity federation, or scoped delegation. On the other hand, allowing broad standing access “for reliability” usually recreates the original problem. The practical compromise is to define explicit exceptions, time-box them, and monitor them as temporary risk acceptances rather than normal operations.

Runtime enforcement also changes what evidence matters. A policy document can support governance, but auditors and incident responders need logs showing the decision engine actually denied, allowed, or revoked access at the right moment. Without that evidence, teams cannot distinguish between a compliant design and a control that exists only in a slide deck.

NHIMG’s Ultimate Guide to NHIs — Key Challenges and Risks is clear that visibility, rotation, and revocation are inseparable in practice. In environments with shared service accounts or hard-coded secrets, documented access rules often fail because the runtime has no trustworthy way to apply them consistently.

Related resources from NHI Mgmt Group

• What breaks when user access reviews are the main identity control?
• What breaks when agent access is pre-provisioned instead of minted at runtime?
• What breaks when access across trust domains is not tightly scoped?
• What breaks when session monitoring is missing from industrial remote access?