Who is accountable when access remains after the business need ends?

Why This Matters for Security Teams

When access outlives the business need, the issue is not simply “who owns the account.” It is whether the organisation has a closed-loop revocation process that survives holidays, project handoffs, contractor offboarding, and emergency exceptions. The risk is especially visible in non-human access because secrets and tokens can stay valid long after the original task is finished. OWASP’s Non-Human Identity Top 10 treats stale credentials and weak lifecycle control as a core failure mode, not a minor hygiene issue.

NHIMG’s Ultimate Guide to NHIs frames this as a governance problem because revocation depends on coordination across identity, application, and operational owners. In practice, many security teams encounter stale access only after a service account is abused, rather than through intentional offboarding or scheduled deprovisioning.

How It Works in Practice

Accountability should be defined as the ability to trigger, verify, and evidence revocation, not merely to “approve” access. For human access, that often means HR initiates the lifecycle event, application owners confirm business need, and identity teams enforce termination in IAM or PAM. For NHI access, the model is similar but more technical: the owner of the workload, pipeline, or service must declare when access is no longer needed, and the platform must revoke the secret, token, or certificate automatically or on a tightly bounded schedule.

Current guidance suggests using a mix of ownership records, expiry timestamps, and event-driven revocation. That means:

• temporary grants expire by default rather than relying on manual cleanup
• business events such as project closure, vendor offboarding, or role change trigger revocation tasks
• identity teams validate that credentials were actually disabled, not just marked for review
• application owners confirm that dependent jobs, APIs, and integrations no longer require the access

For secrets-heavy environments, the practical control is to treat every grant as time-bound and every exception as something that must be re-approved. NHIMG’s The State of Secrets in AppSec highlights how long remediation can drag on when ownership is diffuse, which is why stale access often persists even in teams that believe their controls are mature. NIST’s Zero Trust Architecture reinforces the idea that access should be continually re-evaluated, not assumed valid because it was once approved. These controls tend to break down in SaaS-heavy environments with shared admin roles and no reliable event source for offboarding because there is no single system of record that can prove the need has ended.

Common Variations and Edge Cases

Tighter revocation often increases operational overhead, requiring organisations to balance faster cleanup against release friction and support burden. That tradeoff is real in CI/CD pipelines, third-party integrations, and emergency break-glass access, where immediate revocation can disrupt live services if ownership is unclear.

There is no universal standard for this yet, but current guidance suggests the accountable party should match the control point. If HR owns the employment event, it can initiate human offboarding. If an application team creates the temporary grant, that team should own the business justification and expiry. If identity operations enforce the actual removal, they should own evidence that it happened. The failure mode appears when these responsibilities are split without a final verifier.

For NHIs, this becomes more sensitive because access may be embedded in code, automation, or deployed infrastructure. A certificate may be expired on paper while a cached token still works. A service account may be “inactive” in IAM while still usable by a scheduled job. That is why NHIMG’s 52 NHI Breaches Analysis is useful as a reminder that lifecycle gaps are operational, not theoretical. In practice, accountability is strongest when one team is named to close the loop and prove revocation, because shared ownership without a final owner usually means nobody acts until after exposure.

Related resources from NHI Mgmt Group

• Who is accountable when vendor access remains active after a banking engagement ends?
• Who is accountable for third-party access after a campaign or project ends?
• Who is accountable when a third-party integration keeps an NHI active after the business need ends?
• Who is accountable when access remains active after a mass exodus?