Multi-factor authentication

NIST SP 800-63B (revision 4, finalised in 2025) grades authentication by Authenticator Assurance Level. AAL1 permits a single factor; AAL2 requires two distinct factors and, in revision 4, obliges verifiers to offer at least one phishing-resistant option; AAL3 requires a phishing-resistant cryptographic authenticator with a non-exportable private key, which excludes syncable passkeys. OTP over SMS or voice (PSTN out-of-band) is a "restricted" authenticator whose use requires the verifier to assess the risk and offer an alternative. US federal policy (OMB M-22-09, 2022) went further and required phishing-resistant MFA for agency staff. In EU law, NIS2 Art. 21(2)(j) lists MFA or continuous authentication among the risk-management measures, and the Danish NIS2 law that took effect on 1 July 2025 carries that requirement into national law.

"Phishing-resistant" has a precise technical meaning: the authenticator output must be bound to the verifier's identity so it cannot be replayed to a different site. NIST recognises two mechanisms, verifier-name binding and channel binding. WebAuthn/FIDO2 implements the former: the browser writes the actual origin into clientDataJSON, the authenticator includes a hash of the relying-party ID in authenticatorData, and the signature covers both plus a server challenge, so a response produced on a look-alike domain is useless to the real site. Smart-card client authentication in mutual TLS provides channel binding. OTPs, push approvals and SMS codes carry no such binding, which is why adversary-in-the-middle (AiTM) toolkits such as Evilginx can relay them in real time.

Push-based MFA added its own failure mode, MFA fatigue or prompt bombing, used in the 2022 Uber breach: the attacker holding the password triggers repeated prompts until the user approves one. Number matching (the user types a number shown on the login page into the app), displayed location and application context, and rate limits on prompts are now standard mitigations; Microsoft made number matching mandatory in Authenticator in 2023.

MFA protects the authentication event, not the session that follows. AiTM kits capture not only the password and code but the resulting session cookie or OAuth refresh token, which then works without any further factor; defences include short token lifetimes, conditional access tied to compliant devices, and emerging token-binding approaches such as Device Bound Session Credentials. Other bypass paths are weaker fallback methods left enabled, help-desk resets performed on a phone call, legacy protocols (IMAP, POP, basic authentication) that never prompt for a second factor, and service accounts exempted from policy. An MFA programme is therefore assessed on coverage of all interactive and remote access paths, the strength of the weakest enabled method, and the rigour of enrolment and recovery - not on whether MFA is "turned on".