The business owner and identity team should own it together, because revocation has to be tied to contract expiry, project closure, and entitlement state. If offboarding depends on manual tickets alone, access will outlive the relationship that justified it.
Why This Matters for Security Teams
Access revocation is not just an IT cleanup task. When a supplier contract ends or a project closes, the real control objective is to end the authority that justified the access in the first place. That means the business owner must signal the end of the relationship, while the identity team must remove the technical entitlements, tokens, and secrets that remain in place. If either side assumes the other will act, dormant access becomes the default.
This is especially important for non-human identities because service accounts, API keys, and automation credentials rarely expire on their own. NHI Management Group notes that 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 gap shows why manual ticketing is not a sufficient control. Current guidance from the OWASP Non-Human Identity Top 10 and the Ultimate Guide to NHIs both point toward lifecycle ownership, not ad hoc cleanup.
In practice, many security teams discover leftover access only after a supplier relationship has already ended and the credentials are still live.
How It Works in Practice
Effective revocation should be treated as a joined business and identity workflow. The business owner defines when the relationship ends, including contract expiry, project closure, or supplier disengagement. The identity team then translates that trigger into concrete actions across the stack: disable accounts, revoke API keys, expire certificates, remove role bindings, and invalidate any delegated access paths. If the identity is tied to a system, revocation should also include dependent integrations, CI/CD pipelines, and secrets distribution points.
For NHI governance, the best practice is to connect revocation to the entitlement source of truth, not to a human memory or a ticket queue. That usually means:
- Linking each supplier identity to a contract record, owner, and expiry date.
- Using just-in-time or short-lived credentials where possible so access naturally decays.
- Tracking where secrets are stored, then rotating or deleting them at offboarding.
- Requiring the business owner to confirm closure before identity operations execute final revocation.
The control model is reinforced by the Ultimate Guide to NHIs — Key Challenges and Risks, which highlights the scale of exposure when secrets and service accounts are left unmanaged. The operational lesson is simple: revocation should be event-driven, auditable, and automatic where possible, with the business owner accountable for the trigger and the identity team accountable for the technical execution. These controls tend to break down when supplier access is embedded in shared accounts or when the contract end date is not mirrored in the identity system.
Common Variations and Edge Cases
Tighter revocation control often increases coordination overhead, requiring organisations to balance clean shutdowns against the speed of project delivery. That tradeoff is real, especially where multiple teams or vendors share one automation path.
There is no universal standard for this yet, but current guidance suggests that ownership should shift based on the trigger, not the tooling. For example, procurement may confirm contract end dates, the business owner may approve the relationship closure, and the identity team may execute revocation. In regulated environments, a second reviewer is often added for high-risk supplier access, but that is an operating choice rather than a baseline requirement.
Edge cases deserve explicit handling. If an identity supports several projects, revocation should be scoped to the specific contract or workload, not the entire account. If a supplier uses shared automation credentials, the organisation should plan migration to a distinct workload identity, because shared secrets make clean ownership nearly impossible. The 52 NHI Breaches Analysis shows how often persistent access outlives the original business need. For implementation detail, the OWASP Non-Human Identity Top 10 remains the clearest external reference for lifecycle and credential hygiene.
When contracts end but integrations continue to run, the identity team should treat that as an exception requiring explicit renewal or shutdown approval, not as implied permission to keep access active.
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 address the attack and risk surface, while NIST CSF 2.0 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-06 | Covers NHI lifecycle and offboarding when access must end with the business relationship. |
| NIST CSF 2.0 | PR.AC-1 | Supports controlled access termination as part of identity and access management. |
| NIST AI RMF | GOVERN | Applies governance and accountability to ownership of revocation decisions. |
Assign clear revocation accountability and document approval, execution, and exception handling.
Related resources from NHI Mgmt Group
- Who should own passkey recovery and fallback access controls?
- Who should own partner access and offboarding in a loyalty ecosystem?
- How should security teams connect service management with access governance in project-based environments?
- Why do project-driven workplaces create more access governance risk?
