Who is accountable when zero trust fails because access was never removed?

Why This Matters for Security Teams

zero trust is not only a policy model; it is an operational discipline that depends on identity lifecycle control, timely offboarding, and continuous access review. When access remains after a role change, contract end, or application decommissioning, the breach is usually framed as a network issue even though the real failure is stale entitlement governance. NIST’s NIST SP 800-207 Zero Trust Architecture makes the point that trust decisions must be evaluated continuously, but that only works when access inputs are current.

For Non-Human Identities, the problem is often sharper than with humans because service accounts, API keys, and automation tokens can outlive the team, application, or workflow that created them. NHIMG’s 52 NHI Breaches Analysis shows how identity sprawl and unmanaged credentials repeatedly turn small ownership gaps into real exposure. The practical lesson is that accountability must sit with the identity and application owners who approved or inherited access, while security defines the control and verifies it. In practice, many security teams encounter stale access only after privilege has already been reused, not through intentional offboarding checks.

How It Works in Practice

Accountability starts with a clear control owner for each access path, then moves into enforcement through recurring review, revocation, and evidence capture. The owner is usually the application team, platform team, or business system steward that benefits from the access, while security provides policy, monitoring, and exception handling. Current guidance suggests using zero standing privilege principles so access exists only when a task requires it, and removing it immediately when the task ends.

For NHI-driven environments, lifecycle hygiene needs to be explicit. That means naming the owner of every secret, token, key, certificate, and automation account, then tying that owner to offboarding and recertification workflows. Where possible, short-lived credentials, workload identity, and policy checks at request time reduce the chance that a forgotten credential can remain useful. NHIMG’s Ultimate Guide to NHIs — Standards is a useful reference for mapping those responsibilities back to the identity lifecycle, while the OWASP Non-Human Identity Top 10 helps teams frame stale access as a predictable control failure rather than a one-off mistake.

• Assign one accountable owner for every entitlement, even if access is inherited.
• Require recertification for standing access on a fixed cadence.
• Revoke access automatically when employment, contract, or system ownership changes.
• Log exceptions with expiry dates and an explicit approver.
• Prefer short-lived credentials and workload identity over long-lived static secrets.

These controls tend to break down in legacy environments with shared service accounts and no authoritative system of record for ownership, because no one can prove who should remove access.

Common Variations and Edge Cases

Tighter access governance often increases operational overhead, so organisations must balance revocation speed against change-management friction. In mature environments, the accountability question is straightforward. In inherited or outsourced environments, it is less so, because the original approver may no longer exist and the current operator may only be a custodian. Best practice is evolving here, but the current direction is clear: if ownership is ambiguous, the access should be treated as high risk until a named owner accepts responsibility.

There are also cases where security cannot remove access unilaterally, such as regulated production systems, vendor-managed platforms, or break-glass accounts. In those situations, the control should require documented approval, time-bound exceptions, and compensating monitoring. NHIMG’s Ultimate Guide to NHIs — Key Challenges and Risks is especially relevant when inherited entitlements, service principals, or automation keys outlast their business justification.

When the organisation cannot show who approved the access, who inherited it, and who must remove it, accountability shifts from a person to the control gap itself. That is usually where zero trust drifts into policy theatre rather than enforceable practice.

Related resources from NHI Mgmt Group

• Who is accountable when zero trust controls fail to stop unauthorised access?
• Who is accountable for access decisions under zero trust governance?
• Who is accountable when access is blocked because a device fails posture checks?
• Who is accountable when zero-trust maturity fails in a contractor environment?