Does CISA recommend phishing-resistant MFA like FIDO?

Yes. CISA recommends phishing-resistant MFA and identifies FIDO/WebAuthn and public key infrastructure-based authentication as phishing-resistant approaches. FIDO security keys and properly implemented WebAuthn passkeys address attacks that ordinary one-time codes and approval prompts do not; deployment still requires compatible applications, controlled enrollment, and secure account recovery.

TL;DR

• CISA phishing-resistant MFA FIDO WebAuthn guidance favors authentication bound to the legitimate website, not reusable codes.
• FIDO security keys and WebAuthn passkeys resist credential phishing; application support and recovery controls still matter.
• Number matching improves push MFA but does not make it phishing-resistant.
• Defend Wise provides MSP security awareness training, not a substitute for phishing-resistant authentication.

Does CISA recommend phishing-resistant MFA like FIDO?

Yes. CISA recommends phishing-resistant MFA as the strongest form of MFA. Its Implementing Phishing-Resistant MFA guidance identifies FIDO/WebAuthn and public key infrastructure, or PKI, as phishing-resistant authentication approaches.

For your 2026 deployment plan, distinguish the recommendation from the implementation. Buying an authenticator does not establish phishing resistance across your environment. Each application must accept the intended authentication method, enforce it for the right accounts, and avoid weaker fallback paths that defeat the control.

CISA's guidance addresses authentication. Your users still need to recognize suspicious requests, report phishing, and avoid handing over account-recovery information. For MSPs, Defend Wise provides white-label security awareness training for end-client organizations; that training complements technical access controls.

Authentication option	Phishing-resistant?	Main advantage	Main limitation	Best for
FIDO security key using WebAuthn	Yes, when correctly implemented	Authentication is bound to the legitimate service	Requires compatible services and a lost-key recovery process	Users who need a separate physical authenticator
WebAuthn passkey	Yes, when correctly implemented	Avoids a shared authentication secret that users can disclose	Device, synchronization, and recovery policies need review	Users on supported devices and applications
PKI-based authentication	Yes, when correctly implemented	Uses certificates and cryptographic proof	Certificate issuance, renewal, and revocation add administration	Organizations with an established certificate infrastructure
Push MFA with number matching	No	Reduces accidental approvals compared with simple approval prompts	Does not provide WebAuthn's website binding	Transitional deployments that cannot yet support phishing-resistant MFA
Authenticator-app one-time codes	No	Adds another barrier beyond a password	An attacker can capture and relay the code	Transitional access where stronger methods are unsupported
SMS one-time codes	No	Provides another factor where supported	Codes can be phished; phone-number attacks add risk	Interim protection when stronger methods are unavailable

The table is not a claim that weaker MFA has no value. Deploy MFA rather than leaving accounts protected by passwords alone, then replace phishable methods with phishing-resistant authentication. Do not label the interim method as the finished control.

Why this matters

Phishing-resistant authentication changes what an attacker can do with a convincing login page. A fake website can collect a password and ask for an authentication code. It cannot obtain a valid WebAuthn authentication response for the legitimate service merely by copying that service's appearance.

That distinction matters when an MSP describes a client's protection. An account with SMS MFA and an account requiring WebAuthn are not protected against the same attacks. Reporting both as simply MFA enabled hides the difference.

For a 2026 client review, record the authentication method, enforcement point, and recovery path. A completion checkbox is insufficient. You need to know whether the user can still choose a weaker method when signing in or resetting access.

FIDO security keys: website-bound authentication

A FIDO security key is a physical authenticator that can work with WebAuthn. During authentication, it uses cryptographic credentials associated with the legitimate service rather than supplying a reusable code for the user to copy.

Best for users who need a separate physical authenticator. The key provides a clear separation between the login device and the authentication device. Compatibility still matters: connectors, browser support, device policies, and application support determine whether the intended workflow works.

The operational downside is physical handling. Users lose keys, leave them elsewhere, or encounter devices that cannot use them. Establish a controlled replacement process before enforcement, and test how users regain access without introducing an easy bypass.

A key's presence alone does not prove phishing resistance. Some hardware authenticators also support one-time-code modes. Evaluate the authentication protocol used by the application, not just the object plugged into the computer.

WebAuthn passkeys: phishing resistance without copying codes

WebAuthn passkeys use public-key credentials associated with a service. Users can authenticate through a supported device or authenticator without entering a shared password for that credential or copying a one-time code into the website.

Best for users on supported devices and applications. Passkeys remove the code-entry step that attackers exploit in many credential-phishing flows. They can also reduce the need to carry a separate security key, depending on the implementation.

The trade-off is management. Device-bound and synced passkeys have different deployment and recovery considerations. Review where credentials reside, how users access them, and which accounts or services control synchronization and recovery.

Do not assume every passkey deployment satisfies every client requirement. A regulated client can impose authenticator, device, or assurance requirements beyond basic phishing resistance. Match the implementation to those requirements instead of treating the word passkey as the entire assessment.

PKI-based authentication: certificates with lifecycle work

CISA also identifies PKI-based authentication as a phishing-resistant approach. Certificate-based authentication uses cryptographic proof rather than asking the user to transfer a shared secret to the login page.

Best for organizations with an established certificate infrastructure. PKI fits environments that already manage certificate issuance, trust, revocation, and approved authenticators. Its strength depends on protecting private keys and correctly configuring the authentication system.

The downside is lifecycle administration. Certificates expire, devices change, and access must be revoked when users leave. An MSP should account for that work before selecting PKI solely because it appears alongside FIDO/WebAuthn in CISA guidance.

Why phishing-resistant MFA deployment varies

CISA's recommendation is clear. Your implementation depends on the systems, users, and access paths you must protect.

• Application support: Confirm that each application supports the intended WebAuthn or certificate-based method. An unsupported application needs a separate access-control decision.
• Identity architecture: Determine whether the identity provider enforces the method and whether direct application logins bypass that enforcement.
• Authenticator management: Decide how authenticators are enrolled, replaced, removed, and associated with individual users.
• Device access: Test authentication on the devices and browsers users actually use, including shared or restricted devices.
• Recovery controls: Identify who can reset authentication and what evidence that person requires. Recovery is part of the security boundary.
• Fallback methods: Inspect whether SMS, one-time codes, or ordinary push approvals remain available. A weaker alternative can undermine the stronger requirement.

For 2026 planning, separate technical compatibility from policy enforcement. A successful demonstration proves that a user can sign in with WebAuthn. It does not prove that the same user cannot sign in through an easier, phishable route.

How should an MSP roll out phishing-resistant MFA?

Use an application-level rollout rather than a hardware purchasing exercise. The outcome is enforced phishing-resistant access, not a box of security keys.

1. Inventory access. List applications, privileged accounts, identity providers, direct login paths, and existing MFA methods. Include administrative consoles and remote access.
2. Select authentication. Match FIDO security keys, WebAuthn passkeys, or PKI to supported applications and client requirements. Document exceptions rather than hiding them under a general MFA status.
3. Test recovery. Test lost authenticators, replacement devices, enrollment failures, and administrator-assisted resets. Define who authorizes recovery and how that decision is recorded.
4. Enforce access. Require the selected method at the relevant access point. Check alternative login paths and remove weaker fallbacks where the application and policy permit.
5. Verify evidence. Record the policy, affected accounts, exceptions, and review date. Confirm that authentication logs reflect the intended method rather than only a generic successful login.

Select the method, test recovery, and verify enforcement before calling the rollout complete.

During your pilot, ask users to complete their normal work rather than only a test login. Administrative access, remote work, device replacement, and recovery reveal different failure points. Resolve those paths before extending enforcement to additional client organizations.

For a 2026 rollout, put privileged access first in your planning. Those accounts control identity settings, recovery, and other users' access. Document emergency access separately so it remains controlled, monitored, and distinguishable from an everyday bypass.

What is the difference between FIDO and WebAuthn?

FIDO refers to an authentication standards family; WebAuthn is the web authentication standard used by browsers and applications. FIDO2 combines 2 standards: WebAuthn and the Client to Authenticator Protocol, or CTAP.

WebAuthn handles the interaction between the website and the browser's authentication interface. CTAP handles communication with an external authenticator, such as a compatible security key. The distinction helps you ask useful compatibility questions instead of requesting an unspecified FIDO feature.

Is number matching phishing-resistant MFA?

Number matching is not phishing-resistant MFA. It requires users to match a number shown during login with the authentication prompt, reducing the risk of blindly approving an unsolicited request.

CISA's Implementing Number Matching in MFA Applications guidance presents number matching as an improvement to push authentication when phishing-resistant MFA is not yet available. It remains a transitional control, not an equivalent replacement for FIDO/WebAuthn.

Does phishing-resistant MFA replace security awareness training?

Phishing-resistant MFA does not replace security awareness training. It protects the authentication exchange, not every action a user takes after receiving a deceptive message.

Users still encounter malicious attachments, payment-change requests, fake support calls, and requests to weaken account security. Training should explain those risks and teach a clear reporting process without suggesting that users must personally defeat every credential-phishing attempt.

Where security awareness training fits

Defend Wise is best for MSPs that want white-label security awareness training, not an MFA replacement. Its platform supports MSP training and cybersecurity compliance management for end-client organizations. Keep that role separate from the identity provider and authenticator controls that enforce access.

Defend Wise's flat-fee model includes unlimited seats, which removes per-seat licensing from the training platform's economic model. That does not remove the MSP's work: client onboarding, authentication decisions, exception handling, and evidence review still need an owner.

In your 2026 service description, separate the deliverables. Training addresses user behavior; identity policy addresses authentication; evidence records what was implemented. Defend Wise belongs in the training layer, not in a claim that a client has adopted FIDO/WebAuthn.

FAQ

Does CISA recommend FIDO security keys?

Yes. CISA identifies FIDO/WebAuthn as a phishing-resistant authentication approach. A compatible security key must use that approach with an application that supports and enforces it.

Are WebAuthn passkeys phishing-resistant?

Yes, properly implemented WebAuthn passkeys are phishing-resistant because authentication is bound to the legitimate service. Enrollment, synchronization, recovery, and fallback policies still require review.

Is an authenticator app as phishing-resistant as a security key?

An authenticator app that generates one-time codes is not phishing-resistant like a FIDO security key using WebAuthn. Attackers can capture and relay those codes through a fake login page.

Does MFA always require a password and a code?

No. MFA uses at least 2 distinct authentication factors, but those factors do not have to be a password and a code. A correctly configured authenticator can combine possession with a PIN or biometric verification.

Does CISA require every business to use FIDO?

CISA's general recommendation is not a universal legal requirement for every business. Applicable laws, contracts, sector rules, and government policies determine an organization's specific obligations.

Does phishing-resistant MFA stop stolen session cookies?

Phishing-resistant MFA does not by itself stop an attacker from using a stolen authenticated session cookie. Endpoint protection, session controls, and incident response remain necessary.

Can Defend Wise replace an MFA platform?

No. Defend Wise provides white-label security awareness training for MSPs, not a replacement for identity-provider enforcement or phishing-resistant authenticators. Training and technical authentication controls serve different purposes.

One last thing

Test the bypass, not just the successful login. A user signing in with a security key proves compatibility. A user unable to choose a weaker fallback proves something more useful about enforcement.

For each pilot account, register 2 separate authenticators where policy permits, then test losing access to the primary authenticator. Treat this as a deployment recommendation, not a universal CISA requirement. Your recovery process should restore legitimate access without making phishing-resistant MFA optional.