NHI offboarding is the controlled removal or reassessment of machine credentials when business ownership changes, work ends, or a system is retired. It extends human offboarding concepts to secrets, tokens, certificates, and service accounts that can otherwise remain active indefinitely.
Expanded Definition
NHI offboarding is the end-of-life control point for non-human identity access, covering secrets, tokens, certificates, service accounts, and API keys when an application is retired, ownership changes, or machine access is no longer justified. It is part of the broader lifecycle described in the NHI Lifecycle Management Guide and the Ultimate Guide to NHIs.
Definitions vary across vendors on whether offboarding means only revocation, or also discovery, dependency mapping, and rotation before shutdown. In practice, mature offboarding should verify where the NHI is used, remove standing access, revoke issued credentials, and confirm that downstream jobs, integrations, and automation do not fail unexpectedly. This matters because NHI access is often embedded in pipelines and services rather than attached to a person, so the control must be event-driven, not calendar-driven. The closest external governance anchor is NIST Cybersecurity Framework 2.0, which reinforces access management, asset awareness, and protective handling of credentials.
The most common misapplication is treating NHI offboarding as a ticket closure step, which occurs when teams delete the workload before revoking the secrets, tokens, or certificates it used.
Examples and Use Cases
Implementing NHI offboarding rigorously often introduces dependency-management overhead, requiring organisations to balance faster system retirement against the risk of breaking hidden integrations or leaving credentials active.
- An application is decommissioned, and its API key is revoked only after logs confirm no remaining service calls depend on it, reducing the chance of orphaned access.
- A contractor-owned automation script is transferred to another team, and the associated service account is reassigned, rotated, and documented instead of simply left in place.
- A certificate used by a CI/CD pipeline reaches the end of ownership, and the pipeline is updated before the certificate is disabled so deployment jobs do not stall.
- A cloud integration is migrated to a new secrets manager, and the old token is invalidated after confirming no references remain in code, vaults, or ticketing systems.
- A retired internal tool still has active machine credentials, so the security team uses the lifecycle guidance in the Ultimate Guide to NHIs and validates the shutdown sequence against the access expectations in the NIST Cybersecurity Framework 2.0.
These scenarios are common where ownership changes faster than access inventories are updated. They also map to the recurring failure patterns described in Top 10 NHI Issues, especially when secrets are duplicated across tools and no single team can prove final revocation.
Why It Matters in NHI Security
NHI offboarding is a security boundary, not an administrative nicety. If it is missed, stale service accounts, tokens, and certificates can remain usable long after the business process has ended, creating quiet paths for lateral movement, unauthorized API calls, and supply chain exposure. That risk is especially severe because non-human identities often outnumber human identities and are frequently granted broad permissions.
NHIMG research shows that Ultimate Guide to NHIs — What are Non-Human Identities reports only 20% of organisations have formal processes for offboarding and revoking API keys, while Entro Security found that 91% of former employee tokens remain active after offboarding. That gap explains why offboarding is central to both governance and incident response. It also aligns with Zero Trust thinking, where access must be explicit, short-lived, and continuously revalidated rather than assumed to persist. For operational depth, practitioners should pair the lifecycle view in Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs with the control discipline of 52 NHI Breaches Analysis.
Organisations typically encounter NHI offboarding as an urgent requirement only after a breach, failed audit, or system retirement reveals that credentials were still valid, at which point the term becomes operationally unavoidable to address.
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 Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 | Covers secret and credential lifecycle gaps that offboarding is meant to close. |
| NIST CSF 2.0 | PR.AA | Access management and identity lifecycle controls map directly to NHI offboarding. |
| NIST Zero Trust (SP 800-207) | PA/PE/MA | Zero Trust requires explicit, revocable machine access with no standing trust. |
Revoke, rotate, and verify removal of all NHI credentials during decommissioning and ownership transfer.
