Phishing-resistant MFA: which methods hold up, and where to enforce them first

What phishing-resistant MFA is and which methods qualify

Phishing-resistant MFA is multi-factor authentication whose response a fake sign-in page cannot capture and replay, because the authenticator binds it to the legitimate service’s domain name or to the encrypted channel. FIDO2 security keys, passkeys and other WebAuthn authenticators qualify, and so do smart cards that sign in through a public key infrastructure (PKI). One-time codes from SMS, apps or hardware tokens do not, and neither do push approvals. CISA’s fact sheet “Implementing Phishing-Resistant MFA” (October 2022) calls it “the gold standard for MFA”.

NIST SP 800-63B-4, final since July 2025, defines phishing resistance as the protocol’s ability to stop secrets and valid authenticator outputs from reaching an impostor verifier, “without relying on the vigilance of the claimant”. Section 3.2.5 recognises verifier name binding, where the authenticator chooses its secret by the verifier’s authenticated domain name, as WebAuthn does, and channel binding to the TLS session, as with smart cards that use client-authenticated TLS. Authenticators with manual entry, such as OTP and out-of-band authenticators, “SHALL NOT be considered phishing-resistant”, because a typed code is not bound to the session being authenticated. At registration, a FIDO authenticator creates a key pair unique to that account on that service and keeps the private key, and in the FIDO Alliance’s words “a passkey is only presented to the site it was registered with”.

How attackers bypass MFA that is not phishing-resistant

ENISA Threat Landscape 2025, published in October 2025, calls phishing “the dominant intrusion vector (60%)”. It also describes phishing-as-a-service platforms that clone login pages, among them an adversary-in-the-middle kit that bypasses MFA. Such a kit proxies the legitimate sign-in page, relays the password and any typed code, waits for any push approval and keeps the session cookie the service issues.

CISA, the FBI and five partner agencies describe other routes in their advisory on the actors known as Scattered Spider (AA23-320A, first published on 16 November 2023 and updated on 29 July 2025), who use social engineering, push bombing and SIM swap attacks to obtain credentials and bypass MFA. They sent repeated MFA prompts until employees pressed Accept, posed as IT staff to obtain one-time passwords and persuaded mobile carriers to move a user’s number to a SIM card in their possession. Posing as employees, they also phoned help desks to have passwords reset and MFA transferred to a device they controlled.

After sign-in, the service recognises the user by a session cookie or token, which malware on the endpoint can copy and replay without a second factor. NIST SP 800-63B-4 lists device bound session credentials, an emerging specification, among the technologies that “mitigate the risk of theft of session secrets”. At AAL2 its reauthentication timeouts SHOULD be at most 24 hours overall and 1 hour of inactivity. At AAL3 the overall timeout SHALL be at most 12 hours, and the inactivity timeout SHOULD be at most 15 minutes.

MFA methods compared: which are phishing-resistant

CISA’s fact sheet ranks MFA forms from phishing-resistant MFA down to SMS or voice, placing push with number matching above push without it. NIST SP 800-63B-4 sets requirements by authenticator assurance level (AAL), and at AAL2 a verifier “SHALL offer at least one phishing-resistant authentication option”. NIST treats SMS and voice codes as restricted authenticators, which must come with an unrestricted alternative, notice of the risks and a migration plan.

CISA fact sheet on phishing-resistant MFA (October 2022), Table 1; NIST SP 800-63B-4 (July 2025), sections 2, 3.1.3, 3.2.5, 3.2.9 and Appendix B; FIDO Alliance passkeys page. The last column is our recommendation.

Our cyber resilience assessment covers infrastructure, access and backups and ends with a risk map and a prioritised action plan. Tell us which MFA methods your systems accept today and where each is used.

MFA fatigue and number matching

CISA’s fact sheet “Implementing Number Matching in MFA Applications” (October 2022) says MFA fatigue, also known as push bombing, “occurs when a cyber threat actor bombards a user with mobile application push notifications” until the user approves by accident or out of annoyance. CISA recommends number matching against it, a setting that makes the user enter a number from the identity platform into the app before the request is approved. The number appears on the screen of whoever started the sign-in, so a user who did not start it has nothing to enter. CISA presents it as an interim mitigation until phishing-resistant MFA is in place, and advises training users to report unknown or bulk requests and investigating denied pushes.

The out-of-band rules of NIST SP 800-63B-4 require the user to transfer a secret between the two channels, as when typing the number from the sign-in page into the app, and the older method of comparing two values and approving on the phone “is no longer considered acceptable”. Number matching still relies on manual entry, so it stops blind approvals but not a relay, because a proxied sign-in page shows the user the legitimate number.

Passkeys for business: synced or device-bound

The FIDO Alliance describes a passkey as a FIDO credential used to sign in to apps and websites with the device’s own biometric, PIN or pattern check. It calls passkeys copied between a user’s devices through a cloud service “synced passkeys”, and those that never leave a single device, including those on FIDO security keys, “device-bound passkeys”. Both kinds are phishing-resistant, and NIST’s appendix on syncable authenticators says that constraining a synced key to the domain where it was created “prevents a falsified web page from being able to capture and reuse an authenticator output”.

NIST SP 800-63B-4 allows syncable authenticators at AAL2 when the keys are stored in the sync service only in encrypted form, only the authenticated user can reach them and access to them is protected by AAL2-equivalent MFA; because their keys are exportable, they “SHALL NOT be used at AAL3”. For federal enterprise keys it also requires agency-managed sync accounts and device management that stops syncing to unauthorised devices or sync fabrics, and recommends attestation.

A company can give staff passkeys on managed devices, synced only through accounts it controls, and give administrators and break-glass accounts device-bound keys. WebAuthn’s Backup Eligible and Backup State flags tell the service whether a key can be synced and whether it has been, and attestation identifies the key model, so it can refuse synced or unapproved keys for those accounts.

Where to enforce phishing-resistant MFA first

Start where one account gives access to many systems. CISA notes that “if a cyber threat actor can compromise the account of a system administrator, they may be able to access any system and any data in the organization”, that attackers often target email and remote access, and that hosted email and single sign-on, which mostly support FIDO, are good starting points. The order below suits a company of 200 to 2,000 staff.

1. Administrator accounts, including the identity provider’s admin roles and cloud and SaaS admin accounts, kept separate from everyday accounts and protected by two device-bound FIDO2 security keys per person.
2. Management consoles of hypervisors, firewalls, switches, storage and baseboard management controllers (BMCs), through federated sign-in, so the identity provider’s MFA policy applies, or else only from a jump host that requires phishing-resistant MFA; the backup server keeps its own MFA-protected accounts outside the production directory.
3. Remote access through VPN and remote desktop gateways, including the access paths of suppliers.
4. Email and every application behind single sign-on, for all staff, with passkeys or security keys and number matching for those not yet moved.
5. With each step, the weaker routes into the same accounts: SMS, codes and push removed once a person has keys or passkeys, since a relay page can offer any method still accepted, and password-only protocols and endpoints closed or limited to named systems.

vCenter has supported federated sign-in through an external identity provider since vSphere 7.0, according to Broadcom’s documentation, and Mandiant advised on 23 July 2025 using it to enforce phishing-resistant MFA for all vCenter sign-ins. Our guide to ESXi ransomware hardening shows how stolen directory credentials reach vCenter and the hosts, and why vCenter roles and backup credentials stay outside the directory. Admin identities, vaults and just-in-time rights belong to privileged access management, and MFA’s place among other controls to our zero trust guide for mid-size companies.

Under our cyber resilience service, our engineering partner Vixen.UNO sets up multi-factor authentication as part of a zero-trust architecture, in agreed maintenance windows with a rollback plan. Write to us with the consoles and gateways that still accept a password alone.

Enrolment, recovery and break-glass accounts

Attackers who cannot defeat the authenticator go after enrolment and recovery. NIST SP 800-63B-4 asks providers to encourage users to keep “at least two separate means of authentication”, to notify the user through an independent channel when an authenticator is added, and to send a notification after every account recovery. For staff that means two keys or passkeys per person, enrolled only from a managed device or after an identity check. At the help desk, no reset should follow a phone call alone. Call back on the number in the HR record or have the manager confirm, check identity in person or by video, and issue a one-time enrolment code that expires within hours. Alert on every new authenticator registered to an administrator account.

Break-glass accounts are for the day the identity provider, the federation service or the MFA service is down. Keep two for the identity provider, each with its own FIDO2 security keys in separate safes and a long random password stored offline, and treat the built-in local administrator of each console as a break-glass account with an offline password. Exempt them from rules that depend on one network location or system, alert on every sign-in and test them on a schedule.

NIS2 MFA requirements: points 11.6 and 11.7 of Regulation 2024/2690

Article 21(2)(j) of the NIS2 Directive lists “the use of multi-factor authentication or continuous authentication solutions” among the minimum measures, “where appropriate”. Implementing Regulation (EU) 2024/2690 details the measures for the digital infrastructure, ICT service and digital providers listed in its Article 1. For other essential and important entities it is a reference, not an obligation, and whether a company is in scope is a legal assessment for its legal department.

Point 11.7.1 asks that users be authenticated “by multiple authentication factors or continuous authentication mechanisms” where appropriate, in accordance with the classification of the asset to be accessed, and 11.7.2 that the strength of authentication be appropriate to that classification. Point 11.6.2 adds separate credentials for privileged or administrative accounts, termination of inactive sessions and blocking after a set number of failed log-in attempts, and 11.3.2(a) names multi-factor authentication for privileged and system administration accounts. Neither 11.6 nor 11.7 names a specific method, such as FIDO2, or mentions phishing.

Where an entity finds a requirement qualified “where appropriate” not appropriate, Article 2(2) of the regulation asks it to document its reasoning “in a comprehensible manner”, so a register of systems without MFA, each with its reason and a review date, is useful evidence for any company. In-scope customers ask their IT suppliers the same questions, as our guide to NIS2 supply chain requirements shows, and all ten measures of Article 21 are in our NIS2 Article 21 guide.

What we do

Under Cyber Resilience, our engineering partner Vixen.UNO builds a zero-trust architecture following NIST CSF 2.0 with multi-factor authentication, privileged access management, network segmentation and mobile device management (MDM). The technical assessment covers infrastructure, access, backups and NIS2 requirements and ends in a risk map and a prioritised action plan. Changes roll out step by step in agreed maintenance windows with a rollback plan, and support continues under an agreed SLA. The first call is free of charge, and the price of the technical assessment is fixed before work begins.

FAQ