They should connect onboarding, access review, role changes, and offboarding as one lifecycle rather than separate processes. That keeps entitlements aligned to current job need and prevents access from surviving after the employee’s role changes or ends. The same identity record should drive grant, review, and removal decisions.
How to treat onboarding as a lifecycle, not a one-time event
Onboarding works best when it is treated as the start of an identity lifecycle, not a standalone provisioning task. That means the same employee record should continue to drive access changes as the person moves teams, gains responsibilities, changes employment status, or exits. Joiner-Mover-Leaver (JML) Guide is the clearest operational model for making those transitions repeatable.
The practical shift is from “grant once” to “govern continuously.” On day one, access should reflect the current role; after that, role changes should trigger review and adjustment rather than fresh entitlement sprawl. That lifecycle view reduces the gap between HR reality and system permissions, especially where access is granted through multiple platforms, teams, or delegated approvers.
A single lifecycle model also makes ownership clearer. If the employee record is authoritative, then provisioning, recertification, and deprovisioning all reference the same source of truth instead of three different processes with different timing and different assumptions. IAM and IGA Basics covers why identity governance depends on that connection between access requests, entitlement review, and lifecycle control.
Why role changes matter as much as joiners and leavers
Most lifecycle failures happen in the middle, not just at the start or end. When someone moves roles, keeps a second job function, or switches managers, old access often stays in place because the organisation treats the move as administrative rather than security-relevant. The result is access creep: permissions accumulate faster than they are removed, and the account begins to reflect history rather than present need.
That matters because role changes usually alter both risk and legitimacy. A person may still need some shared systems, but not the same data sets, admin privileges, or workflow rights. The correct response is not to reissue everything from scratch; it is to compare current entitlements with current job need and then remove what is no longer justified. Where leaver or mover handling is weak, stale permissions become one of the easiest ways to preserve unintended access.
IAM and IGA Basics is useful here because it frames access reviews, entitlement management, and joiner-mover-leaver handling as parts of one control system rather than separate admin chores. That is the difference between an access process that looks complete and one that actually tracks job change.
What good lifecycle control looks like in practice
Good lifecycle control is visible when access decisions are tied to events, not memory. A hire, transfer, leave of absence, manager change, or termination should each trigger a known response, with the response differing by event type. The system should not rely on someone remembering to chase access after the fact.
For practitioners, the most useful discipline is to align access review and removal with business events that already exist in HR or identity operations. That reduces delay, makes entitlement decisions auditable, and lowers the chance that old access survives because no one owned the follow-up. NHI Lifecycle Management Guide is broader than employee access, but its lifecycle logic is the same: provision, review, rotate or remove based on change, not convenience.
Offboarding should be treated as a high-confidence removal step, not a best-effort cleanup. If any part of the process depends on manual discovery after departure, the organisation is already exposed to orphaned access and delayed revocation. For that reason, lifecycle design should favour automatic removal for standard access and explicit exception handling only where business continuity genuinely requires it.
Risk and Threat Considerations
When onboarding is not extended into the full lifecycle, access tends to outlive the business reason for it. That creates avoidable exposure from stale entitlements, especially after role changes or departures, and it increases the chance that old access can still be used for sensitive systems, data, or administrative functions.
Failure mechanism: The organisation provisions access at entry, but does not reliably recertify or revoke it when the employee’s role changes or ends. Old privileges remain attached to an identity record that still authenticates successfully, so the account keeps more reach than the current job justifies.
Impact: Unneeded permissions expand blast radius, enable unauthorized use after internal moves or exits, and make compromise harder to contain because the account still carries historical access that no longer matches business need.
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 and CIS Controls v8 set 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 | Employee lifecycle access depends on account creation, changes, review, and removal. |
| IA-5 — Authenticator Management | Lifecycle control must include credential issuance, rotation, and retirement. | |
| Recommendation — Link account state changes to HR events and revoke obsolete access promptly. Manage authenticators through the full employee lifecycle and retire them on exit. | ||
| ISO/IEC 27001:2022 | A.5.16 — Identity management | This subject requires identities to be provisioned, changed, and removed as roles change. |
| A.5.18 — Access rights | Role changes and offboarding require timely review and removal of access rights. | |
| Recommendation — Define an identity lifecycle process that updates access when employment status changes. Review access rights on role change and remove rights when they are no longer needed. | ||
| CIS Controls v8 | CIS-5 — Account Management | Lifecycle onboarding and offboarding map directly to account inventory and removal controls. |
| Recommendation — Inventory accounts, review them regularly, and disable accounts promptly on exit. | ||
Practitioner Guidance
What to prioritise: Build one lifecycle workflow that covers hire, move, review, and exit, and make HR or another authoritative worker record the trigger for each state change. If those events are scattered across ticketing, email, and ad hoc manager requests, the process will drift.
What to verify: Check whether every role change causes an entitlement delta, not just a new access grant. A strong test is whether you can prove which permissions were removed when the job changed and who approved the remaining exceptions.
Common mistake: Teams often focus on rapid provisioning and assume removal can be handled later. In practice, the most damaging lifecycle gap is not slow onboarding, it is access that was never rescinded because the employee became “someone else’s problem” after a transfer or departure.
Practitioner takeaway: The maturity signal is whether access follows the person’s current business need throughout employment, not whether onboarding was completed quickly on day one.
Related resources from NHI Mgmt Group
- How should organisations structure employee IT lifecycle management to reduce access risk across onboarding, role changes, and offboarding?
- What is the difference between runtime protection and NHI lifecycle management?
- How can organisations reduce the risk of stale API keys and machine tokens?
- How should organisations govern authentication across the full lifecycle?