Because they define when access is valid. Onboarding sets the initial scope, offboarding removes residual access, and change management keeps both aligned when roles shift. If those transitions fail, entitlement creep and lingering access become normal operating conditions rather than exceptions.
How onboarding and offboarding set the boundary of valid access
Onboarding and offboarding control programme risk because they determine when an identity should gain access, keep it, or lose it. That boundary is not administrative detail, it is the control plane for entitlement, ownership, and accountability. If joiner and leaver events are handled loosely, access begins to outlive the business need that justified it.
The practical issue is that onboarding is not just account creation. It is the point where access scope, role fit, approvals, and baseline entitlements should be defined together. Offboarding is the mirror image, where access must be removed cleanly, including lingering credentials, tokens, shared access paths, and delegated permissions. For lifecycle depth, see NHI Lifecycle Management Guide and Joiner-Mover-Leaver (JML) Guide.
When people move roles, the same control problem appears in a different form: old access must be withdrawn at the same time new access is granted. If that sequencing is weak, organisations create entitlement creep, excessive privilege, and exceptions that become the norm. Good programmes treat onboarding, mover, and leaver handling as one lifecycle instead of separate ticket flows.
Where control breaks down in the lifecycle
The risk is usually not a single missed deprovisioning event. It is cumulative drift. Each incomplete handoff leaves behind a small amount of residual access, and over time those leftovers become hidden attack surface. That includes orphaned accounts, dormant entitlements, overbroad roles, and credentials that remain valid after the business relationship changes.
Lifecycle failure also shows up when ownership is unclear. If no one can say who approved access, who should remove it, or what evidence proves removal, the programme cannot reliably distinguish valid access from leftover access. In identity programmes, that ambiguity is itself a control failure because it makes review, recertification, and exception handling inconsistent. The broader lifecycle view in IAM and IGA Basics is useful when you need to connect provisioning, entitlement governance, and access review.
Offboarding failures are especially dangerous when access is tied to keys, service accounts, shared accounts, or automation. Those assets do not expire emotionally when a person leaves, they continue to work until revoked. The result is residual access that can persist long after the original business justification has vanished. The breach lesson is clear in Coupang Signing Key Breach, where unrevoked signing key credentials persisted after offboarding.
Why lifecycle control becomes a governance and detection issue
Once onboarding and offboarding are inconsistent, the problem stops being only access administration and becomes governance. Teams lose confidence that inventories are current, reviews are meaningful, and exceptions are truly temporary. That weakens least privilege because the access model no longer reflects the current workforce or operating structure.
This is also why the risk is hard to see from a single incident review. You often need visibility into identity inventory, access recertification, and deprovisioning timeliness to understand whether the programme is functioning. A strong lifecycle process makes those signals measurable, which is what lets security and operations detect drift before it becomes a compromise path. The top-level failure patterns are summarised well in Top 10 NHI Issues, even though the same governance logic applies across many identity populations.
At scale, the operational consequence is that every manual exception becomes a future audit problem. The more integrations, systems, and approvers involved, the more likely it is that onboarding and offboarding will drift apart. A programme controls risk best when it can prove that access starts with a business need and ends when that need ends.
Risk and Threat Considerations
Lifecycle failures create more than housekeeping debt. They expand the time window in which stale access, dormant accounts, or old credentials can be abused, and they make it harder to distinguish legitimate use from lingering access after a role change or exit.
Failure mechanism: Access is granted faster than it is reviewed and removed, so residual entitlements, secrets, or delegated permissions remain valid after the original need has ended.
Impact: Entitlement creep, unauthorised access, lateral movement, and avoidable audit findings become normal programme outcomes rather than exceptional failures.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 sets the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-2 — Account Management | Onboarding and offboarding directly manage account creation, changes, and removal. |
| IA-5 — Authenticator Management | Offboarding must revoke and rotate credentials, tokens, and other authenticators. | |
| AC-6 — Least Privilege | Lifecycle errors cause entitlement creep and residual overprivilege. | |
| Recommendation — Define joiner/mover/leaver workflows under AC-2 and remove access when the business need ends. Apply IA-5 to expire, revoke, or rotate authenticators tied to departing users and roles. Use AC-6 to limit baseline access and prune excess permissions during role changes. | ||
| ISO/IEC 27001:2022 | A.5.18 — Access rights | Access rights must be provisioned, changed, and removed as people move or leave. |
| A.5.16 — Identity management | Identity lifecycle control is central to onboarding and offboarding governance. | |
| Recommendation — Review and revoke access rights promptly when employment or role status changes. Maintain authoritative identity records so joiner, mover, and leaver actions stay aligned. | ||
Practitioner Guidance
What to prioritise: Treat leaver handling, role-change handling, and entitlement review as one process, not three disconnected workflows. The highest-value control is timely removal of access that no longer matches the current business need.
What to verify: For each joiner, mover, and leaver event, verify that the access granted or removed matches an approved source of truth, and that the revocation path covers credentials, sessions, and delegated access where relevant. If the process cannot produce evidence of removal, assume the access may still be live.
Decision rule: If a role change affects privilege, environment, or data sensitivity, remove old access before or at the same time as new access is added. If that order cannot be enforced, treat the change as a higher-risk exception.
Practitioner takeaway: Programme risk falls when lifecycle control is designed to make stale access hard to keep and easy to prove removed, not when teams merely process onboarding tickets quickly.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 6, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org