Introduction

Microsoft is retiring Microsoft-supported SMS and Voice authentication in Entra ID on February 1st, 2027. As of September 1st, 2026, passkeys have become the default authentication method, and once the retirement takes effect, organizations that still need SMS or voice will need to configure and pay for a customer-managed telecom provider through the Microsoft Security Store. This blog post walks you through what’s changing, when, and what you need to do.

Critical Dates and Milestones

Microsoft is executing this transition across four key milestones. Here’s what happens by:

• September 1st, 2026 – Users enabled for SMS or Voice are automatically prompted to enroll for Passkeys
• September 18th, 2026 – Microsoft announces customer-managed telecom providers through the Microsoft Security Store
• October 30th, 2026 – Customers can begin selecting and configuring third-party telecom providers
• February 1st, 2027 – Microsoft SMS and Voice are fully retired in Entra ID
• After February 1st, 2027 – Users with only SMS or Voice registered will be blocked from signing in. You have roughly 4.5 months from today to plan, test, and execute this change.

Can You Answer These Questions?

• Do we know who’s using exclusively SMS and/or Voice?
• Which users absolutely cannot use passkeys?
• Can our Conditional Access Policies handle passkey-only authentication?
• What happens to our third-party integrations?
• What’s our contingency if we’re not ready by February 1st?

Why is Microsoft Retiring SMS and Voice?

SMS and Voice authentication are phishable and vulnerable to SIM-swap attacks, social engineering, and call spoofing. As decades-old methods rely on shared secrets, they don’t meet today’s security standards. Passkeys reduce this risk, minimizing the remote attack vectors that compromise weaker MFA methods.

What is a Passkey?

Passkeys are strong, phishing-resistant, cryptographic authentication methods built on the Fast Identity Online 2 (FIDO2) standards developed by the FIDO Alliance. Each passkey is a public and private key pair. The private key stays with the user, on a phone, a computer, or in a hardware security key, while the public key is registered with the website or service holding the identity.

How that private key is stored, and whether it can move between devices, is what separates the two types of passkeys:

• Device-bound – The private key is stored on a physical device (YubiKey, Microsoft Authenticator, etc.) and never leaves it.
• Synced – The private key is encrypted locally, then synced to a cloud provider (Apple, Google, Microsoft), so it’s available across a user’s devices.

Passkeys combine first and second factor authentication into one (no SMS codes or push notifications):

1. The first factor is possession; you have a physical device (YubiKey, Microsoft Authenticator, Windows Hello) or software device (Apple iCloud Keychain, Bitwarden, LastPass) that holds your private key.
2. The second factor is user interaction; you have to prove you control that device by touching a sensor, entering a PIN, or using biometrics.

Only when both conditions are met, device and user action, does authentication succeed. With passkeys, your device and the service (Entra ID) complete a cryptographically assured handshake that’s resistant to replay attacks. The private key never leaves your device, and each authentication is cryptographically bound to that specific interaction. This is different from other MFA methods where a code travels over a network and can be intercepted, replayed, or SIM-swapped.

Passkeys are also resistant to Adversary-in-the-Middle (MITM) attacks and login page cloning. Because passkeys are cryptographically bound to the issuing domain through origin binding (Entra ID), attackers can’t reuse a stolen passkey on a fake login page, so the cryptographic handshake will fail. This protects users from the login page spoofing attacks that catch users with traditional MFA.

SRA’s Recommendation: Your choice between device-bound and synced passkeys depends on your organization’s threat model and risk tolerance.

Device-bound passkeys restrict the attack plane to physical devices and user interaction (PIN, biometric, sensor touch). The private key never leaves your hardware. This is the strongest option for privileged accounts, administrators, and high-security environments.

Synced passkeys back up to cloud providers, so when users get a new device, their keys “just work.” Synced passkeys are particularly useful for organizations with BYOD policies or those operating in regions with strict privacy laws (GDPR, CCPA) where you can’t mandate specific apps on personal devices. Since synced passkeys back up to the user’s existing cloud account, organizations don’t need to require Microsoft Authenticator installation. Users maintain control over their device while your organization gets strong authentication.

How to decide: If your threat model requires preventing all remote compromise scenarios, use device-bound. If your organization values user experience and accepts cloud provider compromise as a low-probability risk, synced is probably sufficient.

A note on Passkey Attestation in Entra ID: FIDO2 attestation allows a provider (Microsoft) to require additional metadata from passkeys registered with a tenant. Microsoft uses the FIDO Alliance Metadata Service (MDS) to determine passkey authenticator compatibility and legitimacy. If attestation is enforced, additional requirements apply, such as a passkey needing FIDO2 certification and using a verification or client pin. See Microsoft’s article here for more detailed information on Passkey Attestation. Attestation enforcement is recommended for device-bound passkeys. Note that synced passkeys cannot be enforced for attestation.

How to Configure Passkeys and Passkey Policy?

A Passkey Policy in Entra ID defines which users can register passkeys, what types are allowed, and what security controls are enforced. It’s your control mechanism for the rollout.

SRA recommends this configuration:

1. Assign the Authentication Policy Administrator role (minimum required)
2. Navigate to portal.azure.com > Entra ID > Security > Authentication methods > Passkeys (FIDO2)
3. Configure:

• • Enabled: Yes
  • Scoped: All users (or specific security groups if rolling out in phases)
  • Allow self-service setup: Yes
  • Enforce attestation: Yes (SRA recommends)
  • Passkey types: Device-bound (SRA recommends)
  • Key restrictions: No

Why these settings: Attestation verifies the authenticity of passkey providers via the FIDO Metadata Service. As addressed above, device-bound keeps the private key on hardware you control, not cloud infrastructure. Organizations can configure multiple passkey profiles to support multiple personas. If device-bound passkeys cannot be supported for all users in the organization, consider configuring various passkey profiles for standard users, frontline workers, administrators, and other personas.

What Should Organizations Do, and When?

Your migration strategy should follow three phases.

Phase 1: Assessment & Planning (Now – September 2026)

• Run Microsoft’s SMS/Voice usage analyzer script: https://github.com/microsoft/entra-sms-voice-usage-analyzer
  • This identifies who’s using SMS/Voice and how many users you need to migrate
• Categorize users:
  • Can use passkeys: Standard employees, privileged admins, contractors
  • Cannot use passkeys: Frontline workers without devices, legacy system service accounts, users in restricted environments
• For those who can’t use passkeys, identify compensating controls now (Intune device compliance, network restrictions, conditional access rules)

Phase 2: Enablement & Communication (September – December 2026)

• Enable passkeys in Entra ID using the configuration above
• If you’re not ready for automatic prompts, disable them via PowerShell:

Connect-MgGraph –Scopes "Policy.ReadWrite.AuthenticationMethod"
$params = @{
    optOutSettings = @{
        passkeyDynamicMigration = $true
    }
}
Update-MgBetaPolicyAuthenticationMethodPolicy -BodyParameter $params

• Update internal communications and create passkey registration guides in your knowledge base
• Socialize the change to users and get them comfortable with enrollment and usage before February

Phase 3: Migration & Enforcement (January – February 2027)

• Review and update Conditional Access Policies to support passkeys across all personas
• Exclude cloud service accounts (non-human accounts that can’t interactively authenticate) from passkey requirements
• Periodically report on passkey adoption to track progress toward the February deadline
• By February 1st: If you must keep SMS/Voice for specific users, purchase third-party provider support from the Microsoft Security Store
• After February 1st: Users with only SMS/Voice registered will be blocked from signing in

SRA guidance: This timeline is aggressive. Start Phase 1 now, waiting until November leaves little room for testing, user feedback, or troubleshooting.