What Microsoft has confirmed
Microsoft has announced that passkeys will become the default phishing-resistant authentication method in Microsoft Entra ID. Microsoft’s current documentation states that, beginning September 1, 2026, users enabled for SMS or voice authentication in the Entra Authentication Methods Policy or legacy MFA settings will be automatically enabled for passkeys and prompted to register one during a future multifactor sign-in.
Microsoft also states that Microsoft-provided SMS and voice delivery will retire on February 1, 2027, for Entra ID in the public cloud. After that date, users whose only available MFA method is SMS or voice will be required to register a passkey before continuing to sign in. Microsoft says there will be no opt-out from that enforced registration behavior.
The dates are important because the current date is August 29, 2026. A Central Florida business has only a short planning window before the September 1 transition milestone.
Who is affected
The change matters to organizations using Microsoft Entra ID for Microsoft 365 or other cloud applications, especially those with users who rely on:
- SMS codes for multifactor authentication.
- Voice calls for multifactor authentication.
- Legacy MFA settings rather than the current Authentication Methods Policy.
- Shared administrative practices with no documented recovery path.
- Contractors, seasonal staff, or remote workers who may not be available for an in-person setup.
It may also affect help-desk procedures. A user who loses a phone, replaces a laptop, or changes a device will need a secure way to register or recover an authentication method. A process based only on sending another SMS will not be a durable identity-recovery design.
Why passkeys are different
Microsoft describes passkeys as credentials based on public-key cryptography rather than shared secrets. Supported Entra options include synced passkeys, device-bound credentials, passkeys in Microsoft Authenticator, Windows-based passkeys, and FIDO2 security keys.
Microsoft recommends phishing-resistant methods because passwords, SMS, voice, and email codes can be phished, relayed, intercepted, or socially engineered. A passkey does not make every account or device secure, but it changes the authentication mechanism and reduces reliance on phishable codes.
The office manager’s inventory
Before changing settings, create a list of affected users and record:
- Primary device and operating system.
- Current authentication methods.
- Whether the user has registered more than one method.
- Whether the user is an administrator.
- Whether the user works remotely or travels.
- Whether the user handles payroll, banking, sensitive records, or security administration.
- Who can assist if registration fails.
Microsoft provides documentation and a PowerShell method for identifying users enabled for SMS or voice. A qualified administrator should validate the result against the tenant’s current policy and sign-in logs.
Do not assume that a user who receives a text message is configured in only one place. Review both current Authentication Methods Policy settings and legacy MFA configurations where applicable.
A phased rollout
Phase one: prepare
- Enable an approved passkey method for a small pilot group.
- Confirm licensing, device support, and policy scope.
- Create at least two secure administrative recovery paths.
- Document how a user is verified before an authentication method is reset.
- Identify users who cannot complete the transition without assistance.
Phase two: communicate
Tell users what is changing, why it matters, what device they should use, and how to recognize the legitimate registration prompt. State clearly that the IT team will not ask for a password, MFA code, or approval through an unexpected message.
Use direct internal communications rather than links sent through unfamiliar channels. Provide a contact method that staff already trust.
Phase three: pilot and expand
Start with administrators and a small group of ordinary users. Test sign-in, device replacement, account recovery, remote access, shared work patterns, and emergency access. Record failure points before expanding.
Do not remove every fallback method at once. Maintain a documented transition path until the pilot confirms that users can sign in and recover safely. At the same time, avoid leaving SMS enabled indefinitely simply because it is familiar.
Do not overlook recovery accounts
Strong authentication can still fail operationally if the only administrator loses access. Create a controlled emergency-access design with separately protected accounts, monitored use, documented custodians, and tested recovery procedures.
The person who can reset authentication methods is a high-value identity. Limit that role, review it regularly, and require independent verification for sensitive changes.
SMS exceptions and uncertainty
Microsoft has stated that organizations with a genuine regulatory, technical, or operational need for SMS or voice may be able to select a supported telecom provider through the Microsoft Security Store. Microsoft’s current timeline says provider information is expected September 18, 2026, and configuration is expected to become available October 30, 2026.
Those future provider details, pricing, eligibility, and technical requirements remain subject to Microsoft’s current documentation. Do not make a purchasing or compliance decision based on an assumption that an existing provider will automatically work.
What is confirmed and what is uncertain
Confirmed: Microsoft has published the September 1, 2026 passkey-management milestone and February 1, 2027 retirement date for Microsoft-provided SMS and voice authentication in public-cloud Entra ID.
Uncertain: Exact tenant behavior can depend on policy configuration, cloud environment, targeted authentication methods, device support, and later Microsoft updates. Validate settings in the tenant and review Microsoft’s current documentation before rollout.
Start this week
- Export or review the current SMS and voice user population.
- Identify administrators and users with no phishing-resistant method.
- Select a pilot group.
- Write the recovery procedure before changing the policy.
- Send a clear internal notice.
- Test registration and account recovery.
This is not merely an authentication-method change. It is an identity inventory, communications, help-desk, and business-continuity task.