Forging Valyrian Steel: Your Post-SMS Path to Phishing-Resistant MFA

Alright, Guardians. Last time I told you the Wall was coming down. Microsoft provided SMS and voice authentication is on its way out of Entra ID for MFA and SSPR alike. The prompts started September 1, 2026. Delivery ends for most users on February 1, 2027 and for Global Admins and external users on July 1, 2027.

That post was about what's going away. This one is about what replaces it.

In Westeros, ordinary steel breaks against the things that come from beyond the Wall. Only Valyrian steel holds. It's rare, it's forged with care, and once you have it, you don't go back. Phishing-resistant MFA is our Valyrian steel. In Destiny terms, it's an exotic you build the whole loadout around, not a blue drop you swap out next week.

The good news: you have more blades to choose from than ever and most of them don't need a phone number. Let's forge them.

What "phishing-resistant" actually means

A phishing-resistant method can't be handed to an attacker, even by a user who is completely fooled. The credential is cryptographically bound to the real sign-in site. If a user lands on a fake Microsoft login page, the key simply won't answer, because the domain doesn't match.

That's the line SMS, voice, email codes, and OATH codes all fail. A user can read a code to a convincing caller or type it into an adversary-in-the-middle proxy and the attacker walks away with a session.

Microsoft Authenticator push with number matching is a big step up from SMS but it isn't the finish line either. A user who approves a prompt on a phishing page still approves it. Think of push as the bridge you cross, not the castle you live in.

In Entra ID, the phishing-resistant set is:

• Passkeys (FIDO2): on a security key, in Microsoft Authenticator, or synced through a passkey provider
• Windows Hello for Business
• Platform SSO Secure Enclave keys on macOS
• Certificate-based authentication with smart cards, when configured as multifactor

These all satisfy the built-in Phishing-resistant MFA authentication strength in Conditional Access. That's how you'll enforce it later.

The three blades

You don't need every method. You need the right one for each kind of user, plus a backup.

Passkeys: the everyday blade

A passkey is a FIDO2 credential. Entra ID supports two kinds, both generally available:

• Device-bound passkeys live on one piece of hardware: a FIDO2 security key or Microsoft Authenticator on the user's phone. They can't be copied off it.
• Synced passkeys live in a passkey provider like iCloud Keychain, Google Password Manager, or a third-party manager and follow the user across their devices. Recovery is easier, at the cost of trusting that provider's account security.

You control both through passkey profiles in the Passkey (FIDO2) policy. Each profile sets attestation, which passkey types are allowed, and which authenticators (by AAGUID) are allowed or blocked. You can target each profile to a group. Passkeys are included in every Entra ID edition, Free included, so there's no extra license to argue about.

My split: device-bound with attestation enforced for admins and high-risk users and synced allowed for everyone else. That lines up with Microsoft's own example profiles.

FIDO2 security keys: the blade with no phone attached

A hardware key in a pocket or on a lanyard. No app, no battery, no personal device. Microsoft recommends security keys as the primary portable credential for admins and highly regulated users. They're also your answer for anyone who can't or won't use a phone (more on that in the next section).

Budget for two keys per user where you can. One gets lost; the other gets them back in.

Windows Hello for Business: the blade already in the hilt

Windows Hello for Business turns the Windows sign-in itself into a phishing-resistant credential, bound to the device's TPM and unlocked with a PIN or biometrics. Users already unlock their laptop every morning. Now that gesture is the MFA.

It's a local credential, so it only helps on that device. Pair it with a portable credential (a passkey or security key) so users can still sign in from a new or borrowed machine. For hybrid environments, use cloud Kerberos trust; it's the simplest model to deploy.

One newer option to watch (in preview as of this writing): Microsoft Entra passkeys on Windows store a device-bound passkey in the Windows Hello container without needing the device to be Entra joined or registered. Microsoft also recommends it for shared Windows devices.

The users without a phone

This is the question I get in every engagement: "What about the people who don't have a company phone, won't put work apps on their personal one, or can't carry a phone on the floor?"

SMS let us dodge that question for years. It's about to stop letting us. Here's how I handle the common cases:

Two practices make this work at scale:

• Temporary Access Pass (TAP) is the on-ramp. A TAP is a time-limited passcode the service/help desk issues after verifying the user. The user signs in with it once and registers their first phishing-resistant credential. No phone needed at any point.
• Register keys on the user's behalf. For large frontline groups, IT can enroll FIDO2 keys for users before handing them out, through Microsoft Graph (in preview as of this writing). The user receives a key that already works.

The hard part is usually not the tech. It's the conversation with key stakeholders about who pays for keys. A security key costs less than a single account-takeover investigation; that's the framing that tends to land.

Staging the rollout

Don't flip this on for the whole realm in one night. Microsoft's own guidance is persona-based, and its motto fits: don't let perfect be the enemy of good. Every user you move is one less phishable sign-in.

1. Scout the realm. Pull the Authentication methods activity report and find out who's still on SMS or voice only. Then sort users into persona groups: admins and highly regulated users, information workers, and frontline workers. You'll target every policy below at these groups.
2. Forge the policies. Enable passkey profiles in the Passkey (FIDO2) policy, one per persona. Enable the Temporary Access Pass policy. Deploy Windows Hello for Business through Intune for managed Windows devices.
3. Arm the Night's Watch first. Start with IT and admins. They're the highest-value targets, they'll find the rough edges, and they become your champions. Give them device-bound passkeys or security keys with attestation enforced.
4. Drive registration. Use the registration campaign with Passkey as the target method, scoped to each persona group as it comes up. Use TAP for anyone without an existing MFA method. Microsoft is already nudging SMS and voice users toward passkeys as of September 1, 2026, so get your profiles in place before they register something you didn't plan for.
5. Enforce with authentication strengths. Create Conditional Access policies that require the Phishing-resistant MFA authentication strength. Run each one in report-only first, check who would fail, then turn it on. Go in this order: admin portals and privileged roles, then sensitive apps, then all apps for each persona that's finished registering.
6. Lower the old banners. Once a group is enforced, remove it from SMS, voice, and other weak methods in the Authentication methods policy. Leave the Email OTP bridge from my last post in place for now: passkeys and Windows Hello for Business don't count as SSPR methods, so retire it only once those users are truly passwordless and no longer reset passwords at all.

Two credentials per user, always. A passkey plus Windows Hello for Business, or two security keys. A single credential is one lost phone away from a service desk call.

Pitfalls I see in the field

• Enforcing before registering. An authentication strength policy turned on before users have a passkey is a lockout with extra steps. Report-only first, every time.
• One credential per user. The phone breaks, the key goes through the wash, and the service desk is back to issuing TAPs all week.
• Forgetting the break-glass accounts. Keep them excluded from your new enforcement policies (see my break-glass post for why).
• Calling Authenticator (passwordless) push "phishing-resistant." It's better than SMS. It isn't the same thing and your Conditional Access policies will know the difference.
• Synced passkeys for admins. Convenient for most users. For privileged accounts, keep to device-bound and enforce attestation.
• Ignoring legacy apps. Older apps that only do basic auth or can't handle modern sign-in won't get phishing resistance for free. Find them early in report-only mode.
• No recovery plan. Decide now who can issue a TAP, how the user proves who they are, and how fast it happens. A recovery process that relies on a phone call is the new weakest link. Ask me about it, I have horror stories.

The Guardian's forge checklist

• [ ] Users sorted into persona groups (admins, information workers, frontline)
• [ ] Passkey profiles created per persona: device-bound with attestation for admins, synced allowed for everyone else
• [ ] Temporary Access Pass policy enabled, with a documented identity check before issuing one
• [ ] Windows Hello for Business deployed to managed Windows devices (cloud Kerberos trust for hybrid)
• [ ] Security keys budgeted and issued for users without a phone, two per user where possible
• [ ] Registration campaign targeting passkeys, scoped by persona
• [ ] Conditional Access requiring the Phishing-resistant MFA authentication strength, report-only first
• [ ] Break-glass accounts excluded from the new policies
• [ ] SMS and voice removed from enforced groups in the Authentication methods policy
• [ ] Every user with at least two phishing-resistant credentials

The Wall is coming down whether we're ready or not. The realms that come through it are the ones that forged their steel before the Long Night, not during it. You don't have to move everyone this quarter. Start with your admins, prove it works, and keep going one group at a time.

Thanks for reading, and for sticking with this series. I appreciate every one of you who shows up for these posts. Got a phoneless-user scenario I didn't cover, or a rollout lesson of your own? Drop it in the comments, and subscribe so you don't miss the next one.

Stay vigilant out there.

— Kevin