On May 8, Microsoft finished flipping number matching to on-by-default for every Microsoft Authenticator push approval, tenant setting or not. It kills the laziest version of an MFA fatigue attack — no more approving a prompt half-asleep at 2 a.m. without reading it, no more twelve pushes in a row until someone caves just to stop the buzzing. That's real progress against one specific abuse pattern. It is not, however, what most of the phishing-resistant MFA mandates landing on our clients' desks this quarter actually require, and that gap is what this note is about.
We've had that exact conversation three times in six weeks with one state agency client alone. Their grant-renewal compliance office read a zero-trust attestation form, saw "phishing-resistant multifactor authentication," and asked whether number matching satisfied it. It does not, and saying so in writing is a more uncomfortable conversation than it should be, because the industry spent the better part of a year training everyone that MFA is one checkbox. Federal zero-trust guidance, insurer underwriting questionnaires, and a growing number of state procurement clauses now use "phishing-resistant" as a specific, defined term, and Microsoft Authenticator — number matching included — does not meet it.
This note covers what actually qualifies as phishing-resistant under Azure AD today, how Conditional Access authentication strengths let you require it selectively instead of tenant-wide, where certificate-based authentication earns its place for the badge-and-smart-card crowd, and the rollout mechanics that decide whether this becomes a durable control or another audit finding nobody closed on time.
What actually counts as phishing-resistant
Microsoft's own definition — now codified as a built-in Conditional Access authentication strength — recognizes exactly three methods: FIDO2 security keys, Windows Hello for Business, and certificate-based authentication. Everything else, SMS, voice call, one-time passcode, and number-matching push included, is still a secret or an approval traveling over a channel a real-time proxy can intercept and relay.
That distinction is not academic. Microsoft's own write-up on the large-scale adversary-in-the-middle campaign it disclosed in July 2022 described a reverse proxy sitting between the victim and the real Azure AD sign-in page, harvesting the session cookie the moment authentication completed. Number matching raises the cost of that attack — the attacker now needs the session's live displayed code to hand the victim rather than a bare approve prompt — but a well-built AiTM kit is still proxying the whole exchange in real time, code included. The person on the phone has no way to know they typed a number from a fake page into a real approval.
FIDO2 breaks that model structurally. The WebAuthn challenge is cryptographically bound to the origin at the protocol level, not by a human reading a URL, so a look-alike page cannot complete the handshake — the key material never signs a challenge for the wrong domain. Windows Hello for Business works the same way underneath: the private key is generated and sealed in the device TPM, never leaves it, and sign-in is a hardware-backed challenge, not a secret in transit. Certificate-based authentication is the same shape again, a signed challenge from a private key on a smart card or protected key store, validated against a trust chain, with nothing reusable for an attacker to steal.
That's the sentence for a compliance officer: phishing resistance is not a stronger MFA, it's a different mechanism that removes the thing phishing kits actually steal.
Authentication strengths: requiring the right method for the right sign-in
Conditional Access authentication strengths reached general availability this spring, and it's the feature that makes a phishing-resistant mandate enforceable instead of aspirational. Before it, a Conditional Access grant control could only require "multifactor authentication" — any registered method satisfied it, push notification included. Authentication strengths let you define which combination of methods counts and attach that definition to one specific policy.
Microsoft ships three built-in strengths:
| Authentication strength | Satisfied by |
|---|---|
| Multifactor authentication | Any two registered factors, including SMS, voice, one-time passcode, or push |
| Passwordless MFA | Windows Hello for Business, FIDO2 security key, or Authenticator phone sign-in |
| Phishing-resistant MFA | FIDO2 security key, Windows Hello for Business, or certificate-based authentication only |
Custom strengths exist too, useful when a population needs a narrower combination — FIDO2 only for unmanaged personal devices, say, where Windows Hello for Business was never going to be provisioned.
The pattern we're deploying this quarter is two policies, not one: a narrow policy scoped to Global Administrator and the other privileged directory roles requiring the Phishing-resistant MFA strength with no exceptions beyond a documented break-glass pair, and a broader policy for the general population requiring Passwordless MFA today with a dated plan to tighten it later. Requiring the strict strength everywhere on day one is how a project generates the exception list it will be explaining to auditors for the next three years.
Connect-MgGraph -Scopes "Policy.ReadWrite.ConditionalAccess"
Get-MgPolicyAuthenticationStrengthPolicy | Select-Object DisplayName, Id
New-MgPolicyAuthenticationStrengthPolicy `
-DisplayName "Privileged - Phishing Resistant Only" `
-AllowedCombinations @("fido2", "windowsHelloForBusiness", "x509CertificateMultiFactor")
Attach the resulting policy as a grant control set to "Require authentication strength" rather than the generic multifactor checkbox, and the mandate stops being a sentence in a Word document.
Certificate-based auth for the badge-and-smart-card crowd
Azure AD certificate-based authentication went generally available in 2022 as a native capability — no ADFS, no NPS extension, no federation server to keep patched. For any organization already issuing smart cards, that native support is most of the argument, because the alternative was federating through infrastructure most of our clients were trying to retire, not expand.
The mapping work is where this lives or dies. Azure AD validates the certificate chain against root and intermediate authorities you upload yourself, checks revocation against the certificate revocation list distribution points those authorities publish, then maps the authenticated certificate to a directory user through a configurable field — typically the Principal Name or a Subject Alternative Name entry — against a matching attribute. Get that mapping wrong and it doesn't fail loudly; it authenticates the wrong person, or nobody, which is a worse Tuesday than a locked-out helpdesk ticket.
The decisions that belong before the mandate deadline, not during it: which certificate field maps to which attribute, how often revocation is refreshed, and — the one people forget — what happens when a card issuer rotates an intermediate authority. If adding a new trust anchor is an emergency change instead of a routine one, the control works until the first PKI event, and those are not rare.
This isn't only a government pattern. A regional bank client with an existing internal PKI wanted certificate-based authentication specifically over FIDO2 keys, because their auditors already understood certificate lifecycle management and did not want a second asset class introduced for one project. Legitimate reason to pick CBA — same logic as fixing directory hygiene from an old multi-forest consolidation before layering a new authentication method on top of it.
Rollout logistics nobody puts in the SOW
The policy design is the interesting part of the meeting. The rollout is what determines whether the mandate is actually met by the date on the form.
Bootstrapping comes first: nobody can register a FIDO2 key or provision Windows Hello for Business without an existing strong credential, so new users and bulk enrollment events need a Temporary Access Pass — time-boxed, limited-use, issued through a supervised process, never emailed as a static value.
Windows Hello for Business has its own prerequisites depending on deployment model. Hybrid Azure AD join needs the on-premises groundwork done first; cloud trust as a deployment model removes the old requirement for a full on-premises PKI just to issue Windows Hello for Business certificates, worth revisiting if an earlier plan stalled because nobody wanted to stand up ADCS.
FIDO2 key logistics at scale are logistics, not architecture, and they still eat the calendar: procurement lead times for two keys per user, a provisioning event that doesn't turn into a line at the helpdesk, and a lost-key revocation SLA that's written down instead of assumed. Budget for the backup key — the first "left it in my other bag" ticket explains why.
Break-glass accounts need explicit handling here, not an assumption they're fine because they always have been: at least two, excluded from the phishing-resistant policy through a documented exception, monitored on every sign-in, credentials physically secured. Shared and frontline devices are their own design problem — FIDO2 keys tap-and-go reasonably well on a kiosk, Windows Hello for Business does not, because it's built around one identity per device.
Ring order that has actually worked for us:
- Ring 0 - IT and security, phishing-resistant required, one week
- Ring 1 - one cooperative business unit, two weeks, log every ticket
- Ring 2 - broad population, phased by department, dated
- Ring 3 - executives and their assistants last, white-glove, never first
Measuring coverage instead of declaring the mandate satisfied
A signed attestation is not a control, and "we bought keys for everyone" is not a metric. What we pull for clients instead is per-user authentication method registration, cross-referenced against directory role membership, so "are we phishing-resistant" gets a number instead of an impression.
Connect-MgGraph -Scopes "UserAuthenticationMethod.Read.All","Directory.Read.All"
$roleId = (Get-MgDirectoryRole -Filter "displayName eq 'Global Administrator'").Id
$admins = Get-MgDirectoryRoleMember -DirectoryRoleId $roleId
foreach ($admin in $admins) {
$methods = Get-MgUserAuthenticationMethod -UserId $admin.Id
$strong = $methods | Where-Object {
$_.AdditionalProperties['@odata.type'] -match 'fido2|windowsHelloForBusiness|x509Certificate'
}
[PSCustomObject]@{
UserId = $admin.Id
StrongMethods = $strong.Count
PhishResistant = $strong.Count -gt 0
}
}
Run that against every privileged role, not only Global Administrator — Exchange Administrator, Privileged Role Administrator, and anyone with standing access to identity infrastructure belong in the same report. The target for that population is 100 percent before the general-population rollout date, not after.
For everyone else, track coverage as a rolling percentage against the ring schedule, on the same dashboard as helpdesk ticket volume for lost keys and failed provisioning. If the percentage stalls while tickets climb, that's a logistics failure, not a user-behavior one, and needs a logistics fix — more provisioning capacity, clearer backup-key policy — not another awareness email.
The date on the attestation form is real. It is not, by itself, evidence of anything. The count of privileged accounts that cannot sign in without a FIDO2 key, a Windows Hello for Business gesture, or a certificate is the evidence, and it's the only version we'd sign our name to.
If you're facing this
If a compliance form, an insurer, or a state contract just told you to implement phishing-resistant MFA and you are not sure your current rollout qualifies, that is a short, concrete conversation, and better to have it before the attestation is signed than after an incident tests it. Bring the mandate language and your current authentication method registration numbers, and we can usually tell you within a day which population is already compliant and which one is still running on a checkbox.