They should not keep it by default. SMS is a weaker factor with known risks, so the decision should be based on assurance requirements and user experience, not simply on continuity. If the target platform supports stronger options such as TOTP or passwordless, migration is the right time to re-baseline the policy.
Why SMS MFA usually should not survive an identity migration unchanged
Migration is the best time to reset the authentication baseline, because continuity can preserve weak habits that the new platform no longer needs. SMS delivers some coverage, but it also carries SIM-swap, number-porting, interception, and recovery-abuse risks. Teams should judge it against the assurance level the target estate actually needs, not against the old policy they are replacing.
SMS is often retained for convenience, but convenience is not the same as control quality. If the destination platform can support stronger authenticators, such as TOTP, push with number matching, or passwordless and passkeys, the migration is the right moment to move users onto a stronger default and treat SMS as temporary at most.
A team should also separate primary sign-in from recovery. Many organisations discover that SMS is most dangerous not at login, but in account recovery, help-desk resets, and number reassignment scenarios. The right decision is therefore about the whole identity journey, not just the first-factor prompt.
What actually determines the decision
The practical decision hinges on two questions: what assurance the application or workforce segment needs, and what fallback paths remain if the factor fails. For low-risk use cases, SMS may remain a short-lived bridge. For higher-assurance environments, especially those exposed to phishing, remote access, or privileged workflows, SMS should be phased out in favour of stronger methods and tighter recovery controls.
That judgement is easier when you compare methods explicitly rather than treating MFA as one category. NHIMG’s MFA Guide is useful here because it frames SMS alongside stronger factors and shows where bypass patterns matter operationally. It is also the right place to remind stakeholders that an “MFA present” checkbox can hide very different failure modes.
identity migration also changes governance. If you are moving from one identity provider to another, the question is not only whether SMS still works, but whether you want to re-baseline authenticator policy, recovery policy, and exception handling together. That broader view is often what separates a clean migration from a merely successful cutover.
How teams can phase it out without breaking users
The safest pattern is to make SMS an exception path, not the default. Start by identifying populations that can move first, such as employees with managed devices or users already enrolled in stronger factors, then set a deadline for the remaining legacy cases. Keep a documented exception process for users who genuinely lack access to stronger methods, but avoid open-ended grandfathering.
For workforce migrations, a good migration sequence is: establish the new default factor, pre-register stronger methods where possible, verify recovery paths, then disable SMS only after adoption crosses the threshold you have defined. NHIMG’s Workforce Identity Security Guide is a strong reference for that transition because it ties phishing-resistant MFA, account recovery, and session theft into one operational model.
If you need a standards anchor, NIST SP 800-63 Digital Identity Guidelines is the clearest external reference for thinking about authenticator assurance and phishing resistance. The useful takeaway is not that every environment must ban SMS immediately, but that migration is the moment to align policy with the assurance target you actually want to reach.
Risk and Threat Considerations
SMS MFA is exposed to telecom-level abuse, number portability weaknesses, and recovery-channel compromise. During an identity migration, those risks can become more visible because administrators are already changing enrollment, fallback, and exception rules, which creates a natural window for account takeover or support-channel abuse.
Failure mechanism: Attackers exploit SIM swap, SMS interception, phishing that captures one-time codes, or help-desk workflows that reset access based on weak identity checks. Once SMS is accepted as the proofing or recovery step, the attacker can satisfy the factor without owning the user’s real device.
Impact: The result can be account takeover, unauthorized access to email or SSO, and privilege escalation into downstream systems. In a migration, the blast radius can widen if the old SMS path remains enabled while the new platform is being tuned or if recovery rules are not updated at the same time.
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 addresses the attack and risk surface, while NIST SP 800-63, NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-63 | Digital Identity Guidelines | Sets authenticator assurance and phishing-resistant MFA expectations for migration decisions. |
| Recommendation — Use assurance levels to replace SMS with stronger authenticators where the target platform supports them. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | SMS MFA decisions depend on authenticator lifecycle, enrollment, and replacement controls. |
| Recommendation — Manage authenticators so SMS stays temporary and stronger factors become the default. | ||
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | SMS is a weak authentication method with known interception and bypass paths. |
| NHI-07 — Long-Lived Secrets | Migration often exposes long-lived fallback and recovery secrets tied to SMS-based access. | |
| Recommendation — Prefer phishing-resistant authentication over SMS for any high-value identity path. Reduce dependence on legacy recovery factors and rotate away from fragile fallback paths. | ||
| CIS Controls v8 | CIS-6 — Access Control Management | Migration policy should re-baseline access methods and exceptions, including MFA strength. |
| Recommendation — Remove SMS as a default access path and enforce stronger authentication where possible. | ||
Practitioner Guidance
What to prioritise: Decide on the target assurance level before the cutover plan is final. If the new platform supports stronger factors, migrate users directly to that baseline instead of carrying SMS forward as a permanent compatibility layer.
What to verify: Check not only login enrollment, but also account recovery, device replacement, and help-desk reset flows. A control is not trustworthy if SMS still re-enters the process through an exception path.
Common mistake: Keeping SMS “just in case” because it reduces support tickets during the transition. That usually delays the hard decision rather than reducing risk, and it tends to leave a weak factor in place long after the migration is complete.
Practitioner takeaway: Treat SMS as a transitional compatibility choice, not the default outcome of migration; if stronger authenticators are available, the migration should be used to raise assurance and narrow recovery abuse paths, not preserve them.
Related resources from NHI Mgmt Group
- How do organisations decide whether to keep Ingress support during a gateway migration?
- How should organisations decide whether to keep using traditional MFA?
- How should IAM teams decide whether to keep ADFS in their architecture?
- How should security teams decide whether an AI agent gets human or non-human identity?