The business owner of the process should own offboarding, with security enforcing the control and engineering executing the change. If ownership sits only in the platform team, credentials often survive personnel changes, vendor changes, or application retirement and remain valid far longer than intended.
Why Lifecycle Offboarding Needs a Clear Owner
Offboarding is where non-human identity risk becomes operational, because the credential itself outlives the people, vendors, or applications that originally justified it. The owner of the business process should decide when access is no longer needed, while security sets the control requirements and engineering carries out the technical removal. That split matters because platform teams often see the system, but not the business event that should end access. The OWASP Non-Human Identity Top 10 treats stale and over-privileged NHIs as a recurring failure mode, and NHIMG research shows how often cleanup is missed in practice: in the 2025 State of NHIs and Secrets in Cybersecurity, 91% of former employee tokens remain active after offboarding. That is not a tooling problem alone. It is an ownership problem.
Security teams that leave offboarding to infrastructure admins usually discover the gap only after a vendor contract ends, a workload is retired, or an employee changes roles and the credential still works.
How Offboarding Should Work in Practice
Effective offboarding starts with a named business owner for each process that uses a secret, token, certificate, or service account. That owner confirms when the process ends, changes scope, or transfers to another system. Security then validates the required control path, such as revocation, rotation, vault deletion, certificate expiry, or disabling the associated workload identity. Engineering executes the actual change because it owns the implementation details and dependency mapping. This is the practical translation of lifecycle governance: the business decides when, security defines how safely, and engineering performs what must change.
For many organisations, the control workflow should include four checks:
- Identify every place the credential is stored or referenced, including CI/CD, vaults, code, tickets, and secrets managers.
- Confirm the business event that triggers offboarding, such as retirement, role change, contract end, or migration.
- Revoke or expire the credential, then verify that dependent services fail closed rather than silently reusing it.
- Record ownership, timing, and evidence so the offboarding action is auditable.
The NHI Lifecycle Management Guide and the Ultimate Guide to NHIs both reinforce that lifecycle control must be tied to business events, not just technical housekeeping. Where teams still rely on static, long-lived secrets, the guidance from NIST SP 800-63 Digital Identity Guidelines supports stronger lifecycle hygiene, especially when credentials are used as proof of system identity. These controls tend to break down in federated environments with shared service accounts because no single team can see every downstream dependency.
Common Ownership Models and the Edge Cases That Break Them
Tighter offboarding control often increases coordination overhead, requiring organisations to balance speed of decommissioning against the risk of leaving dormant access behind. There is no universal standard for ownership in every org chart, but current guidance suggests the business process owner should remain accountable even when the technical system is delegated to platform or DevOps teams. In practice, that prevents the common failure where a team inherits credentials but no one owns the decision to retire them.
Edge cases need explicit handling. Shared NHIs across multiple applications should not be offboarded by one app owner without confirming every dependency. Vendor-managed integrations often require contractual notice periods, so offboarding should be staged rather than immediate. For service accounts tied to production workloads, the business owner may initiate the change, but engineering must coordinate rotation and replacement before revocation. The Guide to the Secret Sprawl Challenge is useful here because duplicated secrets frequently survive in hidden locations long after the primary system is gone. The operational lesson is simple: offboarding fails when ownership stops at the platform boundary, because the credential often survives in the places nobody checked.
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-03 | Lifecycle cleanup and rotation failures are core NHI risks. |
| NIST CSF 2.0 | PR.AC-4 | Access removal supports least-privilege and timely entitlement revocation. |
| NIST AI RMF | AI RMF governance supports lifecycle accountability for autonomous or automated identities. |
Assign offboarding triggers to process owners and require verified revocation across all secret stores.
