Passkeys become the default in Entra ID: Timeline, risks and to-dos

17/07/2026 · 3 min read · 🌐 Automatically translated

From 1 September 2026, Entra ID will default to passkeys. On 1 February 2027, Microsoft's own SMS/voice delivery ends. Here is what changes and how to migrate cleanly.

What’s changing

Microsoft is switching the default authentication in Microsoft Entra ID to passkeys. The rollout starts on 1 September 2026 and will be deployed to tenants in stages. Users who currently use SMS or phone calls for MFA will be prompted to register a passkey during their next MFA event.

On 1 February 2027, Microsoft will end its own telecommunications delivery for SMS and voice calls; these channels will then no longer be natively available in Entra ID. If you still need SMS/Voice, you can select and configure a supported telecommunications provider in the Microsoft Security Store from 30 October 2026. Prices, terms and conditions, and the list of supported providers are scheduled to be published on 18 September 2026.

These dates initially apply to Microsoft Entra ID in the public cloud; other environments will follow with their own timelines.

Background: Passkeys are based on asymmetric cryptography and are considered phishing‑resistant. At the same time, AI‑assisted phishing campaigns are increasing and achieve significantly higher click‑through rates than traditional campaigns, making phishable factors like SMS/Voice more vulnerable.

Where operations and costs shift

• Risk reduction: By default, phishable methods are pushed back. This reduces risks from SIM‑swap, MFA fatigue, and intercepted SMS/Voice.
• Cost model: For remaining SMS/Voice cases, charges from the chosen carriers will apply. Microsoft will no longer provide these channels natively.
• User flow: Passkeys speed up sign‑ins when devices and platforms support passkeys.
• Compliance: Regulatory requirements involving SMS/Voice need to be reassessed and, if necessary, implemented via partner carriers. The fixed end dates require clear transition rules.
• Hard cutover: From 1 February 2027, users still using SMS/Voice must register a passkey before signing in; there is no opt‑out option.

Which passkey variants Entra ID supports

• Synced passkeys (platform-/account‑bound, e.g. the platform credential manager)
• Device‑bound passkeys, including:
  • Microsoft Authenticator
  • Entra passkey on Windows
  • FIDO2 security keys

Checklist: How to prepare for the migration

1. Inventory of methods

• Determine tenant‑wide which users/groups use SMS or Voice.

2. Define the passkey architecture

• Define suitable variants per target group: synced passkeys (for personal devices) vs. device‑bound passkeys such as FIDO2 keys (for shared or highly regulated devices).

3. Pilot and registration campaign

• Enable passkeys in policies and use registration prompts during MFA sign‑ins to systematically increase adoption.

4. Communication and support

• Inform users early about changes, timelines, and self‑service guides. Create helpdesk playbooks for recovery without phishable factors.

5. Conditional Access and exceptions

• Prefer phishing‑resistant methods, minimise transition exceptions, and define tightly scoped groups for special cases.

6. If SMS/Voice are still needed

• Identify regulated/technical segments.
• Review available carrier options from 18/09/2026 and procure via the Security Store from 30/10/2026.
• Run a carrier pilot and document delivery quality and costs.

7. Secure the deadlines

• By 01/09/2026: Prepare policies for passkeys, start user communications.
• By 01/02/2027: Put carrier configuration (if needed) into production; ensure all users have a phishing‑resistant method.

Practical implementation notes

• Example configuration (pseudo configuration, illustrative):

# Ziel: Passkeys erlauben, SMS/Voice nur in Ausnahmen
AuthenticationMethodsPolicy:
  MethodsEnabled:
    - PasskeySynced: Enabled
    - PasskeyDeviceBound: Enabled
    - FIDO2SecurityKey: Enabled
    - SMS: Disabled (Default)  # Nur falls Carrier integriert und in definierten Gruppen erlaubt
    - Voice: Disabled (Default)
  RegistrationCampaign:
    TargetGroups: ["AllUsers"]
    PromptOnMFASignIn: true
    Deadline: "2027-02-01"

ConditionalAccess:
  RequirePhishingResistantMFA:
    Assignments: AllCloudApps, AllUsers
    Controls: ["RequirePasskeyOrFIDO2"]
    Exclusions: ["BreakGlass-Accounts", "Regulated-SMS-Only-Group"]

• Operational aspects
  • Device and browser compatibility: Check OS versions and platform credential managers for passkey support.
  • Emergency accounts: Define at least two break‑glass accounts with strong protection and test regularly.
  • Device scenarios: Decide where device‑bound (shared devices, high‑security areas) vs. synced passkeys (personal devices) make sense.

When the deployment is particularly worthwhile

• High phishing exposure (e.g. large frontline workforces, external users)
• Strict compliance requirements for MFA strength
• Planned reduction of helpdesk tickets due to password/MFA issues

My assessment

Phishable factors are overdue for replacement and, given growing AI‑driven attacks, retiring them is sensible. The clear milestones provide planning certainty. Prioritise a broad registration campaign, robust recovery paths, and limit SMS/Voice to tightly defined exceptions via the Security Store.