There is an unwritten rule in this industry. The moment you finally close the laptop, put the phone in a drawer and decide that for three weeks you are going to be a person instead of an identity architect, Microsoft publishes something that changes how every tenant on the planet does authentication. 😑 “Thank you” for that Microsoft….

I was on vacation on July 13th. Microsoft announced that passkeys are becoming the default authentication method in Entra ID and that Microsoft-provided SMS and voice are being retired entirely. We’re not talking about adjusted or deprecated with a friendly note, but RETIRED.

To be clear, I am not upset about the change itself. I have been arguing on this blog and in my work for years that SMS-based MFA is the weakest thing in your tenant and that phone-based methods belong in a museum. Microsoft is doing the right thing here. I just have a small, gentle, entirely reasonable request for Redmond: Could the identity-shaking announcements arrive in a week when I am not soaking up the sun around the Mediterranean with spotty internet connection and zero intention of reading Message Center? 😉

Anyway. Vacation is over, the coffee cup is filled, and this one deserves a proper post. Because the announcement tells you what is happening. It does not tell you what it does to the policies you already own, and that is the part worth reading before September.

Two changes, not one

Sources: Passkeys by default and retirement of Microsoft-provided SMS and voice authentication | Message Center MC1426371 | Microsoft Security Blog, 13 July 2026

Almost everything I have read about this treats it as a single announcement. It is two changes wearing one coat because they obviously are related, but you will plan much better if you separate them for now:

September 1, 2026: Passkeys become the default. Users enabled for SMS or voice get automatically enabled for passkeys, and your registration campaign gets switched on to nudge them. This one changes your policy configuration. Nothing breaks, but things move without you touching them and some of your end-users will see a new wizard on their screens.

February 1, 2027: Microsoft stops delivering SMS and voice. The telecom delivery is gone, SSPR included. Users whose only method is a phone number hit a registration prompt they cannot snooze or dismiss. This one is where productivity can come to a screeching halt if you do not prepare properly.

Two different problems. Plan them separately, or you will risk ending up doing the February work in a panic while still arguing about September. There are two dates in between which matter as well: September 18, 2026 for telecom provider options and terms, and October 30, 2026 for when you can actually configure one.

One scoping note before we go further: This timeline applies to public cloud only. Other cloud environments follow later on a schedule Microsoft has not published.

⚠️ Before we start, a word about what this post is. It is my reading of Microsoft’s documentation as of August 2nd, and nothing more than that. A change of this size, with two cutover dates still ahead of it, is going to move. Microsoft has already revised these articles since the announcement, and I expect they will again.

So use this to understand the shape of what is coming and to start planning. But check the source links, which I have put at the top of every section for exactly this reason, before you make a change in production. If something below no longer matches what you see on Microsoft Learn, Microsoft Learn wins.

Right. Let’s take them one at a time.

September 1, 2026: Passkeys by default

What changes without you touching anything

Source: Move users to passkeys

The retirement page spells this out in an Important callout, and it is worth reading slowly:

• Users enabled for SMS or voice in the Authentication methods policy (AMP), or in legacy MFA settings, are auto-enabled for passkeys in the same policy.
• Those users are put into a passkey profile allowing all types of passkeys.
• “Your Registration Campaign settings will be set to Microsoft Managed state targeting passkeys, and will automatically bring these users into scope.”
• When those users next sign in and complete MFA, the campaign nudges them to register a passkey.
• By default, users will have unlimited snoozes of the nudge prompt.

Note the legacy MFA settings part. If you still have users enabled for phone methods in the old per-user MFA settings, they count too. (BTW, I thought Microsoft said they would forcefully remove the legacy MFA options 🤔).

So on September 1, Microsoft reaches into a policy you own and changes its state. The page tells you the unlimited snoozes bit, which matters a lot. What it does not tell you is everything else that changes along with the state.

What Microsoft managed actually does

Source: Registration campaign

For that you need the registration campaign article. It states that when Microsoft managed is selected, the target authentication method, snooze duration and limited number of snoozes are set automatically and cannot be configured. It then lists the changes rolling out incrementally to tenants:

• Targeted authentication method changes from Microsoft Authenticator to passkeys (FIDO2).
• Days allowed to snooze changes to 1 day. No longer configurable.
• Limited number of snoozes changes to Disabled, meaning unlimited snoozes. No longer configurable.
• User targeting changes from voice call or text message users to all MFA capable users.

🤔 Unlimited snoozes, against a hard February deadline, with the snooze controls locked. Both articles agree on that part, so it is not a wording quirk. Think about that combination for a moment. Your users can dismiss this prompt forever, and you have no lever to tighten it. I hope you can see the issue with that.

One important thing you do keep. The same section says plainly that you can still configure include and exclude targets under Microsoft managed. Method and snooze settings go to Microsoft. Targeting levers stay with you.

Also worth knowing: A registration campaign can only target one authentication method at a time. If you are currently running an Authenticator campaign, it gets replaced with passkeys.

The targeting default changes underneath you 😱

🚨 This is the bullet I would put on a sticky note 🚨

“Microsoft managed” does not just swap the method being pushed. It also decides who the campaign is aimed at, and this is the part to get straight: It decides that only if you have not decided it yourself. Set your include targets and your selection applies. Leave them empty and “Microsoft managed” fills the gap with all MFA capable users, which is a much wider net than the SMS and voice population this whole change is supposedly about.

Read the small print carefully though. Microsoft tags two of those bullets with “This setting is no longer configurable”, specifically the snooze duration and the snooze limit. The user targeting bullet carries no such tag, and the sentence just above confirms you can still configure include and exclude targets.

So my honest interpretation is this: Microsoft managed changes your default targeting, not your ability to target. If you have explicit include targets, those still apply. If you do not, the default filling that gap is now considerably wider than your SMS and voice population.

That distinction is easy to miss and very uncomfortable to get wrong. Picture a tenant with 8000 users, all of them MFA capable. 200 of them are on SMS. You built this campaign expecting it to reach those 200. With no explicit include targets, the default that fills the gap on September 1 reaches all 8000. That is 7800 people you never planned to nudge, and worst case scenario 7800 more people who might call the service desk about it. Not all 8000 will see a prompt, since anyone who already has a passkey on that device and browser is skipped. But 8000 is the number the campaign is working from, and that is not what you configured.

The campaign can skip exactly the users you need it to reach

Both of these are in the registration campaign documentation.

Targeting specific AAGUIDs stops the method flip.

The registration campaign article states that if your passkey (FIDO2) authentication method policy targets specific AAGUIDs, then the Targeted authentication method setting in your registration campaign does not change to passkeys under Microsoft managed mode.

Be clear on what that means, because it is not the same as nothing happening. The campaign still runs. It just never becomes a passkey campaign. That same article describes the flip as going from Microsoft Authenticator to passkeys, so a campaign that does not flip presumably keeps nudging for Authenticator, though it does not spell that out. Either way, you may end up running a campaign you did not configure, pushing a method you may not have chosen.

The fix is in the same paragraph: Switch State to Enabled and configure passkey targeting yourself.

A hardened passkey profile suppresses the nudge entirely.

The registration campaign article states that under Microsoft managed mode, the nudge is evaluated per user, and the user’s passkey profile is checked first. If that profile has any of these, no nudge appears: Synced only, device-bound only, attestation enforced, or AAGUID restrictions.

Before I explain why that stings, one thing I have to repeat, because I still meet administrators who have not made this distinction: Scoping a user for an authentication method does not mean the user has set it up. The Authentication methods policy decides what a user is allowed to register. It does not register anything. A user can be perfectly scoped for passkeys and still have nothing but an SMS code on their account. Nothing in that policy changes it.

So what actually gets a credential registered onto an account? The user doing it. Either voluntarily, or because something prompted them. The registration campaign nudge is exactly that prompt, that’s the whole point of it.

Now put the two together. Say you built a device-bound, attestation-enforced passkey profile for your admins and executives, exactly as you should have. That authentication profile permits only the strongest passkeys, which is the right call. But that same hardening suppresses the nudge for those users, so nothing ever prompts them to actually register one. 😖

The result: Your most privileged accounts are allowed the best credential available, and are the least likely to be told to go and get it. So the campaign works perfectly for the people who matter least, and skips your Global Admins. Think about that for a second.

If you have hardened Passkey (FIDO2) profiles, those users need a separate plan. A targeted communication, a scheduled onboarding session, TAP issuance, whatever fits your organisation. Just do not assume the campaign covers them, because it does not.

To be clear: A passkey profile like this (screenshot below), will block the nudge from the registration campaign, and you risk that these accounts will not configure a passkey until it is too late.

Other reasons a user might never see the nudge

The passkey profile restrictions above are the ones most likely to catch a well-configured tenant, but they are not the only way a user slips through. The registration campaign article documents a long list, and it is worth knowing before you conclude your campaign is broken.

The nudge is per device and browser, not per account. This is the one that surprises people. When a user signs in, the campaign checks whether they already have a local passkey for that specific device and browser combination. If they do, no nudge. If they do not, they get nudged, even if they have passkeys elsewhere. So a user with Windows Hello for Business is skipped on their Windows machine but can be prompted on their Mac. Same account, same day, different result. The article includes a platform table showing which credential types suppress the nudge on which operating system and browser, and it is worth a read before you start fielding “why did it ask me again” tickets.

The rest of the list:

• Inside an existing SSO session. If the user is already signed in, the nudge does not trigger.
• Linux. Never nudged, because FIDO2 passkeys aren’t available on Linux.
• Out-of-box experience. No nudge during OOBE, or in browser views embedded in Windows settings. Campaigns do work in embedded browser views in some other applications. If you were hoping to catch users during device provisioning, this is not the tool.
• Immediately after registering something else. A user who just completed MFA registration is not nudged again in the same session.
• Terms of use. No nudge if a terms of use screen is presented during sign-in.
• Conditional Access custom controls. No nudge if the user is redirected by custom controls.
• Conditional Access blocking the Register security information page. No nudge if a policy puts that page out of reach.

That last one deserves your full attention if you have hardened your registration path, and I come back to it in the February section. It is the difference between a campaign that quietly underperforms and a user who cannot recover their account at all.

What to do before September 1

1. Record your registration campaign state before Microsoft changes it

Source: Run a registration campaign

Do this today. It takes two minutes and it is the difference between knowing and guessing in September.

1. Sign in to the Microsoft Entra admin center as at least Authentication Policy Administrator.
2. Browse to Entra ID > Authentication methods > Registration campaign.
3. Record the current State, the targeted Authentication method, Days allowed to snooze, Limited number of snoozes, and your include and exclude targets.

Keep it somewhere you will find it later. If/When Microsoft changes your registration campaign, you will be able to see exactly what changed and can act accordingly.

2. Decide who runs your campaign, you or Microsoft

Sources: Enable passkeys (FIDO2) | Proactively drive adoption with a registration campaign

Here I disagree with Microsoft, but you must decide yourself for your own tenant. The retirement article’s recommended procedure is to set State to Microsoft Managed and target your SMS and voice group. That is their official guidance.

I would set State to Enabled instead. Under Microsoft managed you cannot configure the targeted method, the snooze duration or the snooze limit. Unlimited snoozes against a hard February deadline is a bad combination, because a user can dismiss the prompt indefinitely and you have no way to tighten it. Under Enabled, you can cap snoozes at three and force registration once they run out. Microsoft’s route is defensible and less work. Just go into this knowing what you handed over to them.

The obvious follow-up question is this: If I set State to Enabled today, does it stay Enabled on September 1, or does Microsoft change it anyway? I cannot answer that, because I don’t know and the two articles point in different directions.

• The retirement article says your Registration Campaign settings will be set to Microsoft Managed state targeting passkeys. No conditions, no exceptions, no “unless you configured it yourself”. Read literally, your Enabled state gets overwritten.
• The registration campaign article defines the Graph state property as enabled, disabled or default, and describes default as the value used when the configuration hasn’t been explicitly set. In the portal, default is what appears as Microsoft managed. Read that way, Microsoft managed is a fallback for tenants that never configured anything, and an explicit Enabled should survive untouched.

Again, the way I personally interpret this: Those are two different claims about the same setting.

What I would suggest you do: Set State to Enabled anyway. It is the better configuration either way. If it survives the September 1 rollout, you keep your snooze controls and you have lost nothing. If Microsoft overwrites it, you are no worse off than the tenant that did nothing. Then watch the blade over the following weeks and find out which it was, be aware that the implementation is incremental and begins on September 1st. It may take days or weeks before your tenant is affected.

First, the prerequisites. Passkey (FIDO2) must be enabled, and self-service setup must be on:

1. Sign in to the Microsoft Entra admin center as at least Authentication Policy Administrator.
2. Browse to Entra ID > Security > Authentication methods > Policies.
3. Select Passkey (FIDO2). If you have not opted in to passkey profiles, select the link in the banner text.
4. 🚨 Stop before you click. The enable passkeys article states that after you opt in to passkey profiles, you can’t opt out. Your existing global settings transfer to a Default passkey profile. You are limited to ten profiles including the Default.
5. On the Configure tab, set Allow self-service set up to Yes. If this is No, users cannot register a passkey through Security info even when passkeys are enabled. This is a global setting, not per profile.
6. Select the Default passkey profile, choose your Passkey types, and select Save.

Then the campaign:

1. Browse to Entra ID > Authentication methods > Registration campaign and select Edit.
2. Set State to Enabled.
3. For Authentication method, select Passkey.
4. Set Days allowed to snooze and Limited number of snoozes deliberately. Days allowed to snooze accepts 0 to 14, and 0 means the user is nudged on every single MFA attempt. Limited number of snoozes set to Enabled forces registration after three skips. This number of skips can’t be configured.
5. Set your include and exclude targets. I suggest you start with a pilot group and follow it up.
6. Select Save.

✅ Verify: Sign in with a pilot account that has no passkey registered, complete MFA, and confirm the nudge appears. Then confirm a user in an excluded group is not nudged.

📌 And note the date. Whatever you configure here, write down what you set and when. Then check it again periodically, because this is not a single-day event. That is a five-minute job that tells you something the documentation currently will not.

❗ Troubleshooting: If nobody sees a nudge, work the suppression list before assuming it is broken. Check the user’s passkey profile for synced-only, device-bound-only, attestation or AAGUID restrictions. Check you are not inside an SSO session. Check for a Conditional Access policy blocking the Register security information page, a terms of use screen, or custom controls.

3. If you are not ready, use the opt-out

Source: Temporary opt-out

A temporary opt-out is available for the September 1 through February 1 changes, and the call is published:

PATCH https://graph.microsoft.com/beta/policies/authenticationmethodspolicy
Content-Type: application/json

{
   "optOutSettings": {
     "passkeyDynamicMigration": true
   }
}

Set passkeyDynamicMigration to true and your tenant is excluded from the automatic passkey enablement and the Registration Campaign rollout during the opt-out period. Note the endpoint is /beta, not /v1.0.

❗ Before you feel relieved. The documentation states that beginning February 1, 2027, the standard passkey migration and enforcement timelines apply regardless of this setting. The opt-out buys you September to February. It buys you nothing after that. Use it to buy planning time, and spend that time wisely. 🚨 Ignore or forget at your own risk! 🚨

4. Or move users out of scope

The documented way to avoid the auto-enablement is to move users out of SMS or voice scope in the Authentication Methods Policy before September 1.

1. Sign in to the Microsoft Entra admin center as at least Authentication Policy Administrator.
2. Browse to Entra ID > Protection > Authentication methods > Policies.
3. Select SMS. On the Enable and Target tab, set the target to No users, or scope it to a small named group that genuinely needs it.
4. Repeat for Voice call.
5. Select Save.

⚠️ An honest gap. In my February post I covered the SMS Use for sign-in toggle, which keeps SMS for password reset while removing it as a sign-in method. What I do not know, and could not find documented anywhere, is whether setting that to No is enough to take a user out of “SMS scope” for the September 1 auto-enablement, or whether only the Enable and Target scope counts.

February 1, 2027: SMS and voice are gone

What actually breaks

Source: After retirement

🚨 This is the date that changes whether people can work.

Microsoft-provided SMS and voice delivery is retired in Entra ID. If your tenant still has users enabled for phone methods and you have not configured a customer-managed telecom provider, those users can no longer use SMS or voice to complete MFA and sign in as usual.

After that date, users whose only available MFA method is SMS or voice are required to register a passkey during sign-in. The prompt is blocking, so they cannot continue signing in until they do.

Straight from the documentation: “There is no opt out from this February 1 behavior. It will be enforced for all tenants.”

It is not an account lockout, and the FAQ is explicit about that. No data loss, no disabled accounts. Just a registration prompt the user cannot get past.

Useful distinction when management asks, but your service desk will not care about it when the phones start going on February 2nd. 😉

SSPR goes too

The retirement applies across Entra, and the FAQ is explicit that this includes self-service password reset. If your users can reset their password with an SMS code or voice call today, that stops on February 1, 2027, unless you have configured a customer-managed telecom provider.

Microsoft also says it plans to introduce support to change password for users who authenticate with passwordless sign-in, with more details to come. So that part of the story is not finished.

The bootstrap problem (that Conditional Access policy I told you to build)

Sources: How to enable passkeys (FIDO2) | Registration campaign FAQ

In February I wrote Passkey onboarding in Entra: What Microsoft doesn’t tell you, and recommended a Conditional Access policy on the Register security information user action requiring an authentication strength that accepts Temporary Access Pass. If you built that, you are in better shape than most tenants. Here is why.

Two documented facts:

1. Users must complete MFA within the past five minutes before they can register a passkey.
2. No nudge appears if a Conditional Access policy blocks access to the Register security information page.

Now add SMS disappearing to the equation:

A user whose only working method is SMS cannot satisfy an MFA challenge once SMS is gone. So they cannot satisfy the five-minute rule. So they cannot register the passkey the blocking prompt demands. And if you hardened the registration path with a phishing-resistant-only authentication strength, they cannot reach the page at all.

To be clear, that chain is my own reasoning from two documented facts. Microsoft does not say anywhere that a user ends up stuck. I would hope the blocking prompt is built so the passkey registration happens right there in the sign-in flow, which would make the whole problem go away. But nothing in the documentation says that.

What you can test today is your own half of it. Take a test account whose only method is SMS, remove the user from the SMS-scope in Authentication methods, and see whether your Conditional Access policies still let that user reach Security info to register something new (I’m pretty sure that will fail). If they cannot, you have just watched your February 1st problem in advance.

That is the whole point. If TAP is in place, it does not matter how Microsoft built the prompt, because you have a way to get a legitimate user back on their feet either way. Build for the case where you do not know the answer, because right now nobody does. This is the same argument I have been making for years: Temporary Access Pass (TAP) is not optional in a passwordless transition. It is what lets a legitimate user bootstrap a credential when the old one is gone, and what stops an attacker doing the same. Assume breach. Build the TAP process before September, not in February when the phones start ringing.

Guests are in scope, and cannot register the replacement

Sources: B2B passkey support | Enable passkeys, Known issues

The retirement FAQ says passkey support for B2B and internal guest users is planned by the end of calendar year 2026, and that these users are included in the scope of the retirement.

The enable passkeys article, under Known issues, says registration of passkey credentials isn’t supported for internal or external guest users, including B2B collaboration users in the resource tenant.

So guests lose phone-based MFA on February 1, 2027, and cannot register the replacement today. “Planned by end of 2026” means it has to ship, and ship with enough runway for you to actually deploy it.

If you enforce MFA for guests, and I hope you do, put this on your risk register now and follow up on it. Do not assume it resolves itself.

So is there a workaround?

Probably, and it is Microsoft Authenticator, though you will not find Microsoft saying so.

The February 1 prompt fires only for users whose only available MFA method is SMS or voice. A guest with Authenticator does not meet that condition. And we know guests can register Authenticator. So Authenticator plugs the hole.

Two things before you relax though.

• Microsoft’s own guidance for this migration names passkeys, Windows Hello and FIDO2. Authenticator push is not on that list, because push is not phishing-resistant. It survives AiTM about as well as SMS does. It buys you time, and time is worth buying, but it does not fix the underlying issue which is MFA methods vulnerable to phishing.
• Note what the documentation does not say. Neither the retirement article nor the registration campaign article states that Authenticator is the answer for guests, and neither says the blocking prompt will accept anything other than a passkey. If you are relying on this, test it with a real guest account well before February.

If you genuinely need a phone channel

Source: Evaluate a telecommunications provider

If you operate in a regulated industry or have a real operational need for a telecoms channel, you can contract a provider through the Microsoft Security Store.

1. Identify the specific user segments with a genuine regulatory or operational need, and document it. Which regulation, which scenario.
2. From September 18, 2026, review the providers and terms available in the Security Store.
3. From October 30, 2026, select and configure a provider.
4. Stand up the carrier contract and test with a pilot group before broad rollout.
5. For every other segment in your tenant, default to passkeys.

Costs are per-message and vary by provider, region and volume, so this is a budget conversation as well as a technical one. Migrating users to passkeys instead carries no additional cost.

What to do before February 1

1. Find out who is affected

Source: microsoft/entra-sms-voice-usage-analyzer

Microsoft published a PowerShell script that reads your SMS and voice policy state and scope, shows your current registration campaign state, exports targeted groups and users to CSV, and prints an impact summary.

It needs the Policy.Read.All and Group.Read.All scopes, and a minimum role of Global Reader, Authentication Policy Administrator or Security Reader.

Install-Module Microsoft.Graph.Authentication -Scope CurrentUser
Install-Module Microsoft.Graph.Identity.SignIns -Scope CurrentUser
Install-Module Microsoft.Graph.Groups -Scope CurrentUser

.\Get-SmsVoicePolicyUsers.ps1 -TenantId "contoso.onmicrosoft.com"

💡 You need two lists, and Microsoft’s script only gives you one. The script above reports policy scope, which decides who gets auto-enabled on September 1. It does not tell you who has actually registered a phone number, which then decides who is blocked on February 1. Those are different people.

The native option for the second list is the Authentication methods activity report, filtered on the phone methods. It gets you started, but it will not tell you which of those accounts hold privileged roles, when they last signed in, or which are shared mailboxes and room accounts that should have been disabled years ago. It also leaves out disabled accounts entirely, and those have a habit of being re-enabled at the worst possible moment.

This is exactly why I built I.D.E.A. #004 back in June. It turns out to be the report I would have written for this migration specifically. It scores every account on the strength of what is registered, and the tier it calls Weak only, along with the High risk score, is your February 1 population, named and listed. The Good versus Secure distinction matters here too: A user with FIDO2 and SMS both registered looks fine in most reports, but the SMS is still there, and on February 1 it is still going away.

If you only run one thing this week, run that. It gives you the list, and the list is what everything else in this post depends on.

2. Fix your break-glass accounts

Go and look at them. Right now, before you finish reading.

If any break-glass account has a phone number as a fallback, that fallback stops working on February 1, 2027. These accounts belong on FIDO2 security keys, stored physically separated, documented in a way that does not depend on the identity system you are trying to recover.

And while you are in there, confirm they sit in a Restricted Management Administrative Unit. Yes, I am going to keep mentioning RMAUs. They are still underused and I am still right about them. 😉

3. Communicate, properly

Microsoft recommends a phased plan, and it matches what actually works in the field:

1. Awareness: Announce that SMS and voice are retiring, explain why, and tell users which method they move to.
2. Action: Direct users to register a passkey, with step-by-step guidance for their device type.
3. Reminder: Chase the ones who have not done it.

👉 Templates are available at aka.ms/mfatemplates. Scope your messaging to the SMS and voice group you built earlier, so the right people hear from you at the right time.

What is not changing

There has been some panic about this, so let me try to clarify.

The retirement is scoped to SMS and voice authentication method policies and legacy MFA policies. Microsoft Authenticator is not in it. Push notifications, TOTP codes and passkeys in Authenticator all continue. External MFA providers aren’t in scope either, unless those users are also enabled for SMS or voice. Users already on a phishing-resistant method keep using it.

Passkeys also cost nothing extra. They are available in every Entra ID edition including Free, with no additional licenses.

To be clear though: Authenticator push surviving is not permission to stay there. Push is not phishing-resistant. This retirement removes the worst option, it does not bless the second-worst one.

January 28 or February 1?

Source: microsoft/entra-sms-voice-usage-analyzer

As of August 2nd: The first-party PowerShell script I linked above is genuinely useful. But the impact summary it prints to your console gives the retirement date as January 28, 2027. Every other Microsoft source says February 1, 2027.

Four days, perhaps a rollout window or shifting date? Regardless you should NOT plan to land this migration in the last week of January! Please prepare for this change as early as you can. (Yes, I have reported this to Microsoft).

A checklist to get you moving

• Inventory: Policy scope and registered methods. Both. They are different lists.
• Baseline: Record your registration campaign configuration today, in every tenant.
• Break-glass: FIDO2 keys, no phone fallback, in an RMAU.
• Conditional Access: Audit anything touching the Register security information user action.
• Passkeys: Enable deliberately. Passkey profiles are a one-way door.
• Campaign: Decide consciously between Enabled and Microsoft Managed, and set your include targets explicitly.
• TAP: Build a secure issuance and delivery process before you need it.
• Opt-out: Make a conscious decision, and remember it expires on February 1.
• Guests: Separate plan. Track whether B2B passkey support actually ships.
• SSPR: Remove phone dependency from reset flows.
• Telecom: Only if you can name the regulation and the scenario. Review from September 18, configure from October 30.
• Comms: Awareness, action, reminder.
• Test: In your own tenant, with a real SMS-only account, before December.

Closing thoughts

Honestly: I am genuinely glad this is happening. 👍

SMS-based MFA has been the weakest link in far too many tenants for far too long, and every year we spent politely nudging people off it was another year of SIM-swap and adversary-in-the-middle attacks working exactly as designed. Microsoft removing the option is the correct call and I will defend it.

What I am less relaxed about is the shape of the change. Silent modifications to policies you own. Unlimited snoozes with the controls locked, against a hard deadline. A targeting default that quietly widens if you never set explicit include targets. And the one that still bothers me most: A nudge that skips your admins and executives precisely because you built them a properly hardened passkey profile.

So do not panic. Take a deep breath. Read the small print, configure this yourself instead of inheriting whatever Microsoft decides, and then test it in your own tenant. That last part is not optional. It never is.

September 1 is close. February 1 is not far behind it. That is enough time to do this properly, with a pilot, a TAP path and a communication plan, if you start now. It is nowhere near enough if you start in the new year.

👉 Start with the inventory this week. Find the accounts that have nothing but SMS or voice on them, because those are the ones that stop working. Everything else follows from knowing who is affected.

And Microsoft, if you are reading: I am taking a week off in October. Just so you know. 😁

Thank you all for reading, and as always, stay safe out there!