Yes, when the exiting employee had exposure to automation, cloud operations, or shared credentials. Rotating API keys, certificates, and tokens closes hidden access paths that user deactivation does not reach. If a person influenced a workflow, the workflow credentials should be treated as part of the exit event.
Why This Matters for Security Teams
Employee off-boarding is not just an HR event when the departed person could access automation, cloud consoles, shared inboxes, or deployment pipelines. Deactivating a user account does not invalidate the API keys, certificates, service tokens, or vault references that person may have handled. That is why secret rotation is part of identity cleanup, not an optional hardening step. Current guidance from the OWASP Non-Human Identity Top 10 treats exposed machine credentials as a lifecycle risk, not a one-time leak problem.
The scale of the issue is visible in NHIMG research. In the 2025 State of NHIs and Secrets in Cybersecurity, Entro Security reported that 91% of former employee tokens remain active after off-boarding. That means a large share of organisations are preserving access long after employment ends, even when the human identity has been removed. The practical risk is not only direct reuse by the former employee, but also secondary exposure through shared tools, copied credentials, and undocumented automation paths. In practice, many security teams encounter secret reuse only after a pipeline, script, or integration has already been abused, rather than through intentional access review.
How It Works in Practice
Effective off-boarding should treat secrets like any other privileged asset with an owner, expiry expectation, and revocation path. The first step is to identify where the departing employee had influence: CI/CD systems, cloud IAM, ticketing platforms, chatops, incident response tools, code repositories, and any workflow that used a shared credential. Then classify the credential type. Static keys and long-lived tokens should be rotated immediately. Certificates should be replaced or reissued. Where possible, replace permanent secrets with short-lived, scoped credentials so future exits are easier to contain. The Ultimate Guide to NHIs — Static vs Dynamic Secrets is useful here because the control objective is not just revocation, but reducing the number of credentials that can outlive a person.
Operationally, strong off-boarding includes three tracks:
- Rotate anything the person knew, stored, or could have copied.
- Invalidate any token tied to a shared workflow, even if it was not personal.
- Verify that downstream systems picked up the new secret and no hardcoded fallback remains.
That verification matters because secrets often persist outside repositories. NHIMG’s Guide to the Secret Sprawl Challenge shows how credentials drift into Slack, Jira, Confluence, and similar systems, where off-boarding checklists commonly miss them. For implementation detail, the OWASP Non-Human Identity Top 10 and established workload-identity patterns such as SPIFFE reinforce the same principle: authenticate the workload, not the person who once set it up. These controls tend to break down in environments with undocumented admin access, unmanaged vaults, or ad hoc automation that no one officially owns.
Common Variations and Edge Cases
Tighter rotation often increases operational overhead, requiring organisations to balance risk reduction against service disruption. The tradeoff is especially real in legacy environments, where shared secrets support many applications and one rotation can break several downstream systems at once. In those cases, current guidance suggests moving in phases: first inventory and label the dependencies, then replace the highest-risk long-lived secrets, then eliminate the shared ones that cannot be safely attributed to a single owner.
There is no universal standard for every edge case. A contractor who only touched documentation may not justify broad rotation, but if that person had visibility into deployment keys, incident tooling, or cloud bootstrap credentials, the safer move is to rotate. Likewise, if a secret is stored in a vault but was also copied into a ticket, chat thread, or build log, rotation should include the hidden copies, not only the source record. NHIMG’s NHI Lifecycle Management Guide is a practical reminder that lifecycle controls must cover creation, usage, review, and retirement as one continuous process, not separate events.
For broader breach context, the 52 NHI Breaches Analysis and the Reviewdog GitHub Action supply chain attack both illustrate how quickly one exposed credential can become a wider trust failure. The best practice is evolving toward automatic revocation, short TTLs, and explicit ownership for every workflow secret, because off-boarding is only complete when the access path is gone, not merely undocumented.
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 | Addresses secret rotation and revocation for non-human identities after exposure. |
| NIST CSF 2.0 | PR.AC-1 | Supports access removal and credential lifecycle control during off-boarding. |
| NIST AI RMF | GOVERN | Covers accountability for automation and the secret lifecycle around it. |
Rotate and revoke all workflow secrets tied to a departed employee, then verify downstream replacement.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on May 30, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
