Phishing-resistant MFA is the term CISA, NIST 800-63B Rev. 4, and Executive Order 14028 use for the authentication category that survives the attack patterns that defeated SMS, OTP, and push-approval MFA. The 2026 enterprise reference on what qualifies, what doesn't, and the deployment architecture across mixed workforces.
Phishing-resistant MFA is the term CISA, NIST 800-63B Rev. 4, and Executive Order 14028 use for the authentication category that survives the attack patterns that defeated SMS, OTP, and push-approval MFA. The 2026 enterprise reference on what qualifies, what doesn't, and the deployment architecture across mixed workforces.
"Phishing-resistant MFA" is the term you'll see in CISA's authentication guidance, NIST Special Publication 800-63B Revision 4, Executive Order 14028, the CISA Secure-by-Design Pledge, the FedRAMP authorization framework, and the broader 2026 federal zero-trust roadmap. It is the regulatory term for the category of multi-factor authentication that survives the attack patterns that have defeated SMS, OTP, push-approval, and most of the MFA methods enterprises deployed between 2015 and 2022.
The term matters because it carves a specific category. "MFA" in 2026 is no longer a clean signal — an enterprise saying it has "MFA deployed" might mean it has SMS OTP (which is regulatorily deprecated for high-assurance use), or push-based authenticators (which are vulnerable to MFA fatigue attacks), or hardware FIDO2 keys (which are phishing-resistant). The category boundary is where the regulatory framework draws its line. The enterprises that are required to deploy phishing-resistant MFA — federal agencies, critical infrastructure operators, federal contractors, defense contractors — already know the term. The enterprises that are not required but should still be moving toward it for security-architecture reasons are the audience for this piece.
The companion pieces handle the adjacent territory: Beyond Foundational MFA in 2026 covers the broader recovery-channel architecture, Passkey Deployment Playbook covers the deployment sequence for the dominant phishing-resistant method, MFA Fatigue Attacks covers the specific attack the category structurally prevents, and Biometric Authentication covers the unlock mechanism most phishing-resistant credentials use. This piece is the regulatory-framing reference that ties them together.
Three regulatory documents that define the category. CISA names the methods. NIST 800-63B specifies the technical assurance level. Executive Order 14028 establishes the federal mandate. The category boundary is what they describe in common.
The phrase "phishing-resistant MFA" appears in three regulatory documents that drive enterprise authentication decisions in 2026.
CISA's guidance is the most direct. CISA's "Implementing Phishing-Resistant MFA" guidance specifies the category technically: authentication methods where the cryptographic ceremony binds to the relying party's origin domain, so a credential captured at a phishing site cannot be replayed against the real site. The qualifying methods CISA names are FIDO2/WebAuthn (passkeys and hardware keys) and PIV/CAC smart cards. CISA explicitly excludes SMS OTP, voice call, email-based magic links, and push notifications with simple approve/deny prompts. CISA recommends phishing-resistant MFA for federal agencies, critical infrastructure operators, and any organization that wants to defeat the dominant 2024-2026 attack patterns.
NIST 800-63B Revision 4 (Digital Identity Guidelines, Authentication and Lifecycle Management) carries the regulatory specification. The document defines Authenticator Assurance Levels (AAL1, AAL2, AAL3) and specifies which authentication methods qualify for each level. AAL3 — the highest level — requires phishing-resistant authentication. The methods that qualify at AAL3 are FIDO2/WebAuthn with hardware-backed credentials, PIV cards with proper enrollment, and equivalents. SMS OTP is deprecated for AAL2 and explicitly excluded from AAL3. NIST 800-63B is the technical specification that federal regulators reference when they require "phishing-resistant MFA" — the term in the regulation; the specification in NIST.
Executive Order 14028 ("Improving the Nation's Cybersecurity," May 2021) requires federal agencies to adopt phishing-resistant MFA for federal employees, contractors, and partners as part of the broader zero-trust roadmap. The OMB Memorandum M-22-09 implements the EO with specific deadlines and technical requirements, including the move to FIDO2-compatible authentication across federal information systems. The federal-zero-trust requirement is what drives the cascade into federal contractor environments, defense contractor environments, and the broader supply chain.
The cascade matters for non-federal enterprises too. Federal contractors are required to deploy phishing-resistant MFA; defense contractors are required for CMMC compliance (with specific phishing-resistant requirements at higher CMMC levels); cyber insurance carriers are increasingly underwriting based on phishing-resistant MFA adoption rates; and the broader 2026 enterprise security architecture conversation has converged on phishing-resistant as the default direction for new deployments. An enterprise that is not federally required but is planning a new MFA deployment in 2026 should be planning for phishing-resistant from the start.
Four methods that qualify as phishing-resistant in the regulatory sense. The deployment architecture decides which method goes to which workforce segment — managed desks get platform passkeys, privileged accounts get hardware keys, frontline gets deviceless cards, mobile-heavy users get syncable.
In 2026 production, four authentication methods qualify as phishing-resistant MFA. The deployment architecture decides which goes to which workforce segment.
Platform passkeys are FIDO2/WebAuthn credentials bound to a managed device's hardware-protected enclave (Apple Secure Enclave, Windows TPM, Android StrongBox, Chrome OS TPM). The user enrolls the passkey on first login by completing the WebAuthn ceremony locally and unlocking with biometrics (Touch ID, Face ID, Windows Hello fingerprint or face, Android biometric unlock). Subsequent authentications complete the WebAuthn challenge-response without any password. Platform passkeys are the dominant deployment pattern for managed-desk-worker segments — fastest enrollment, lowest friction, strong security posture. The phishing-resistance comes from the WebAuthn origin binding: the credential won't sign a challenge from a phishing site because the origin doesn't match.
Syncable passkeys are FIDO2/WebAuthn credentials that sync across the user's devices through a cloud sync provider (Apple iCloud Keychain, Google Password Manager, 1Password, Dashlane, Bitwarden). The user can authenticate from any of their synced devices using whichever biometric the device supports. Syncable passkeys fit knowledge-worker segments where users have multiple personal devices and want seamless cross-device authentication. The phishing-resistance is the same WebAuthn property as platform passkeys; the trust dependency is broader because it includes the sync provider's security posture.
Hardware FIDO2 security keys are physical credentials (YubiKey, Feitian, Token2, Google Titan, and similar) that the user carries and presents at authentication time. The key holds the cryptographic credential; the user touches the key (or completes biometric unlock for biometric-enabled keys like YubiKey Bio) to approve the WebAuthn challenge. Hardware keys are the strongest phishing-resistant option and are the standard pattern for privileged accounts — domain administrators, financial-system operators, security tools. The deployment overhead is higher (physical distribution, replacement on loss, helpdesk support for forgotten keys), but the security posture for the workforce segments it covers is the strongest available.
FIDO2-compatible deviceless cards — the Avatier Identity Challenge Card pattern — handle the workforce segments where personal devices and hardware keys don't fit. Frontline workers on shared workstations, contractor populations without managed devices, clinical workers at shared healthcare workstations, defense facilities where phones aren't viable — these segments need authentication that runs without a personal phone or laptop. The deviceless card carries the FIDO2 cryptographic credential; the user taps the card at a reader connected to the shared workstation and (optionally) enters a PIN. The cryptographic ceremony is identical to the other three methods; the phishing-resistance comes from the same WebAuthn origin binding.
Smart cards (PIV/CAC) are the federal-government and defense pattern for phishing-resistant authentication. PIV cards (Personal Identity Verification, defined in FIPS 201) and CAC cards (Common Access Card, the DoD equivalent) carry cryptographic credentials with strong identity proofing at enrollment. Smart cards predate FIDO2 but achieve the same phishing-resistant property through the PIV/CAC certificate-based authentication ceremony. Federal agencies use smart cards extensively; non-federal enterprises typically use FIDO2 methods instead because the enrollment overhead of PIV/CAC is high.
Most 2026 enterprise deployments mix the methods. Platform passkeys for the desk-worker majority. Hardware keys for the privileged-account minority. Deviceless cards for the frontline and shared-workstation segments. Syncable passkeys for the mobile-heavy or BYOD knowledge worker. The deployment architecture decides which method goes where based on segment-specific operational fit.
The other half of the phishing-resistant MFA framing is what doesn't qualify. The exclusions are specific and worth understanding because many enterprises think they have phishing-resistant MFA when they have an authentication method the regulatory framework explicitly excludes.
SMS OTP is excluded because the OTP code can be relayed through an adversary-in-the-middle proxy. The user gets the legitimate SMS from the legitimate IdP after the attacker has triggered the authentication. The user types the OTP into the phishing site (thinking it's the real site); the attacker forwards it to the real site; the attacker is authenticated. SMS additionally has known transport-level vulnerabilities — SIM swap attacks (the attacker socially-engineers the carrier into porting the user's number to an attacker-controlled SIM), SS7 protocol exploitation (the attacker intercepts SMS in transit), and carrier service-desk social engineering. NIST 800-63B Rev. 4 deprecates SMS for AAL2 and excludes it from AAL3 explicitly.
Voice OTP is excluded for the same relay reason plus the additional vulnerability of synthetic voice and deepfake voice attacks. The IdP places a phone call, the user reads the code; the attacker can relay the code through a man-in-the-middle, or use a deepfaked voice to social-engineer the user into reading the code to an attacker-impersonating IT support.
Push notifications with simple approve/deny are excluded because the user can approve a malicious authentication attempt — the MFA fatigue attack vector. Number matching (where the user types a number displayed on the originating device into the authenticator app) closes the blind-approval vulnerability and is a meaningful improvement, but is still not phishing-resistant in the regulatory sense because an adversary-in-the-middle attack with social-engineering pretext can still extract the number from the user. CISA's guidance distinguishes between "MFA" (which includes number-matching push) and "phishing-resistant MFA" (which doesn't) and recommends migration from the former to the latter for federal agencies.
Email-based magic links are excluded for similar reasons — the link can be relayed, the user has no signal that the requesting site is legitimate, and email transport has its own vulnerabilities (BEC compromises, MX hijacking, etc.).
Soft-token OTP authenticator apps (Google Authenticator, Authy, third-party TOTP apps that don't support number matching or origin binding) are excluded for the same relay reason as SMS OTP. The user can type the OTP into a phishing site, the attacker relays it, the authentication succeeds. The major IdP-vendor authenticator apps (Microsoft Authenticator, Okta Verify, Duo Mobile) have moved to number matching and now ship FIDO2 support for the apps; the third-party TOTP apps that don't support these features remain in the excluded category.
The exclusion framing matters operationally because most enterprises in 2026 have a mix of phishing-resistant and non-phishing-resistant methods deployed simultaneously. The path to "phishing-resistant MFA" as a category claim is migrating the workforce segments that still use the excluded methods over to the qualifying methods.
The deployment pattern that produces phishing-resistant MFA as the workforce default across a mixed enterprise environment has five operational pillars.
Pillar 1: Privileged accounts on hardware FIDO2 keys. Domain admins, financial-system operators, security tools, and executives get hardware keys with SMS-OTP fallback explicitly disabled. The privileged surface is small and high-impact; the deployment timeline is short (4-6 weeks). This is the highest-ROI first move because the impact of a privileged-account compromise is catastrophic.
Pillar 2: Recovery-channel infrastructure deployed in parallel. Phishing-resistant authentication does not by itself fix the recovery channel. When a user loses their hardware key or their managed-laptop device, the recovery flow needs to issue a new credential. If the recovery flow relies on knowledge-based questions or unstructured help-desk verification, the Storm-2949 attack pattern works against phishing-resistant accounts as well as against any others. The mitigation is workflow-tied verification — the Avatier Password Station pattern — deployed before the broader rollout.
Pillar 3: Managed-desk-worker segment on platform passkeys. Roll out platform passkey enrollment to the managed-laptop workforce as enrollment-on-first-login. The IdP prompts the user to enroll a passkey on the device; the password remains as fallback during transition; after successful enrollment the user can disable password fallback for that account. Timeline is 3-6 months depending on device-fleet maturity.
Pillar 4: Frontline and shared-workstation segment on FIDO2 deviceless cards. Deploy the Avatier Identity Challenge Card pattern (or equivalent) for workforce segments where personal devices and hardware keys structurally don't fit. The card carries the FIDO2 credential; the user taps the card at a reader; the cryptographic ceremony is identical to passkey authentication. Timeline is 6-9 months including card distribution and reader installation.
Pillar 5: Per-segment password removal as each segment matures. For segments where phishing-resistant deployment is complete and operationally stable, remove the password fallback entirely. The IdP no longer accepts password authentication for those accounts. The security-posture upgrade actually lands at this phase — until password fallback is removed, the password-related attack surface remains.
The five-pillar pattern produces phishing-resistant MFA as the workforce default within 12-18 months for most enterprises. Most enterprises will run hybrid environments (some segments at phase 5, others at phase 3 or 4) for years; the architectural test is whether the hybrid state tracks segment maturity cleanly rather than producing a confusing mix where the security team doesn't know which segments have crossed the threshold.
Avatier Identity Anywhere ships phishing-resistant authentication across all the qualifying methods. The platform supports FIDO2/WebAuthn passkey enrollment and authentication across platform providers (Windows Hello, macOS Touch ID, Android, Chrome OS), syncable providers (Apple iCloud Keychain, Google Password Manager, 1Password, Dashlane, Bitwarden), hardware FIDO2 keys (YubiKey, Feitian, Token2, Google Titan), and smart cards for federal and defense contexts. For workforce segments where personal devices don't fit — frontline shared workstations, contractor populations without managed devices, defense facilities where phones aren't viable — the Avatier Identity Challenge Card provides FIDO2-compatible deviceless authentication running on the same cryptographic ceremony.
Recovery flows tie through Password Station for workflow-verified resets — the architecture that closes the Storm-2949 social-engineering vector. Lifecycle integration with the Avatier Identity Anywhere Lifecycle Management platform handles credential provisioning at joiner, re-enrollment at mover events, and credential revocation at leaver events. The Avatier Trust Center publishes our compliance posture (SOC 2 Type II zero exceptions, ISO/IEC 27001:2022, PCI DSS v4.0.1, CSA STAR Level 1, NIST 800-53 Rev. 5 aligned, CISA Secure-by-Design Pledge signatory).
The architectural pattern works regardless of vendor — the point of this piece is not that you have to buy Avatier — but the integrated pattern of FIDO2 passkeys + hardware keys + deviceless cards + workflow-verified recovery is what separates an enterprise that has actually achieved phishing-resistant MFA across the workforce from one that has merely deployed a few FIDO2 keys to executives and called it done.
Phishing-resistant MFA is the 2026 regulatory framing for the authentication category that survives the attack patterns that defeated everything else. The category boundary is specific: FIDO2/WebAuthn passkeys, hardware FIDO2 keys, FIDO2-compatible deviceless cards, and PIV/CAC smart cards qualify; SMS OTP, push-approval (with or without number matching), voice OTP, email magic links, and soft-token TOTP do not. Most enterprises in 2026 have a mix of qualifying and non-qualifying methods deployed across different workforce segments. The path to "phishing-resistant MFA as the default" runs through five pillars — privileged accounts first, recovery infrastructure in parallel, desk workers on platform passkeys, frontline on deviceless cards, per-segment password removal as maturity allows. The enterprises that get this transition right will close the dominant authentication attack vectors of the 2022-2025 era. The enterprises that treat phishing-resistant as a future-state aspiration without a deployment plan will keep ending up in the incident-disclosure cycle.
Adaptive authentication evaluates risk signals at every session and adjusts the authentication requirement to match — stronger MFA when risk is high, frictionless access when risk is low. The 2026 enterprise reference on the signals that actually matter, the architecture that composes risk with phishing-resistant MFA, and where adaptive deployments break.
Push-bombing and MFA fatigue attacks defeat MFA by exhausting the user, not the cryptography. The 2026 defense patterns — number matching, push throttling, phishing-resistant migration, and the architecture that survives the attack vector that took down Uber, Cisco, and a long list of enterprises since 2022.
What the Stryker attack revealed about device-dependent MFA — and what phishing-resistant authentication actually means in an era of AiTM session theft.
Gartner Peer Insights で評価
Avatier の 14 件の検証済みレビューに基づくIdentity Governance and Administration
Gartner Peer Insights でレビューを読む