Security · identity, mfa, passkeys, fido2, conditional-access
Phishing-resistant MFA: plan the rollout by cohort, not by department
Push prompts and SMS codes fall to a live phishing proxy; FIDO2 keys and passkeys do not. A cohort-by-cohort rollout plan, the temporary pass that bootstraps it, and the metric that proves the change held.
Security
Key points
- Push prompts and SMS codes fall to a proxy that relays them live. A FIDO2 credential signs a challenge bound to the real origin and cannot be replayed.
- Microsoft's built-in phishing-resistant strength covers FIDO2 keys, Windows Hello, platform credentials and certificate-based authentication. Authenticator phone sign-in and Temporary Access Pass do not qualify.
- Plan waves by cohort: shared factory and ward workstations, contractors, old phones, Linux desktops, service accounts and break-glass admins each need a different method.
Why a live proxy beats push prompts and SMS codes
A real-time phishing proxy sits between the employee and the genuine sign-in page, forwards the password, and relays whatever the second factor produces while the session is open. The attacker inherits a completed login, not a secret. CISA rates a physical security key strongest and text codes weakest.
A FIDO2 credential holds a private key in a secure element and signs a challenge containing the requesting site's origin, so a proxy on a lookalike domain collects a signature the real site rejects. There is no code to read aloud.
Tell the steering committee that framing: any method where a person reads, types or approves something an attacker can also read and forward stays phishable at sign-in. CISA treats number matching as an interim improvement on push, not a destination.
Hardware keys, platform passkeys and what the policy enforces
A hardware key is a separate object that signs only when it is present and touched. A platform passkey, Windows Hello for Business included, lives in the device's secure hardware and opens with a PIN or fingerprint. Both satisfy Microsoft's built-in phishing-resistant strength, as does certificate-based authentication.
Syncing is the policy decision. FIDO Alliance describes passkeys as credentials a platform or password manager can sync across a user's devices, which is what makes them deployable without buying hardware for everyone. The key then lives in the provider's cloud, so a policy written around device binding stops describing what protects the account.
Do not assume the control is absolute. Entra evaluates an authentication strength only after the initial authentication, so a user can type a password first and be pushed to a phishing-resistant method second, and Windows Hello behaves differently when it was the primary method for the session.
Advertisement
The cohorts that break a naive rollout
Shared workstations are the first wall. A factory terminal or ward PC is used by six people across a shift, none of whom should sign a personal platform account into it, and synced passkeys assume exactly that. A person-assigned hardware key or a badge-linked smart card fits better.
Contractors arrive with unmanaged phones and leave before the enrolment queue reaches them, so the credential must expire with the contract. Old phones and Linux desktops land on the same answer: a USB key and a WebAuthn-capable browser. Service accounts and shared mailboxes are not people and need certificate credentials instead.
Break-glass accounts get their own rule: two keys registered in advance, stored separately, tested on a calendar, and excluded from the change windows that would otherwise lock them out. A wave is a set of people who share a constraint, not a department.
| Wave | Cohort | Method that fits | Why it is separate |
|---|---|---|---|
| 1 | Identity and IT admins | Two device-bound keys each | Builds recovery before scale |
| 2 | Managed-laptop knowledge workers | Platform passkey plus a backup | Devices are yours, so enrolment is scriptable |
| 3 | Factory and ward workstations | Person-assigned key or smart card | One device, many users, no personal phone |
| 4 | Contractors, temps, seasonal staff | Time-limited account and loaned key | Expires with the contract |
| 5 | Linux desktops and BYOD | USB key in a WebAuthn browser | No platform passkey, mixed OS versions |
| 6 | Service accounts, mailboxes, MFPs | Certificate or workload credential | Not interactive, so human MFA breaks jobs |
| 7 | Break-glass administrators | Two keys in separate safes | The path you need when identity fails |
Temporary access passes and re-enrolment
A Temporary Access Pass is a time-limited code an administrator issues so a user can sign in and register a stronger method. The Entra policy sets the lifetime, whether passes are single use, and the passcode length, with published defaults of one hour and an eight-hour maximum lifetime.
It is a bootstrap, not a destination, and the phishing-resistant strength does not include it. Scope it to onboarding and recovery, keep lifetimes short, prefer single-use passes, and log every issue and use. Registration from a single-use pass must finish within ten minutes, so device enrolment sometimes needs two passes.
Re-enrolment after a lost key follows the same shape: revoke the old credential, issue a pass, register the replacement over a verified channel, and close the exception the same day. The temptation is to leave a weaker method on for users who struggle, which makes a temporary problem permanent.
Advertisement
What still refuses modern authentication
Legacy on-premises applications that authenticate with NTLM, LDAP binds or Kerberos never see a WebAuthn assertion, because the protocol they speak has nowhere to carry one. The honest options are a brokering layer in front of them, certificate-based authentication where the application supports it, or a retirement date.
VPN concentrators and RDP gateways behind RADIUS and the Network Policy Server extension expect a password and a code, and Microsoft's documentation notes that a Temporary Access Pass cannot be used with the NPS extension at all. Certificate-based authentication over RADIUS, per-session MFA at the gateway, or an identity-aware proxy are the workarounds that hold.
Then there is the equipment nobody thinks of as an identity client: multifunction printers doing scan-to-email and address book lookups, print servers holding domain credentials, and OT networks of devices that will never run a browser. Give them narrow credentials of their own and treat the remainder as a segmentation problem.
Measure sign-ins, and decide what a lost key costs
The number that matters is the share of successful sign-ins that used a phishing-resistant method, measured weekly and split by application. Enrolment percentage counts people who hold a key; sign-in share counts sessions that were protected. Entra records the method and whether the strength was satisfied, and Okta records the authenticator used.
Plan the helpdesk for the first two weeks, not the whole programme. Track tickets per hundred enrolments by cohort, passes issued, and the applications where hardware keys fail most often. Those counters tell you which cohort to slow down and which application to put behind a broker.
The lost-key policy is where rollouts quietly give back what they gained. Anyone with a standing privileged role carries two keys, users can revoke a lost credential themselves, recovery runs through a pass and verified re-enrolment, and every exception carries an expiry date and a named owner.
Advertisement
Sources 5
- 1FIDO Alliance — FIDO Passkeys: Passwordless Authentication, 1 May 2023
- 2Cybersecurity and Infrastructure Security Agency — Require MFA in Government, 1 Aug 2025
- 3Microsoft Learn — Conditional Access authentication strengths, 24 Oct 2025
- 4Microsoft Learn — Configure Temporary Access Pass to register passwordless authentication methods
- 5Okta — Okta FastPass, 1 Jun 2024


