Who is accountable when zero-trust controls fail to reduce access over time?

Why This Matters for Security Teams

When zero trust does not reduce access over time, the issue is usually not the philosophy itself but the operational handoff behind it. Identity teams define trust conditions, application owners keep exceptions alive, and governance teams are expected to recertify access before it becomes permanent. If those responsibilities are vague, elevated access quietly survives each review cycle and the environment drifts away from the intent of NIST SP 800-207 Zero Trust Architecture.

This is especially visible in NHI programs because machine access often outlives the original use case. Secrets are copied into pipelines, service accounts accumulate scopes, and revocation becomes a paper exercise. NHIMG’s Ultimate Guide to NHIs — Key Challenges and Risks highlights how standing access, fragmented ownership, and weak review cadence create the conditions for access creep. In practice, many security teams discover this only after an audit finding or an incident has already shown that “temporary” access had become operationally permanent.

How It Works in Practice

Accountability in a zero trust model is distributed, but not blurred. The identity owner is responsible for the trust policy attached to the identity, the application owner is responsible for the permissions the workload actually needs, and the governance function is responsible for ensuring those decisions are revisited. That is the operational meaning of zero trust: trust is never assumed for long, and access must be continuously justified, not merely approved once.

In a mature implementation, the review loop should cover three things: whether the identity is still needed, whether the scope is still minimal, and whether the control still enforces revocation at the point of access. For NHIs, that often means validating secrets, tokens, certificates, and workload permissions against the actual runtime behavior described in Ultimate Guide to NHIs and, where applicable, replacing static credentials with workload identity patterns documented in NHIMG’s Guide to SPIFFE and SPIRE.

• Identity owners define who or what is trusted and under what conditions.
• Application owners define the minimum entitlements required for the workload to function.
• Governance owners recertify access on a fixed cadence and remove stale exceptions.
• Control owners verify that revocation is enforced in IAM, PAM, and the application layer.

Where teams get this wrong is assuming that an approved policy will automatically decay with time. Zero trust only reduces access over time when the policy, review, and enforcement layers are all operating together. These controls tend to break down when a legacy application cannot revoke entitlements cleanly because access is embedded in code, shared service accounts, or long-lived tokens.

Common Variations and Edge Cases

Tighter access review often increases operational overhead, requiring organisations to balance security gains against change-management friction. That tradeoff is real, especially in environments with high release velocity, shared infrastructure, or many service-to-service dependencies. Best practice is evolving, but current guidance suggests that exception handling should be explicit, time-bound, and owned by a named business or application stakeholder rather than left in a central queue.

One common edge case is shared technical ownership. If no single team owns the service account, recertification can stall indefinitely and responsibility gets fragmented across IAM, platform, and application teams. Another is environment sprawl: access may be reduced in production but remain over-permissive in CI/CD, test, or disaster recovery systems. The 52 NHI Breaches Analysis is a useful reminder that weak lifecycle control, not just initial compromise, is a recurring pattern.

In high-risk cases, organisations should treat “who can approve” and “who can revoke” as separate questions. That separation is often what reveals the real accountability gap. When access persists after intended expiry, the failure usually sits with ownership discipline, not with the zero trust model itself.

Related resources from NHI Mgmt Group

• Who is accountable for zero-trust adoption in public sector contractor ecosystems?
• When do NHI access reviews create more value than a one-time cleanup?
• How do organisations reduce the dwell time of exposed credentials at scale?
• When should organizations review access controls?