User offboarding removes the human account, but NHI access can continue if the person still knows a live secret, token, or key. Revoking NHI access means invalidating the credential that authenticates directly to the resource. In practice, the two actions are related but not interchangeable.
Why these two actions are different
User offboarding and NHI revocation solve different problems because they act on different trust objects. Offboarding a user removes a person’s account or access path, but that does not necessarily invalidate any secret the person already obtained. Revoking NHI access targets the credential itself, so it cuts off the machine, application, or integration even if a human who knew the secret still exists elsewhere in the business.
That distinction matters most when the credential is the real access mechanism. A live API key, token, certificate, or client secret can continue to authenticate directly to a resource after the human account has been disabled, which is why lifecycle and credential control need to be treated separately in NHI lifecycle management and service account security. In practice, offboarding is about the person, while revocation is about the standing authority that still works.
What actually has to be disabled in each case?
For a user, the question is whether the person can still sign in, reach corporate systems, or use delegated access after departure or role change. For an NHI, the question is whether the credential still authenticates successfully, whether it can still call downstream services, and whether any hidden copies of the secret remain in code, vaults, pipelines, or configuration. The control objective is different even when both actions happen on the same day.
The cleanest way to think about it is that user offboarding is a joiner-mover-leaver process, while NHI revocation is a credential and trust-path problem. That is why organisations often need both identity governance and secret lifecycle controls, not just an HR-triggered account closure. The same issue shows up in NHI lifecycle management, where offboarding, rotation, and inventory are separate steps because one does not substitute for the others.
Where the NHI is tightly bound to a specific system, revocation may mean disabling a role, rotating the secret, expiring the certificate, or deleting the token issuer rather than simply closing an account. In other words, the real target is the active authentication path, not the human relationship around it.
Why practitioners should treat them as related but not interchangeable
They are related because the same employee, contractor, or admin may have created, known, or administered the NHI. They are not interchangeable because a human departure does not automatically remove every secret they touched, and a secret rotation does not automatically remove a user’s normal access. In mixed environments, that gap is where orphaned access and stale credentials persist.
Current guidance on machine identity emphasizes inventory, ownership, rotation, and offboarding because the main failure mode is leaving a still-valid secret behind after a human change event. NHIMG’s Top 10 NHI Issues and OWASP Non-Human Identity Top 10 both reflect that the access path, not the person, is what keeps working when revocation is incomplete. That is also why human vs non-human identity is a useful distinction when ownership, consent, and credential custody overlap.
Risk and Threat Considerations
The main risk is residual access: an offboarded person may still know a live secret, or a forgotten token may still authorize production access long after the owner has left. That creates both insider-risk exposure and a clean post-exit attack path if the secret is copied, shared, or stored outside its intended boundary.
Failure mechanism: The human account is disabled, but the underlying NHI credential remains valid, is reused elsewhere, or is not rotated everywhere it was distributed. Attackers or former insiders can then use the credential directly against the resource without needing the human account.
Impact: The organisation can believe access has been removed while the service, API, or workload still accepts authentication. That can lead to unauthorized actions, data exposure, lateral movement, and delayed detection because the activity appears to come from a legitimate machine credential.
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 addresses the attack surface, NIST SP 800-53 Rev 5 and NIST SP 800-57 set the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 — Improper Offboarding | User departure can leave valid NHI secrets behind. |
| NHI-07 — Long-Lived Secrets | Persistent secrets keep working after human offboarding. | |
| NHI-02 — Secret Leakage | Known secrets can remain usable after offboarding. | |
| Recommendation — Revoke or rotate every credential tied to the departed user. Shorten secret lifetime and remove standing credentials. Detect and invalidate exposed secrets during offboarding. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | NHI revocation depends on managing authenticators, not just accounts. |
| AC-2 — Account Management | User offboarding is account lifecycle management. | |
| IA-9 — Service Authentication | Machine credentials authenticate directly to services and must be revoked. | |
| Recommendation — Rotate, revoke, and track authenticators throughout their lifecycle. Disable and remove user accounts promptly at departure. Require service-to-service credentials to be revocable and auditable. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | The question is about separating user access removal from credential revocation. |
| A.8.5 — Secure authentication | NHI revocation depends on invalidating authenticators that still work. | |
| Recommendation — Define and enforce distinct processes for user access and machine credentials. Ensure authenticators can be revoked when access must end. | ||
| NIST SP 800-57 | 1 — General key management guidance | Secrets, keys, and certificates must be retired when access ends. |
| Recommendation — Manage cryptoperiods so keys expire or rotate on schedule. | ||
Practitioner Guidance
What to verify: Treat user departure and NHI revocation as two separate closure checks. Verify that the human account is disabled, then verify that every credential the person could have used, generated, stored, or copied has been rotated or invalidated in each runtime and environment.
Decision rule: If the credential can authenticate directly to a production resource, prioritise revocation and blast-radius reduction before assuming the user offboarding completed the job. If the secret was shared across systems, rotate first, then confirm no dependent integration still requires the old value.
Common mistake: Teams often close the human account and stop there. That leaves long-lived secrets, tokens, or certificates alive in pipelines, scripts, and service configurations, which is why offboarding needs to be coupled to credential inventory and ownership.
Practitioner takeaway: User offboarding ends a person’s access; NHI revocation ends the credential’s authority. When those are not handled separately, organisations remove the actor but leave the access path.
Related resources from NHI Mgmt Group
- What is the difference between rotating a secret and revoking access?
- What is the difference between runtime protection and NHI lifecycle management?
- What is the difference between user access and NHI access in SaaS environments?
- What is the difference between disabling a user in the IdP and fully offboarding access?