News Date: 2026-07-13
Microsoft is preparing a major authentication change for enterprise customers by making passkeys the default sign-in method in Entra ID. Beginning September 1, 2026, users who are enabled for SMS or voice authentication will also be enabled for passkeys and prompted to register one during a future multifactor authentication event.
A Move Away From Phishable Factors
Passkeys rely on public-key cryptography rather than passwords, one-time codes or shared secrets. The credential is bound to the legitimate service, making it substantially harder for a phishing page or social engineer to capture something that can be replayed from another device.
Microsoft says identity attacks are becoming faster and more convincing as adversaries adopt artificial intelligence. SMS codes can also be exposed through phishing, SIM-swapping attacks, telecom weaknesses and fraudulent account-recovery requests. Voice authentication faces similar social-engineering and interception concerns.
The more consequential deadline arrives on February 1, 2027, when Microsoft will stop providing native SMS and voice delivery for Entra ID. Organizations that must retain these methods for regulatory, operational or accessibility reasons will be able to contract with supported telecom providers through the Microsoft Security Store.
Preparation Cannot Wait Until September
Microsoft plans to publish provider information and commercial details on September 18, 2026. Administrators will be able to configure supported providers beginning October 30. The announced dates apply to Entra ID's public cloud, with separate schedules expected for other cloud environments.
Recommended Migration Plan
- Identify users and applications still dependent on SMS or voice.
- Choose between synced passkeys, device-bound passkeys and FIDO2 keys.
- Run a controlled pilot with executives, administrators and support personnel.
- Update account-recovery and device-replacement procedures.
- Prepare clear user guidance before registration prompts appear.
I believe making phishing-resistant authentication the default is the right direction, but the migration will expose weak recovery processes in many organizations. A strong passkey deployment can still be undermined if a help desk resets access after receiving a convincing fraudulent call.
Enterprises should therefore treat this as an identity-program change rather than a simple authentication toggle. Success requires technical deployment, user education, resilient recovery controls and support for employees who cannot use the standard device-based registration process.