Entra ID: Remove SMS MFA Without Scripts

Key insights

• In this video Louis Mastelinck explains why organizations must stop using Entra ID SMS MFA and move to modern methods.
  Microsoft now requires the Authentication methods policy, and legacy MFA/SSPR controls are retiring on 30 September 2025.
• Understand the two different goals: block SMS as a second factor versus block SMS sign‑in (passwordless first factor).
  Treat each separately because the Authentication methods policy controls both availability and the “Use for sign‑in” setting.
• Practical migration steps: migrate off legacy controls, then disable SMS and voice in the Authentication methods policy for the right groups.
  Turn off the “Use for sign‑in” SMS option and scope changes to pilot groups before full rollout.
• Adjust registration and access rules: update the MFA registration policy, remove any requirement to register a phone, and audit Authentication Strengths and Conditional Access policies.
  Ensure policy scope and allowed methods align so users stop being prompted for phones.
• Watch related risks and future options: fix the SharePoint Email OTP guest-access blind spot, enable Azure B2B integration where needed, and evaluate passkeys (device‑bound vs synced).
  Plan defenses against downgrade attacks when moving to passwordless or FIDO2 solutions.
• Post-migration cleanup and troubleshooting: after policies block SMS, remove phone numbers from accounts as appropriate and monitor for leftover prompts.
  Use a “stop the bleed” phased approach, manage user groups for exceptions, and expect edge-case fixes during rollout.

Overview of the Conversation

In a recent YouTube discussion led by Merill Fernando, security consultant Louis Mastelinck outlines a clear plan to remove SMS MFA across organizations using Entra ID. The conversation frames the work as a practical migration rather than a single-script fix, and it stresses that server-side policies are now the authoritative controls. Moreover, the video highlights Microsoft’s shift toward centrally managed, stronger methods such as app notifications and FIDO2 keys. Consequently, administrators are urged to migrate from legacy per-user controls to modern policy frameworks.

Initially, Mastelinck emphasizes the need to “stop the bleed” by preventing new phone registrations while planning user moves to better options like the Authenticator app. He also calls attention to a blind spot with guest access where Email OTP can undermine other protections, and he suggests concrete fixes. In addition, the dialogue covers the evolving role of Authentication Strengths and Conditional Access in enforcing desired behaviors. Overall, the exchange is practical and geared toward operational teams facing real-world constraints.

The Case Against SMS MFA

First, the video reiterates well-known technical weaknesses of SMS verification, including susceptibility to SIM swap attacks and phishing-based interception. As a result, organizations that rely on SMS MFA face persistent threat vectors that stronger second factors largely mitigate. Furthermore, Microsoft’s guidance and product changes make reliance on SMS riskier because legacy controls will stop being supported for management. Therefore, teams must plan to retire phone-based methods to maintain compliance with best practices and product expectations.

However, the programmatic removal of phone-based options introduces tradeoffs between security and user friction, since some users rely on phones for access continuity. Consequently, IT leaders must weigh the immediate security gains against potential help-desk load and account recovery challenges. Moreover, abrupt removals can leave users unable to complete self-service tasks if registration policies still require phone methods. Thus, a careful, staged approach is essential to reduce disruption while improving resilience.

Strategy to Stop the Bleed

Mastelinck and Fernando map out a staged strategy that begins with blocking new phone registrations and disabling SMS and voice in the central Authentication methods policy. Next, they recommend checking the “Use for sign-in” setting to ensure passwordless SMS is not enabled where it is unwanted, since this setting differs from SMS as a second factor. In addition, admins should migrate off legacy per-user MFA and SSPR controls, because Microsoft is deprecating those settings and server-side policies are becoming the authoritative control plane. By taking these initial steps, organizations can prevent new dependency on phone-based methods while keeping existing workflows intact.

Then, the team suggests using scoped policy changes so pilot groups move first and help-desk impact remains manageable. At the same time, communication campaigns and training must accompany technical changes to reduce user confusion and support calls. Moreover, tagging or grouping users aids targeted enforcement through Conditional Access and Authentication Strengths, which help ensure the right users see the right prompts. Ultimately, this balanced approach favors both improved security and smoother operational rollout.

Migration Steps and Troubleshooting

Practically, Mastelinck lays out steps such as auditing conditional access policies, updating MFA registration configuration, and removing stored phone numbers after disabling SMS at policy scope. Additionally, administrators should confirm that no policies implicitly force a phone registration, because such rules would continue to prompt users. When problems arise, he recommends verifying scopes and group membership so that developers and admins do not inadvertently leave windows of exposure. Meanwhile, scripted removal of numbers should only follow policy changes to avoid re-triggering prompts.

Furthermore, the video addresses common troubleshooting scenarios where users still see “Add a phone” prompts despite policy updates, and it explains how to trace those prompts back to legacy settings or registration policy requirements. Therefore, careful auditing of registration and authentication configuration is central to a clean migration. Also, teams should log and monitor authentication events to validate that changes actually stop SMS prompts. By doing so, teams can measure success and iterate when gaps appear.

SharePoint Email OTP and B2B Risks

Importantly, the speakers identify a critical security gap: Email OTP used for SharePoint guest access can circumvent stronger protections and create an identity assurance weakness for external collaborators. Consequently, organizations that enable Email OTP for convenience may expose sensitive resources to weaker authentication flows. To address this, the video recommends enabling Azure B2B integration patterns and aligning guest access settings with tenant-level authentication policies. In other words, guest access requires the same policy attention as internal users to avoid accidental exposure.

Moreover, the discussion highlights the tradeoff between ease of guest collaboration and security assurance, and it notes that governance controls are necessary to protect high-value content. Thus, administrators must decide when convenience outweighs risk and document approved exceptions. Finally, implementing tighter guest controls often requires coordination across business units to avoid interrupting partner workflows. While this coordination takes effort, it significantly reduces attack surface from guest accounts.

Passkeys, Downgrade Defenses, and Tradeoffs

Looking forward, the video contrasts device-bound passkeys with synced passkeys, explaining that device-bound keys offer stronger assurance but less cross-device convenience. Conversely, synced passkeys improve user mobility but increase risk if sync services are compromised, so organizations must balance user experience and threat model. In addition, the hosts discuss how Authentication Strengths and Conditional Access can guide which passkey models are allowed for different user sets, thereby preserving both security and usability. Consequently, designing a passkey rollout requires a careful risk assessment and phased testing.

Finally, Mastelinck and Fernando explore defenses against MFA downgrade attacks, which try to trick systems into using weaker methods like SMS or Email OTP. They recommend coupling policy enforcement with monitoring and user education so that suspicious sign-in flows trigger immediate response. Moreover, organizations should use phishing-resistant methods as the default where possible to reduce the effectiveness of downgrade techniques. Ultimately, while technical controls are central, a combination of policy, monitoring, and training yields the best protection.

Keywords

Disable SMS MFA Entra ID, Remove SMS MFA Azure AD, Turn off SMS 2FA Entra ID, Block SMS authentication Azure AD, Migrate from SMS MFA Entra ID, Entra ID disable SMS OTP, Stop SMS MFA without scripts Entra ID, Replace SMS MFA with passwordless Entra ID