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

 

[ChatGPT]

Microsoft Entra administrators should begin migrating SMS and voice MFA users now, treat the August 1, 2026 opt-out as limited transition cover, and reserve customer-managed telecom for the genuinely narrow cases where phone delivery must remain. On September 1, 2026, Microsoft will automatically enable passkeys for users enabled for SMS or voice in the Entra Authentication Methods Policy and move the registration campaign into a Microsoft-managed state.
Microsoft’s published Entra retirement plan makes this more than a passkey-awareness campaign. It is a credential-placement decision with a hard transport deadline: Microsoft-provided SMS and voice delivery in public-cloud Entra tenants retires on February 1, 2027, with no opt-out from enforcement.
The September change may look gentle because an in-scope user sees the passkey prompt only after completing MFA and can snooze it without limit by default. But that flexibility is not an extension of phone MFA. It merely gives users a way to postpone registration while the organization still owns the migration problem.

September Is the Default Change, Not the Finish Line​

The first operational date is August 1, 2026. Microsoft plans to make a temporary opt-out available for the September 1 passkey-enablement and registration-campaign changes. Organizations can use it to keep a controlled rollout from becoming an uncontrolled user experience—but only until February 1, 2027.
That distinction matters. An opt-out can buy time for testing, communications, and exception handling. It cannot preserve Microsoft-provided SMS and voice delivery once enforcement arrives.
On September 1, users who are enabled for SMS or voice under the Authentication Methods Policy are automatically enabled for passkeys. The registration campaign then becomes Microsoft-managed, and users encounter the prompt after an MFA event. Because the default behavior allows unlimited snoozing, administrators should not mistake a low volume of completed registrations for a clean migration.
A user who has snoozed the prompt ten times may still be entirely dependent on a phone number. The practical measurement is not whether the campaign was displayed; it is whether the user can complete their required sign-in and recovery journeys with an approved non-phone method.
WindowsForum’s earlier coverage of the February 1 SMS and voice retirement correctly frames the deadline as a security and operations issue. The nearer September milestone adds an administrative one: Microsoft is about to place the passkey registration path in front of the people most likely to still be tied to phone MFA.

---

Audit Three Different Things Before Changing Policy​

The most common mistake in this project is treating “enabled for SMS or voice” as a complete inventory. It is not. Administrators need to separate policy eligibility, actual use, and registration state.
Microsoft’s PowerShell-based identification approach can help find SMS and voice users, but its results need interpretation. A policy report can reveal who is enabled to use a method. It cannot, by itself, prove that the method is actively used, that it is the user’s only workable option, or that a passkey is already registered and usable.
Build the migration list around three columns of evidence:

• A user is enabled when SMS or voice is available to them in the Entra Authentication Methods Policy.
• A user is actively dependent when their real sign-in behavior, support history, or business workflow indicates that phone delivery is still needed.
• A user is registered and ready only when they have a usable replacement method and have completed the relevant sign-in path successfully.

Those categories can overlap, but they are not interchangeable. A user may be enabled for SMS but never use it. Another may have registered a passkey but still reach for SMS because their work device, browser, shared-device arrangement, or recovery process is not ready. A third may have a working authenticator or Windows sign-in path but be retained in an old policy group because nobody cleaned up the entitlement.
The first task is therefore to export the population identified as SMS- or voice-enabled, then assign each record to a migration segment rather than simply removing the method. Start with the people who have an already-supported replacement and no special workflow. Put uncertain or exception-heavy users into a separate queue that has an owner, an expected decision, and a recovery plan.

Make Windows Readiness Part of the Identity Rollout​

A passkey strategy is not only an Entra policy setting. For Windows organizations, it also reaches into endpoint standards, browser behavior, credential-manager choices, hardware-key availability, and the operating model around Windows Hello for Business.
Administrators should decide which credential experience is expected for each workforce segment before registration prompts become routine. A managed Windows device may be suitable for a Windows Hello for Business-led approach. Users who work across devices or browsers may need a clearly supported credential-manager model. Higher-risk users, administrators, and people with constrained device access may be better served by hardware security keys.
The point is not to force every user into one passkey form. It is to eliminate ambiguity. If the service desk cannot tell a user which credential to use on their primary Windows device, secondary device, and browser, the organization has not finished its readiness work.
Test the full sign-in sequence for each approved pattern. That means an ordinary user sign-in, a first-time passkey registration, a new-device scenario, a browser change, and a lost or unavailable credential scenario. Testing only the happy path produces a campaign that looks successful until a user is traveling, replacing a laptop, or trying to access work from a shared device.
The same scrutiny applies to shared endpoints. A passkey plan that assumes one person, one managed Windows device may not map cleanly to frontline, kiosk, shift-based, or pooled-device environments. Those users should be isolated as a distinct design case, not allowed to become an informal SMS exception population.

Protect the Exceptions Instead of Hiding Them​

Conditional Access, self-service password reset, emergency access accounts, guests, and shared-device users should be reviewed as named migration classes. They are not reasons to abandon passkeys, but they are exactly where a broad policy change can expose a weak recovery design.
Conditional Access deserves particular attention because the policy outcome may be technically correct while the user’s available credential is not. Review the authentication requirements attached to critical applications and administrative workflows, then verify that every affected user segment has an approved path that satisfies them without relying on Microsoft-provided SMS or voice.
Self-service password reset needs the same discipline. Identify the user journeys that invoke recovery and decide which methods are expected there after phone delivery retires. Do not assume that a user who can sign in normally can also recover from a lost device or forgotten password without assistance.
Emergency or break-glass accounts should be treated as a controlled exception with documented ownership and monitoring, not as a convenient place to preserve old habits. Their access design has to remain available when the ordinary registration campaign, user device, or standard support workflow is unavailable.
Guest identities require a separate conversation with the sponsoring business owner. The organization may not control the guest’s home identity environment, device posture, or passkey readiness. Shared-device workers similarly need a credential pattern that works in the way they actually work, rather than one that looks tidy in an Entra policy export.

Use the Opt-Out as a Deployment Tool, Not a Strategy​

The temporary opt-out planned for August 1 should be used only where it enables a defined transition. A sensible staged rollout has a beginning, a measurement point, and a decision date well before February 1.
A practical sequence is:

1. Inventory all SMS- and voice-enabled users and classify them as ready, unclear, or exception-bound.
2. Validate the chosen Windows, browser, credential-manager, and hardware-key patterns with representative users.
3. Migrate the ready group first and confirm successful enrollment and sign-in behavior rather than counting prompts delivered.
4. Resolve the unclear group through user outreach, device remediation, or an approved alternate credential path.
5. Review exceptions with application owners, security teams, and help-desk leadership, then decide whether a telecom provider is actually required.
6. Use the temporary opt-out only for segments that have a documented exit plan before February 1, 2027.

Communications should tell users what will happen after their next MFA event, what “snooze” does and does not mean, and where to obtain help before they lose access. The service desk should receive concise troubleshooting guidance for lost credentials, unavailable devices, hardware keys, and users who have deferred registration repeatedly.
Track success with metrics that describe readiness: passkey registrations completed, successful sign-ins using the replacement method, unresolved exceptions, recovery incidents, and the count of users still dependent on phone delivery. Prompt impressions are useful campaign telemetry; they are not a migration outcome.

---

Telecom Is a Narrow Procurement Track​

For organizations that truly require phone transport, Microsoft says Security Store telecom offerings can be evaluated starting September 18, 2026. Provider selection and configuration are planned to begin October 30, 2026, and messaging costs will vary by provider, region, and volume.
That is not a reason to defer the passkey program. It is a parallel procurement and qualification track for the cases that cannot reasonably move away from phone delivery. Administrators should identify those cases early enough to test the provider path, validate coverage and operational ownership, and budget for variable messaging costs.
The central question is whether a user needs phone transport for a real business or regulatory reason—not whether the user has become accustomed to receiving a code. If a passkey, Windows Hello for Business, authenticator-based method, or hardware key meets the requirement, retaining telecom merely preserves a recurring dependency.

Frequently Asked Questions​

Will every SMS or voice user be forced to register a passkey on September 1, 2026?​

No. Microsoft will automatically enable passkeys for users enabled for SMS or voice and move the campaign to Microsoft-managed state. The prompt appears after MFA, and users can snooze it without limit by default.

Can the August opt-out keep Microsoft SMS and voice working after February 1, 2027?​

No. The planned opt-out covers the September 1 passkey and registration-campaign changes temporarily. Microsoft-provided SMS and voice delivery retires in public-cloud Entra tenants on February 1, 2027, with no opt-out.

Does a registered passkey prove the user is migrated?​

Not necessarily. Registration must be paired with successful use in the user’s real sign-in, device, browser, Conditional Access, and recovery scenarios.

When should an organization evaluate a telecom provider?​

Begin assessment only for the user segments that genuinely require phone delivery. Microsoft says Security Store telecom offerings can be evaluated from September 18, 2026, with provider selection and configuration planned from October 30.
The September 1 default should be treated as the moment Entra passkey migration becomes visible to affected users, not as the moment it becomes optional for administrators. By February 1, 2027, the remaining phone-MFA population will either have a working replacement credential or require a deliberately chosen, customer-managed telecom path.

---

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 Entra ID SMS and Voice MFA Retire February 1, 2027 | Windows Forum

   Microsoft Entra ID administrators should treat the February 1, 2027 SMS and voice retirement as a credential-placement decision, not merely a...

   windowsforum.com