What is the difference between access review and deprovisioning?

Why This Matters for Security Teams

access review and deprovisioning are often treated as the same activity, but they solve different problems in the identity lifecycle. Review is a decision point: does this service account, API key, token, or workload still need access? Deprovisioning is the enforcement step: remove what no longer has a valid business or technical purpose. In NHI programmes, that distinction matters because stale access is one of the fastest ways to widen blast radius.

The gap shows up when organisations complete governance paperwork but leave credentials active. NHIMG’s Ultimate Guide to NHIs notes that only 20% of organisations have formal processes for offboarding and revoking API keys, while 97% of NHIs carry excessive privileges. That combination makes review without removal a false finish. The OWASP Non-Human Identity Top 10 also highlights how unmanaged machine identities create persistent exposure that is easy to miss in periodic audits.

In practice, many security teams encounter stale access only after an incident, rather than through intentional lifecycle control.

How It Works in Practice

An access review asks whether access remains justified. It typically involves an owner, approver, or system reviewing the identity, its permissions, and the business purpose behind them. For human users, that might happen quarterly. For NHIs, the right cadence is often tied to workload change, deployment events, certificate expiry, or secret rotation rather than a calendar alone.

Deprovisioning is the operational response when access is no longer needed. For NHIs, that means revoking credentials, disabling service accounts, removing API keys, rotating certificates, and updating any dependent workloads or pipelines. Good practice is to connect the review outcome directly to the enforcement path so the decision cannot stall in a spreadsheet or ticket queue. The NHI Lifecycle Management Guide frames this as lifecycle control, not a one-time cleanup exercise.

Practitioners usually separate the process into four actions:

• Identify the identity and its owner, purpose, and dependencies.
• Review whether the access is still required and at what scope.
• Approve removal or retention based on evidence, not habit.
• Execute deprovisioning and verify the credential is no longer usable.

For machine identities, verification matters because a key can be “deleted” in one system but still remain valid in a vault, CI/CD pipeline, cloud role, or cached deployment secret. Current guidance suggests tying review to automated deprovisioning wherever possible, especially for short-lived workloads and ephemeral access paths. These controls tend to break down in heavily distributed CI/CD environments because dependencies are numerous, ownership is unclear, and removal can disrupt production if rollout order is not mapped.

Common Variations and Edge Cases

Tighter deprovisioning often increases operational overhead, requiring organisations to balance stronger revocation with application stability and owner coordination. That tradeoff is real, especially for legacy systems, shared service accounts, and third-party integrations where immediate removal can interrupt critical workflows.

There is no universal standard for this yet, but best practice is evolving toward event-driven deprovisioning for NHIs. Rather than waiting for a periodic access review, many teams revoke access when a pipeline is retired, a workload is replaced, a secret is rotated, or an integration contract ends. That approach is stronger because the review and removal happen close to the actual change in risk.

Edge cases deserve special handling. Shared accounts may need staged replacement before removal. Long-lived certificates may require overlapping validity windows. External partners may need contractual notice before credentials are revoked. In those cases, review should still produce a clear disposition: retain, restrict, rotate, or revoke. NHIMG’s Top 10 NHI Issues and 52 NHI Breaches Analysis both reinforce a common pattern: identities are reviewed too late, and deprovisioning is incomplete or unverified.

For teams with mature governance, the practical test is simple: if an identity failed review today, could it actually be removed today?

Related resources from NHI Mgmt Group

• What is the difference between reviewing human access and reviewing NHIs?
• What is the difference between role-based access and API key governance for NHI security?
• What is the difference between protecting applications and protecting access?
• What is the difference between attack surface management and NHI governance?