Microsoft Entra ID SMS and Voice MFA Retire February 1, 2027

Microsoft Entra ID administrators should treat the February 1, 2027 SMS and voice retirement as a credential-placement decision, not merely a registration-campaign change. Move most users to phishing-resistant passkeys, Windows Hello for Business, or FIDO2 security keys; reserve customer-managed telecom delivery for documented regulatory or operational exceptions that genuinely require phone service.

User population	Recommended direction
Privileged or highly regulated users	FIDO2 security key or another device-bound passkey
Most users who need portability	Synced passkey
Users on managed Windows devices	Windows Hello for Business or Microsoft Entra passkey on Windows
Populations with a documented no-passkey fit	Evaluate customer-managed SMS or voice

These options are not interchangeable in every environment. Final selection depends on device ownership, portability, shared-device use, credential custody, recovery requirements, and applicable compliance controls.

Why the September prompt is not the deadline​

Starting September 1, 2026, Microsoft plans to make passkeys the default authentication experience for users enabled for SMS or voice. Those users will be auto-enabled for passkeys, and Microsoft’s registration campaign can prompt them to register.
Treat that September change as a migration milestone, not as permission to postpone preparation. The critical enforcement date is February 1, 2027, when Microsoft-provided SMS and voice delivery retires.
The February behavior is narrower than “every user with a phone method will be blocked.” A user whose only available MFA method is SMS or voice must register a passkey during sign-in before continuing. Microsoft states that the registration step will be blocking and that tenants cannot opt out of the February enforcement.
WindowsForum’s reports on Microsoft’s May 2026 changes for personal Microsoft accounts show the same broader direction: Microsoft is steering users away from text-message authentication and recovery toward passkeys, authenticator apps, and verified alternatives. Those consumer-account reports do not define the Entra deployment procedure, but they reinforce why organizations should stop treating SMS as a durable identity strategy.

Build an actionable SMS and voice inventory​

Use a three-part inventory covering policy scope, registered credentials, and actual operational dependence. This is a recommended operating model, not a claim that one Microsoft report provides every required field.
The three populations are related but not identical:

• Enabled: Users included in an SMS or voice authentication policy.
• Registered: Users with a phone method recorded on their account.
• Dependent: Users who lack a suitable replacement or whose business process still requires phone delivery.

A registered phone number does not prove that the user still depends on it. Conversely, a user who rarely signs in may remain exposed even when recent activity shows no phone use.

1. Define the inventory scope​

Begin with all human and nonhuman identities that could be affected:

1. Identify users included in SMS or voice authentication policy scope.
2. Include users who have phone methods registered, even if they appear to have another method.
3. Include privileged, emergency-access, frontline, shared-device, contractor, and infrequently used accounts.
4. Add owners for service-related or tenant-critical identities.
5. Record users who cannot carry a personal device or use a personal credential manager.

Use approved tenant reporting, identity-governance processes, and service-desk records to assemble the list. Do not rely on an unverified third-party script or assume that a single export represents complete dependency.

2. Assess credential readiness​

For each account, determine whether the user has a suitable phishing-resistant method and a separately registered backup method.
Record at least:

• User principal name
• Account status
• Department or business unit
• Manager, sponsor, or service owner
• SMS policy status
• Voice policy status
• Phone method present
• Existing phishing-resistant method
• Second registered method
• Managed, shared, or personal-device restrictions
• Portability requirements
• Recovery owner
• Target persona
• Planned credential
• Telecom exception justification
• Pilot result
• Completion date

Validate the information with business owners and affected users. Authentication records alone may not reveal restrictions such as prohibited personal phones, glove use, shared workstations, remote sites, or tightly controlled physical credentials.

3. Classify dependence​

Assign every account to one of four remediation states:

1. Ready: A suitable phishing-resistant method and second method are registered and tested.
2. Registration required: The target method is known, but enrollment is incomplete.
3. Design required: Device, portability, recovery, or shared-use constraints remain unresolved.
4. Telecom exception candidate: Testing indicates that available passkey approaches do not meet a documented requirement.

Every unresolved record needs a named owner and due date. A spreadsheet without ownership is evidence of discovery, not evidence of remediation.

4. Reconcile and review​

Repeat the inventory during each deployment wave. Look specifically for newly hired users, returning employees, policy changes, dormant accounts, failed registrations, and users who received a replacement device.
Do not remove a phone method merely because a replacement appears in an account record. First verify that the replacement works in the user’s normal sign-in, secondary-device, and recovery scenarios.

Choose credentials by persona​

Microsoft’s persona guidance supports different credentials for different working conditions. WindowsForum’s coverage of Windows-first single sign-on and Windows 11 passkeys likewise highlights that organizations must combine identity policy with the devices users actually operate.

Administrators and highly regulated users​

Prefer FIDO2 security keys or another approved device-bound passkey. These options can provide stronger control over where a credential resides and who possesses it.
Before deployment:

1. Select an approved credential that satisfies organizational controls.
2. Register it with a pilot administrator.
3. Test routine sign-in and privileged workflows.
4. Register a separate backup method.
5. Define issuance, loss reporting, revocation, and replacement.
6. Test emergency access independently.

Do not make an employee’s personal phone or personal synced credential the sole recovery path for a tenant-critical account.

Standard and portable users​

Use a synced passkey where the organization permits the relevant credential manager and users need portability across devices. Register a second suitable method so loss of one device does not automatically become an account-recovery emergency.
WindowsForum’s reporting on passkeys in Windows 11 notes that Windows includes Windows Hello and passkey-management capabilities. That makes Windows a strong deployment surface, but it does not mean every Windows user should receive the same credential architecture.

Managed Windows users​

Evaluate Windows Hello for Business or Microsoft Entra passkey on Windows based on management, compliance, and sign-in requirements.
Test:

1. Enrollment on the managed device.
2. Lock, unlock, and ordinary sign-in.
3. Access to required applications.
4. Device replacement or re-provisioning.
5. Sign-in when the primary device is unavailable.
6. Recovery using the separately registered method.

Windows Hello for Business, Authenticator-based passkeys, synced passkeys, security keys, and Microsoft Entra passkey on Windows solve overlapping problems, but they have different device, custody, and portability characteristics.

Shared-device and frontline users​

Do not assume that a personal synced passkey is appropriate for a shared workstation. Establish:

• Whether every worker has an individual account.
• Whether personal phones are permitted.
• Whether credentials must move between workstations.
• Who owns and replaces credentials.
• Whether a physical security key can be carried safely.
• How recovery works during a shift.
• Whether the actual application workflow supports the selected method.

Pilot against real shift changes and shared-device processes. If no supported passkey approach fits, document the obstruction before considering telecom.

Evaluate customer-managed telecom only for exceptions​

Customer-managed SMS or voice should have a business owner, budget, and expiration review. It should not become the default response to incomplete passkey planning.
For each proposed exception, require:

1. A precisely defined user population.
2. The regulation, contract, accessibility need, or operational constraint.
3. The phishing-resistant alternatives tested.
4. The result of each test.
5. Expected geographic coverage and message demand.
6. Security and procurement approval.
7. A budget owner.
8. A review or expiration date.

Do not describe user preference or resistance to change as an operational impossibility. An exception is justified only when the requirement is documented and the alternative methods have been evaluated in the real environment.

Run a representative pilot​

Build a pilot group that exposes different failure modes:

• A privileged administrator
• A managed Windows user
• A mobile or cross-device worker
• A synced-passkey user
• A FIDO2 security-key user
• A shared-device or frontline worker
• An SMS-only user
• A voice-only user
• A user who cannot use a personal mobile device

For every participant, follow the same ordered test:

1. Confirm identity and current methods.
2. Assign the persona and target credential.
3. Register the target phishing-resistant method.
4. Register a second suitable method.
5. Complete an ordinary sign-in.
6. Test required applications.
7. Test a second-device or unavailable-device scenario.
8. Simulate credential loss.
9. Complete replacement or recovery without depending on Microsoft-provided SMS or voice.
10. Record the result and unresolved issue.

Do not declare success because an enrollment screen appeared. Success means that registration, daily use, loss handling, and replacement all work.

Verification and troubleshooting​

Before closing a user’s remediation record, verify that:

• The intended phishing-resistant method is registered.
• The user can complete normal sign-in with it.
• A second method is independently registered.
• Recovery instructions identify who verifies the user.
• Device loss or security-key replacement has been tested.
• Required applications and shared-device workflows still function.
• Any telecom exception has documented approval and ownership.

If registration fails, check method eligibility, device management state, platform support, and whether the user is following the intended enrollment path. If sign-in succeeds on one device but fails elsewhere, review whether the selected credential is device-bound or portable. If recovery still falls back to phone delivery, redesign the recovery procedure rather than treating the primary registration as complete.
For shared-device failures, reproduce the issue during an actual handoff or shift change. For security-key users, verify spare-key custody and replacement. For privileged users, test emergency access separately from ordinary employee recovery.

Protect recovery and break-glass operations​

A passkey rollout is incomplete when the primary credential works but its loss process does not.
For every persona:

1. Register a phishing-resistant primary method.
2. Register a second suitable method.
3. Document identity verification after device or key loss.
4. Separate normal recovery from privileged emergency access.
5. Test replacement without Microsoft-provided phone delivery.
6. Monitor failures during each rollout wave.
7. Reconcile the inventory after remediation.

Emergency-access accounts require a separately designed and tested procedure. Avoid tying their only recovery path to one employee, one phone, or one device.

Frequently Asked Questions​

Will SMS-only users be locked out on February 1, 2027?​

A user whose only available MFA method is SMS or voice must register a passkey during sign-in before continuing. The blocking registration requirement can cause a practical work stoppage if the user, device, or support process is unprepared.

Is every user with an SMS method blocked?​

Not necessarily. The verified enforcement condition concerns users whose only available MFA method is SMS or voice. That is why administrators must distinguish a merely registered phone method from actual credential dependence.

Can an organization opt out of the February deadline?​

No. Microsoft states that tenants cannot opt out of the February 1, 2027 enforcement. Organizations must migrate affected users or evaluate customer-managed telecom for justified exceptions.

Is Microsoft Authenticator the only replacement?​

No. Available directions include synced passkeys, passkeys in Microsoft Authenticator, FIDO2 security keys, Windows Hello for Business, and Microsoft Entra passkey on Windows. The correct selection depends on device, portability, custody, and compliance requirements.

Should SMS or voice be removed immediately after registration?​

No. First test the primary credential, second method, required applications, device-loss scenario, and recovery procedure. Remove dependence only after the complete workflow succeeds.
Inventory SMS- and voice-dependent users now; assign each user a phishing-resistant credential plus a second registered method; document and approve any customer-managed telecom exception; and complete sign-in, recovery, and replacement testing before February 1, 2027.

---

References​

1. Primary source: learn.microsoft.com
   
   

   Passkeys by default and retirement of Microsoft-provided SMS and voice authentication - Microsoft Entra ID | Microsoft Learn

   Learn how to prepare for the retirement of Microsoft provided SMS and Voice authentication in Microsoft Entra ID and migrate users to passkeys.

   learn.microsoft.com
2. Primary source: WindowsForum
   
   

   Microsoft Phases Out SMS Codes (2026): Passkeys, Authenticator, and Recovery | Windows Forum

   Microsoft has confirmed in May 2026 that it will phase out SMS codes for personal Microsoft accounts, replacing text-message sign-in and recovery with...

   windowsforum.com