Treat onboarding and offboarding as lifecycle controls for every identity that can access data, not just employee accounts. Build an inventory of all issued secrets, assign ownership, and require revocation checks across cloud, collaboration, and code systems before access is considered closed. The control objective is verified retirement, not administrative intent.
Why This Matters for Security Teams
Secrets and service accounts are not administrative leftovers. They are live identities that can authenticate, authorize, and move data long after the team that requested them has forgotten why they exist. That is why onboarding and offboarding must be treated as lifecycle controls, not ticket closure. The control objective is verified retirement, supported by inventory, ownership, and revocation evidence. NHI Management Group’s Guide to the Secret Sprawl Challenge shows how quickly unmanaged issuance turns into persistent exposure, while the OWASP Non-Human Identity Top 10 frames lifecycle failure as a core weakness, not a minor hygiene issue.
The risk is not limited to code repositories. Service account credentials also live in tickets, chat, CI/CD systems, and configuration stores, which makes human offboarding logic an incomplete proxy for machine identity retirement. In the 2025 State of NHIs and Secrets in Cybersecurity, 91% of former employee tokens remained active after offboarding, which is a strong sign that manual offboarding processes do not scale across the systems where secrets actually persist. In practice, many security teams discover stale access only after a credential is used outside its intended owner’s employment window.
How It Works in Practice
Effective onboarding starts with assigning every secret or service account a named owner, a business purpose, and a retirement condition. That record should exist in the same governance workflow as the request itself, so a token, API key, certificate, or service account cannot be created without an accountable approver. Current guidance suggests pairing that inventory with asset tags or metadata fields that identify environment, application, platform, and expiry date. The NHI Lifecycle Management Guide aligns with this approach: onboarding should not finish until the identity is traceable, and offboarding should not finish until revocation is verified everywhere the identity could be used.
Operationally, strong lifecycle control usually includes four steps:
- Discover and register the identity at issuance, including shared secrets, deployed certificates, and service accounts created by automation.
- Bind it to an owner, an application, and a deadline for renewal or retirement.
- Propagate revocation across secret managers, cloud IAM, CI/CD runners, collaboration platforms, and code hosting systems.
- Confirm closure with evidence from logs, scans, or API checks rather than relying on the request being marked complete.
This is where the NIST Cybersecurity Framework 2.0 is useful as a governance baseline: identify, protect, detect, respond, and recover all map cleanly to NHI lifecycle work. The practical lesson is that retirement must be technically enforced, because a deactivated business relationship does not automatically deactivate a credential. These controls tend to break down in environments with duplicated secrets, shadow automation, or manually copied credentials because no single system has a complete view of where the identity is still valid.
Common Variations and Edge Cases
Tighter lifecycle control often increases operational overhead, so organisations must balance revocation certainty against developer velocity and platform complexity. That tradeoff is especially visible for shared service accounts, legacy integrations, and third-party connectors, where one “identity” may support several applications and one shutdown can cause collateral outages. Best practice is evolving here, and there is no universal standard for how to retire shared machine identities without disruption.
One useful pattern is to separate human ownership from technical dependency. If a service account is used by multiple teams, the account can still have one accountable owner and multiple registered consumers. That helps prevent the common failure mode where everyone assumes someone else will revoke it. It also makes exceptions easier to govern when a credential must remain active for a migration, archival process, or vendor handoff. NHI Management Group’s Top 10 NHI Issues is a good reference point for understanding why duplication, overuse, and missing ownership repeatedly undermine lifecycle controls.
For organisations with heavy automation, offboarding should include both secret rotation and dependency mapping, because a “deleted” secret may still be referenced in pipelines or configuration templates. In the 2025 State of NHIs and Secrets in Cybersecurity, duplicated secrets and broad token reuse show how easily lifecycle drift accumulates. The hard lesson is that retirement is only real when every system that could authenticate that identity has been checked and closed.
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 CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | Lifecycle failure and stale secrets are core NHI exposure conditions. |
| NIST CSF 2.0 | PR.AC-1 | Access lifecycle governance depends on knowing who or what is authorized. |
| NIST CSF 2.0 | PR.AC-4 | Least-privilege access must be removed at offboarding, not assumed. |
Track every non-human credential from issue to revocation and prove retirement across all systems.
Related resources from NHI Mgmt Group
- How should organisations manage contractor access without creating orphaned accounts?
- How can organisations improve offboarding when accounts live in many systems?
- How should teams reduce the risk of orphaned service accounts and stale tokens?
- What breaks when organisations manage service accounts like human users?
