Ownership should sit with the identity governance function, with clear execution responsibilities in IT and application teams. The organisation needs one accountable process for revocation, even if the actual removal steps differ by system. Without that accountability, offboarding becomes inconsistent and hidden access persists longer than it should.
Why This Matters for Security Teams
When identity spans SaaS, cloud, CI/CD, ticketing, and internal applications, revocation is no longer a single-system admin task. It becomes a control ownership problem. If nobody owns the end-to-end lifecycle, one system may disable access while another still accepts the same token, key, or service account. That gap is where hidden access persists after offboarding, especially for shared or overused NHIs.
This is why identity governance must own the accountable process, even when IT and application teams execute system-specific removal steps. NHI Management Group’s Ultimate Guide to NHIs and NHI Lifecycle Management Guide both stress that lifecycle control fails when ownership is fragmented across platforms. The operational risk is not just delay, but inconsistency: one revoked credential, one forgotten integration, one stale permission path.
OWASP’s OWASP Non-Human Identity Top 10 frames this as a recurring NHI weakness, and NHIMG research shows only 20% of organisations have formal processes for offboarding and revoking API keys. In practice, many security teams discover revocation gaps only after a contractor or system decommission has already left orphaned access behind.
How It Works in Practice
The cleanest model is one accountable revocation workflow with distributed execution. Identity governance defines the trigger, required approvals, evidence, and closure criteria. IT and application owners then remove access from the systems they control. That separation matters because the revocation event is organisational, while the technical delete actions are system-specific.
At minimum, the process should include:
- A single source of truth for ownership, including who can initiate and who must confirm completion.
- Inventory linkage between the identity record and every system where the NHI is used.
- Time-bound revocation targets for high-risk identities, especially service accounts and API keys.
- Verification that access is not merely disabled in one plane while remaining valid in another.
- Evidence capture for audit, incident review, and downstream control testing.
Current guidance suggests pairing this with workload-aware controls rather than relying on human-style IAM. For example, the OWASP Application Security Verification Standard and broader identity practices align with revocation testing, while NHI governance requires explicit attention to token, secret, and certificate retirement. Where possible, automate notification from HR, CMDB, and pipeline events so revocation starts when the identity change occurs, not when someone remembers to file a ticket.
This becomes especially important when the same NHI is reused across multiple applications, because one missed dependency can keep access alive after the primary credential has been removed.
Common Variations and Edge Cases
Tighter revocation controls often increase coordination overhead, requiring organisations to balance fast offboarding against the reality that some systems cannot be removed instantly or through a single API call. That tradeoff is especially visible in legacy estates, external SaaS, and partner-managed environments.
One common exception is delegated administration, where platform owners can execute removal but do not own the policy decision. Another is shared service identities, where revocation may require staged replacement rather than immediate deletion. Best practice is evolving here: there is no universal standard for this yet, but identity governance should still remain the accountable owner of the lifecycle decision.
In environments with CI/CD, secrets managers, and ephemeral workloads, revocation also has to address derived credentials, cached tokens, and downstream replicas. NHIMG’s Guide to the Secret Sprawl Challenge is relevant here because a revoked primary secret is not sufficient if copies remain in code, tickets, or pipeline variables. For deeper lifecycle nuance, the Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs is a useful reference point.
These controls tend to break down when identity records are incomplete, because the organisation cannot prove where the NHI exists or which system still trusts it.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and CSA MAESTRO address the attack and risk surface, while NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | Lifecycle ownership and revocation are core NHI governance concerns. |
| NIST CSF 2.0 | PR.AA-2 | Identity lifecycle control supports access removal and identity assurance. |
| CSA MAESTRO | MAESTRO addresses operational controls for agent and workload lifecycle governance. |
Use MAESTRO to define ownership, revocation workflows, and runtime validation for autonomous identities.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on July 6, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
