Afterthoughts: I said SMS and voice were being removed

My last post was a long one, and long posts have a way of leaving something behind. This is the bit that kept nagging at me afterwards, plus one practical thing I want to spell out properly rather than in a paragraph buried deep in a long post like the previous one.

Let’s start with the nagging.

The correction I (perhaps) owe you

Source: Evaluate a telecommunications provider in the Security Store

Throughout that post I wrote things like “SMS and voice are gone” and “the date SMS disappears”. While punchy and direct, it is not strictly accurate. But to be honest about that, I’m actually not sure I want to be accurate. 😮 And this is why:

What retires on February 1, 2027 is Microsoft-provided SMS and voice, as in the delivery. Microsoft stops paying the carriers and stops sending the messages. SMS and voice as authentication methods do not physically vanish from Entra ID. If you contract a telecom provider yourself through the Microsoft Security Store, from October 30, 2026, your users can carry on receiving codes and calls exactly as they do today. You just pay for the messages, per message, at rates that vary by provider and region.

So the accurate version is that Microsoft is getting out of the business of delivering your MFA codes. That is not the same as SMS being banned/deprecated.

While the first reaction may be that I should have written it that way, because precision matters on this blog, the honest truth is that I don’t want people to use another telecom delivery, and I fear that for many this may be the “easy way out” of implementing passkeys and remove SMS/voice as MFA factor.

And to be completely honest, I am convinced that many people will go for the easy way out, instead of removing SMS/voice and transition to passkey because, for many people, this seem like more work and higher risk of non-productivity because of access is blocked for the users temporarily.

So why did I skate past it?

Because I found it genuinely difficult to write the sentence “here is how you keep using SMS” without immediately wanting to add “please don’t“. And I am afraid that the “please don’t” in the end will be ignored. That is my opinion and prediction. But this is far from the first time I’ve written my own opinions and evaluations in here. It’s OK to disagree.

SMS-based MFA is compromised as a control. This is not theory, and it is not some edge case. It happens routinely and at scale.

If you want the evidence, CISA has been saying this for years. Their Implementing Phishing-Resistant MFA fact sheet walks through SS7 exploitation and SIM swap, and ranks MFA methods by how easily each one falls. Then in December 2024, after the Salt Typhoon telecom intrusions, CISA and the FBI issued joint mobile communications guidance that does not hedge at all: “Do not use SMS as a second factor for authentication.“

And buried in that same document is the point I have been making all year. CISA tells you to go and disable SMS on each account after enrolling in something better, because enrolling in a stronger method does not remove the weaker one. The fallback stays there, waiting.

And there is a lot of waiting for it. SIM swap. Number port-out. SS7 interception. Social engineering the mobile operator’s retention team, who are paid to be helpful. And underneath all of it, SMS falls to adversary-in-the-middle phishing exactly the way a password does, because a code the user types into a page is a code the attacker in the middle also receives.

These are not hypotheticals. They have been used in real breaches, repeatedly, for years! So when Microsoft finally removes this convenient (but very flawed) security measure, my instinct is not to write a helpful guide to putting it back. My instinct is to say: This is the moment. Take it!!

The floppy drive argument

I have been building my own computers for most of my life. Somewhere in a box in this house there is almost certainly a working floppy drive, and a DVD-ROM, and a bracket for mounting them.

I have not installed either in a home build in many years. Not because they stopped working, but because at some point the industry stopped shipping the port and the whole ecosystem moved on. And it moved on faster precisely because the old thing was no longer sitting there as an easy option. Every year that a motherboard shipped with a floppy header was a year somebody had a reason not to bother learning something better.

Sometimes the drastic move is the correct one. But I’m sure you’ve seen this pattern many times: You cut the old thing, people complain for a while, and then everyone forgets it existed.

The analogy has a limit, though, and the limit is the important part. An unused floppy drive in your case is just clutter. It is not a security problem. Leaving SMS enabled in your tenant is not the same kind of leftover. People are actively attacking it, and they are attacking it because this attack works. The cost of keeping the old option around is not nostalgia and a wasted drive bay. It is an active, exploited attack path that sits there being the weakest thing an attacker has to beat.

That is why I do not want the telecom provider route to become the default answer to this change. I am sure it exists because some organisations may have genuine regulatory obligations, and some have frontline populations with no smartphone and no realistic alternative today. Those are real, and if that is you, go and configure a provider properly. Though I am also sure that they are not the only ones who will go this route….

But “we have always done it this way” is not one of those reasons. Neither is “the project would be easier if we did not have to migrate anyone”. If you cannot name the regulation or the specific population, you do not have a case for keeping it. You have an excuse for not moving on, and Microsoft has just taken that excuse away from you. 🙂 And kinda not because of the option with telecom provider…

Right, the practical bit: How to postpone September 1

Source: What if I have different plans for my tenant?

I mentioned the temporary opt-out in the last post but only gave you the raw Graph call. Several people asked for it in PowerShell, so here it is properly.

This excludes your tenant from the September 1 automatic passkey enablement and from the Registration Campaign being switched to Microsoft Managed.

You need the Policy.ReadWrite.AuthenticationMethod scope, and Authentication Policy Administrator is the least privileged role supported for updating this policy.

Connect-MgGraph -Scopes "Policy.ReadWrite.AuthenticationMethod"

$uri = "https://graph.microsoft.com/beta/policies/authenticationmethodspolicy"

# 1. Look at what is there now, before you change anything
$policy = Invoke-MgGraphRequest -Method GET -Uri $uri
$policy.optOutSettings

# 2. Set the opt-out
$body = @{
    optOutSettings = @{
        passkeyDynamicMigration = $true
    }
} | ConvertTo-Json -Depth 3

Invoke-MgGraphRequest -Method PATCH -Uri $uri -Body $body -ContentType "application/json"

# 3. Confirm it took
$policy = Invoke-MgGraphRequest -Method GET -Uri $uri
$policy.optOutSettings

✅ Verify: Step 3 should return passkeyDynamicMigration set to True. If it comes back empty or the property is missing, the PATCH did not apply. Check your scope and your role before you assume it worked.

Below: Top arrow shows empty output so the value was not set. Bottom arrow shows output that the PATCH applied and we sept 1 one change has been postponed.

A few notes on this, because I do not want anyone caught out:

• The endpoint is /beta. Not /v1.0. Beta endpoints can change without notice, so re-check this before you rely on it in an automated process.
• Microsoft documents this as a raw Graph call. The PowerShell above is my wrapper around their documented call, not something Microsoft published. Run it in a test tenant first, as you should with anything you read on a blog. Including mine. 😉
• Reversing it is not documented. Setting passkeyDynamicMigration back to $false is the obvious way to opt back in, and I would expect it to work, but Microsoft does not spell that out. Do not find out for the first time in a production tenant.

🚨 And now the part I really need you to read🚨

That opt-out buys you exactly one thing: The September 1 changes stop happening in your tenant during the opt-out period.

👉 It does not move February 1, 2027. Not by a day. 👈

Straight from the retirement article: Beginning February 1, 2027, the standard passkey migration and enforcement timelines apply regardless of this setting. Elsewhere on the same page Microsoft is blunter still, saying there is no opt out from the February 1 behaviour and that it will be enforced for all tenants.

So think carefully about what you are actually buying here. You are not buying an extension, just 5 months of silence on this exact matter.

❗ And quiet is dangerous, because the September 1 nudges are the thing that would have started moving your users for you. Turn them off and nothing happens in your tenant for five months. No prompts, no registrations, no gradual progress, no early complaints telling you which part of your plan does not survive contact with real people. Then February arrives, and every user who never got round to registering anything but SMS or voice hits a blocking prompt. 😱

If you use the opt-out, you are taking personal responsibility for the migration that Microsoft’s automation would otherwise have driven. That is a completely reasonable trade, and in a tenant with a hardened passkey profile or a carefully built Conditional Access setup it may well be the right one. But it only works if you actually do the work.

So if you run that PATCH, put these in your calendar before you close the terminal:

• This week: Inventory. Which accounts have nothing but SMS or voice registered. That list is your whole project.
• September: Your own registration campaign, on your terms, State set to Enabled, scoped to a pilot group.
• October: Pilot done, findings folded back in, communications drafted.
• November: Broad rollout. Chase the stragglers.
• December: Everyone migrated, with a full month of margin before the holidays eat your change windows.
• January: Nothing. That is the whole point of the previous five rows. 😉

If that calendar looks empty by October, turn the opt-out off and let Microsoft’s nudges do the work for you. There is no shame in that at all.

What is not fine is opting out, doing nothing, and finding out on February 1st that postponing it actually meant forgetting about it.

Closing thought

I stand by the tone of the last post. This change is good, it is way overdue, and the direction is unarguably right.

The correction is only that “SMS and voice are gone” perhaps should have been “Microsoft-provided SMS and voice are gone, and you can pay someone else to keep them if you must“. You can. I would just like you to think very hard before you do, and to be able to say out loud which regulation or which population makes it necessary. I borderline want to bury this option completely because I am sure this will be treated by many as an easy exit instead of going the longer route to better security.

Everything else stands, so get your inventory done, and I.D.E.A. #004 is great for exactly that. Get a TAP process in place. Start onboarding passkeys. And then start removing SMS and voice altogether, because that is the actual finish line here.

There are two traps ahead of you, and they fail differently. The opt-out just defers the problem, and February arrives regardless. The telecom provider does not defer anything, it keeps the weakest method in your tenant alive indefinitely, and you pay per message for the privilege.

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