A transition matrix is a control document that defines which governance system is authoritative for each workflow during coexistence. It prevents ambiguity when legacy and new IGA platforms overlap. The matrix should cover requests, provisioning, reviews, lifecycle actions, and reporting so that changes do not conflict or duplicate each other.
Expanded Definition
A transition matrix is the decision record that tells teams which governance system is authoritative for each workflow while two platforms coexist. Its purpose is to remove ambiguity during migration, so the same request, approval, provisioning action, review cycle, or report is not handled twice or by conflicting systems.
In practice, the matrix defines boundaries: which system accepts a request, which system performs the change, which system stores the authoritative status, and which system is read-only during the overlap. That separation matters because coexistence periods often fail at the seams, not in the core platforms themselves. A clear matrix is a coordination control, not a technical integration layer.
Definitions in the industry are fairly consistent, but implementation detail varies. Some teams use a simple spreadsheet, others embed the logic in migration runbooks or governance RACI documents. The common misunderstanding is to treat the matrix as a one-time migration artifact; in reality, it should stay current until the legacy platform is fully retired and the handover rules no longer matter. For a broader governance lens, NIST SP 800-53 Rev 5 Security and Privacy Controls is a useful control reference because it reinforces accountability, auditability, and configuration discipline.
Examples and Use Cases
A transition matrix appears anywhere a security or identity workflow spans old and new control planes. Common examples include:
- During an IGA migration, the matrix states whether access requests are raised in the legacy portal or the new platform.
- For provisioning, it assigns the system that creates or updates accounts so the same entitlement is not issued twice.
- For access reviews, it specifies which platform is the source of truth for certifications and attestation evidence.
- For lifecycle changes, it determines where onboarding, role changes, suspension, and deprovisioning are executed.
- For reporting, it defines which platform produces the authoritative audit trail while both systems remain active.
The main tradeoff is speed versus control. A migration team may want to move every workflow at once, but coexistence is often unavoidable, especially when integrations, audit requirements, or business cutovers lag behind the target platform. In that period, the matrix prevents accidental duplicate approvals, inconsistent entitlements, and reporting gaps.
Where the workflow touches machine-access governance or credential lifecycle, the same logic applies: the matrix should still name a single authoritative system for each action path, rather than allowing both tools to “help.”
Security Implications
Without a transition matrix, coexistence creates control drift. Users may submit requests in one system while approvals happen in another, provisioning may be duplicated, and reviews may miss changes that occurred outside the expected path. That kind of split authority makes audit evidence unreliable and can leave access changes partially completed.
The practical failure mode is ambiguity. When no one can quickly answer which platform owns a workflow, teams tend to improvise, which increases the chance of orphaned accounts, stale permissions, and inconsistent offboarding. In regulated environments, that also weakens defensibility because evidence becomes fragmented across systems.
Failure mechanism: conflicting system ownership allows the same workflow to be executed, logged, or reviewed in more than one place, which breaks the single-source-of-truth model.
Impact: duplicated changes, missed revocations, inaccurate audit trails, and longer exposure windows for access that should have been changed or removed.
For teams handling identity migrations, the matrix is often the difference between controlled coexistence and a silent governance gap. The control is simple, but it only works if ownership is explicit and updated as the migration progresses.
Security, Operational and Governance Implications
A transition matrix matters because migration is not only a technical event, it is a governance state. The matrix forces teams to decide who is authoritative for requests, approvals, provisioning, reviews, lifecycle actions, and reporting while the environment is in flux. That reduces the chance that “temporary” overlap becomes permanent operational confusion.
Operationally, the matrix also supports clean cutover decisions. If a workflow still depends on the legacy system, the matrix documents that dependency instead of letting the team assume the new platform owns it. From a governance perspective, it preserves accountability by making each workflow traceable to one control owner at a time.
A useful practitioner observation is that the matrix should be treated as a living migration control, not as documentation after the fact. If the document is stale, the coexistence period itself becomes the risk. In that sense, the matrix is part of change governance, audit readiness, and cutover discipline at once.
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, NIST SP 800-63 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.OC-01 — Organizational Context | Defines governance ownership for overlapping workflows during migration. |
| Recommendation — Document authoritative workflow owners and decision paths for each coexistence phase. | ||
| CIS Controls v8 | 5.3 — Account Management Lifecycle | Coexistence can create duplicate or stale accounts if ownership is unclear. |
| Recommendation — Assign one system as authoritative for account changes and removals during cutover. | ||
| NIST SP 800-63 | IAL/IAL-related lifecycle guidance — Identity Lifecycle and Assurance | Supports authoritative identity lifecycle decisions across migration states. |
| Recommendation — Keep lifecycle events tied to one authoritative governance process at a time. | ||
| NIST SP 800-53 Rev 5 | CM-2 — Baseline Configuration | Transition matrices document controlled change during platform overlap. |
| AU-2 — Event Logging | Authoritative workflow mapping preserves reliable audit evidence during overlap. | |
| Recommendation — Maintain a controlled migration baseline that specifies which system owns each workflow. Ensure each workflow is logged by the system that owns it during coexistence. | ||
Related resources from NHI Mgmt Group
- When should organizations transition from static to dynamic credentials?
- How should organisations build a segregation of duties matrix for modern IAM programs?
- How do organisations reduce the risk of post-quantum transition?
- Who is accountable for endpoint cryptography in quantum transition planning?
