Who should be accountable for privileged access reviews and offboarding?

Why This Matters for Security Teams

Privileged access reviews and offboarding are not paperwork exercises. They are the control points that decide whether elevated access still matches current business need, whether approvals remain valid, and whether abandoned accounts can be reused. NHI Management Group’s Ultimate Guide to NHIs notes that only 20% of organisations have formal processes for offboarding and revoking API keys, which explains why review ownership often becomes ambiguous in practice.

The accountability problem is usually organisational, not technical. System owners understand the service, identity governance teams understand policy and evidence, and the approving manager or service owner understands why access was granted in the first place. If any one of those parties assumes another team will act, privileged access can persist long after the original need has ended. The OWASP Non-Human Identity Top 10 treats lifecycle failure as a core risk because unmanaged privileged access is a common path to misuse, lateral movement, and audit failure. In practice, many security teams discover broken accountability only after a former user, contractor, or service has already retained active privileged access.

How It Works in Practice

Clear accountability should map to a closed-loop process. The system owner owns the business justification for access, confirms whether the privilege is still needed, and accepts the residual risk if it remains. The identity governance team owns the review workflow, evidence collection, escalation, and remediation tracking. The approving manager or service owner validates the original need and signs off when access should continue or end. That split is consistent with lifecycle guidance in the NHI Lifecycle Management Guide.

In operational terms, this means each review should answer four questions: who approved it, why it exists, whether the access is still required, and who will revoke it if it is not. For privileged NHI access, best practice is to couple the review with automated deprovisioning so that approval, remediation, and verification are linked. Where possible, the access owner should not be the same person who performs the review, because self-approval weakens evidence quality. Current guidance from the OWASP Non-Human Identity Top 10 also supports treating orphaned credentials, excessive privilege, and missing rotation as lifecycle issues rather than isolated hygiene problems.

A practical control pattern is:

• system owner validates the business need and approves continuation
• identity governance team records evidence and tracks remediation
• approver or delegate confirms revocation when access is no longer justified
• technical owner verifies removal from vaults, IAM, PAM, and downstream applications

For high-risk credentials, especially API keys and service account tokens, the process should include re-checking dependent systems so that revoked access cannot be silently reintroduced. These controls tend to break down when ownership is split across multiple platforms and no single team can revoke access end to end.

Common Variations and Edge Cases

Tighter review and offboarding controls often increase operational overhead, so organisations have to balance speed against assurance. That tradeoff is real for large estates where NHIs are embedded in CI/CD, cloud platforms, and third-party integrations.

There is no universal standard for every edge case, but current guidance suggests the following distinctions. Shared service accounts should have a named technical owner and a named business owner. Break-glass accounts should be reviewed by governance but revoked only through a documented emergency procedure. Third-party managed access should remain the responsibility of the internal service owner even when a vendor administers the system, because the risk still lands on the organisation. For high-scale environments, NHI Management Group’s Top 10 NHI Issues is a useful reminder that overused identities and weak offboarding are usually symptoms of missing ownership, not just missing tooling.

One useful benchmark is the 91% of former employee tokens still active after offboarding reported in Entro Security’s 2025 State of NHIs and Secrets in Cybersecurity. That finding underscores the point: if offboarding is treated as advisory instead of accountable, revocation becomes optional and risk remains live.

Related resources from NHI Mgmt Group

• Why do privileged access reviews still fail in mature IAM programmes?
• How should security teams run privileged access reviews without missing high-risk accounts?
• Who should be accountable for role-based privileged access governance?
• Who is accountable when privileged access remains in place after a role change or merger?