Teams should choose based on service dependency. If an NHI supports an active workload, rotate or reassign it in a controlled way; if it is no longer needed, deactivate it. The decision should be driven by operational impact, not by whether the credential was exposed by a person.
Why offboarding should distinguish controlled rotation from deactivation
Offboarding should not be treated as a single revoke-or-delete event. When the credential still supports a live workload, the priority is continuity with control, which usually means rotation, reassignment, or a staged handover. When nothing still depends on it, deactivation is cleaner and reduces residual access. The deciding factor is whether the identity is still operationally bound to an active system.
The practical difference is that rotation preserves service function while breaking the old trust relationship. Deactivation removes the trust relationship entirely, but it can also break jobs, integrations, or downstream automations if the identity is still in use. Teams therefore need a dependency check before they choose the offboarding action, not a reflex based on how the credential was discovered.
For teams managing lifecycle transitions, the relevant control problem is the same one described in NHI Lifecycle Management Guide: know what depends on the identity, then decide whether the right outcome is replacement or retirement. That sequencing matters because a credential can be simultaneously a security liability and a production dependency.
What dependency analysis should answer before you rotate or deactivate
Dependency analysis asks a narrow question: does the workload still need this credential, token, key, or certificate to function safely? If the answer is yes, the team should plan a controlled cutover that preserves service while changing the secret, identity binding, or owner. If the answer is no, deactivation is usually preferable because it closes the access path and avoids leaving a dormant credential behind.
That check is especially important for service accounts, API keys, signing keys, and automation tokens, because they often sit behind multiple applications or pipelines. A clean offboarding decision depends on understanding ownership, call paths, environment scope, and whether the credential is embedded in code, configuration, or secret storage. A credential that appears “owned” by a person may actually be shared by a workload chain.
Good lifecycle practice combines inventory with ownership and usage evidence. The stronger your mapping of what uses the identity, the easier it is to tell whether the right move is lifecycle management for non-human identities or final deactivation. If the dependency picture is incomplete, treat the identity as still active until proven otherwise.
Teams also need to watch for stale assumptions. A removed employee may still leave behind active jobs, scheduled scripts, CI/CD hooks, or third-party integrations that fail only after the credential is turned off. That is why the decision should be tied to service impact, not to the fact that the secret was once exposed by a person.
How to keep offboarding safe without leaving excess access behind
The safest offboarding pattern is to reduce privilege before removal. If the identity must survive, rotate it into a new credential, confirm the workload still authenticates, and then retire the old binding. If the identity does not need to survive, deactivate it and verify there are no unexpected callers, retries, or orphaned processes relying on it.
When offboarding touches long-lived secrets, the main risk is not only disclosure but persistence. A secret that remains valid after the person leaves can continue to authenticate, and a rotated secret that is not actually updated in every dependent system can create hidden outage or fallback behavior. Teams should therefore treat offboarding as both an access-control action and a service-validation step.
Where offboarding intersects with broader identity governance, the issue is often excessive entitlements or invisible reuse. The foundational distinction between reassigning and removing access is well covered in IAM and IGA Basics, while the mechanics of revoking access during leaver processing are addressed in Joiner-Mover-Leaver (JML) Guide. Those controls matter here because the offboarding action should reflect actual service dependency, not just employment status.
Risk and Threat Considerations
Offboarding mistakes usually fail in one of two ways: teams deactivate something that still runs production, or they leave a valid secret in place after the owner is gone. The first creates availability risk, while the second creates lingering unauthorized access and a larger blast radius if the credential is later abused.
Failure mechanism: Incomplete dependency mapping causes teams to retire a credential that is still embedded in a workload, or to keep a live credential active because no one wants to break the service.
Impact: The result can be outage, shadow dependencies that escape review, or an unneeded credential that remains usable long after offboarding, which is the more dangerous condition from a security perspective.
That is why long-lived credentials deserve special scrutiny. OWASP Non-Human Identity Top 10 highlights the recurring problems that make offboarding risky, including weak secret handling, overprivilege, and failed retirement. When a dependency is unclear, the default should be to confirm usage before deactivation, then rotate or retire in a controlled sequence.
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 and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 — Improper Offboarding | Directly covers retirement decisions for non-human identities and their credentials. |
| NHI-07 — Long-Lived Secrets | Rotation vs deactivation hinges on reducing secret lifetime and residual validity. | |
| Recommendation — Map each offboarding case to runtime dependency, then deactivate only when the identity is no longer needed. Shorten secret lifetime and replace long-lived credentials before retiring any exposed or outdated secret. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Offboarding decisions change authenticator lifecycle, rotation, revocation and replacement. |
| AC-2 — Account Management | The question is about deciding whether an account or credential should remain active or be removed. | |
| IA-9 — Service Identification and Authentication | Service and workload credentials must be rotated or retired based on operational dependence. | |
| Recommendation — Revoke or replace authenticators on a controlled schedule that matches workload dependency. Disable accounts when no legitimate use remains, and document exceptions for still-active dependencies. Validate service dependencies before rotating or disabling non-human authenticators. | ||
Practitioner Guidance
What to verify: Before choosing deactivation, confirm where the credential is called from, who owns the workload, and whether any automation, pipeline, or third-party integration will fail if it is removed. Before choosing rotation, confirm every dependent system can accept the new secret on the same cutover path.
Decision rule: If the identity still authenticates a live workload, rotate or reassign first; if it has no legitimate runtime dependency, deactivate it. When in doubt, treat unknown dependencies as active until usage is disproven.
Practitioner takeaway: Offboarding is not “revoke or keep”, it is “preserve service when necessary, otherwise close the access path completely.” The right choice comes from dependency evidence, not from the source of the exposure.
Related resources from NHI Mgmt Group
- What is the difference between rotation and deprovisioning for NHIs?
- How should security teams decide between dynamic secrets and rotation?
- How should security teams decide between disabling MFA and losing backups during a major outage?
- What is the difference between immediate deactivation and login prevention during offboarding?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 6, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org