The Cybersecurity and Infrastructure Security Agency (CISA) urges organizations to make phishing-resistant multifactor authentication (MFA) a high-priority security objective. Its guidance identifies FIDO/WebAuthn and public key infrastructure (PKI)-based authentication as the two approaches that meet the phishing-resistant standard. If an organization cannot deploy either immediately, CISA recommends stronger interim controls while it plans the migration.
That distinction matters. Conventional MFA can stop an attacker who has only a stolen password. It may not stop an attacker who can persuade a user to reveal a one-time code, approve a fraudulent push notification, or authenticate through a convincing proxy site. Phishing-resistant MFA changes the authentication process so that a credential cannot simply be handed to the wrong destination and reused.
For enterprise security leaders, CISA's phishing-resistant MFA guidance is more than a recommendation to add another login factor. It is a roadmap for moving from credentials that users must protect to cryptographic authentication that enforces important protections by design.
What Is CISA's Phishing-Resistant MFA Guidance?
CISA's guidance explains which authentication methods provide meaningful resistance to phishing and how organizations should move toward them. It describes phishing-resistant MFA as the strongest available MFA protection and encourages organizations to begin planning a migration even if immediate enterprise-wide deployment is not possible.
CISA identifies two phishing-resistant approaches:
- FIDO/WebAuthn authentication, which uses public key cryptography and binds authentication to the legitimate website or application.
- PKI-based authentication, including smart cards such as Personal Identity Verification (PIV) and Common Access Cards (CAC), which relies on certificates and mature identity-management processes.
The guidance also makes an important practical concession. When phishing-resistant MFA cannot yet be implemented, app- or token-based one-time passwords and mobile push with number matching can serve as interim options. CISA is explicit that number matching is not phishing-resistant, however. It is a mitigation for push fatigue, not the destination of the migration. CISA's implementation fact sheet provides the underlying hierarchy.
Why CISA Published the Guidance
MFA adoption increased, but attackers adapted. Instead of trying only to guess passwords, they began targeting the authentication workflow itself. Real-time phishing proxies can capture passwords and OTPs. Push bombing can pressure a user into approving an unexpected request. Malware can steal authenticated browser sessions.
At the same time, the U.S. government was moving toward an identity-centered Zero Trust model. The federal Zero Trust strategy established by OMB Memorandum M-22-09 requires phishing-resistant MFA for federal agency staff, contractors, and partners. It also directs agencies to discontinue routine authentication methods that do not resist phishing, including SMS, voice calls, OTPs, and push notifications.
The OMB mandate applies to federal agencies; CISA's broader guidance helps public- and private-sector organizations understand the same security direction. The shared principle is identity-first security: access decisions should begin with strong evidence that the legitimate user is authenticating to the legitimate service.
What CISA Means by Phishing-Resistant MFA
Phishing-resistant MFA is designed to prevent authentication secrets and outputs from being disclosed to an impostor website or application. The protection is built into the protocol, rather than depending on a user recognizing every fraudulent page or prompt.
FIDO2 achieves this with asymmetric cryptography. A private key remains under the authenticator's control, while the corresponding public key is registered with the service. During login, the authenticator signs a fresh challenge for the legitimate relying party. No reusable shared secret is sent for an attacker to capture.
This is why phishing resistance describes an architectural property, not simply a product label or the number of factors used. To understand how this differs from conventional controls, see What Is Phishing-Resistant MFA?.
Why Traditional MFA Is No Longer Enough
Traditional MFA remains substantially better than password-only authentication. The problem is that not every MFA method provides the same protection. Methods based on transferable codes or user-approved prompts can still be manipulated by an attacker operating in real time.
Organizations therefore need to evaluate MFA by the attacks it can resist, not by whether a login screen technically asks for two factors.
SMS and OTP Vulnerabilities
SMS codes and app-generated one-time passwords expire quickly, but they remain transferable during their valid window. A phishing site can ask a victim for a password and then request the code sent by the real service. The attacker relays both values to the legitimate login page and completes authentication before the code expires.
SMS also introduces telecommunications risks, including SIM swapping and message interception. Authenticator-app OTPs avoid some of those weaknesses, but they do not solve the phishing problem because a user can still type the code into an attacker-controlled page.
The core limitation is replayability. The code proves that someone obtained the temporary value. It does not cryptographically prove that the user is communicating with the intended service.
Push Fatigue Attacks
Push-based MFA asks a user to approve or deny a login notification. If an attacker has the password, they can generate repeated prompts and rely on confusion, interruption, or fatigue to secure an approval. Attackers may also contact the victim while impersonating IT support and instruct them to approve the request.
Number matching improves this workflow by requiring the user to enter or select a number shown on the login screen. That makes blind approval harder and is why CISA recommends number matching as an interim measure. It still does not provide the domain binding that makes FIDO2 resistant to a well-designed phishing proxy.
Session Hijacking
Authentication is only the beginning of a session. After a user signs in, many applications issue a session cookie or token so that the user does not need to reauthenticate for every action. If malware, a malicious browser extension, or another post-authentication technique steals that token, an attacker may be able to replay the session without repeating MFA.
Phishing-resistant MFA substantially reduces credential phishing and adversary-in-the-middle login attacks, but it does not make endpoints, applications, or sessions invulnerable. Organizations still need endpoint security, short and risk-appropriate session lifetimes, token protection, anomaly detection, and step-up authentication for sensitive actions.
This is a critical implementation point: stronger authentication closes a major entry path, but it must operate within a broader identity and session-security program.
Why CISA Recommends FIDO2
FIDO2 meets CISA's phishing-resistant objective because it replaces transferable authentication secrets with cryptographic proof. It combines the World Wide Web Consortium's Web Authentication API, or WebAuthn, with the FIDO Alliance's Client to Authenticator Protocol, or CTAP, for communication with external authenticators.
Together, these standards let services authenticate users with public key credentials that are unique to the service and controlled by a platform or roaming authenticator.
Public Key Cryptography
When a user registers a FIDO2 authenticator, it creates a public-private key pair for that service. The service stores the public key. The private key remains protected by the authenticator and is not transmitted to the service.
At login, the service sends a unique cryptographic challenge. The authenticator signs it with the private key after the required user-presence or user-verification step. The service validates the signature using the registered public key.
An intercepted assertion cannot be reused for a later login because the challenge is fresh. A database breach does not expose a shared authentication secret because the service stores only the public key. The FIDO Alliance explains that FIDO standards use public key cryptography to provide phishing-resistant authentication.
Origin Binding
WebAuthn binds the authentication ceremony to the legitimate website. The browser supplies the origin, and the authenticator will use a credential only for the relying party with which it was registered.
For example, a credential registered for example.com cannot be used to authenticate at a lookalike domain such as examp1e.com. The fake site may imitate the brand and login page, but it cannot make the authenticator produce a valid assertion for the legitimate relying party.
Origin binding removes a decision users routinely get wrong under pressure. The protocol, not the person, verifies the destination. For a deeper technical explanation, read How FIDO2 Stops Phishing Attacks.
Hardware Security Keys and Platform Authenticators
FIDO2 supports more than one authenticator model:
- Platform authenticators are built into a laptop, phone, or other computing device. They can offer a familiar biometric or PIN-based experience and reduce the need to distribute separate hardware.
- Roaming authenticators are external security keys or other portable devices that can be used across supported computers and mobile devices. They can provide stronger portability, separation from the endpoint, and enterprise control over the credential-bearing hardware.
Neither model is automatically the correct choice for every workforce. Platform authenticators may suit employees with managed, individually assigned devices. Roaming authenticators can be valuable for administrators, shared-workstation users, frontline personnel, contractors, and recovery scenarios.
Enterprise planning should account for authenticator ownership, hardware-backed key storage, supported transports, shared-device workflows, lost-device recovery, accessibility, attestation requirements, and lifecycle management. The right decision is often a governed mix rather than a single authenticator for every user.
CISA's Recommended Approach to Implementing Phishing-Resistant MFA
Moving to phishing-resistant MFA is an identity-program change, not merely a new login setting. CISA encourages organizations to plan the migration, prioritize the most consequential exposure, and use stronger interim controls where immediate adoption is not possible.
A phased deployment also gives security teams time to test application compatibility, enrollment, support, recovery, and policy enforcement before expanding the control.
Identify High-Risk Users
Start with accounts whose compromise would give an attacker the greatest reach or access to the most sensitive resources. This typically includes:
- Global, domain, cloud, and identity administrators
- Privileged access and security operations teams
- Executives and employees likely to face targeted phishing
- Remote-access users
- Developers with production or code-signing access
- Finance, payroll, and payment-approval personnel
- Third parties with access to critical systems
Prioritization should consider both privilege and exposure. A lightly privileged account with external access to a sensitive workflow may deserve protection before an internal administrator whose access is tightly constrained.
Replace Legacy MFA Methods
Inventory where passwords, SMS, voice calls, OTPs, and push approvals remain in use. Then map each application to the identity provider, protocol, population, business owner, and FIDO2 or PKI support status.
The migration should include primary login, privileged elevation, remote access, sensitive transactions, account recovery, and help-desk resets. If a user can bypass FIDO2 by selecting “try another way” and receiving an SMS code, the weaker path becomes the attacker's preferred target.
Legacy applications may require federation through a modern identity provider, an access proxy, or a longer modernization plan. During the transition, organizations can reduce exposure with number matching, tighter conditional access, network and device restrictions, and closer monitoring. The goal should remain retirement of phishable paths, not indefinite coexistence.
Educate Users
FIDO2 reduces the need for users to identify fake login pages, but deployment still requires clear onboarding. Users need to understand how to enroll an authenticator, when to use it, what to do if it is lost, and how to report unexpected authentication activity.
Training should be specific to the new workflow. Show users what a legitimate prompt looks like, explain why authentication will fail on an unrecognized domain, and provide tested recovery instructions. Managers and help-desk teams need the same preparation so they do not reintroduce insecure exceptions under pressure.
Adoption is not separate from security. If the approved method is difficult to carry, unreliable across daily workflows, or poorly supported, users will seek workarounds and administrators will preserve weaker fallbacks.
How Phishing-Resistant MFA Supports Zero Trust
Phishing-resistant MFA strengthens the identity pillar of Zero Trust by improving the quality of evidence used to make an access decision. It helps establish that a registered authenticator is participating in a login to the correct service, but it does not independently deliver a complete Zero Trust architecture.
OMB's federal Zero Trust strategy pairs strong identity controls with device signals, application-layer enforcement, granular authorization, monitoring, and continual evaluation.
Identity Verification
Zero Trust rejects implicit trust based on network location. Each access request should be evaluated using current information about the user, authenticator, device, resource, and context.
Phishing-resistant MFA makes the initial identity signal harder to forge through credential theft. User verification, such as a local biometric or PIN, can also require the person holding the authenticator to unlock it before the private key is used. This provides stronger assurance than possession alone, though biometric verification should not be confused with full identity proofing at enrollment.
Least Privilege Access
Authentication answers whether the claimant has demonstrated control of the expected credentials. Authorization determines what that identity may do. Zero Trust requires both.
Organizations should grant only the access needed for the user's role and current task, constrain privileged sessions, and require stronger or repeated authentication for high-impact actions. A phishing-resistant login should not translate into broad, permanent trust across unrelated systems.
Combining FIDO2 with role- or attribute-based access policies limits what an attacker can reach even if another layer fails.
Continuous Authentication
“Never trust, always verify” does not mean prompting a user with MFA every few seconds. It means continually evaluating whether the active session remains consistent with policy and risk.
Signals may include device compliance, location, network, behavior, resource sensitivity, token use, and changes in privilege. If risk increases, the system can require phishing-resistant reauthentication, restrict an action, shorten the session, or deny access.
This distinction prevents a common overclaim: FIDO2 provides strong authentication at an access event, while the broader Zero Trust system supplies continuous evaluation and enforcement around that event.
How TokenCore™ Aligns with CISA's Guidance
TokenCore™ implements the FIDO2 principles CISA recommends through hardware-backed, phishing-resistant authentication. It is designed to work as an assurance layer alongside an organization's existing identity, SSO, PAM, and application environment rather than requiring those systems to be replaced.
TokenCore™ also combines FIDO2 credentials with on-device biometric verification and signed over-the-air firmware updates. These capabilities address two practical enterprise concerns: confirming that the registered user is physically participating in authentication and keeping deployed authentication hardware current as security needs evolve.
Hardware-Backed Authentication
TokenCore™ stores FIDO2 credentials in dedicated hardware so private keys remain protected by the authenticator. Authentication uses cryptographic proof rather than a password or OTP that can be copied, entered on a phishing page, or shared with another user.
For enterprises, hardware-backed authentication can provide consistent control for high-risk users, shared-workstation environments, remote access, and workflows where relying solely on a general-purpose endpoint does not provide the desired level of assurance.
Biometric Identity Verification
On-device fingerprint verification requires the enrolled user to unlock the TokenCore™ authenticator before it can complete the authentication operation. The biometric template remains on the device rather than being sent to the application as an authentication secret.
This local verification helps bind use of the credential to the enrolled person and reduces the risk of a lost, borrowed, or shared authenticator being used by someone else. It adds user assurance to FIDO2's cryptographic proof of device possession and destination binding.
Enterprise Deployment
Effective enterprise authentication must be deployable, supportable, and maintainable throughout the credential lifecycle. TokenCore™ is designed to interoperate with existing identity infrastructure, giving organizations a path to strengthen authentication without replacing their IAM stack.
The TokenCore™ portfolio includes the Wearable, Portable, Portable+, and Node, giving organizations multiple form factors for different users, environments, and authentication workflows. Across the portfolio, organizations can apply a consistent FIDO2 and biometric authentication model while selecting the product best suited to each workforce use case. Signed over-the-air firmware updates help deployed devices remain current as capabilities and security requirements evolve.
Deployment still requires sound policy. Organizations should define who receives which authenticator, how enrollment is verified, how spare devices are controlled, what happens during loss or replacement, and how non-phishing-resistant fallback methods will be retired.
Common Questions About CISA's MFA Guidance
CISA's recommendations are often summarized too broadly. These answers clarify what the agency means and how organizations can apply the guidance.
What Does CISA Mean by Phishing-Resistant MFA?
CISA means an authentication process designed to prevent authentication secrets or outputs from being disclosed to an impostor website or application. Its guidance identifies FIDO/WebAuthn and PKI-based authentication as phishing-resistant approaches. These methods use cryptographic mechanisms rather than transferable codes or simple approvals.
Does CISA Recommend FIDO2?
Is Traditional MFA Still Acceptable?
Whether a traditional method is legally or contractually acceptable depends on the specific regulation, framework, customer requirement, and system. CISA guidance should not be presented as a universal legal mandate for every private organization.
Which Users Should Be Protected First?
The long-term objective should be broad coverage. Attackers often compromise an ordinary account first and then move laterally, exploit recovery processes, or escalate privileges. High-risk-user deployment is the first phase, not the finish line.
Turn CISA's Guidance Into an Enterprise Authentication Plan
CISA's recommendation is not simply to place another challenge after a password. It is to move toward authentication that resists phishing because the underlying protocol prevents a credential from being used at the wrong destination.
For security leaders, the practical work is to identify high-risk users, map legacy dependencies, choose the right mix of authenticators, secure enrollment and recovery, and retire weaker fallback paths. FIDO2 provides the phishing-resistant foundation. Identity governance, least privilege, device trust, and continuous session evaluation determine how effectively that foundation supports Zero Trust.
Explore TokenCore™ to see how hardware-backed FIDO2 authentication, on-device biometrics, and enterprise-ready form factors can help your organization put CISA's guidance into practice.
Sources
- CISA: Implementing Phishing-Resistant MFA
- CISA: Guidance on Phishing-Resistant MFA and Number Matching
- Office of Management and Budget: M-22-09, Moving the U.S. Government Toward Zero Trust Cybersecurity Principles
- NIST SP 800-63B: Authentication and Authenticator Management
- W3C: Web Authentication, Level 3
- FIDO Alliance: Passkeys and FIDO Authentication
