The user can lose access needed for the new role even though the governance action appears complete. That creates a continuity gap in the identity lifecycle, because the system has changed state without preserving the business entitlement the role requires. In practice, teams need mover workflows that remove obsolete access and assign the replacement entitlement as one controlled change.
When the mover workflow stops at removal
An IGA mover process is not complete when it only subtracts old access. The business state changed, but the entitlement state did not catch up, so the person can be left without the access that the new role actually depends on. That is a lifecycle break in the identity governance and administration model, not just an administrative miss.
In practical terms, the failure is often hidden by the fact that the governance action “succeeded” from a ticketing or approval perspective. The real issue is that mover workflows must treat removal and regrant as one atomic change, otherwise role transitions can create a temporary, or sometimes lasting, entitlement gap.
Why this breaks continuity, not just access
The main problem is continuity of business entitlement. If the new role assumes a baseline permission set, removing the old access without issuing the replacement entitlement can interrupt work, delay approval chains, and force manual workarounds that bypass the intended governance path.
This is why Joiner-Mover-Leaver (JML) workflows need explicit mover logic, not just deprovisioning logic. A mover event is a change of state, and the control objective is to preserve the right access profile while removing what is no longer valid.
At a design level, the workflow should distinguish between obsolete access and replacement entitlement. If those are collapsed into one “remove access” step, the process becomes prone to service interruption, duplicate tickets, and inconsistent manual remediation.
What the entitlement gap usually looks like in operations
Teams usually notice this break when a user cannot enter a system, cannot approve a step they now own, or loses access to a shared application, data set, or administrative function that the new role expects. The visible symptom is a failed task; the underlying issue is a broken lifecycle handoff between role change and entitlement assignment.
The control gap is especially common when role engineering and provisioning are separated. A workflow may correctly remove access from the prior role, but if the replacement entitlement is not mapped, approved, or synchronized, the new role exists on paper while the necessary permissions do not.
Role mining and role design matters here because a stable role model reduces these gaps. If the role catalog does not clearly define the successor entitlement, the mover workflow has nothing consistent to assign.
Risk and Threat Considerations
This is an availability and governance risk more than a pure authorization issue. A bad mover workflow can create avoidable downtime, force exceptions, and leave users temporarily stranded between roles, which is exactly when manual shortcuts and shadow access requests tend to appear.
Failure mechanism: the system revokes the prior entitlement before the replacement entitlement is provisioned, so the user’s access state no longer matches the business role state.
Impact: the user loses required access for the new role, work stalls, and teams may create ad hoc access paths that weaken governance and auditability.
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 NIST CSF 2.0 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 | Mover workflows govern account changes and entitlement transitions. |
| AC-6 — Least Privilege | Replacement entitlements should preserve only the access needed for the new role. | |
| IA-5 — Authenticator Management | Lifecycle changes often affect the credentials that enable role-based access. | |
| Recommendation — Automate account updates so role changes remove obsolete access and add required entitlements. Assign the minimum successor access needed for the new role and avoid manual overgranting. Track credential changes with the same lifecycle discipline as entitlement changes. | ||
| NIST CSF 2.0 | PR.AA-01 — Identities and credentials are issued, managed, verified, revoked, and audited | The issue is a lifecycle failure in issuing and revoking access during role change. |
| GV.OC-03 — Cybersecurity roles, responsibilities, and authorities are established and communicated | Mover handling depends on clear ownership for role and entitlement changes. | |
| Recommendation — Tie mover workflows to verified entitlement issuance and revocation records. Define who owns mover approvals, role mapping, and entitlement assignment. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | The question concerns whether access is preserved correctly across a role change. |
| A.5.18 — Access rights | This is a failure to manage access rights through their lifecycle. | |
| Recommendation — Map mover controls to access control rules that preserve required access during transitions. Review and update access rights when a role changes so replacement entitlements are not missed. | ||
Practitioner Guidance
What to verify: treat every mover as a paired control, not a revoke-only action. Verify that the workflow removes outdated access and assigns the successor entitlement in the same controlled transaction, with exception handling if either side fails.
Decision rule: if the new role has a known entitlement baseline, the mover should not close until that baseline is present or an approved temporary fallback is issued. If the entitlement mapping is ambiguous, stop and fix the role model rather than letting the workflow improvise.
What good looks like: after a move, the user can immediately perform the duties of the new role without manual intervention, and the access trail shows a clean transition rather than a gap, duplicate ticket, or emergency override.
Practitioner takeaway: the real control objective in mover processing is continuity of correct access, not just removal of old access; if the replacement entitlement is missing, the workflow has failed even when the deprovisioning step succeeded.