Accountability usually sits across IAM, security operations, and the application owner because each owns part of the lifecycle. HR can trigger the event, but it cannot revoke machine credentials on its own. The control owner must be able to prove that exposed secrets were identified, rotated, or retired.
Why This Matters for Security Teams
When an employee leaves, exposed NHI secrets are not just an HR cleanup issue. The real risk sits in machine credentials that keep working after human access ends, especially API keys, service accounts, and tokens embedded in code, chat, or CI/CD systems. NHI Mgmt Group research shows former employee tokens can remain active after offboarding, and secrets are often duplicated across multiple locations, which makes accountability both broader and harder to prove. See the Ultimate Guide to NHIs and Top 10 NHI Issues for the governance view.
Accountability should therefore be assigned to the control owner who can revoke, rotate, or retire the secret, usually IAM, security operations, and the application owner working together. That aligns with the reality that non-human identities sit outside classic joiner-mover-leaver processes and often outnumber human identities by orders of magnitude. OWASP also treats NHI lifecycle and secret sprawl as core exposure paths in the OWASP Non-Human Identity Top 10. In practice, many security teams discover exposed machine secrets only after offboarding has already happened and the credential has already been used.
How It Works in Practice
The practical answer is to split responsibility by control plane, not by job title. HR can trigger the departure event, but the technical owner must verify what secrets existed, where they were stored, who depended on them, and whether rotation was possible without breaking production. That means inventorying tokens, service account bindings, CI/CD variables, and vault entries, then deciding whether each secret should be rotated, disabled, or replaced with a new workload identity.
Current guidance from the 52 NHI Breaches Analysis and the Anthropic report on AI-orchestrated cyber espionage is that exposed secrets are often exploited quickly once found, so the response window must be measured in minutes or hours, not days. A workable offboarding process usually includes:
- identifying all NHIs linked to the departing employee, including indirect ownership and shared credentials
- revoking standing access first, then rotating secrets that cannot be immediately retired
- checking whether the secret was duplicated in code, tickets, chat, or documentation
- validating that alerts, logs, and ownership records prove the secret was contained
For teams trying to operationalise this, the key is a documented handoff between IAM, SecOps, and the application owner, with one named control owner for each secret class. The control owner is accountable for evidence, even if multiple teams execute the work. These controls tend to break down when secrets are hardcoded into legacy applications because rotation can require code changes, release coordination, and downtime risk.
Common Variations and Edge Cases
Tighter offboarding controls often increase operational overhead, so organisations have to balance speed against service disruption. That tradeoff becomes sharper when the secret supports a production workload, a third-party integration, or a long-lived automation task that was never designed for rapid revocation.
There is no universal standard for this yet, but best practice is evolving toward zero standing privilege, short-lived credentials, and workload identity instead of static shared secrets. In that model, accountability still sits with the control owner, but the design reduces the number of secrets that can survive an employee exit. NHI Mgmt Group’s Guide to the Secret Sprawl Challenge is useful here, because duplicated secrets and hidden copies often make “who owns this?” harder than “how do we rotate it?”.
Edge cases include contractors, break-glass accounts, and shared service identities. Those need explicit ownership, time-bounded access, and a revalidation path after the personnel change. The most mature programs also align with NIST Zero Trust principles and the NIST AI Risk Management Framework when autonomous tooling is involved, because identity and intent must be checked at runtime, not assumed from prior trust. Where teams lack secret inventory, the answer degrades quickly into manual hunting across code, vaults, and collaboration tools, which is unreliable in large hybrid environments.
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 | Secret rotation and offboarding are direct NHI lifecycle controls. |
| NIST CSF 2.0 | PR.AC-4 | Least-privilege and access removal map to post-exit secret containment. |
| NIST AI RMF | Accountability for autonomous systems depends on governance and traceability. |
Assign clear owners and evidence obligations for every secret that powers an AI or automated workload.
Related resources from NHI Mgmt Group
- Who is accountable when inherited NHI credentials remain active after a merger or acquisition?
- Who is accountable when a third-party integration keeps an NHI active after the business need ends?
- Who is accountable when exposed machine secrets are found in a public repository or portal?
- Who is accountable when exposed NHI credentials cause repeated lockouts?
