Most federal agencies have multi-factor authentication (MFA) deployed. Their security teams know the numbers, the policy deadlines, and the vendor deployments. They check the box on MFA and move to the next item on the zero trust roadmap. What they often have not done is ask a harder question: does the MFA they deployed actually resist phishing, or does it just require a second factor?
Those are not the same thing. SMS one-time passcodes, push notifications, and time-based authenticator apps all require a second factor. None of them qualify as phishing-resistant under Office of Management and Budget (OMB) M-22-09. An attacker who intercepts the authentication session, proxies the credential in real time, or tricks a user into approving a push notification defeats every one of those methods. The credential is replayable. The session is hijackable. The MFA box is checked, and the agency is still exposed.
OMB M-22-09 draws the line precisely here. Phishing-resistant MFA means the credential cryptographically binds to the specific origin being authenticated. An intercepted credential is useless to the attacker because it cannot be replayed against a different session or domain. Federal agencies required enterprise-wide deployment by end of FY2024. Most agencies are now in the continuous improvement phase, which means the audit question has shifted from “do you have MFA?” to “does your MFA actually resist phishing?” These are different audits, with different evidence requirements.
Deploy phishing-resistant MFA by selecting one of two approved methods: Fast Identity Online 2 (FIDO2)/WebAuthn security keys (YubiKey, Windows Hello for Business with hardware TPM) or Personal Identity Verification/Common Access Card (PIV/CAC) smart cards. Both bind the credential cryptographically to the authenticating origin, which means an intercepted credential cannot be replayed. SMS codes, Time-based One-Time Password (TOTP) apps, and push notifications fail the phishing-resistance test even though they satisfy AAL2 under NIST SP 800-63B. OMB M-22-09 draws a harder line than 800-63B alone.
What OMB M-22-09 Actually Requires for Federal Phishing-Resistant MFA
OMB M-22-09 defines phishing-resistant MFA as a federal zero trust requirement, not a recommendation. The memo requires all federal employees, contractors, and partners accessing federal systems to use phishing-resistant MFA. The FY2024 deadline passed. Agencies now operate in the continuous improvement phase under the Federal Zero Trust Strategy, which means the baseline expectation is deployment completed, not deployment in progress.
What the Memo Specifically Prohibits
M-22-09 does not merely recommend stronger MFA. It specifically excludes authentication methods that fail the phishing-resistance test. SMS-based one-time passcodes, email-delivered codes, and push notification approvals are not phishing-resistant. These methods are vulnerable to real-time phishing proxies, SIM swapping, and push fatigue attacks. The intercepted credential can be replayed. The session can be hijacked. They do not satisfy the federal requirement regardless of how widely they are deployed across the enterprise.
TOTP apps such as Google Authenticator or Microsoft Authenticator in standard OTP mode fall into the same category. A user can be tricked into entering their TOTP code into a convincing phishing site that forwards it immediately to the legitimate service. The attack succeeds in seconds, well within the 30-second code window. Widespread deployment of these tools does not constitute compliance with M-22-09.
The Two Approved Methods
M-22-09 recognizes two authentication approaches as phishing-resistant for federal systems. The first is PIV/CAC, the smart card standard federal agencies have used for years under HSPD-12. The second is FIDO2/WebAuthn, a modern cryptographic standard that binds authentication to the specific origin URL and device. Both methods generate credentials that cryptographically cannot be replayed against a different session or domain.
The practical distinction matters for audit purposes. PIV/CAC is already embedded in most civilian federal agencies. The gap is often not deployment of the card itself but enforcement: whether systems actually require PIV authentication rather than falling back to username/password when PIV fails. FIDO2 is the modern path, particularly for cloud-native systems and remote workers who lack card readers.
The audit fix. Pull your MFA deployment inventory from your identity provider. Classify every authentication method in use: PIV/CAC, FIDO2/WebAuthn, TOTP app, SMS OTP, push notification, or password only. Flag every non-phishing-resistant method. For each flagged method, identify the user population still relying on it and the system or application blocking migration. This inventory is the starting point for your M-22-09 compliance evidence package.
NIST SP 800-63B Authenticator Assurance Levels for Federal Systems
NIST SP 800-63B defines three Authenticator Assurance Levels that determine which authentication methods meet which risk thresholds. Federal systems require AAL2 at minimum. High-value assets, privileged access, and sensitive data require AAL3. Understanding where your systems fall on this scale determines which authentication technologies satisfy the requirement and which do not.
AAL1, AAL2, and AAL3 Defined
AAL1 requires single-factor authentication. A password alone satisfies AAL1. This level is insufficient for any federal system covered by M-22-09. AAL2 requires two authentication factors, one of which must use approved cryptography. FIDO2 hardware keys, PIV/CAC smart cards, and TOTP authenticator apps on a trusted device all satisfy AAL2, but only FIDO2 and PIV/CAC are phishing-resistant within the AAL2 category. AAL3 adds the requirement for hardware-based authentication and verifier impersonation resistance. Physical FIDO2 hardware keys such as YubiKeys and PIV/CAC cards both satisfy AAL3.
The gap that catches agencies in audit: deploying a TOTP app satisfies AAL2 technically, but fails the phishing-resistance requirement in M-22-09. The two requirements are separate. An agency can satisfy NIST AAL2 while still failing OMB M-22-09. Both must be met simultaneously. The only methods that satisfy both are FIDO2 and PIV/CAC.
Mapping Systems to Assurance Levels
Federal agencies must categorize every system by risk level and map that risk level to the required AAL. Low-impact systems require AAL2. Moderate and high-impact systems, particularly those handling Controlled Unclassified Information (CUI) or supporting mission-critical operations, require AAL3. Privileged access: IAM roles with administrative rights, root accounts, and system administration require AAL3 by default under federal zero trust architecture principles.
The phishing-resistant MFA requirement in M-22-09 and the AAL requirements in NIST SP 800-63B are two separate compliance tracks that intersect. Meeting AAL2 with a TOTP app does not satisfy M-22-09. Meeting M-22-09 with FIDO2 hardware keys satisfies both simultaneously. Audit preparation requires demonstrating compliance with both standards, not just one.
The audit fix. Build a system-to-AAL mapping matrix. List every application and system in scope. Assign each an impact level (low, moderate, high) based on your FIPS 199 categorization. Map each impact level to required AAL: low systems require AAL2 with phishing-resistant method; moderate and high systems require AAL3. Document which authenticator type is deployed for each system and whether it satisfies both the AAL requirement and the M-22-09 phishing-resistance requirement. This matrix is the core audit artifact for your zero trust identity pillar.
Implementation Options: FIDO2, PIV/CAC, and Windows Hello for Business
Three implementation paths satisfy the federal phishing-resistant MFA requirement. Each has different infrastructure requirements, user experience profiles, and deployment considerations. The right choice depends on your existing identity infrastructure, your remote workforce size, and whether you are operating in a Windows-centric environment or a cloud-native one.
FIDO2/WebAuthn Hardware Keys
FIDO2 is the modern standard for phishing-resistant authentication. A FIDO2 hardware key such as a YubiKey generates a cryptographic key pair unique to the specific origin URL during registration. When the user authenticates, the key signs a challenge that includes the origin. A phishing site at a different domain cannot use the intercepted credential because the signature would fail origin validation. The credential is bound to the legitimate site by cryptography, not by user vigilance.
FIDO2 hardware keys satisfy AAL3 when combined with PIN or biometric verification on the device. They work across platforms: Windows, macOS, Linux, iOS, and Android all support FIDO2 authenticators. The primary deployment consideration is key management: procurement, issuance, replacement for lost or broken keys, and the backup authenticator policy for account recovery. Agencies must also confirm that every application in scope supports FIDO2. Legacy on-premises applications frequently require additional configuration or proxy solutions.
PIV/CAC Smart Cards
PIV (for civilian agencies) and CAC (for Department of Defense) are the established federal phishing-resistant standard. PIV certificates on smart cards satisfy both M-22-09 and AAL3. Most federal agencies have existing PIV infrastructure including card management systems, card readers, and HSPD-12 enrollment processes. The audit question for PIV is not whether the card exists but whether every system requires it and whether fallback bypass paths have been eliminated.
Remote workers and cloud-native systems present the primary PIV gap. PIV requires a physical card reader. Laptop-based card readers are available but create friction. Cloud applications that do not support certificate-based authentication require a federation layer to proxy PIV credentials through a modern identity provider such as Microsoft Entra ID or Okta with PIV/certificate connector. Agencies running hybrid environments often have PIV enforced for on-premises systems and a separate FIDO2 or smart card path for cloud access.
Windows Hello for Business
Windows Hello for Business satisfies the phishing-resistant MFA requirement when deployed in hardware-backed mode with a Trusted Platform Module (TPM). The authentication credential is bound to the specific device’s TPM chip and to the specific service being authenticated, providing origin binding equivalent to FIDO2. It satisfies AAL2 for most configurations and AAL3 when combined with hardware TPM attestation.
Windows Hello for Business integrates natively with Microsoft Entra ID and Active Directory environments. For agencies already running Microsoft 365 and Azure Government cloud services, it is often the lowest-friction deployment path. The audit caveat: Windows Hello for Business in software mode (without hardware TPM) does not satisfy the phishing-resistant requirement. Confirm that every enrolled device has TPM 2.0 enabled and that WHFB is configured in hardware key trust or certificate trust mode, not cloud Kerberos trust without hardware attestation.
The audit fix. For each of the three approved technologies in your environment, document the following: deployment scope (percentage of user population covered), hardware requirements met (TPM version for WHFB, card readers for PIV, USB/NFC support for FIDO2), backup authentication policy for account recovery, and any application-level exceptions where phishing-resistant MFA is not yet enforced. Exceptions require a documented Plan of Action and Milestones (POA&M) with a remediation target date.
Federal Zero Trust Deployment Roadmap for Phishing-Resistant MFA
Agencies in the continuous improvement phase under M-22-09 need a deployment roadmap that addresses the remaining gaps: legacy systems without phishing-resistant MFA support, exceptions for specific user populations, and the audit evidence trail that demonstrates continuous compliance. The roadmap follows a sequenced approach based on risk, not alphabetical system inventory.
Phase 1: Privileged Access First
Start with privileged accounts. System administrators, IAM administrators, security operations personnel, and any account with elevated rights represent the highest-value targets for credential theft. A compromised privileged account causes more damage than a compromised standard user account by several orders of magnitude. Deploy FIDO2 hardware keys or enforce PIV for all privileged access before addressing the broader user population. This is also where the CISA Zero Trust Maturity Model places the identity pillar’s highest-maturity requirements.
Phase 2: High-Value Systems and External Interfaces
After privileged access, move to systems that handle CUI, PII, or mission-critical data, and any system accessible from the public internet. External-facing systems are the primary target for phishing attacks. An agency that enforces phishing-resistant MFA on internal systems but allows password-plus-SMS access to its public-facing portals has solved the wrong problem. Prioritize internet-accessible applications in Phase 2.
Phase 3: Enterprise-Wide Migration and Legacy Remediation
The final phase addresses the full user population and any legacy systems that required application-level changes to support phishing-resistant authentication. Legacy systems frequently require federation solutions, protocol upgrades, or modernization. Agencies that cannot complete legacy remediation within their roadmap timeline must document open exceptions as POA&M items with risk acceptance sign-off from the Authorizing Official. Undocumented exceptions are the audit finding. Documented exceptions with accepted risk are not.
The continuous improvement expectation under M-22-09 requires agencies to track and reduce exceptions over time. An agency with 15% of users still on non-phishing-resistant MFA in 2024 that has reduced that to 3% by 2026 and has a roadmap to zero demonstrates continuous improvement. An agency with 15% in 2024 and 14% in 2026 with no roadmap demonstrates stagnation. Auditors see the difference.
The audit fix. Build a phishing-resistant MFA deployment tracker. Track three numbers: total user population, users enrolled in phishing-resistant MFA (PIV, FIDO2, or WHFB hardware-backed), and users with open exceptions. Calculate your phishing-resistant coverage percentage monthly. Set a target date to reach 100% enrollment or document the residual exceptions with accepted risk. Present this tracker as your primary M-22-09 compliance evidence. Update it before every compliance review or ATO renewal.
| Authentication Method | Phishing-Resistant | AAL Level | M-22-09 Compliant | Federal Use Case |
|---|---|---|---|---|
| PIV/CAC Smart Card | Yes | AAL3 | Yes | Civilian agency standard; DoD primary method |
| FIDO2 Hardware Key (YubiKey, etc.) | Yes | AAL2/AAL3 | Yes | Cloud-native systems, remote workers, BYOD environments |
| Windows Hello for Business (Hardware TPM) | Yes | AAL2/AAL3 | Yes | Microsoft 365 and Azure Government environments |
| TOTP App (Google/Microsoft Authenticator, standard mode) | No | AAL2 | No | Transitional use only; must be replaced |
| SMS One-Time Passcode | No | AAL1 (restricted) | No | Not permitted for federal systems |
| Push Notification (Duo, Microsoft Authenticator push) | No | AAL2 | No | Not permitted; vulnerable to push fatigue attacks |
| Email One-Time Passcode | No | AAL1 | No | Not permitted for federal systems |
| Windows Hello for Business (Software mode, no TPM) | No | AAL1 | No | Not permitted; must confirm hardware TPM enforcement |
The federal phishing-resistant MFA requirement is not ambiguous. OMB M-22-09 names two compliant methods: FIDO2/WebAuthn and PIV/CAC. Windows Hello for Business in hardware-backed mode satisfies the same cryptographic standard. Every other method currently deployed across federal enterprises, SMS, push notifications, and TOTP apps, does not qualify regardless of how widely it is deployed or how recently it was implemented. Agencies that completed M-22-09 deployment on schedule but deployed the wrong technology face the same compliance gap as agencies that never started. The audit evidence required is not a count of MFA-enrolled users. It is a demonstration that the enrolled method cryptographically resists phishing. Start with that question, and the roadmap writes itself.
Frequently Asked Questions
What does federal phishing-resistant MFA implementation require under OMB M-22-09?
OMB M-22-09 requires all federal employees, contractors, and partners to authenticate using methods that cryptographically bind the credential to the specific origin being accessed, making intercepted credentials non-replayable. The two approved methods are FIDO2/WebAuthn and PIV/CAC. SMS OTP, push notifications, and TOTP apps do not satisfy this requirement. Enterprise-wide deployment was required by end of FY2024.
Why are SMS and authenticator app OTPs not considered phishing-resistant?
SMS and TOTP codes can be intercepted and immediately replayed by an attacker operating a real-time phishing proxy. The attacker presents a convincing fake login page, captures the user’s code, and forwards it to the legitimate service within the valid window. The authentication succeeds. Phishing-resistant methods use cryptographic binding to the specific origin URL, so an intercepted credential is mathematically useless against a different domain or session.
What NIST authenticator assurance level is required for federal systems?
Federal systems require AAL2 at minimum, with AAL3 required for high-value assets, privileged access, and systems handling sensitive data. AAL2 alone is insufficient if the deployed authenticator is not phishing-resistant. Only FIDO2 and PIV/CAC satisfy both AAL2 and the M-22-09 phishing-resistance requirement simultaneously. TOTP apps satisfy AAL2 but fail M-22-09.
Does Windows Hello for Business satisfy the federal phishing-resistant MFA requirement?
Windows Hello for Business satisfies the phishing-resistant MFA requirement only when deployed with a hardware Trusted Platform Module (TPM 2.0) in hardware key trust or certificate trust mode. Software-mode WHFB without hardware TPM does not qualify. Agencies must verify TPM enforcement in their Intune or Group Policy configuration before claiming WHFB compliance.
How does FIDO2 differ from PIV/CAC for federal deployments?
PIV/CAC is the established federal standard using physical smart cards and certificate-based authentication, ideal for agencies with existing HSPD-12 infrastructure. FIDO2 is a modern alternative that works across cloud platforms without card readers, making it more practical for remote workers and cloud-native applications. Both satisfy M-22-09 and AAL3 when properly configured. Many agencies deploy both: PIV for on-premises and legacy systems, FIDO2 for cloud and mobile access.
Where does identity rank within the CISA Zero Trust Maturity Model?
Identity is the most mature pillar in the CISA Zero Trust Maturity Model v2.0, meaning federal agencies have the clearest implementation guidance and the longest compliance runway. The optimal maturity level for identity requires phishing-resistant MFA enterprise-wide, continuous identity validation, and automated anomaly detection. Agencies should use the ZTMM identity pillar maturity levels as their benchmark for measuring progress beyond the M-22-09 baseline.
What audit evidence is required to demonstrate M-22-09 phishing-resistant MFA compliance?
Auditors look for four evidence items: a current MFA deployment inventory showing which authenticator type each user population uses, a system-to-AAL mapping that confirms phishing-resistant methods are applied to the correct risk tiers, documented exceptions with accepted-risk sign-off for any users or systems not yet migrated, and a plan of action with milestones for resolving open exceptions. A count of MFA-enrolled users without authenticator type classification does not demonstrate compliance with M-22-09.
What happens if an agency misses the M-22-09 phishing-resistant MFA deadline?
OMB M-22-09 did not include specific financial penalties, but non-compliance has direct consequences for ATO status and federal audit findings. Systems operating outside M-22-09 requirements face elevated risk ratings during FISMA audits and ATO reviews. The practical consequence is either an ATO with conditions requiring remediation, a denial of ATO until phishing-resistant MFA is deployed, or a formal POA&M that auditors track until closure.
Subscribe to The Authority Brief for next week’s analysis.
