The process of moving authentication, user records, and related access controls from one identity platform to another. In practice, it also shifts lifecycle logic, assurance methods, and operational dependencies, so the migration must be managed as a governance change rather than a simple technical transfer.
Expanded Definition
identity provider migration is the controlled transfer of authentication flows, identity records, assurance policies, and access dependencies from one identity platform to another. In NHI security, that usually includes service accounts, workload identities, tokens, certificates, federation trust, and the automation that renews or revokes them. The migration is not just a directory move. It changes how identities are issued, validated, audited, and decommissioned, so it must be treated as a governance event under the principles reflected in NIST Cybersecurity Framework 2.0.
Definitions vary across vendors when the scope includes passwordless sign-in, external identity federation, or workload-to-workload trust. NHI Management Group treats the term broadly because operational risk often appears in the hidden connections: legacy app bindings, SCIM provisioning rules, certificate authorities, and secret distribution paths. A successful migration preserves assurance while reducing privileged drift, not merely preserving login continuity. The most common misapplication is treating identity provider migration as a cutover task, which occurs when teams move human sign-in first and leave machine identities, trust chains, or offboarding logic behind.
Examples and Use Cases
Implementing identity provider migration rigorously often introduces temporary duplication of identity logic, requiring organisations to weigh continuity of access against the cost of parallel controls and extra validation.
- Moving SaaS workforce authentication from one SSO provider to another while preserving MFA policy, conditional access, and account recovery logic.
- Rebinding service accounts and API clients to a new issuer so workloads continue to authenticate without reusing stale secrets, as discussed in the Ultimate Guide to NHIs.
- Transitioning federation from a legacy IdP to a modern platform while maintaining trust with partner systems that depend on SAML, OIDC, or certificate-based trust.
- Migrating directory and lifecycle workflows so joiner, mover, and leaver events still trigger deprovisioning, rotation, and access review in the new control plane.
- Reissuing certificates and rotation schedules after a platform change to avoid broken automation, a pattern that shows up repeatedly in the 52 NHI Breaches Analysis.
For implementation teams, the useful question is not whether users can sign in on day one, but whether the new platform can enforce the same or stronger identity assurance across every dependent workload. Where identity and secret handling intersect, guidance from NIST CSF and NHI migration lessons should be read together.
Why It Matters in NHI Security
Identity provider migration matters because it can silently widen the attack surface if old issuers, dormant accounts, or unrotated credentials remain trusted after cutover. NHI Management Group research shows that 97% of NHIs carry excessive privileges, which means migration can preserve dangerous access unless entitlement mapping is actively redesigned rather than copied forward. When an identity platform changes, every dependent token, certificate, webhook, and automation path becomes part of the security boundary.
Migration failures typically surface as service outages, failed authentication, orphaned secrets, or broken revocation paths. That is why identity provider migration must be aligned with access governance, secret hygiene, and zero trust validation rather than handled as a ticketed infrastructure change. It also creates a practical moment to remove legacy trusts and improve visibility, especially when the original environment had poor inventory quality or incomplete lifecycle control. Organisations typically encounter the business impact only after expired trust relationships, failed rotations, or account misuse are discovered during incident response, at which point identity provider migration becomes operationally unavoidable to address.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC-4 | Migration changes access paths and trust relationships governed by least-privilege access controls. |
| OWASP Non-Human Identity Top 10 | NHI-01 | IdP migration directly affects NHI lifecycle, federation, and identity inventory control. |
| NIST Zero Trust (SP 800-207) | Zero trust requires re-establishing identity assurance and trust after platform changes. |
Inventory every NHI dependency before cutover and verify issuance, rotation, and revocation in the new IdP.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 7, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
