What is phishing resistant MFA and how does it work?

Most MFA methods—SMS codes, one-time passwords, push notifications—work by generating a secret that the end user then provides to a service. For instance, when a user logs in to their bank account, they might enter both a password and a six-digit code sent to their phone or generated by an authenticator app.

While these MFA methods can help stop many attacks, they can struggle with phishing—cyberattacks that use deceptive communications to trick users into revealing credentials or approving fraudulent access.

Phishing attacks exploit human behavior rather than technical vulnerabilities, which can makes them harder for traditional MFA to block. The authentication factors that attackers steal or manipulate are technically valid. The code is real, the approval is genuine and the credentials are correct. Traditional MFA has no way to tell the difference between a legitimate login and one that was coerced or intercepted.

According to the IBM X-Force Threat Intelligence Index, phishing is one of the primary ways attackers obtain the valid credentials they then abuse. Stolen accounts are one of the most common initial attack vectors, accounting for 32% of incidents. 

Phishing-resistant multifactor authentication helps stop these attacks by providing authentication in a fundamentally different way. Instead of transmitting a secret, it uses public key cryptography and a technique called origin binding.

Public key cryptography is a cryptographic approach that uses a pair of mathematically linked keys, one public and one private, to verify identity without transmitting a shared secret.

Origin binding is when the authenticator—such as a security key or passkey on a phone—responds only when it recognizes the legitimate domain. If the site is spoofed, the authenticator stays silent and there’s nothing for the attacker to capture.

For example, say that an employee is lured to a spoofed login page instead of the real one. Their authenticator checks the domain, finds no match and stays silent, even if they’ve already entered their credentials.

With phishing-resistant MFA, organizations can help protect user accounts even when employees fall for phishing attempts. They can also help satisfy the growing body of standards and regulatory requirements—from parties such as the National Institute of Standards and Technology (NIST), the Cybersecurity and Infrastructure Security Agency (CISA) and cyber insurance underwriters—that now treat phishing-resistant authentication as the baseline for strong authentication.

The trouble with most authentication methods is that they share a structural weakness: they depend on a secret that the user transmits. When that secret is in transit, it can be intercepted, replayed or extorted through social engineering.

Each type of authentication factor in traditional MFA generally has a specific vulnerability, and cybercriminals have built entire toolkits around exploiting them.

SMS text message codes route through carrier infrastructure that was never designed with cybersecurity in mind.

In a SIM swap attack, an attacker convinces a mobile carrier—or social-engineers a call center employee—to transfer the victim’s phone number to a new SIM card. After that number is ported, every text message goes to the attacker, including MFA codes.

SMS codes are also exposed to SS7 vulnerabilities—decades-old weaknesses in the signaling protocol telecom providers still use to route messages between networks. SS7 vulnerabilities can allow attackers to intercept or redirect SMS messages at the network level, without needing access to the victim’s device or carrier account. SS7-based attacks can be even harder to detect than a SIM swap.

Authenticator apps use one-time passwords (OTPs) to verify a user’s identity at login. OTPs are often harder to intercept in transit because they’re generated locally on the user’s device rather than sent over a phone network. But they’re still vulnerable to man-in-the-middle attacks (MitM) in which a cybercriminal secretly positions themselves between the user and the legitimate service to intercept and relay credentials in real time.

MitM attacks occur when a threat actor sets up a proxy server between the victim and the real login page. The victim then clicks a link from a phishing attack and lands on what looks like the real login page because it effectively is, just reflected through the attacker’s proxy. The victim enters their username, password and OTP. The proxy relays everything to the genuine service, which validates the code and returns a session token. The proxy captures that token and funnels it to the attacker. The one-time password was valid; it was just used by the wrong person, through the wrong site.

Phishing kits that automate this entire process are now sold as services on the dark web, as are troves of stolen credentials. Cybercriminals don’t need to build their own tools. They can buy access to user accounts and sensitive data the same way a business buys software.

Push notifications can simplify the authentication process, allowing users to tap “Approve” on their phones instead of entering a code. However, this simplicity, can create a vulnerability known as push notification bombing.

The attack works like this: a cybercriminal who already has stolen credentials fires off approval requests repeatedly, sometimes for an hour or more. To make the interruptions stop—or believing they are real—the target taps “Approve,” providing the attacker access to their account.

Social engineering can further the attack. Hackers can send messages through WhatsApp or Teams posing as IT security, warning of unusual login attempts on the victim’s account and asking them to approve the notification.

Generative AI has made these cyberthreats harder to spot. Attackers can now craft messages that reference real ongoing projects, mimic company IT notification styles and match the target’s language. Capabilities that required sophisticated human effort just a few years ago and can now be automated and streamlined.

The core difference between traditional MFA and phishing-resistant MFA comes down to what crosses the network. Traditional authentication sends a shared secret—a code—from the user to the server. Anyone who can intercept or relay that code can use it. Phishing-resistant authentication eliminates the shared secret entirely.

Instead, the authentication process uses a challenge-response protocol built on public key cryptography. The user’s device holds a private key that never leaves the device. The service holds the corresponding public key. When the user logs in, the service sends a random challenge. The device signs it with the private key. The service checks the signature against the public key. If it matches, the user is authenticated, and there was nothing in this exchange for an attacker to steal or replay.

Two common approaches are FIDO2 and PKI-based certificate authentication. Both rely on public key cryptography but differ in how they’re implemented and where they’re typically deployed. In other words, cryptography is the core method, and FIDO2 and PKI are the two most common ways organizations implement it.

Authenticators—the physical or software token a user interacts with—come in different forms depending on the approach. Security keys and passkeys are common for FIDO2, while smart cards are common for PKI-based certificate authentication.

FIDO2 is a set of open authentication standards maintained by the FIDO Alliance and the World Wide Web Consortium (W3C).

It consists of two protocols: WebAuthn, the browser API that websites use to request cryptographic authentication, and CTAP (Client to Authenticator Protocol), which lets external authenticators communicate with browsers and operating systems.

When a user enrolls in a FIDO2-enabled service, their authenticator generates a key pair. The private key stays on the authenticator. The public key goes to the service. That key pair is also bound to the specific domain (origin) of the service—say, “login.example.com.”

When the user tries to log in, the browser checks the site’s domain against the registered origin. On “login.example.com,” the domains match and the authenticator responds.

On “login-example.com”— potentially close enough to phish a human, but not a match—the authenticator stays silent. The end user doesn’t need to evaluate whether a URL looks legitimate. The FIDO authentication protocol handles it automatically.

Public key infrastructure (PKI) uses digital certificates issued by a trusted certificate authority. The authentication process follows the same challenge-response pattern as FIDO2: the service sends a challenge, the physical device signs it, the service verifies the signature. No secret crosses the wire.

PKI-based authentication has been the standard in the federal government and defense for decades. Smart cards—physical cards with an embedded chip that stores credentials and authenticates the user when inserted into a card reader or tapped against one—meet strict identity assurance requirements.

While smart cards are the most common PKI authenticator, they’re not the only one. PKI certificates can also be stored on USB tokens or managed through software. In government and enterprise deployments, smart cards are typically preferred because they provide hardware-level protection for the private key.

Other industries with existing on-premises infrastructure and strict regulatory requirements, such as healthcare, financial services and legal services, often rely on smart cards for the same reasons

For organizations building from scratch, FIDO2 is typically the favored choice because it requires far less operational overhead.

Authenticators are the physical devices or software mechanisms users interact with to complete the authentication process—in other words, the practical implementation of the FIDO2 and PKI standards.

The right form factor depends on risk level, existing infrastructure and the user experience tradeoffs an organization is willing to accept. Many large organizations end up using more than one.

Some of the most common authenticator types include:

Hardware security keys are physical devices, such as YubiKey or Google Titan Key, that store cryptographic keys in tamper-resistant hardware. They connect through USB or near-field communication (NFC), such as tapping a key fob against a phone or holding a contactless card to a reader.

Because the private key is generated inside the key’s tamper-resistant chip and never exported (not even during authentication), an attacker needs physical possession of the device to compromise it. Remote attacks are effectively impossible. The operational cost is distribution: organizations need to ship, inventory and replace them. For many high-risk roles—system administrators, developers with production access—that cost can be worth it.

Platform authenticators use the biometric sensors and secure hardware built into laptops and mobile devices, such as a fingerprint reader or a facial recognition camera.

The private key lives in the device’s secure enclave or Trusted Platform Module (TPM), meaning there is no extra hardware to carry. The user must verify their identity locally, either through a fingerprint, facial recognition or a device PIN. Local verification unlocks the private key—it doesn’t replace the cryptographic process—which then signs the authentication challenge.

The limitation of platform authentication is that authentication is tied to whichever machine holds the key.

Passkeys are cryptographic credentials stored natively on a user’s device that replace passwords entirely. Like other FIDO2 authenticators, they use a private key that never leaves the device to sign authentication challenges, with the user verifying their identity through a biometric or device PIN.

Unlike hardware security keys, passkeys can sync credentials across mobile devices through a cloud provider, such as Apple, Google or Microsoft. A user who enrolls a passkey on their phone can also authenticate on their laptop, provided both are signed into the same account.

The passwordless authentication experience is smoother than any other phishing-resistant method—no password to remember, reset or lose to a phishing attack. The caveat is platform dependency: passkeys aren’t always  easily portable between ecosystems.

Smart cards, such as PIV, CAC and similar PKI-based cards, are the primary authenticator type for PKI deployments. They provide a tamper-resistant hardware store for the private key in a portable form factor. Federal mandates around PIV and CAC cards also created decades of entrenched infrastructure around them.

Smart cards require card readers and middleware on each workstation, along with back-end certificate management infrastructure.

Their footprint is heavier than FIDO2, but the technology is mature and deeply embedded in government and regulated industry environments.

 Phishing-resistant MFA addresses the problem of phishing and credential theft at the source—by making stolen credentials useless—while also supporting broader cybersecurity and compliance goals.

Some of the most significant benefits of phishing-resistant MFA include:

Phishing-resistant MFA rarely operates in isolation. It typically sits within a broader identity and access management (IAM) architecture that includes several supporting layers.

Conditional access policies add context to authentication decisions. Rather than treating every login identically, these policies evaluate signals—device health, network location, user behavior patterns—and adjust requirements accordingly. 

For example, an employee logging in from a managed device on the corporate network might authenticate with a single passkey tap. The same employee connecting from an unfamiliar device in a new country might face extra verification steps.

On the defensive side, endpoint detection and response (EDR) catches threats that sit outside MFA’s scope. Phishing-resistant MFA helps stop credential theft at the login page, but infostealer malware on a compromised device can still harvest session tokens, cached credentials and other sensitive information.

Threat intelligence feeds complement both layers by identifying phishing infrastructure—flagging malicious URLs, spoofed domains and known command-and-control servers before users ever reach a fake login page.