Multi-Factor Authentication (MFA): Methods and Best Practices

Multi-factor authentication (MFA) is a layered access control mechanism requiring users to present two or more independent verification factors before gaining access to a system, application, or dataset. Federal standards bodies including NIST and CISA have published formal guidance positioning MFA as a baseline security control across both public-sector and commercial environments. This page covers the classification of authentication factors, the technical architecture underlying MFA workflows, the regulatory and operational contexts where MFA is mandated or strongly recommended, and the boundaries that determine which MFA implementations are appropriate for which threat profiles. Practitioners and researchers consulting the Identity Security Authority providers will encounter MFA as a recurring requirement across identity governance, privileged access, and zero trust frameworks.

Definition and scope

MFA is formally defined by NIST Special Publication 800-63B as an authentication method that uses two or more factors from distinct categories to verify a claimant's identity. NIST SP 800-63B establishes three assurance levels — AAL1, AAL2, and AAL3 — with AAL2 requiring at least two factors and AAL3 requiring hardware-based cryptographic authenticators.

The three canonical factor categories are:

1. Something you know — passwords, PINs, security questions
2. Something you have — hardware tokens, smart cards, mobile authenticator apps, FIDO2-compliant security keys
3. Something you are — biometric characteristics including fingerprints, facial geometry, and iris patterns

A valid MFA implementation requires factors drawn from at least two of these three categories. Two passwords, or two PINs, do not satisfy the MFA definition because they occupy the same factor category.

The scope of MFA as a security control extends across identity-layer functions: authentication at the login boundary, step-up authentication for privileged operations, and continuous verification in session-based systems. CISA's identity and access management guidance explicitly distinguishes MFA from single sign-on (SSO) and from password managers, noting that only cross-category factor combinations deliver the assurance benefits associated with the control.

How it works

An MFA workflow operates in a structured sequence regardless of the specific factor technologies involved:

1. Identity claim — The user presents a primary identifier, typically a username or email address, which associates the session with a registered account.
2. First factor verification — The system validates the first credential, most commonly a password, against stored hashed values.
3. Second factor challenge — The system triggers a second verification prompt. Depending on implementation, this may be a time-based one-time password (TOTP) generated by an authenticator app, a push notification to a registered device, an SMS or voice call code, or a hardware key assertion.
4. Factor response and validation — The system validates the second factor against expected values. TOTP codes are validated against the current 30-second HMAC-SHA1 window as specified in RFC 6238; FIDO2 authenticators use public-key cryptography validated against registered credentials.
5. Session establishment — On successful validation of all required factors, the system establishes an authenticated session.

TOTP vs. push-based MFA: TOTP codes are generated client-side and require no persistent server-to-device connection, making them resistant to real-time phishing interception when combined with origin binding. Push-based MFA, while more user-friendly, introduces exposure to MFA fatigue attacks — a documented attack pattern in which adversaries send repeated push requests until a user inadvertently approves one. CISA Alert AA22-074A specifically documented MFA fatigue as a technique used in the Lapsus$ intrusion campaign.

FIDO2 and WebAuthn-based authenticators, standardized by the FIDO Alliance and W3C, are classified as phishing-resistant MFA because authentication is cryptographically bound to the registered origin domain. NIST SP 800-63B designates phishing-resistant authenticators as required at AAL3.

Common scenarios

MFA is deployed across a defined set of operational contexts where unauthorized access carries elevated risk:

• Remote access and VPN authentication — Federal policy under OMB Memorandum M-22-09 (the federal zero trust strategy) requires MFA for all federal employees accessing agency resources remotely, with phishing-resistant MFA required for privileged accounts by fiscal year 2024.
• Privileged access management (PAM) — Accounts holding administrative rights over systems, databases, or cloud infrastructure are standard targets for MFA enforcement. The CIS Controls v8, published by the Center for Internet Security, identifies MFA for privileged accounts as a Safeguard under Control 6 (Access Control Management).
• Healthcare and financial regulated environments — The HIPAA Security Rule (45 C.F.R. § 164.312) does not mandate MFA by name but requires access controls and audit controls that MFA implementations directly satisfy. The PCI DSS v4.0 standard, published by the PCI Security Standards Council, explicitly requires MFA for all non-console administrative access into the cardholder data environment.
• Consumer-facing account protection — Identity and credential compromise represents the entry vector in a substantial share of breach incidents. IBM's Cost of a Data Breach Report 2023 placed the average breach cost at $4.45 million, with stolen credentials identified as the most common initial attack vector.

The outlines the broader framework categories within which MFA functions as a component control.

Decision boundaries

Not all MFA implementations carry equivalent assurance, and selecting the appropriate tier depends on the threat model, compliance obligation, and user population. The following boundaries structure that decision:

Factor strength hierarchy (low to high assurance):

Regulatory floor vs. operational ceiling: Compliance mandates establish a floor — PCI DSS v4.0 Requirement 8.4.2 mandates MFA for all access into the cardholder data environment; OMB M-22-09 mandates phishing-resistant MFA for federal privileged users. Organizations operating above the regulatory floor must determine whether their threat profile warrants phishing-resistant controls even when not explicitly required.

Backup and recovery path: Any MFA deployment must address account recovery. NIST SP 800-63B Section 6.1 specifies that recovery mechanisms must not bypass the assurance level of the primary authentication path. SMS-based recovery for a FIDO2-protected account downgrades effective assurance to the SMS level.

Practitioners researching the service providers and tools that implement these controls across enterprise environments can consult the identity security providers for provider network-organized categories relevant to authentication infrastructure.