The break is usually not authentication, it is accountability. If approvals, certifications, and entitlement history do not carry forward cleanly, teams lose the ability to prove why access exists and whether it was ever reviewed. That creates an audit gap even when users can still sign in.
What actually breaks when control continuity is lost
When identity governance moves but the surrounding controls do not move with it, the failure is usually in the evidence chain, not the login path. Approvals, certifications, entitlement history, and ownership records stop lining up, so teams can no longer explain why access exists or whether it was ever revalidated. That is why a migration can look operationally successful while governance is already degraded.
Control continuity matters because identity governance is more than provisioning and deprovisioning. It also includes the record of who approved access, what entitlement was granted, which review cycle applied, and when a decision was revoked or renewed. If that history is split across systems or lost during cutover, the organisation may still have working accounts but no trustworthy provenance for them.
This is especially visible when the old and new platforms handle approvals, recertification evidence, and entitlement metadata differently. A team may preserve current access assignments but fail to preserve the context around them, which means auditors, risk owners, and reviewers lose the ability to validate whether access was justified at the time it was granted. The problem is continuity of governance state, not continuity of authentication.
Why accountability is the first casualty
Identity governance exists to make access explainable over time. If the migration drops approval records, reviewer comments, exception notes, or entitlement lineage, the organisation loses accountability even if users can still authenticate normally. That weakens the ability to answer a simple control question: who accepted this access, under what policy, and with what evidence?
For practitioners, the key distinction is between “the account still works” and “the access remains defensible.” The latter depends on preserved ownership, traceability, and review history. In a migrated environment, the most common failure is that the new tool contains today’s access state but not yesterday’s decision trail, which creates gaps in auditability and makes subsequent access reviews less reliable.
Where IAM and IGA Basics explains the relationship between provisioning, access reviews, and entitlement governance, this question is about what happens when those controls are not carried forward as a coherent whole.
What breaks in practice during the migration
The first break is often entitlement lineage. If access is re-created in the target platform without mapping each grant to its original request and approval, the organisation loses the ability to show how a privilege entered the environment. The second break is recertification continuity. A review that was in progress, or recently completed, may no longer be provable if the evidence is not migrated with its full context.
The third break is exception handling. Temporary access, compensating controls, and policy exceptions often live in notes, tickets, or workflow artefacts outside the entitlement record. If those artefacts are not joined back to the migrated identity record, reviewers inherit an access list without the rationale that makes the list governable. That is how a clean technical cutover becomes a messy control gap.
For lifecycle-heavy environments, the most useful anchor is the migration path itself. Joiner-Mover-Leaver (JML) Guide is relevant because control continuity is largely a lifecycle problem: if joiner, mover, and leaver state is not preserved, access histories become incomplete and revocation decisions become harder to defend.
Risk and Threat Considerations
The primary risk is that an organisation ends up with active access but no durable proof of why it exists. That creates audit exposure, weakens segregation-of-duties enforcement, and makes it harder to detect stale or excessive access after the migration.
Failure mechanism: Control artefacts such as approvals, certifications, ownership, and exception history are not mapped cleanly from the source governance model to the target model, so the identity record loses provenance even though authentication still functions.
Impact: Reviewers cannot reliably prove entitlement legitimacy, auditors may treat the population as incomplete, and risky access can persist longer because no one can confidently distinguish authorised access from inherited technical residue.
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 | AU-10 — Non-repudiation | Migrated governance needs proof of who approved or reviewed access. |
| AC-2 — Account Management | Identity governance migration must retain account lifecycle state and ownership. | |
| AU-6 — Audit Record Review, Analysis, and Reporting | Control continuity depends on reviewable entitlement and certification history. | |
| Recommendation — Preserve approval and review evidence so access decisions remain attributable after migration. Carry forward account lifecycle records, ownership, and revocation status during cutover. Verify migrated audit and certification data can still support effective review and analysis. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Access must remain governed and explainable through the migration. |
| A.5.16 — Identity management | Control continuity relies on preserving identity ownership and lifecycle records. | |
| Recommendation — Retain access-control accountability across source and target governance platforms. Map identity records and ownership cleanly into the target governance model. | ||
Practitioner Guidance
What to verify: Before cutover, verify that every migrated entitlement can be traced back to an original owner, approval path, and review outcome. If a control object cannot be reconciled, treat it as an open governance exception rather than a harmless data-mapping issue.
What to prioritise: Preserve the evidence needed to explain access first, then preserve the convenience of the workflow second. If you have to choose, continuity of approval and review history is more valuable than preserving superficial screen parity between platforms.
Practitioner takeaway: A migration is only complete when the governance history survives it; if you cannot prove why access exists after the move, you have replaced control continuity with an audit gap.
Related resources from NHI Mgmt Group
- What breaks when organisations extend legacy identity governance to autonomous systems without changing the control model?
- Why is it important to integrate identity and data governance?
- What breaks when AI agents are given access without identity governance?
- What breaks when microsegmentation is implemented without identity governance?