An access onboarding and termination policy defines how identities are granted access and how that access is removed when it is no longer needed. For audit purposes, the policy matters only if it is consistently executed and produces evidence that can be traced across teams and systems.
Expanded Definition
An access onboarding and termination policy sits at the center of NHI lifecycle governance because it defines when a service account, API key, certificate, or agent is allowed to gain access and when that access must be removed. In NHI security, the policy is broader than initial provisioning: it covers approvals, identity proofing for machine actors where applicable, scope assignment, credential issuance, revalidation, deprovisioning, and evidence retention. A useful policy also distinguishes between time-bound access and standing access, then ties each to a documented owner and revocation path.
Definitions vary across vendors on whether onboarding and termination belong to access management, identity governance, or privileged access operations, but the operational outcome is consistent: every grant must be traceable, and every removal must be verifiable. NHI Management Group treats this as a lifecycle control, not a one-time admin task, and aligns it closely with guidance in the OWASP Non-Human Identity Top 10 and the NIST Cybersecurity Framework 2.0. The most common misapplication is treating termination as a ticket closure rather than a complete revocation event, which occurs when credentials, tokens, and downstream entitlements are left active after the owning system or team changes.
Examples and Use Cases
Implementing onboarding and termination rigorously often introduces coordination overhead, requiring organisations to weigh fast service delivery against tighter approval, logging, and revocation discipline.
- A new deployment pipeline receives a short-lived build token only after the workload owner is recorded and the token scope is limited to one repository and one environment.
- A customer-facing agent is onboarded with segmented permissions, then disabled automatically when the linked application is retired, using the process described in Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs.
- An API key used by an integration partner is revoked at contract end, and the termination record is preserved for audit review alongside access logs and approvals.
- A certificate for a production workload is reissued only after the prior certificate is fully retired, reducing overlap and preventing dual-validity confusion.
- A secrets rotation workflow is paired with termination steps so that old credentials do not remain usable in scripts, CI/CD jobs, or cached configuration, a pattern highlighted in the 52 NHI Breaches Analysis and the OWASP guidance.
Why It Matters in NHI Security
This policy matters because NHI access tends to multiply silently, then persist long after business need has ended. NHI Management Group reports that only 20% of organisations have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them, which helps explain why dormant credentials and forgotten entitlements remain common attack paths. That gap is especially dangerous in environments where secrets are stored outside managed vaults or where service accounts are shared across tools, teams, or automation layers.
A strong policy improves Zero Trust execution, supports auditability, and reduces the blast radius when an agent, integration, or vendor relationship changes. It also gives security teams a defensible answer to the question of who approved access, what was granted, and how it was removed. The same lifecycle discipline appears in the Ultimate Guide to NHIs and is reinforced by the Top 10 NHI Issues, especially where excessive privilege and incomplete offboarding intersect. Organisations typically encounter the consequences only after a credential leak, a failed audit, or a post-incident review, at which point the policy becomes operationally unavoidable to address.
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 Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | Covers lifecycle governance for NHI creation, use, and removal. |
| NIST CSF 2.0 | PR.AC-1 | Access provisioning and revocation support identity and access control outcomes. |
| NIST Zero Trust (SP 800-207) | SP 2 | Zero Trust depends on continuous verification and controlled access removal. |
Use policy-driven onboarding and termination to support continuously verified access.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 7, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
