How should security teams write an access onboarding and termination policy?

Why This Matters for Security Teams

An access onboarding and termination policy is the control that turns identity governance into a repeatable operational process. Without it, access decisions drift into ad hoc approvals, orphaned accounts linger after role changes, and revocation depends on informal follow-through. That is especially dangerous for NHIs, where service accounts, API keys, and tokens often outlive the people who created them. Current guidance from the OWASP Non-Human Identity Top 10 and the NIST Cybersecurity Framework 2.0 both point to lifecycle control as a core governance requirement, not a paperwork exercise.

For security teams, the policy has to define who can request access, who can approve it, what evidence is required, and what triggers immediate or scheduled termination. That includes role changes, contract end dates, project completion, incident response, and system decommissioning. The policy should also state which systems are in scope, since revocation must cover every pathway that can reach data, not just the primary application. NHI Management Group’s Ultimate Guide to NHIs notes that many organisations still lack formal offboarding and revocation processes, which is why access reviews alone are not enough.

In practice, many security teams discover the policy gap only after an account remains active long after a worker or workload has changed.

How It Works in Practice

A workable policy starts with lifecycle stages: request, approval, provisioning, review, change, suspension, and termination. Each stage needs a named owner and a clear trigger. For humans, that might be HR status changes, manager transfers, or termination notices. For NHIs, it may be workload retirement, pipeline deletion, secret rotation failure, or removal of a third-party integration. The policy should require least privilege by default, with access granted only for the current job function or task.

For onboarding, security teams should define minimum inputs for every request: business justification, data classification, target system, duration, approver, and evidence of need. For termination, the policy should require revocation across all connected systems, including identity providers, SaaS apps, CI/CD tools, API gateways, vaults, and any delegated OAuth app paths. The NHI lifecycle guidance in NHI Lifecycle Management Guide is useful here because it frames access as an end-to-end process rather than a one-time ticket.

• Define requesters, approvers, and emergency approvers separately.
• Set review cadence by sensitivity, not by convenience.
• Require evidence capture for approvals, exceptions, and revocations.
• Automate termination triggers where possible, then verify completion.
• Track whether every secret, token, or account was actually invalidated.

For control design, map the policy to the lifecycle and audit expectations in the Ultimate Guide to NHIs — Regulatory and Audit Perspectives, then align the operational language to CSF and identity controls. These controls tend to break down when access is spread across unmanaged SaaS, shadow IT, and embedded secrets because there is no single termination point.

Common Variations and Edge Cases

Tighter onboarding and termination controls often increase operational overhead, so organisations need to balance speed against assurance. That tradeoff is real, especially in engineering environments where rapid deployment and frequent role changes are normal. Current guidance suggests that exceptions should be time-bound, documented, and automatically reviewed, but there is no universal standard for how often every class of access must be revalidated.

One edge case is delegated and third-party access. If vendors connect through OAuth apps or shared admin roles, termination is not just account deprovisioning, it is also token revocation and trust removal across integrations. Another is machine-to-machine access in pipelines, where a human departure may not end the workload lifecycle. In those cases, the policy should distinguish between ownership change and actual service retirement. NHI Management Group’s Top 10 NHI Issues is a practical reminder that excess privilege and weak rotation often combine with poor offboarding to create persistent exposure.

For high-risk systems, best practice is evolving toward shorter review intervals, stronger evidence requirements, and explicit revocation validation. That becomes essential when credentials are embedded in code, infrastructure templates, or shared automation, because termination policy must cover the secret itself, not just the account behind it.

Related resources from NHI Mgmt Group

• How should security teams run access reviews for non-human identities?
• How should security teams govern non-human identities that have persistent access?
• How should security teams govern API keys used for generative AI access?
• How should security teams run user access reviews for FedRAMP compliance?