On July 13, 2026, Microsoft announced one of the biggest changes to authentication in Microsoft Entra ID in years: Microsoft-provided SMS and voice call authentication is being retired, and passkeys become the default authentication experience for everyone. If you still have users approving MFA with a text message or a phone call, this change lands in your tenant automatically – starting September 1, 2026, and finishing with a hard cutoff on February 1, 2027.

I have spent the last two weeks walking customers through what this actually means for them, and the same questions come up every time: What exactly happens to my tenant, and when? How do I find out who is affected? How do I get my users onto passkeys without melting the help desk? And – the question behind the question – what if I am not ready? Can I buy more time, and can I stop Microsoft from prompting my users to register new methods while I work out my plan?

This post is the playbook I wish I could just hand to every IT admin right now. We will cover:

• The full retirement timeline and what changes automatically in your tenant
• How to find every user who still relies on SMS or voice
• How to move them to passkeys (or the Authenticator app) in a controlled way
• How to extend the period if you need more time – the temporary opt-out and the customer-managed telecom provider option
• How to suppress the registration prompts so your users are not nudged before you are ready
• Lessons learned from real migrations, so you can skip the mistakes I have already made for you

Everything below is based on Microsoft’s official announcement and documentation as of late July 2026, plus hands-on testing in my own tenant. Where Microsoft has said “details coming later” I will say so explicitly, because a few important pieces (the opt-out API and the Security Store telecom catalog) are not published yet at the time of writing.

Why Microsoft is doing this

The short version: SMS and voice are the weakest links in the MFA chain, and attackers know it. Phone-based factors are vulnerable to SIM swapping, SS7 interception, social engineering of telecom support desks, and – increasingly – AI-assisted phishing that walks a user through approving a fraudulent prompt in real time. Microsoft’s own numbers have long shown that SMS is roughly 40% less effective at preventing compromise than the Authenticator app, and neither of them holds up against a well-built adversary-in-the-middle (AiTM) phishing kit. Passkeys do, because the credential is cryptographically bound to the site it was registered for – there is nothing for the user to type or approve on a fake page.

Microsoft has been signaling this direction for years: system-preferred MFA, the passkey registration campaign feature, mandatory MFA for Azure management, and the Secure Future Initiative. The July announcement is the point where the signaling stops and enforcement begins. SMS and voice are no longer positioned as secure authentication methods in Entra ID, and Microsoft will simply stop delivering them natively.

It is worth being clear about the scope: only Microsoft-provided SMS and voice delivery is being retired. Microsoft Authenticator (push and TOTP), hardware OATH tokens, FIDO2 security keys, Windows Hello for Business, certificate-based authentication, and external/third-party MFA methods are all unaffected. And SMS/voice as a concept does not disappear entirely – organizations with a genuine regulatory or operational need can keep it by bringing their own telecom provider through the Microsoft Security Store (more on that below).

The timeline – dates you need in your calendar

Here is the full sequence of events. I recommend literally putting these in your team calendar today.

Date	What happens
August 1, 2026	API support and documentation for the temporary opt-out becomes available. This lets you delay the September changes while you finish your migration (details below).
September 1, 2026	Users enabled for SMS or voice in the Authentication Methods Policy (or legacy per-user MFA settings) are automatically enabled for passkeys. Your registration campaign is set to Microsoft managed, targeting passkeys, and these users are pulled into scope. On their next MFA sign-in they are nudged to register a passkey (skippable, with unlimited snoozes by default).
September 7, 2026	(Related change) Self-service password reset only accepts authentication methods the user has actually registered.
September 18, 2026	Microsoft publishes the telecom provider options, terms, and pricing information in the Microsoft Security Store.
October 30, 2026	You can select and configure a customer-managed telecom provider through the Security Store if you need to keep SMS or voice.
February 1, 2027	Microsoft-provided SMS and voice delivery is retired. Users whose only MFA method is SMS or voice get a blocking passkey registration prompt at sign-in – no more skipping. There is no opt-out from this milestone. It applies to all tenants in the public cloud.

Two things stand out. First, the September 1 changes are automatic – if you do nothing, Microsoft changes your authentication methods policy and your registration campaign settings for you. Second, February 1, 2027 is a hard wall. The temporary opt-out only postpones the nudging, not the retirement itself. Every plan you make should work backwards from February 1.

Note that this timeline applies to the public cloud. Sovereign and government cloud environments follow a later schedule that Microsoft will communicate separately.

What actually changes in your tenant on September 1

This is the part most summaries gloss over, so let us be precise. If you have users enabled for SMS or voice on September 1, 2026, Microsoft will:

1. Auto-enable passkeys (FIDO2) in your Authentication Methods Policy for those users, placed in a passkey profile that allows all passkey types – synced passkeys (iCloud Keychain, Google Password Manager) as well as device-bound passkeys (Microsoft Authenticator, Entra passkey on Windows, hardware security keys).
2. Set your registration campaign to “Microsoft managed”, targeting passkeys. Under Microsoft managed, the snooze duration becomes one day, snoozes are unlimited, and targeting expands to MFA-capable users. In practice: every time an affected user completes MFA (at most once per day), they see a “set up a passkey” interrupt they can skip.
3. Nudge users at their next MFA sign-in. The nudge is evaluated per device-and-browser combination – a user with Windows Hello for Business will not be nudged on their Windows PC in Chrome or Edge, but the same user may be nudged when signing in from a Mac or a phone, because that credential does not travel with them.

If that is exactly what you want – great, you can lean back and let Microsoft drive registration for you. But in most organizations you will want to control the pacing, the communication, and the target method yourself. Everything below shows you how.

Step 1: Find out who is actually affected

Before you plan anything, get the numbers. “We use the Authenticator app” is what every IT manager tells me; the registration report almost always tells a different story – old accounts that registered a phone number in 2019, frontline workers, service-adjacent accounts, board members, external consultants.

Option A: Microsoft’s official analyzer script

Microsoft published a dedicated PowerShell script for exactly this purpose: the Entra SMS and Voice Usage Analyzer on GitHub. Run it with Global Reader, Security Reader, or Authentication Policy Administrator, and it reports which users are enabled for and actively using SMS or voice. Any non-zero result means your tenant is in scope for this whole exercise.

Option B: The user registration details report

In the portal: Entra ID > Authentication methods > User registration details. Filter on the registered methods column for Phone / Alternate phone / Office phone, and pay special attention to users whose default MFA method is a phone-based one. Note that this report requires a Microsoft Entra ID P1 license – in an unlicensed tenant the blade returns a 401, so fall back to the analyzer script or Graph below.

Option C: Microsoft Graph PowerShell, if you want it scriptable

Connect-MgGraph -Scopes "AuditLog.Read.All","UserAuthenticationMethod.Read.All"

# Pull registration details for all users
$details = Get-MgReportAuthenticationMethodUserRegistrationDetail -All

# Users with any phone-based method registered
$phoneUsers = $details | Where-Object {
    $_.MethodsRegistered -match 'mobilePhone|alternateMobilePhone|officePhone'
}

# The high-risk subset: phone is their DEFAULT (or only) MFA method
$phoneDefault = $phoneUsers | Where-Object {
    $_.DefaultMfaMethod -in @('mobilePhone','voiceMobile','voiceAlternateMobile','voiceOffice','sms')
}

$phoneOnly = $phoneUsers | Where-Object {
    -not ($_.MethodsRegistered -match 'microsoftAuthenticator|passKey|windowsHelloForBusiness|fido2|softwareOneTimePasscode|hardwareOneTimePasscode')
}

$phoneUsers    | Export-Csv .\phone-users-all.csv -NoTypeInformation
$phoneOnly     | Export-Csv .\phone-users-ONLY-phone.csv -NoTypeInformation

"Any phone method: {0}  |  Phone as default: {1}  |  Phone as ONLY method: {2}" -f `
    $phoneUsers.Count, $phoneDefault.Count, $phoneOnly.Count

The three buckets matter because they need different treatment:

• Phone registered, but stronger methods too: lowest risk. These users just need their default flipped (system-preferred MFA usually handles this already) and eventually a passkey.
• Phone as default: will notice the change. Needs communication.
• Phone as the ONLY method: these are the users who hit the blocking registration prompt on February 1, 2027. This list is your migration backlog, sorted by priority.

While you are here, create a security group (for example SG-MFA-PhoneOnly-Migration) and fill it with the affected users. You will reuse it for the registration campaign scoping, for Conditional Access pilots, and for targeted communication.

Step 2: Decide where each user segment lands

Do not try to move everyone to the same method. In every migration I have run, the population splits into three or four segments:

1. Knowledge workers with a Windows PC or Mac: passkeys, full stop. Windows Hello for Business already covers the primary device for many; add a synced or Authenticator-based passkey for the phone and browser scenarios. No license cost, phishing-resistant, and it satisfies the February 2027 requirement.
2. Mobile-first users who already have Authenticator: passkey in Microsoft Authenticator. The app they already have becomes a device-bound passkey store. This is usually the smoothest single upgrade in the whole project.
3. Frontline and shared-device users: this is where you slow down and think. FIDO2 hardware keys work brilliantly for shared-PC scenarios. For users with no corporate phone and no personal-phone policy, hardware OATH tokens remain supported (they are not part of this retirement) – just remember they are not phishing-resistant, so treat them as transitional.
4. The genuinely stuck: regulated out-of-band SMS requirements, alarm and dispatch numbers, environments where smartphones are banned. This small segment is what the customer-managed telecom provider option exists for. Document the requirement (which regulation, which scenario) – you will want that paper trail anyway.

Synced versus device-bound passkeys deserves a sentence: synced passkeys (iCloud Keychain, Google Password Manager) are the most user-friendly and survive device loss, but the private key follows a consumer cloud account. Device-bound passkeys (Authenticator, security keys, Entra passkey on Windows) keep the credential on hardware you can reason about. Microsoft’s September auto-enablement allows all types; if your security team wants device-bound only, configure that in the passkey (FIDO2) policy yourself – and note that a restricted passkey profile changes the nudge behavior (see the suppression section below).

Step 3: Enable and configure passkeys properly

If you let the September 1 auto-enablement do this for you, passkeys arrive with an open, allow-everything profile. Doing it yourself first means you choose the settings – and you take the change out of Microsoft’s hands.

In the Entra admin center: Entra ID > Authentication methods > Policies > Passkey (FIDO2).

The settings that matter:

• Enable the method, targeting either all users or your migration group to start with.
• Allow self-service set up: must be Yes, both for users to register from My Security Info and for the registration campaign nudge to work at all.
• Enforce attestation: only if you have a real requirement – attestation-enforced profiles suppress the registration nudge, which may be exactly what you do not want during a migration.
• Key restrictions / AAGUIDs: same caveat. If you restrict to specific security key models, the Microsoft managed campaign will not switch to passkey targeting automatically, and nudge behavior changes. Restrict deliberately, not by inherited habit.

For the enterprise-grade rollout, follow Microsoft’s phishing-resistant passwordless deployment guide – it covers the persona-based approach in far more depth than I can here.

Step 4: Run the registration campaign on your terms

The registration campaign (“nudge”) is the engine Microsoft will use in September – but you can start it earlier, scope it tighter, and pace it yourself. A campaign you run in August against a pilot group beats a Microsoft managed campaign that hits everyone in September.

In the portal: Entra ID > Authentication methods > Registration campaign.

Configuration that has worked well for me:

• State: Enabled (not Microsoft managed – Enabled gives you control of every knob).
• Target method: Passkey (FIDO2). Note you can only run one campaign at a time – passkeys or Authenticator, not both.
• Include targets: your pilot group first, then the SG-MFA-PhoneOnly-Migration group in waves. Do not start with All users.
• Days allowed to snooze: 3 or 7 during the soft phase. This is tenant-wide, not per group.
• Limited number of snoozes: Disabled (unlimited) during the pilot; switch to Enabled (three skips, then required) when you move to enforcement mode. The snooze counter is tracked per user and survives configuration changes.

The same policy via Graph, if you prefer infrastructure-as-code (permissions: Policy.ReadWrite.AuthenticationMethod):

PATCH https://graph.microsoft.com/v1.0/policies/authenticationMethodsPolicy

{
  "registrationEnforcement": {
    "authenticationMethodsRegistrationCampaign": {
      "state": "enabled",
      "snoozeDurationInDays": 3,
      "enforceRegistrationAfterAllowedSnoozes": false,
      "excludeTargets": [],
      "includeTargets": [
        {
          "id": "<objectId of SG-MFA-PhoneOnly-Migration>",
          "targetType": "group",
          "targetedAuthenticationMethod": "fido2"
        }
      ]
    }
  }
}

A few behaviors worth knowing before your help desk finds out for you:

• The nudge only appears after a successful interactive MFA – users inside an existing SSO session are not interrupted.
• Conditional Access policies scoped to Register security information are evaluated first. If you restrict security info registration to compliant devices or trusted networks (and since July 6, 2026 these policies are enforced during Windows Hello for Business and macOS Platform SSO enrollment too), users outside those conditions silently do not get nudged. Plan for how those users will ever register.
• Closing the browser counts as a snooze.
• The passkey nudge checks whether the user has a local passkey for the current device-and-browser combination. Expect users to report “it keeps asking me even though I already did it” when they switch between PC, Mac, and phone. That is by design; put it in your FAQ.

Step 5: Communicate like the sign-in experience depends on it (it does)

Coordinated communication is the single biggest predictor of a smooth rollout – Microsoft says the same thing in their deployment guidance, and my experience agrees. The pattern that works:

1. Awareness (now to August): “SMS and phone-call MFA is being retired by Microsoft. Here is why, and here is what will replace it.” Scope it to the affected group – blasting the whole company about a change that only touches 15% of users creates noise and ticket volume for nothing.
2. Action (September onwards): step-by-step registration guides per device type – Windows Hello, iPhone/iCloud, Android/Google, Authenticator. Microsoft has ready-made end-user templates at aka.ms/mfatemplates that you can rebrand.
3. Reminder (November-January): targeted mails to the shrinking list of users who still have no phishing-resistant method, with a hard date. Pull the list from the same Graph report you used in step 1 and watch it trend toward zero.

Give the help desk a one-pager: what the nudge screen looks like, how to register each passkey type, what “Skip for now” does, and – critically – what changes on February 1, 2027, when skipping stops being an option.

Need more time? Your two extension options

Now for the part many of you scrolled here for. There are two legitimate ways to buy time, and they solve different problems. Neither of them moves the February 1, 2027 wall.

Option 1: The temporary opt-out (September 2026 to February 2027)

Microsoft is providing a temporary, tenant-level opt-out from the September 1 changes – the passkey auto-enablement and the automatic registration campaign switch. This is aimed at organizations that have a different plan (for example, migrating to a customer-managed telecom provider, rolling out hardware keys on their own schedule, or moving users to another method) and do not want Microsoft touching their authentication methods policy in the meantime.

What we know as of late July 2026:

• The opt-out is exercised via API, and Microsoft publishes the API details and documentation on August 1, 2026. Keep an eye on the official retirement page – that is where it will land.
• It delays the September 1 auto-enablement and nudging while you complete your transition activities.
• It is temporary by design: it covers the September 1, 2026 through February 1, 2027 window. On February 1, enforcement applies to all tenants, opted out or not. Users whose only method is SMS or voice will face the blocking passkey registration prompt unless you have configured a telecom provider.

My advice: even if you plan to opt out, do it as a scheduling decision, not an avoidance decision. Opting out without a dated migration plan just moves your crunch from September to January.

Option 2: Keep SMS/voice with a customer-managed telecom provider

If you have a genuine regulatory or operational requirement for a telephony factor – out-of-band SMS mandated by a compliance regime, users in environments where nothing else works – you can continue using SMS and voice past February 2027 by contracting with a telecom provider through the Microsoft Security Store:

• September 18, 2026: Microsoft publishes the provider catalog, terms, and pricing in the Security Store. Evaluate providers against your regional and compliance requirements.
• October 30, 2026: configuration opens. You select a provider, stand up the contract through the marketplace flow, and wire it into your tenant.
• Costs: this is the part to socialize with management early. Unlike today, where SMS delivery is bundled into your licensing, the customer-managed model is your contract with the carrier – typically per-message pricing that varies by provider, volume, and geography. Migrating users to passkeys costs nothing; keeping SMS becomes a line item.

Treat this as a scoped exception, not a tenant-wide strategy: identify the specific user segments with the documented need, put them on the customer-managed channel, and default everyone else to passkeys. Between the carrier cost, the audit questions, and the fact that SMS remains phishable, the economics push the same direction as the security argument.

One more planning note: test the provider flow with a pilot group well before February. You do not want to discover carrier delivery quirks in specific countries during the enforcement week.

Suppressing the registration prompts while you work out your plan

Maybe you are mid-negotiation with a telecom provider. Maybe your change advisory board meets quarterly. Maybe you simply do not want users seeing Microsoft-branded prompts before your communication has landed. Whatever the reason, here is how you keep the nudges away from your users – deliberately and reversibly.

The clean way: take your users out of scope before September 1

The September auto-enablement only targets users enabled for SMS or voice in the Authentication Methods Policy or legacy per-user MFA settings. If you migrate users to other methods and disable SMS/voice for them before September 1, there is nothing for Microsoft to auto-enable and nobody gets pulled into the Microsoft managed campaign. This is the option Microsoft itself points to, and it has the advantage of actually solving the problem rather than postponing it.

The control way: set the registration campaign yourself

The registration campaign is a tenant setting, and your configuration is the control surface. To stop nudging entirely:

Portal: Entra ID > Authentication methods > Registration campaign > set State to Disabled > Save.

Graph:

PATCH https://graph.microsoft.com/v1.0/policies/authenticationMethodsPolicy

{
  "registrationEnforcement": {
    "authenticationMethodsRegistrationCampaign": {
      "state": "disabled",
      "snoozeDurationInDays": 1,
      "enforceRegistrationAfterAllowedSnoozes": true,
      "excludeTargets": [],
      "includeTargets": []
    }
  }
}

If you want the campaign running but need to shield specific populations – VIPs mid-quarter-close, a factory site with no phones, a business unit in the middle of a divestiture – use exclude targets instead of disabling the whole thing:

{
  "registrationEnforcement": {
    "authenticationMethodsRegistrationCampaign": {
      "state": "enabled",
      "snoozeDurationInDays": 7,
      "enforceRegistrationAfterAllowedSnoozes": false,
      "excludeTargets": [
        { "id": "<objectId of SG-MFA-Nudge-Excluded>", "targetType": "group" }
      ],
      "includeTargets": [
        { "id": "all_users", "targetType": "group",
          "targetedAuthenticationMethod": "fido2" }
      ]
    }
  }
}

Exclusion wins over inclusion – a user in both lists is excluded. And remember the softer levers before you reach for Disabled: a long snooze duration (up to 14 days) with unlimited snoozes is a much gentler campaign than the Microsoft managed default of daily prompts.

What suppression does NOT do

Three honest caveats, because I have seen all three misunderstood already:

1. Disabling the campaign today does not prevent the September 1 change. Microsoft sets the campaign to Microsoft managed as part of the rollout. Expect to re-assert your configuration after September 1, or use the official opt-out API from August 1 – that is the supported mechanism for exactly this scenario.
2. Other setup prompts still exist. Security defaults, SSPR combined registration enforcement, and Conditional Access policies requiring MFA registration are separate mechanisms. The registration campaign switch only controls the passkey/Authenticator nudge.
3. Nothing suppresses February 1, 2027. The blocking prompt for SMS/voice-only users is enforced for all tenants. Microsoft has been unusually explicit: there is no opt-out from that milestone. Suppression buys you communication time; it does not buy your users a future with SMS codes.

Lock in the gains with authentication strengths

Once a user segment has registered passkeys, close the door behind them. A Conditional Access authentication strength policy requiring Phishing-resistant MFA for your most sensitive applications (or for privileged roles) ensures that a registered passkey is not just an option sitting next to a weaker method – it becomes the method that actually gets used. The built-in strengths cover the common cases:

• Phishing-resistant MFA: passkeys (FIDO2), Windows Hello for Business, certificate-based authentication. This is the end state.
• Passwordless MFA: the above plus Authenticator passwordless sign-in. A good intermediate target.
• MFA: the classic list, including SMS and voice – which is exactly why you want to move off it.

Sequence matters here: roll out authentication strengths after registration in each wave, not before. If you require phishing-resistant MFA from users who have not registered a passkey yet, and they cannot satisfy the security info registration CA policy either, you have built a deadlock the service desk gets to untangle with Temporary Access Passes, one ticket at a time. Pilot group, registration wave, comms, then the strength policy – in that order, per wave.

This is also the answer to a question I get a lot: “if SMS stops working in February, does that not just mean attackers move to phishing our Authenticator prompts?” Yes – retiring SMS is necessary, not sufficient. Authentication strengths are how you convert the passkey rollout from a registration statistic into an actual reduction of attack surface.

Quick answers to the questions everyone asks

Does this affect Microsoft 365 personal or family accounts? No – this timeline is about Microsoft Entra ID (work and school accounts) in the public cloud. Consumer accounts and sovereign clouds run on their own schedules.

Are Authenticator push notifications and TOTP codes going away too? No. Only Microsoft-provided SMS and voice delivery is retired. Authenticator, TOTP, hardware OATH tokens, FIDO2 keys, Windows Hello for Business, and certificate-based authentication all continue.

Will my users get locked out on February 1, 2027? Not locked out – blocked-until-registered. A user whose only method is SMS or voice will be required to register a passkey during sign-in before they can continue. That is a support-heavy morning if it hits hundreds of users at once, which is the entire argument for doing this on your own schedule.

We use a third-party MFA provider through external authentication methods – are we affected? External MFA methods are not being retired. But if some of your users are also enabled for Entra SMS or voice, those users are in scope for the September auto-enablement, so clean up the policy targeting.

Can I keep using SMS for SSPR only? Only through a customer-managed telecom provider. The retirement covers SSPR as well as MFA.

Do not forget SSPR

The retirement applies across Entra, including self-service password reset. If your SSPR policy leans on phone-based verification, those methods stop working on the same February 2027 date unless a customer-managed provider is in place. Combine that with the September 7, 2026 change (SSPR only accepts methods the user has registered) and the message is clear: your SSPR method policy needs the same review as your MFA policy. Microsoft has said that password change support for passwordless users is coming, but if passwords are still part of your world, make sure every user has at least two non-phone methods registered – Authenticator plus email, or Authenticator plus security questions – before you switch off phone options.

Lessons learned from the field

These are the things the documentation will not tell you, collected from migrations I have run or rescued:

1. The registration report always contains surprises. Every tenant I have analyzed had phone-only users nobody expected: meeting room accounts someone MFA-enabled in a panic, a CFO whose Authenticator broke in 2023 and “temporarily” fell back to SMS, external bookkeepers, that one integration account a vendor set up with a real mobile number. Run the report before you estimate the project, not after.

2. Check your break-glass accounts first, not last. If your emergency access accounts use voice call as a factor (it was a common recommendation a decade ago), fix that this week. FIDO2 hardware keys stored in physically separate locations is the pattern. You do not want to discover this dependency during an incident in March 2027.

3. Per-user MFA settings are still lurking in older tenants. Users enabled through the legacy per-user MFA portal are in scope for the September auto-enablement too. If you never finished the migration to the Authentication Methods Policy, this is the forcing function – converged authentication methods migration first, then the passkey rollout. Doing them simultaneously multiplies the confusion.

4. The nudge’s per-device evaluation generates tickets. Users who registered a passkey on their PC get nudged again on their phone and conclude “it didn’t work”. Pre-empt it in your comms: one passkey per platform is normal, and Windows Hello for Business does not follow you to your iPhone.

5. Conditional Access and the nudge interact silently. A CA policy that locks security info registration to compliant devices will quietly prevent nudges for users on unmanaged devices – which, in a BYOD-heavy organization, can be most of the affected population. Decide on a registration path for those users (Temporary Access Pass issued by the service desk works well) before you turn on enforcement.

6. Watch out for shared phone numbers. Shops, wards, and warehouses where one number backs ten accounts break in interesting ways when those accounts each need an individual passkey. FIDO2 keys on a lanyard have solved this everywhere I have tried them.

7. Guests are in scope, and passkey support for B2B is not fully there yet. Microsoft says passkey support for B2B and internal guests lands by end of 2026 – which is cutting it close to February 2027. Inventory your guest users with phone-based MFA now, and consider whether external MFA trust settings (accepting the home tenant’s MFA claim) can take them out of the equation entirely.

8. Do not let “temporary” become permanent. Every extension mechanism in this post – the opt-out, the telecom provider, long snoozes, exclusion groups – is a bridge. Put an expiry date and an owner on each one the day you create it. The tenants that struggle in January 2027 will be the ones that treated September’s opt-out as a solution.

9. Sell the upside, not just the deadline. Passkeys are genuinely faster – no more typing codes, no more “open the app on your other phone”. Users who experience a passkey sign-in once rarely want to go back. Frame the change as an upgrade with a deadline, not a compliance chore, and your registration numbers will show the difference.

My recommended plan, condensed

1. Now: run the analyzer script and the registration report. Build the affected-users group. Check break-glass accounts.
2. August: decide per segment: passkey, Authenticator bridge, hardware key, or (rarely) telecom provider. If the September auto-changes conflict with your plan, grab the opt-out API details on August 1 and file the change request. Configure the passkey policy yourself before Microsoft does it for you.
3. September-October: pilot the registration campaign against IT, then wave by wave. Send awareness and action comms. Evaluate the Security Store catalog (from September 18) if you have a telephony requirement, and configure the provider from October 30.
4. November-December: flip the campaign to limited snoozes for the stragglers. Chase the phone-only list down toward zero. Fix SSPR methods.
5. January 2027: buffer month. Nothing new – just verification, reporting, and the final targeted reminders before the February 1 enforcement.

References and further reading

• Microsoft Security Blog – Passkeys are the default authentication method in Entra ID (the announcement, July 13, 2026)
• Microsoft Learn – Passkeys by default and retirement of Microsoft-provided SMS and voice authentication (the authoritative timeline + FAQ)
• GitHub – Entra SMS and Voice Usage Analyzer (official PowerShell script)
• Microsoft Learn – Run a registration campaign (nudge) for passkeys or Authenticator
• Microsoft Learn – Plan a phishing-resistant passwordless deployment
• Microsoft Learn – Enable passkeys (FIDO2) for your organization
• Microsoft end-user communication templates (aka.ms/mfatemplates)
• Office 365 for IT Pros – No More SMS One-time Codes and Voice Calls from Entra ID (Tony Redmond’s take)
• LazyAdmin – Microsoft Entra ID Will Retire SMS and Voice Authentication
• BleepingComputer – Microsoft Entra ID gets passkeys default authentication starting September
• AdminDroid – Passkeys Become the Default Auth Method in Microsoft Entra
• Message Center archive – MC1426371 (the message your tenant received)

Wrapping up

Microsoft retiring SMS and voice MFA is not a surprise direction – it is the industry direction with a date on it. The organizations that will sail through this are the ones that treat September 1, 2026 as their deadline for having a plan, not February 1, 2027 as their deadline for panicking. Run the report today, segment your users, take control of the registration campaign before Microsoft’s defaults do it for you, and use the extension mechanisms for what they are: bridges with an expiry date.

If you want help assessing your tenant – from a quick phone-method inventory to a full passkey rollout – you know where to find me.