Multi-Factor Authentication: Types, Standards, and Deployment

Multi-factor authentication (MFA) is a security control requiring users to present two or more distinct verification factors before gaining access to a system, application, or dataset. Federal mandates under frameworks such as NIST SP 800-63B and sector-specific rules from agencies including the Federal Financial Institutions Examination Council (FFIEC) and the Cybersecurity and Infrastructure Security Agency (CISA) have elevated MFA from a recommended best practice to a compliance obligation across critical infrastructure sectors. This page maps the factor taxonomy, deployment mechanics, regulatory context, and decision criteria that structure MFA adoption in US organizations — a subject catalogued across the Information Security Providers maintained on this site.

Definition and scope

Multi-factor authentication is formally defined within NIST Special Publication 800-63B, Digital Identity Guidelines: Authentication and Lifecycle Management as authentication using two or more distinct authentication factors. NIST classifies every authentication factor into exactly one of three categories:

1. Something you know — memorized secrets such as passwords, PINs, and security question answers
2. Something you have — physical or logical possession artifacts such as hardware tokens, smart cards, cryptographic keys, and one-time password (OTP) authenticator applications
3. Something you are — biometric characteristics including fingerprint scans, facial geometry, retinal patterns, and voiceprints

MFA is distinct from two-step verification (2SV), which may chain two instances of the same factor type — for example, a password followed by a security question — and therefore does not meet the cross-category threshold NIST requires. The scope of MFA obligations in the US extends across at least 8 identified federal regulatory regimes: HIPAA Security Rule (45 CFR §164.312), NIST CSF, FISMA, PCI DSS (version 4.0 requires MFA for all access into the cardholder data environment per PCI Security Standards Council Requirement 8.4), FFIEC guidance for financial institutions, CISA Zero Trust Architecture mandates, FTC Safeguards Rule, and the Cybersecurity Maturity Model Certification (CMMC) for Defense Industrial Base contractors.

The clarifies how regulatory references are structured across this network's providers without substituting for licensed compliance counsel.

How it works

MFA authentication follows a sequenced challenge-response architecture. A generalized deployment operates through four discrete phases:

1. Identity claim — The user presents a primary identifier, typically a username or email address, initiating an authentication session.
2. First-factor verification — The system evaluates the first factor. In password-based flows, this is a memorized secret checked against a stored credential (NIST SP 800-63B §5.1 requires salted and hashed storage using approved algorithms such as SHA-256 or bcrypt).
3. Second-factor challenge — Upon successful first-factor validation, the system issues a challenge requiring the second factor. Common mechanisms include:
4. TOTP (Time-based One-Time Password) — a 6–8 digit code generated every 30 seconds via RFC 6238-compliant apps such as those built on the OATH standard
5. FIDO2/WebAuthn — a W3C and FIDO Alliance standard using public-key cryptography; the authenticator (hardware key or platform authenticator) signs a server challenge without transmitting a shared secret
6. Push notification authentication — a server sends an approval request to a registered device; user interaction is captured and returned as a signed assertion
7. SMS/voice OTP — a code delivered via public switched telephone network (PSTN); NIST SP 800-63B §5.1.3.2 designates PSTN as a "restricted authenticator" due to SIM-swapping and SS7 protocol vulnerabilities
8. Session establishment — After both factors validate, the server issues a session token scoped to a defined time window and privilege level.

The FIDO2 protocol, published jointly by the FIDO Alliance and the W3C, is the only major MFA standard that eliminates the shared-secret model entirely, rendering phishing-based credential theft structurally ineffective against enrolled authenticators.

TOTP vs. FIDO2 — a direct comparison: TOTP codes can be intercepted in real-time phishing attacks because the code is transmitted to the relying party; FIDO2 authentication binds the cryptographic response to the origin domain, so a cloned phishing site receives no usable credential. CISA's 2023 guidance on phishing-resistant MFA explicitly identifies FIDO2 and PIV/smart-card authentication as the only implementations that satisfy "phishing-resistant" status (CISA Phishing-Resistant MFA Fact Sheet).

Common scenarios

MFA deployment varies by sector risk profile, user population, and the sensitivity of assets being protected.

Federal civilian agencies — OMB Memorandum M-22-09 mandates phishing-resistant MFA for all federal workforce accounts as part of the Zero Trust Architecture strategy. Personal Identity Verification (PIV) cards and FIDO2 hardware keys are the accepted implementation paths.

Healthcare organizations — HIPAA does not mandate MFA by name, but the HHS Office for Civil Rights has cited inadequate access controls — the absence of MFA among them — in enforcement actions under 45 CFR §164.312(d). Healthcare remains one of the highest-breach-cost sectors at $10.93 million average per incident in 2023 (IBM Cost of a Data Breach Report 2023).

Financial services — The FFIEC Authentication Guidance (2005, updated 2011) established that single-factor authentication is inadequate for high-risk transactions. PCI DSS 4.0, effective March 2024, expands MFA requirements beyond administrative access to cover all access into cardholder data environments.

Defense contractors — CMMC Level 2 maps to 110 practices from NIST SP 800-171, including Requirement 3.5.3, which explicitly requires MFA for local and network access to privileged accounts (NIST SP 800-171 Rev 2).

Consumer-facing platforms — The FTC Safeguards Rule (16 CFR Part 314), amended in 2021 and enforceable for non-banking financial institutions, requires MFA for any individual accessing customer information systems.

Decision boundaries

Selecting an MFA implementation requires mapping four variables: threat model, regulatory mandate, user population characteristics, and authenticator assurance level (AAL).

NIST SP 800-63B defines 3 Authenticator Assurance Levels:

• AAL1 — single-factor authentication; no MFA required
• AAL2 — two distinct factors required; approved cryptographic devices or OTP devices acceptable
• AAL3 — hardware-based cryptographic authenticator with verifier impersonation resistance required; satisfies the highest federal assurance tier

The decision to deploy SMS OTP versus FIDO2 hardware keys turns on phishing risk exposure. Organizations operating in sectors where spear-phishing is a documented attack vector — financial services, government contractors, healthcare — face a structural argument against PSTN-based OTP given NIST's restricted-authenticator designation and CISA's published phishing-resistant MFA guidance.

Biometric factors present a distinct boundary: under NIST SP 800-63B §5.2.3, biometrics alone do not constitute a valid authentication factor; they must be paired with a physical authenticator (something you have) — making "biometric MFA" a possession-plus-biometric model, not a standalone alternative.

Organizations subject to multiple overlapping mandates — for example, a defense contractor that is also a HIPAA covered entity — must satisfy the stricter of the applicable standards across all access pathways. The how to use this information security resource page outlines how regulatory references in this network are scoped to help practitioners identify the applicable framework tier without rendering compliance determinations.