Who should be accountable for stale access in a Zero Trust programme?

Why This Matters for Security Teams

In a zero trust programme, stale access is not a housekeeping issue. It is proof that entitlement decisions are drifting away from current purpose, current risk, and current ownership. NIST’s NIST SP 800-207 Zero Trust Architecture makes continuous verification central to the model, which means access that remains valid after its business need expires is a control failure, not an admin delay.

This is especially damaging for non-human identities, where service accounts, API keys, and automation tokens often outlive the workflow that created them. NHIMG notes that only 5.7% of organisations have full visibility into their service accounts in the Ultimate Guide to NHIs, and that visibility gap is exactly where stale access persists. The ownership question matters because lifecycle action tends to fail when everyone is partially responsible and no one is accountable for entitlement validity. In practice, many security teams discover stale access only after a review, incident, or audit finding, rather than through intentional lifecycle governance.

How It Works in Practice

Accountability should be shared across identity, application, and control owners, but one function must be designated as the system of record for entitlement validity. That owner approves who can grant access, how long it can remain active, what evidence renews it, and when it must be removed. In mature Zero Trust programmes, this is paired with continuous verification and lifecycle triggers rather than annual recertification alone.

The operational pattern usually looks like this:

• Identity teams maintain the authoritative identity and credential lifecycle state.
• Application owners define which entitlements are required for each workload or workflow.
• Control owners enforce policy, logging, and review thresholds for stale or unused access.
• Automation revokes or flags access when the task, ticket, deployment, or approval expires.

For NHI-heavy environments, current guidance suggests tying entitlement validity to workload identity and short-lived credentials, not static role grants. NHIMG’s Guide to SPIFFE and SPIRE is useful here because workload identity gives you a cryptographic basis for knowing what the workload is at runtime, while policy decides whether its access is still justified. That is a better fit than asking only who approved the role months ago. OWASP’s OWASP Non-Human Identity Top 10 also reinforces that weak lifecycle control and over-privilege are common failure modes, so entitlement reviews must be operational, not ceremonial. A practical governance model assigns one named owner for stale-access remediation SLAs, with measurable thresholds for last use, last review, and business owner attestation. These controls tend to break down when access is embedded in legacy batch jobs or shared automation accounts because the true business owner is no longer visible.

Common Variations and Edge Cases

Tighter entitlement governance often increases administrative overhead, requiring organisations to balance faster revocation against workflow disruption. That tradeoff becomes sharper in environments with regulated change windows, embedded vendor access, or highly automated CI/CD pipelines.

There is no universal standard for this yet, but current guidance suggests a few consistent patterns. First, shared service accounts should not be exempted from ownership just because multiple teams use them; they need a named lifecycle owner and a documented renewal path. Second, break-glass access is different from routine entitlements, so it should have separate approval, monitoring, and expiry rules. Third, the application owner may understand functional need, but the identity owner usually has the best position to enforce revocation mechanics.

NHIMG’s Ultimate Guide to NHIs — Key Challenges and Risks is a useful reminder that visibility gaps and weak rotation are often linked. When teams cannot see who still uses an entitlement, they cannot prove who should still own it. Best practice is evolving toward event-driven reviews, where access is revalidated after deployment, ownership change, inactivity, or risk signal rather than on a fixed calendar alone. In legacy estates with no reliable usage telemetry, this model degrades quickly because expired access cannot be distinguished from dormant but still required access.

Related resources from NHI Mgmt Group

• How should security teams govern vendor access in a zero trust programme?
• Who is accountable when identity-based access fails in a Zero Trust programme?
• How should security teams govern vendor access in a zero trust environment?
• How should security teams govern disconnected applications in a Zero Trust programme?