Who is accountable when a stale identity still has privileged access?

Accountability should sit with the identity owner, the system owner, and the governance function that allows access to persist. For privileged identities, PAM owners must also ensure expiry, session control, and revocation are enforced. If no one owns the offboarding path, the organisation has a governance failure, not just an operational delay.

Why This Matters for Security Teams

A stale privileged identity is not just an unused account. It is an active trust relationship that can be abused long after the original owner, project, or vendor context has changed. That makes accountability a governance issue, not simply a ticketing delay. OWASP’s OWASP Non-Human Identity Top 10 treats overprivileged and poorly governed NHIs as a persistent attack path, while NHI Mgmt Group’s Ultimate Guide to NHIs highlights how rotation and offboarding failures are common across real environments.

The practical question is who is accountable when revocation does not happen on time. In mature programs, that spans the identity owner, the system owner, and the governance or PAM function that approves, monitors, and removes access. If privileged access remains in place after a role change, termination, application retirement, or vendor exit, security teams should treat it as a control failure with a named owner, not an ambiguity to resolve later. In practice, many security teams encounter this only after a breach review, not through intentional offboarding.

How It Works in Practice

Accountability becomes real when it is tied to lifecycle controls. The identity owner is responsible for declaring when the identity should no longer exist or no longer have privilege. The system owner is responsible for knowing which application, workload, or environment still depends on that identity. The governance or PAM function is responsible for making sure expiry, session controls, rotation, and revocation actually happen. NHI Mgmt Group’s Key Challenges and Risks discussion is clear that excessive privilege and weak offboarding are recurring control gaps.

Operationally, strong programmes assign ownership in the access review record and require a revocation path for every privileged identity, including service accounts, API keys, certificates, and break-glass credentials. The review should answer four questions:

• Who requested and approved the access?
• Who owns the underlying workload or system?
• What event triggers revocation or downgrade?
• Who verifies that the credential is no longer valid?

That model aligns with the idea that privileged access should be time-bound, observable, and attributable. Where possible, teams should use expiry, session logging, and least-privilege scope to reduce the blast radius before revocation catches up. The 52 NHI Breaches Analysis shows why this matters: stale or exposed identities repeatedly become a foothold for lateral movement and privilege abuse. These controls tend to break down when ownership is split across teams but no one is accountable for the offboarding action itself because approvals, operations, and governance each assume another party will revoke access.

Common Variations and Edge Cases

Tighter offboarding control often increases operational overhead, requiring organisations to balance fast change delivery against reliable revocation. That tradeoff is especially visible for shared service accounts, inherited access in acquired systems, and third-party integrations where a single owner may not exist. Current guidance suggests the answer is to make the accountability chain explicit, even when technical ownership is distributed.

There is no universal standard for every edge case yet, but good practice is to define a fallback owner for orphaned identities, a remediation SLA for stale privileged access, and a revalidation step after mergers, role changes, and vendor offboarding. For highly privileged NHI access, PAM teams should not rely on annual review cycles alone. They should use shorter review intervals, expiration by default, and exception handling with documented risk acceptance. If the identity cannot be mapped to a current business owner, that is a strong signal to suspend access until ownership is re-established. Industry analysis in the Top 10 NHI Issues reinforces that visibility gaps and excessive privilege are often coupled, which makes stale identities especially dangerous.

Related resources from NHI Mgmt Group

• Who is accountable when a contractor still has privileged cloud access after departure?
• Who is accountable when DNS weaknesses disrupt access to identity services?
• Who is accountable when privileged access controls fail in cloud environments?
• Who is accountable for over-privileged service accounts and stale secrets?