Microsoft SMS and Voice Retirement: Check Affected Users and Plan the Change
The September 2026 registration changes are underway. Microsoft-provided SMS and voice delivery retires from February 1, 2027. Check policies, usage, devices and recovery methods before deciding who needs to move.
AZ / decision fieldnote
Registration is not the same as readiness.
Authentication-method change / user readiness
Inventory methods
Identify affected users and registered alternatives
Prepare the change
Align policy, registration and communication
Validate sign-in
Check users can complete the required authentication
Use this in your decision
Demonstrate that affected users can sign in under the target policy.
- Who depends on the methods being changed?
- Which alternative works with the target policy?
- What evidence demonstrates readiness before enforcement?
Reading aid for this article. The analysis and supporting sources follow below.
Microsoft’s retirement concerns its own SMS and voice authentication delivery. It is not a ban on every customer-managed telecom provider. The practical job is to establish which users and recovery routes depend on the retiring delivery, then give them a tested alternative.
The dates and population
Microsoft’s published plan starts passkey enablement and registration prompts for SMS/voice-enabled users from September 1, 2026, with unlimited snoozes by default. Microsoft-provided SMS and voice delivery retires from February 1, 2027. The guidance also describes a customer-managed provider route for organizations that need to retain phone methods. Check the applicable cloud, tenant policy and provider conditions in Microsoft’s retirement guidance.
As of September 7, the September phase has begun. Treat the sign-in and self-service recovery paths as separate things to verify. A phone number in a report does not by itself prove that a person has no other way to sign in.
Build an affected-user register
| Input | What it helps establish | What it does not prove |
|---|---|---|
| Registered methods | Which methods a user has registered | That a registered method is usable today |
| Authentication policy | Which methods and groups are allowed | That all users have completed registration |
| Recent sign-in usage | Which methods have been observed | Complete future behavior or instantaneous reporting |
| Device and user checks | Whether the chosen method fits the actual working context | Readiness of every untested device |
| Recovery checks | What happens when the usual method is lost | That sign-in changes automatically fix password recovery |
Record the report timestamp and its coverage. Resolve service, guest, shared-device and emergency-access accounts explicitly. Use a representative pilot to test the result rather than predicting lockouts from registration data alone.
Roll out in an order people can follow
- Agree the target methods, support owner and fallback process.
- Confirm licenses and device support for the chosen method.
- Enable the target method for a pilot and send clear registration instructions.
- Test normal sign-in, lost-method recovery and relevant shared-device scenarios.
- Expand in agreed groups; track completed registration and unresolved exceptions.
- Retire legacy methods only under the approved policy and rollout plan.
Passkeys, security keys and Windows Hello for Business have different provisioning and device considerations. A working plan accounts for the actual population rather than demanding that every person use the same personal phone.
What the project leaves with your team
The Microsoft 365 Passkey Migration scope produces the agreed population register, policy changes, pilot results and exception ownership. Hardware procurement, end-user support and any customer-managed provider are explicit responsibilities. Ongoing help-desk coverage is a separate operating need.
About this article
Published by AZ Innovations, led by Alwatheq Zboun. We complete scoped Microsoft 365, security, migration and automation work. See who does the work or the delivered work.
Keep everyone signing in after Microsoft stops sending phone codes.
We establish the people affected, agree supported methods, pilot registration and document the remaining exceptions.