Dual authority creates conflict risk. Requests, provisioning, reviews, and lifecycle events can diverge, leaving one system with one truth and the other with another. That can produce duplicate approvals, missed revocations, inconsistent evidence, and disputes about which record governs. A transition matrix is needed so each workflow has one clear owner at a time.
Why dual authority fails during migration
When a legacy iga platform and a new platform both remain authoritative, the migration stops being a clean cutover and becomes a split-brain control problem. Each system can independently approve, provision, certify, or revoke access, so the same identity event may be interpreted two different ways depending on where it lands. That creates operational ambiguity, audit friction, and a real chance that governance decisions no longer match runtime access.
The practical failure is not just duplication, it is divergence. A role change, joiner event, access review outcome, or termination can be accepted in one system while the other still holds the prior state, which means downstream systems inherit conflicting instructions. In practice, security teams usually notice the mismatch after a user still has access, a reviewer disputes the evidence, or a queue of “successful” tasks does not produce the expected access state.
How the conflict shows up in workflows
Dual authority affects the full identity lifecycle, not just provisioning. If both platforms can create entitlements or manage certifications, then every workflow needs a single source of action, even if data is mirrored in both places. Without that, requests can be approved twice, approvals can be replayed into the wrong system, and revocation can be recorded as complete while the target account remains active elsewhere.
- Provisioning can fork, producing duplicate accounts, duplicate groups, or inconsistent entitlement sets.
- Access reviews can become non-comparable because each platform stores a different approval history or snapshot.
- Offboarding can fail if one platform treats the termination as complete before the other has executed revocation.
- Audit evidence can drift, because the log trail reflects two control planes rather than one governed workflow.
A useful operating rule is to separate system-of-record from system-of-action. One platform may store reference data or historical evidence, but only one platform should trigger the live control decision for a given workflow at any point in time. The NIST SP 800-53 Rev 5 Security and Privacy Controls controls for access control, auditability, and configuration management fit this migration problem because the issue is governance of who can act, when, and under which recorded state. The relevant test is not whether both platforms are technically working, but whether they produce one authoritative decision path per lifecycle event.
In migration programs, the break usually appears when cutover ownership is ambiguous and both teams assume the other system is now only passive history.
Managing exceptions, coexistence, and cutover timing
Tighter control during migration often slows delivery, because teams must coordinate every ownership change and verify each event before decommissioning the old platform. That tradeoff is worth it, since temporary convenience is a poor substitute for unambiguous authority. The hard part is that coexistence can be legitimate for a short period, but it needs explicit scope: one platform owns a named workflow, the other is read-only or downstream only.
Edge cases usually appear where business units are mid-change, integrations are asynchronous, or approvals must continue during a phased migration. In those environments, the safest pattern is to define a transition matrix that names the authoritative owner for each workflow type, environment, and date range. If the matrix is missing, teams tend to improvise local exceptions, and those exceptions become the hidden path by which stale access survives.
For identity-specific migration planning, the Ultimate Guide to NHIs is useful as a reference point for lifecycle discipline, because the same governance problem applies whenever access objects must be rotated, revoked, or retired cleanly. A practical migration should also account for non-human accounts and service credentials that may still be governed by the legacy platform even after human workflows move first. The important judgment is to avoid parallel authority longer than necessary, because every extra day increases the chance that one system becomes the record and the other becomes the reality.
Risk and Threat Considerations
Dual authority creates exposure because stale permissions, missed revocations, and inconsistent approvals can persist longer than intended. The risk is strongest where access decisions are time-sensitive, such as termination, privilege elevation, or periodic recertification, because each platform may believe the other has already completed the control.
Failure mechanism: An attacker or negligent operator only needs one authoritative path to remain active. If the legacy system still provisions or revokes while the new one does the same, the mismatch can preserve access after a supposed offboarding event, or reintroduce access that the newer platform already removed. Conflicting audit trails also make it harder to prove what actually happened.
Impact: The organisation can end up with unauthorized access, delayed containment, inconsistent evidence for auditors, and disputed ownership of identity events. At scale, this weakens both governance and incident response because no team can rely on one coherent record of access state.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0, CIS Controls v8 and NIST SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV — Govern | Migration authority needs explicit governance and ownership rules. |
| PR.AC — Identity Management, Authentication and Access Control | Dual authority directly affects provisioning, revocation, and access state. | |
| PR.DS — Data Security | Conflicting records and evidence are a governance and integrity problem. | |
| Recommendation — Define decision ownership and cutover governance for each identity workflow. Constrain live access decisions to one authoritative control path. Protect identity records so authoritative state stays consistent during migration. | ||
| CIS Controls v8 | 5 — Account Management | IGA migration directly changes how accounts are created, changed, and removed. |
| 6 — Access Control Management | Competing IGA authorities create inconsistent access enforcement. | |
| Recommendation — Centralise account lifecycle actions to one approved system at a time. Remove parallel approval paths and enforce a single access authority. | ||
| NIST SP 800-63 | 3 — Federation and Assertions | Identity assertions and lifecycle events must resolve to one trusted source. |
| Recommendation — Ensure assertions and lifecycle events map to one trusted authoritative record. | ||
Practitioner Guidance
What to prioritise: Assign exactly one authoritative owner per workflow, per phase of the migration. If the same workflow can be executed in both platforms, treat that as a design defect, not a flexibility feature.
What to verify: Confirm that provisioning, access reviews, role changes, and deprovisioning have a single source of action and that the secondary platform is either read-only, reconciliatory, or explicitly downstream. Verify the cutover rules against real test cases, not just migration plans.
Decision rule: If a control outcome can differ between platforms, freeze one of them from making live decisions until reconciliation is complete. Do not allow “temporary” dual write or dual approval to remain after the cutover window closes.
Practitioner takeaway: Migration succeeds when authority is narrowed before it is transferred, because parallel control planes create exactly the kind of ambiguity that identity governance is meant to remove.
Related resources from NHI Mgmt Group
- Why do legacy identity platforms create risk during migration?
- What happens when a legacy application supports access review but not automated removal?
- Why do legacy IGA platforms create governance blind spots in cloud environments?
- Why do legacy IGA platforms fail in cloud and API-driven environments?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 14, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
