## Why SMS MFA retirement is now a practical IT project
Multi-factor authentication is still one of the highest-value security controls an organization can deploy, but not all MFA methods provide the same protection. SMS text messages and voice calls are vulnerable to SIM swapping, number port-out fraud, social engineering against mobile carriers, MFA fatigue workarounds, and interception in some scenarios. For many cyber insurance questionnaires, compliance reviews, and incident response investigations, the question has shifted from whether MFA exists to whether the MFA method is resistant to modern attacks.
For Microsoft 365 and Entra ID environments, the good news is that organizations can phase out weaker MFA methods without forcing a disruptive overnight migration. The key is to treat the change as an identity engineering project: inventory current methods, prepare break-glass accounts, publish clear user communications, pilot stronger methods, and enforce them with Conditional Access authentication strengths.
This article explains a practical rollout model for retiring SMS and voice MFA in Microsoft Entra ID while reducing the risk of user lockouts. It is written for IT managers, MSPs, nonprofit technology leaders, and hands-on administrators who need a safe plan rather than another generic MFA checklist.
## What you are trying to achieve
The goal is not simply to disable texting. The goal is to ensure that sign-ins to important cloud resources require an authentication method appropriate to the risk of the session.
In a mature rollout, you usually want three outcomes:
1. Users can no longer satisfy MFA with SMS or voice calls for normal Microsoft 365 access.
2. Administrators and privileged roles use stronger methods such as FIDO2 security keys, certificate-based authentication, Windows Hello for Business, or Microsoft Authenticator number matching.
3. The organization has a documented recovery path if Conditional Access is misconfigured or a user loses a device.
Microsoft Entra ID supports this through authentication methods policies, Conditional Access, and authentication strengths. Authentication strengths let you define which MFA methods are acceptable for a given policy. Instead of merely requiring MFA, you can require phishing-resistant MFA for admins or require passwordless MFA for sensitive apps.
## Start with prerequisites and licensing reality
Before building policies, confirm which features are available in your tenant. Conditional Access generally requires Microsoft Entra ID P1. Some advanced identity governance, risk-based controls, and reporting capabilities may require higher licensing. Many Microsoft 365 Business Premium tenants include the core controls needed for a strong SMB rollout, but assumptions are dangerous. Verify licensing before you communicate deadlines to users.
You should also confirm that modern authentication is in use. Legacy protocols such as POP, IMAP, SMTP AUTH, and older Office clients can bypass or complicate MFA enforcement. If your organization still depends on legacy authentication, address that before making major MFA changes.
At a minimum, prepare the following:
– Two emergency access accounts excluded from Conditional Access
– At least one phishing-resistant method tested for global administrators
– A pilot group with technically comfortable users
– A user communication plan with screenshots
– A help desk process for lost phones and method resets
– Audit logging and sign-in log review access
## Protect emergency access accounts first
Every Conditional Access project should begin with emergency access planning. A break-glass account is a highly protected cloud-only account used only when normal administrative access is broken. It should not use the same MFA dependency that your Conditional Access policy might accidentally block.
Recommended characteristics include:
– Cloud-only account, not synchronized from Active Directory
– Long, randomly generated password stored in a secure offline or privileged vault process
– Excluded from Conditional Access policies
– Assigned only the roles absolutely required for recovery
– Monitored aggressively for any sign-in attempt
– Tested on a schedule
A common pattern is to create two emergency accounts so that one can be recovered if the other has a problem. These accounts should not be used for daily administration.
You can monitor break-glass sign-ins with a simple scheduled review in the Entra admin center, or with Microsoft Sentinel if available. If you use Sentinel, a basic KQL query might look like this:
“`kusto
SigninLogs
| where UserPrincipalName in~ (‘[email protected]’, ‘[email protected]’)
| project TimeGenerated, UserPrincipalName, IPAddress, AppDisplayName, ConditionalAccessStatus, ResultDescription
| order by TimeGenerated desc
“`
If these accounts ever sign in outside a planned test, treat it as a security event.
## Inventory current authentication methods
Do not guess how many users still rely on SMS. Inventory first. In the Entra admin center, review authentication methods registration and user registration details. For automation, Microsoft Graph PowerShell can help export registered methods.
Install and connect with the Microsoft Graph PowerShell SDK:
“`powershell
Install-Module Microsoft.Graph -Scope CurrentUser
Connect-MgGraph -Scopes User.Read.All, UserAuthenticationMethod.Read.All
“`
Then export each user’s registered methods:
“`powershell
$users = Get-MgUser -All -Property Id,DisplayName,UserPrincipalName,AccountEnabled
$results = foreach ($user in $users) {
$methods = Get-MgUserAuthenticationMethod -UserId $user.Id
foreach ($method in $methods) {
[PSCustomObject]@{
DisplayName = $user.DisplayName
UserPrincipalName = $user.UserPrincipalName
AccountEnabled = $user.AccountEnabled
MethodType = $method.AdditionalProperties[‘@odata.type’]
}
}
}
$results | Export-Csv .\entra-auth-methods.csv -NoTypeInformation
“`
The exported method type values are not always friendly, but they are useful. For example, phone methods, Microsoft Authenticator methods, FIDO2 methods, and Windows Hello methods are distinguishable. Use this data to identify users who have only phone-based MFA and would be locked out if SMS were blocked immediately.
For a quick count by method type:
“`powershell
$results | Group-Object MethodType | Sort-Object Count -Descending | Select-Object Count, Name
“`
This inventory should drive the rollout schedule. If 70 percent of users still have only phone methods, the project is not ready for enforcement.
## Decide which methods you will allow
There is no single correct MFA standard for every organization. A law firm, manufacturer, hospital, church, and software company may have different risk profiles and support constraints. The important decision is to separate stronger, acceptable methods from methods you are intentionally retiring.
A pragmatic target state for many SMB and nonprofit tenants is:
– Allow Microsoft Authenticator push with number matching for standard users
– Encourage passwordless Microsoft Authenticator where appropriate
– Require FIDO2 security keys or Windows Hello for Business for administrators
– Disable SMS and voice as usable MFA methods after migration
– Keep temporary access pass available for controlled recovery workflows
For higher-risk environments, use phishing-resistant MFA for privileged users and sensitive applications. Phishing-resistant methods are designed to prevent credential replay against fake sign-in pages. FIDO2 security keys are a strong option because the authentication is bound to the legitimate site.
## Configure authentication methods policy
Authentication methods policy controls which methods users can register and use. Conditional Access controls when and where those methods are required. You usually need both.
In the Entra admin center, go to Protection, then Authentication methods. Review each method and scope it carefully. Instead of enabling everything tenant-wide, use groups:
– MFA-Authenticator-Allowed
– MFA-FIDO2-Allowed
– MFA-SMS-Temporary
– MFA-Passwordless-Pilot
During migration, you may temporarily allow SMS for users who have not completed registration. Once the migration window closes, remove users from the SMS-allowed group or disable the method entirely.
If you support FIDO2 security keys, document key models, PIN requirements, attestation settings, and replacement procedures. Avoid letting users purchase random keys without guidance. Standardizing on a few supported models simplifies help desk support.
## Use authentication strengths instead of plain MFA
A traditional Conditional Access policy says: require MFA. The problem is that SMS can satisfy that requirement if it remains enabled. Authentication strengths solve this by specifying which methods count.
Microsoft provides built-in authentication strengths, and you can create custom strengths. For example, you might use:
– Multifactor authentication for broad baseline access
– Passwordless MFA for sensitive applications
– Phishing-resistant MFA for administrators
A phased approach might look like this:
### Phase 1: Report-only policy
Create a Conditional Access policy in report-only mode:
– Users: pilot group or all users, excluding emergency access accounts
– Cloud apps: Office 365 or selected apps
– Conditions: start broad, avoid overcomplicating the first policy
– Grant: require authentication strength that excludes SMS
– Mode: report-only
Report-only mode lets you see what would have happened without blocking users. Review the Conditional Access insights and sign-in logs for failures.
### Phase 2: Pilot enforcement
Enable the policy for a pilot group. Choose users from multiple departments and device types. Include at least one remote worker, one mobile-heavy user, and one person who uses shared or frontline workflows if applicable.
Run the pilot for at least one business cycle. For some organizations, that means a week. For accounting firms, it might mean a month-end close. The goal is to catch real-world exceptions before broad enforcement.
### Phase 3: Department waves
Move users into enforcement groups in waves. A typical schedule might be:
– Week 1: IT and security-aware users
– Week 2: finance and leadership
– Week 3: operations and office staff
– Week 4: remaining users and exceptions
Do not make the final SMS disablement date the same day as your first broad Conditional Access enforcement. Give users time to register stronger methods.
## Example Conditional Access design
A clean Conditional Access design is easier to troubleshoot than a pile of overlapping policies. For many tenants, the following structure works well:
### Policy A: Block legacy authentication
– Users: all users, excluding emergency access accounts
– Client apps: legacy authentication clients
– Grant: block access
This prevents old protocols from bypassing modern controls.
### Policy B: Require approved MFA for Microsoft 365
– Users: all standard users, excluding emergency access accounts and service accounts
– Cloud apps: Office 365
– Grant: require authentication strength that excludes SMS and voice
– Session: sign-in frequency based on business need
### Policy C: Require phishing-resistant MFA for admins
– Users: directory roles such as Global Administrator, Privileged Role Administrator, Exchange Administrator, SharePoint Administrator, and Security Administrator
– Cloud apps: all cloud apps
– Grant: require phishing-resistant authentication strength
### Policy D: Require stronger controls for risky access
If licensed and appropriate:
– Conditions: high sign-in risk or high user risk
– Grant: require password change or strong authentication
– Mode: start report-only
The important principle is that admin requirements should be stronger than standard user requirements. A compromised administrator can do far more damage than a compromised mailbox.
## Handle service accounts and automation safely
Service accounts are often where MFA projects get messy. A legacy script using basic authentication, an SMTP relay account, or an old scanner mailbox can derail a rollout.
First, determine whether the account is truly a user account. Many automation workloads should move to app registrations, managed identities, certificate-based authentication, or vendor-supported OAuth flows.
For accounts that cannot use MFA, avoid broad exclusions. Instead:
– Restrict by source IP where possible
– Limit permissions to the minimum required
– Use separate accounts per workload
– Monitor sign-ins
– Set strong, rotated credentials or certificate-based auth
– Document the business owner and retirement plan
An exclusion without monitoring becomes permanent technical debt. If an account must be excluded from a Conditional Access policy, record why, who approved it, and when it will be reviewed.
## Prepare users before enforcement
Technical controls fail when communication is poor. Users need to know what is changing, why it matters, and what they should do before the deadline.
A good user message includes:
– A plain-language explanation that text-message MFA is being retired because attackers can bypass it
– The approved replacement methods
– A registration link, such as https://aka.ms/mfasetup
– Screenshots for Microsoft Authenticator setup
– The deadline for each department
– Help desk contact information
– A warning that IT will never ask for their MFA code
Avoid framing the change as an inconvenience imposed by IT. Explain the business reason: protecting payroll, donor records, client data, email, and cloud systems from account takeover.
## Use Temporary Access Pass for recovery
Temporary Access Pass, or TAP, can be extremely helpful during migration and recovery. It lets an administrator issue a time-limited pass that allows a user to register or recover authentication methods.
Use TAP with guardrails:
– Limit who can create a TAP
– Set short lifetimes
– Require identity verification before issuance
– Record the ticket number or approval reason
– Do not send TAP values over insecure channels
A typical help desk workflow is:
1. User calls because they replaced a phone.
2. Help desk verifies identity using documented procedures.
3. Help desk issues a short-lived TAP.
4. User signs in and registers a new approved method.
5. Help desk confirms successful registration and closes the ticket.
This is much safer than leaving SMS enabled forever as a recovery crutch.
## Monitor the rollout
During enforcement, review sign-in logs daily. Look for Conditional Access failures, repeated interrupted sign-ins, and users falling back to older methods.
Useful questions include:
– Which users failed because they did not have an acceptable method?
– Which applications are generating unexpected prompts?
– Are mobile users failing more often than desktop users?
– Are any service accounts affected?
– Are administrators consistently using phishing-resistant methods?
If you export logs to a SIEM, create alerts for policy failures involving executives, administrators, and break-glass accounts. If you do not have a SIEM, schedule manual checks during the rollout window.
## Common mistakes to avoid
### Disabling SMS before registration is complete
This is the classic lockout scenario. Inventory first, then communicate, then pilot, then enforce.
### Excluding too many users
Every exclusion weakens the project. Use groups, document exceptions, and review them frequently.
### Treating all MFA as equal
A text message and a FIDO2 security key are not equivalent. Use authentication strengths to reflect that difference.
### Forgetting mobile and frontline workflows
Shared devices, field staff, and users without corporate smartphones need special planning. Security keys, Windows Hello for Business, or managed shared-device models may be better than app-based MFA for some groups.
### Ignoring administrator accounts
Privileged accounts should move first, not last. If attackers compromise an admin account, they can weaken the very policies you are trying to enforce.
## Practical summary and key takeaways
Retiring SMS MFA in Microsoft Entra ID is one of the most practical identity security improvements an organization can make, but it should be done deliberately. The safest path is to inventory current methods, protect emergency access, pilot stronger authentication, enforce with Conditional Access authentication strengths, and monitor the results.
Key takeaways:
– SMS and voice MFA are better than no MFA, but they are no longer strong enough for many environments.
– Authentication strengths let you require better methods instead of simply requiring any MFA.
– Break-glass accounts must be created, excluded, monitored, and tested before policy enforcement.
– Use report-only Conditional Access policies before broad rollout.
– Temporary Access Pass is a better recovery tool than leaving SMS enabled indefinitely.
– Privileged users should be held to a higher standard, ideally phishing-resistant MFA.
– Service account exclusions should be rare, documented, restricted, and monitored.
For SMBs and nonprofits, this project does not need to be overwhelming. With a phased plan and clear communication, you can reduce account takeover risk significantly without creating a flood of lockouts or help desk tickets.
