Microsoft’s SMS Login Deadline Needs a Plan
Matthew Leo · Published August 13, 2026 · Software & Apps
Microsoft is not switching off every SMS login on September 1, but organizations that treat the date as irrelevant may reach February with users who cannot sign in.
The change applies to Microsoft Entra ID, the identity system behind many work and school accounts. Starting September 1, 2026, users enabled for SMS or voice authentication will also be enabled and prompted to register passkeys. Microsoft plans to retire its own SMS and voice delivery on February 1, 2027.
Consumer Microsoft accounts are not the subject of this Entra announcement. Neither are ordinary text messages generally. The affected decision belongs to the administrator of an Entra tenant and the people who use that tenant to reach business or institutional systems.
The two dates do different things
Microsoft’s retirement notice describes a staged migration.
| Date | Change | Practical effect |
|---|---|---|
| September 1, 2026 | Passkeys become the default experience for users enabled for SMS or voice | Eligible users can be prompted to register a passkey after MFA |
| February 1, 2027 | Microsoft-provided SMS and voice delivery retires | Users need a phishing-resistant method or a customer-managed telecom provider |
| After February 1 | Passkey registration can become blocking | A user relying only on SMS or voice may have to register before continuing |
Microsoft says there is no opt-out from the February behaviour. An organization can retain SMS or voice by arranging a customer-managed provider through the Microsoft Security Store, but complete provider information is scheduled for September 18, 2026.
That missing detail is one reason not to wait. Teams that genuinely need telephone delivery should identify the requirement now, then evaluate providers when Microsoft publishes the commercial and technical options.
Passkeys change where recovery risk lives
A passkey uses public-key cryptography rather than a shared password or one-time code. The private credential stays on a device, credential manager or hardware security key, while the service stores the corresponding public key. A fake sign-in page cannot simply forward a captured code to the real service.
Entra supports synced passkeys stored in services such as iCloud Keychain or Google Password Manager, as well as device-bound credentials including Windows passkeys, Microsoft Authenticator and FIDO2 hardware keys.
That choice affects recovery. A synced passkey can follow a user across devices inside the same credential ecosystem. A device-bound credential provides tighter hardware control but can strand a user if the only registered device is lost and no alternate recovery method exists.
Migration therefore means more than asking everyone to tap “create.” The organization needs rules for approved credential stores, personally owned devices, replacement phones, departing staff and emergency access.
Find the users who still depend on telephone codes
Microsoft provides a PowerShell process for administrators with appropriate reader or authentication-policy roles to identify active SMS and voice users. Exporting that list is the beginning, not the final answer.
Group the users by situation:
- Employees with managed phones and current passkey-capable devices
- Front-line or shared-device workers without an assigned smartphone
- Contractors whose devices are outside normal management
- Users with accessibility requirements affecting biometric or device flows
- Travellers and remote staff who may change SIMs or lose connectivity
- Service and emergency accounts that should not depend on a person’s phone
A uniform deadline email will not resolve those differences. The common policy can still require phishing-resistant authentication, but the credential and recovery route may vary.
Run a pilot that includes failure
Start with a representative group rather than only the security team. Include users on Windows, macOS, iPhone and Android, plus anyone working through shared or restricted devices.
- Document the approved passkey types and devices.
- Enable a registration campaign for the pilot group.
- Confirm sign-in to the applications that matter, not only Microsoft’s portal.
- Test a lost-phone or replaced-laptop scenario.
- Measure help-desk time and failed recovery attempts.
- Keep a protected break-glass account using a separately governed method.
- Expand only after the recovery path works.
Do not remove the existing method from every user immediately after the first successful passkey login. Follow a controlled retirement plan so a registration mistake does not become an organization-wide lockout.
Canadian organizations should review data and labour details
Synced credentials may involve personal Apple or Google accounts when workers use their own devices. Employers should state whether that arrangement is permitted, what management data the organization can see and how access is removed without demanding control over a worker’s personal account.
Public-sector, health, financial and other regulated organizations may have additional authentication, residency, procurement and recordkeeping requirements. A passkey is a stronger sign-in mechanism, but it does not settle every policy question surrounding the device and credential manager.
Accessibility and accommodation also belong in the deployment plan. Passkeys do not require one specific biometric; PINs, device unlock methods and hardware keys can offer alternatives. The support process should explain those choices before a user encounters a blocking prompt.
Canadian organizations facing new supplier-security duties should also connect identity changes to their broader risk programme. Mapletechie’s analysis of Canada’s cybersecurity law and suppliers explains why authentication requirements increasingly travel through contracts.
September is the warning; February is the cutoff
Microsoft’s direction is technically sensible. SMS codes are vulnerable to phishing, SIM swaps and interception, while passkeys bind authentication to the real service.
The operational risk comes from confusing a security improvement with a self-executing project. Inventory the affected users, choose credential types, test recovery and communicate the change in plain language. By February, every critical account should have at least one tested way in and one protected recovery route.
The worst migration outcome would be replacing a phishable code with a secure credential that the legitimate user cannot recover.
Tags: Microsoft Entra, passkeys, authentication, cybersecurity, business software