Skip to main content
← All controls
AAL3 / IA-2(1) / IA-2(2) NIST SP 800-63B

Phishing-resistant authentication

Demonstrate that authentication mechanisms for privileged and high-value accounts resist credential phishing, man-in-the-middle interception, and replay attacks through cryptographic origin binding.

Description

What this control does

Phishing-resistant authentication requires multifactor authentication mechanisms that cannot be successfully exploited through social engineering, man-in-the-middle, or credential replay attacks. This typically includes FIDO2/WebAuthn hardware security keys, platform authenticators (biometric passkeys), or PKI-based certificate authentication bound to a hardware root of trust. Unlike SMS or TOTP codes, phishing-resistant factors cryptographically bind the authentication ceremony to the origin, preventing attackers from proxying credentials even if the user is tricked into authenticating to a fraudulent site.

Control objective

What auditing this proves

Demonstrate that authentication mechanisms for privileged and high-value accounts resist credential phishing, man-in-the-middle interception, and replay attacks through cryptographic origin binding.

Associated risks

Risks this control addresses

  • Adversary-in-the-middle (AitM) phishing attacks successfully proxying user credentials and session tokens despite MFA
  • Credential replay attacks using harvested OTP codes or push notifications approved by socially engineered users
  • Real-time phishing proxy frameworks (e.g., Evilginx, Modlishka) bypassing TOTP and SMS-based MFA
  • Session hijacking following successful MFA where origin validation is absent
  • Insider threats exfiltrating TOTP seeds or SMS-based codes to unauthorized parties
  • Compromise of privileged accounts (administrators, developers, finance) leading to elevated access despite MFA deployment
  • Regulatory non-compliance with emerging standards requiring phishing-resistant authentication for critical systems

Testing procedure

How an auditor verifies this control

  1. Obtain the current inventory of all authentication methods deployed, categorized by user population and system criticality.
  2. Review identity provider configuration exports to identify authentication policies and enrolled factor types for privileged accounts.
  3. Verify technical specifications of deployed MFA factors against FIDO2/WebAuthn standards, examining origin validation and attestation mechanisms.
  4. Select a sample of at least 10 privileged users and inspect their enrolled authentication methods to confirm phishing-resistant factor usage.
  5. Attempt to authenticate to a production or representative test environment using TOTP, SMS, or push notification methods to verify these are blocked or unavailable for privileged access.
  6. Review conditional access or authentication policy rules to confirm enforcement of phishing-resistant factors for administrative consoles, cloud tenant administration, and financial systems.
  7. Examine authentication logs over a 30-day period to identify any successful authentications using non-phishing-resistant methods for in-scope accounts.
  8. Interview identity and access management personnel to understand exception processes, fallback mechanisms, and breakglass procedures that may bypass phishing-resistant requirements.
Evidence required Configuration exports from identity providers (Entra ID, Okta, Google Workspace) showing authentication strength policies and allowed factor types; screenshots of conditional access rules enforcing FIDO2/WebAuthn for privileged roles; authentication logs demonstrating factor usage with timestamps and user identifiers; enrollment reports listing registered hardware keys or platform authenticators per user; policy documents defining phishing-resistant authentication requirements and exemption approval workflows.
Pass criteria All privileged and high-value user accounts enforce phishing-resistant MFA (FIDO2, WebAuthn, or PKI certificates) with no successful authentications using TOTP, SMS, or push notifications in the review period, except documented and approved emergency access scenarios.