Entra Passkey FAQ: What to Tell Clients Before September 1

Entra Passkey FAQ: What to Tell Clients Before September 1
Microsoft just made the biggest change to Microsoft 365 authentication in years, and it lands in every tenant automatically. Starting September 1, 2026, passkeys become the default sign-in method in Entra ID. Starting February 1, 2027, Microsoft-provided SMS and voice MFA retires for good.
If a client hasn't asked you about this yet, they will. The empowering.cloud team put it well in their August update: "six months sounds like a long time." For a client with a few SMS stragglers, it is. For an MSP managing SMS users across dozens of tenants, it isn't.
This post covers the questions we expect SMB end users to ask their MSP, plus the operational questions MSPs are already asking each other on threads like r/msp and in early migration write-ups. Answer these before your clients call you about them.
The Timeline, in Plain Terms
| Date | What Happens |
|---|---|
| September 1, 2026 | Passkeys become the default sign-in experience. Any user currently enrolled in SMS or voice MFA gets auto-enabled for passkeys and nudged to register one at their next sign-in. Microsoft makes this change to the tenant's authentication methods policy automatically. Users can skip the nudge (with unlimited snoozes) unless an admin turns that off. |
| September 18, 2026 | Microsoft publishes more detail on customer-managed telecom providers for organizations that need to keep SMS or voice. |
| October 30, 2026 | Approved telecom providers become available in the Microsoft Security Store. This is the path for clients with a real business reason to keep SMS or voice MFA. |
| February 1, 2027 | Microsoft-provided SMS and voice MFA retires. There is no opt-out. Any user whose only MFA method is SMS or voice gets a blocking prompt to register a passkey before they can sign in. |
Two things worth repeating to every client: the September 1 change happens automatically, whether you act on it or not. And February 1, 2027 is a hard wall, not a soft deadline you can negotiate with a support ticket.
What Your Clients Will Actually Ask
These are the questions an SMB employee is going to bring to their MSP once they see a passkey prompt for the first time. Keep the answers short and jargon-free. Nobody wants a security lecture when they're trying to check email.
Q: "What is a passkey? Is it a password?"
No. A passkey is a credential tied to your device, unlocked with your face, fingerprint, or PIN. There's nothing to type and nothing to remember. It's also harder to phish than a password, because it only works on the real Microsoft sign-in page, not a lookalike one.
Q: "Do I have to set this up on every device I use?"
Yes, on any device where you sign in directly. Once it's set up, sign-in is faster than typing a password and a code, not slower.
Q: "What if I lose my phone?"
This is the most important question to get ahead of, not react to. Every user should register a second method (a second device, or a backup passkey) before they're relying on just one. If a client loses a phone with their only passkey on it, recovery goes through your help desk, not Microsoft support. Set that expectation now, and it'll save both of you unnecessary tickets later.
Q: "Can I just keep using text message codes?"
Not after February 1, 2027, unless your MSP has set up a paid, customer-managed telecom provider through the Microsoft Security Store for that client. That's a real conversation to have with clients who have a specific reason to stick with SMS (older devices, regulatory requirements, etc.), and it comes with an added cost that passkeys don't.
Q: "Is this actually safer, or is Microsoft just pushing something new?"
It's genuinely safer. Passkeys can't be phished the way a password or a text code can, because there's no shared secret to steal or trick someone into typing into a fake site. This is also why Microsoft, Google, and Apple have all been moving in this direction for the last two years. It's not new hype. It's catching up to how identity attacks actually work now.
Q: "What happens to former employees' accounts?"
Nothing changes about offboarding. If an account is disabled when someone leaves, their passkey stops working with it, same as a password would. This is a good moment to double check that offboarding actually disables accounts promptly. That's a policy gap, not a passkey problem.
What MSPs Are Asking Each Other
These are the operational questions we're seeing MSPs work through right now, based on early migration guidance circulating in the community.
Q: "How do I find out which of my clients' users are still on SMS or voice?"
Run a scan across the tenant's authentication methods before September 1. Waiting means you're reacting to a Microsoft-driven change instead of controlling the timeline yourself. This is exactly the kind of tenant-wide visibility question that's hard to answer manually across more than a handful of clients, and it's a good gut check on whether your current tooling can answer it in minutes or requires digging through each tenant one at a time.
Q: "Can I stop Microsoft from auto-enabling passkeys while I plan?"
There's a temporary opt-out for the registration nudges, but it only delays the prompting, not the underlying policy change or the February 1 retirement. Every migration plan should work backward from February 1, regardless of what you do in September.
Q: "Does this cost my clients anything?"
Migrating users from Microsoft-provided SMS or voice to passkeys costs nothing extra. Keeping SMS or voice past February 1, 2027 requires a customer-managed telecom provider from the Security Store, and that comes with per-message pricing that varies by provider and volume. This is a real conversation to have with any client who resists the change: doing nothing isn't actually free, it's just deferred.
Q: "How do I roll this out without burying the help desk in tickets?"
Stagger it. Don't wait for the September auto-enable to force a scramble. Communicate early, register passkeys for your highest-risk or highest-privilege users first (admins, finance, anyone with access worth protecting), and use the lead time between now and February to work through the rest in batches.
The Bigger Point for MSPs
This is the kind of change that's easy to file under "Microsoft stuff, not my problem" until a client calls confused or locked out. The MSPs who come out ahead here are the ones who get in front of it: proactive client emails, a clear internal cutover plan, and a way to see, across every tenant, who's still exposed before Microsoft decides for them.
If you're managing more than a handful of tenants, that last part is the hard one. Knowing who's on SMS or voice in one client's tenant is a five-minute check. Knowing it across 30 tenants at once, and getting a clear list of exactly who needs to move, is a different kind of problem. Get ahead of it now, and you're the MSP who called this before Microsoft forced the issue. That's the kind of proactive move clients remember at renewal time.
Sources: Microsoft Entra ID documentation on the SMS and voice MFA retirement and its FAQ; empowering.cloud's August 2026 Microsoft 365 update.