They often assume one second factor can replace another without changing risk. SMS, TOTP, and passwordless email flows do not provide the same assurance or recovery properties, so the migration must account for user re-enrolment, support load, and policy changes. The right approach is to re-establish assurance, not just preserve login convenience.
Why This Matters for Security Teams
Moving MFA between identity platforms is not a lift-and-shift exercise. Teams often keep the same user-facing prompt while changing the underlying assurance model, recovery path, and enrollment rules. That creates a false sense of continuity: authentication may still “work,” but the security properties can shift materially. Current guidance from the NIST Cybersecurity Framework 2.0 and incident analysis in the 52 NHI Breaches Analysis both point to the same operational lesson: identity controls fail when migration focuses on convenience instead of assurance.
For security teams, the real risk is not simply that users get locked out. It is that fallback paths, enrollment resets, and step-up policies become the new attack surface. A platform swap can also weaken phishing resistance, change who can approve recovery, and create gaps in logging or conditional access enforcement. That is especially dangerous when a legacy factor is replaced with a weaker option under pressure to reduce support tickets. In practice, many security teams encounter abuse of recovery flows only after account takeover has already occurred, rather than through intentional migration testing.
How It Works in Practice
The right migration starts by treating MFA as an assurance chain, not a feature. A team should first map what the current platform actually enforces: factor strength, re-enrolment rules, device binding, backup codes, recovery approvals, and whether the factor survives phishing or SIM-swap abuse. Then it should compare that to the target platform’s real controls, not its marketing claims. For example, SMS, TOTP, push approvals, and passkeys do not provide the same resistance, recovery properties, or auditability.
A practical cutover usually includes:
- Re-enrolling users instead of bulk-transferring factor state, especially when the factor type changes.
- Separating authentication policy from user convenience, so fallback methods do not become the default path.
- Testing step-up rules, device trust, and recovery approvals in the target platform before broad rollout.
- Updating help desk playbooks so identity proofing for resets matches the new platform risk.
- Validating sign-in telemetry and alerting so failed recovery attempts are visible.
For teams building the migration plan, the Ultimate Guide to NHIs is useful as a reminder that identity assurance depends on lifecycle controls, not just initial login. Even though this question is about human MFA, the same lesson applies: credential strength, rotation, and offboarding only matter when the platform actually enforces them. The operational mistake is assuming the old and new platforms are equivalent because both present “MFA” to the user. These controls tend to break down when recovery is delegated to a weak support process because the attacker targets the easiest override, not the strongest factor.
Common Variations and Edge Cases
Tighter MFA migration controls often increase friction, requiring organisations to balance phishing resistance against enrollment overhead and support load. That tradeoff becomes sharper when the source and destination platforms do not support the same factor types or policy logic. Best practice is evolving, but current guidance suggests that a factor should only be preserved across platforms if its assurance level, recovery path, and audit trail remain materially equivalent.
There are also edge cases that change the answer. Regulated environments may need to keep both platforms live during a phased migration so that access reviews and conditional access rules can be validated side by side. Remote-first workforces may need extended re-enrollment windows because device loss, travel, and time zones increase support demand. In passwordless migrations, the biggest mistake is treating email-based fallback as equivalent to strong MFA; it is often just account recovery with a familiar label. Teams should also be careful with privileged users, where platform changes can affect not just sign-in, but admin recovery and break-glass access. The secure path is to re-establish assurance explicitly, then document the new baseline rather than assuming feature parity.
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 SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AA-1 | Identity proofing and auth changes must preserve assurance across platforms. |
| NIST SP 800-63 | Digital identity guidance is central to factor assurance and recovery design. | |
| OWASP Non-Human Identity Top 10 | NHI-03 | Credential lifecycle discipline mirrors the need to re-enrol rather than assume parity. |
Compare old and new MFA methods against assurance and authenticator lifecycle requirements.
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
