Who is accountable when temporary privilege is not revoked on time?

Why This Matters for Security Teams

When temporary privilege is not revoked on time, the issue is rarely a single missed step. It is a control ownership problem, a lifecycle design problem, and often a monitoring problem. Temporary access that lingers becomes standing privilege in practice, which undermines both OWASP Non-Human Identity Top 10 guidance and the lifecycle emphasis in the NHI Lifecycle Management Guide.

NHI Management Group research shows how common this failure is: only 20% of organisations have formal processes for offboarding and revoking API keys, and 91.6% of secrets remain valid five days after notification. That is a clear signal that revocation is too often treated as a manual follow-up task rather than an enforced security control. In practice, many security teams discover the problem only after an audit finding, an incident, or a stale token being reused long after the original approval.

How It Works in Practice

Accountability should be assigned to the control owner for the identity lifecycle, not only the approver of the original request. The approver can confirm business need at the moment of issuance, but the control owner is responsible for making sure the privilege expires, is revoked, or is renewed through a documented process. That distinction matters because temporary access often spans IAM, PAM, CI/CD, cloud APIs, and application-specific controls.

Best practice is to make revocation automatic wherever possible. Short-lived credentials, expiry-based tokens, and JIT access reduce the need for manual cleanup. Where automation exists, the owner must verify that the system actually enforces expiry and revocation at the source, not just on a dashboard. Where automation does not exist, there should still be a named owner, a documented deadline, and an evidence trail for closure.

• Define the control owner for each privileged identity, token, or API key.
• Set a TTL that matches the task, not the convenience of the requester.
• Trigger revocation on completion, time expiry, or workflow closure.
• Log issuance, extension, and revocation as audit events.
• Escalate exceptions when revocation is delayed beyond the approved window.

The same lifecycle discipline appears in NHIMG guidance on Lifecycle Processes for Managing NHIs and in the Top 10 NHI Issues, where stale access and poor offboarding are repeatedly tied to excessive exposure. These controls tend to break down when temporary privilege is spread across multiple toolchains because no single system owns the full revocation path.

Common Variations and Edge Cases

Tighter revocation control often increases operational overhead, requiring organisations to balance speed for responders against assurance for security and audit. Not every environment can fully automate revocation on day one, especially where legacy systems, third-party integrations, or shared service accounts are involved. In those cases, current guidance suggests documenting compensating controls rather than pretending the risk is eliminated.

There is also no universal standard for who owns temporary privilege in every stack. In some organisations, the IAM team owns the platform control while application owners own the resource-level entitlement. In others, PAM, cloud security, or platform engineering takes that role. The key is that the owner must be able to prove revocation happened, not simply assume it occurred. NHI Management Group research on the Secret Sprawl Challenge shows why this matters: stale credentials often survive in places that are outside normal review cycles.

Where temporary privilege is granted to service accounts, automation jobs, or deployment pipelines, delayed revocation can also disrupt production if teams rely on long-lived tokens as a hidden dependency. That is why lifecycle ownership, expiry enforcement, and exception handling should be tested together, not treated as separate chores.

Related resources from NHI Mgmt Group

• Who is accountable when temporary elevated access is not revoked on time?
• 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?
• Who is accountable when SaaS access is not revoked on time?