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

Multi-factor authentication (MFA) is a foundational access control mechanism requiring users to present two or more independent verification factors before gaining access to a system, application, or dataset. Its regulatory standing spans federal frameworks, financial sector mandates, and healthcare compliance regimes, making it one of the most consistently required technical controls across US industry sectors. This page covers the classification of MFA factor types, the operational mechanics of common implementations, the regulatory context that shapes deployment decisions, and the criteria that distinguish one method from another in practice. For broader access control context, see Identity and Access Management (IAM).

Definition and scope

MFA is defined by NIST Special Publication 800-63B as an authentication system that requires the claimant to prove possession and control of two or more different authentication factors. The three canonical factor categories are:

1. Something you know — passwords, PINs, security questions (knowledge factors)
2. Something you have — hardware tokens, smart cards, authenticator apps, one-time passcode (OTP) devices (possession factors)
3. Something you are — fingerprint scans, facial recognition, iris recognition (inherence factors)

Authentication using two factors from the same category — for example, two knowledge factors — does not meet the NIST SP 800-63B definition of MFA. Each factor must come from a distinct category.

The scope of MFA as a control extends across workforce authentication, customer-facing access, privileged account protection, and API-level service authentication. The Cybersecurity and Infrastructure Security Agency (CISA) classifies MFA as a baseline security measure under its Known Exploited Vulnerabilities framework and frequently cites its absence as a contributing factor in federal agency breaches. The Federal Financial Institutions Examination Council (FFIEC) has required MFA for high-risk online banking transactions since its 2005 guidance, updated in 2011.

MFA intersects directly with passwordless authentication architectures, which replace the knowledge factor entirely with possession- or inherence-based authentication. It also forms a core component of zero-trust identity model deployments, where no authentication event is implicitly trusted regardless of network position.

How it works

An MFA challenge is triggered at a defined authentication boundary — typically at login, but also at step-up points such as privilege elevation, sensitive transaction approval, or session re-authentication after a period of inactivity.

The operational sequence follows these discrete phases:

1. Identity assertion — The user presents a primary credential (commonly a username and password) to initiate the authentication request.
2. Factor challenge — The system issues a challenge for a second (and, if required, third) factor from a pre-registered method.
3. Factor verification — The authentication server validates the presented factor against enrolled credentials. For TOTP (Time-based One-Time Password) methods, the server confirms the code against a shared secret using the algorithm defined in RFC 6238, with a validity window typically of 30 seconds.
4. Session establishment — Upon successful verification of all required factors, a session token is issued. The assurance level of that session is governed by the authenticator assurance levels (AAL1, AAL2, AAL3) defined in NIST SP 800-63B.

AAL2 vs. AAL3 distinction: AAL2 requires two factors from distinct categories and permits software-based authenticators. AAL3 requires hardware-based authentication using a cryptographic device (such as a FIDO2-compliant security key) and provides the highest assurance against phishing and remote interception. Federal agencies accessing high-value systems are required to meet AAL3 under OMB Memorandum M-22-09, which mandates phishing-resistant MFA across the executive branch by fiscal year 2024.

Push notification MFA — where an approval request is sent to a registered mobile device — is widely deployed but carries documented vulnerability to MFA fatigue attacks, where adversaries flood users with approval requests to induce accidental acceptance. This attack vector is catalogued in MITRE ATT&CK under technique T1621.

Common scenarios

MFA deployment patterns vary by risk profile, regulatory environment, and identity population:

• Workforce authentication to enterprise applications — The most common deployment context. SAML-based federation or OAuth/OIDC flows (see OAuth and OpenID Connect) typically trigger MFA at the identity provider level, propagating assurance across connected applications via a single assertion.
• Privileged account access — Privileged access management (PAM) platforms require MFA as a prerequisite for accessing administrative consoles, root accounts, and privileged sessions. NIST SP 800-53 Rev 5 control IA-2(1) specifically mandates MFA for privileged users on all federal information systems.
• Remote workforce access — VPN gateways, remote desktop environments, and cloud application portals serving distributed workforces are primary MFA enforcement points. Identity security for remote workforces addresses the layered policy requirements for this environment.
• Customer-facing portals — Financial institutions, healthcare portals, and government benefit systems enforce MFA to protect account takeover risk. The healthcare sector operates under 45 CFR Part 164 (HIPAA Security Rule), which identifies authentication as a required implementation specification.
• Regulatory compliance attestation — PCI DSS v4.0, published by the PCI Security Standards Council, requires MFA for all access to the cardholder data environment (CDE) and for all remote access — an expansion from the v3.2.1 requirement that applied only to non-console administrative access.

Decision boundaries

Selecting an MFA method requires evaluation across four criteria: phishing resistance, user friction, recovery complexity, and regulatory acceptability.

NIST SP 800-63B designates SMS-based OTP as a "restricted authenticator" at AAL2, requiring organizations using it to offer alternative authenticators and to assess risk from the public switched telephone network (PSTN). This designation reflects the documented vulnerability of SMS to SIM-swapping attacks, which contributed to credential theft and account takeover incidents across financial and telecommunications sectors.

For organizations subject to phishing-resistant MFA requirements — including those under OMB M-22-09 or CMMC Level 2 and above — only FIDO2 security keys or PKI-based smart cards (PIV/CAC) qualify. Software-based TOTP and push notification methods do not meet phishing-resistant criteria under CISA's published guidance because they do not cryptographically bind the authentication to the specific origin being accessed.

MFA implementation also intersects with identity governance and administration when managing enrollments at scale: authenticator lifecycle policies must address enrollment verification, lost-device recovery, and de-provisioning to prevent orphaned credentials. These processes are distinct from authentication mechanics but directly affect the security assurance that MFA provides.

References

• NIST Special Publication 800-63B: Digital Identity Guidelines — Authentication and Lifecycle Management
• CISA Multi-Factor Authentication Guidance
• OMB Memorandum M-22-09: Moving the U.S. Government Toward Zero Trust Cybersecurity Principles
• NIST SP 800-53 Rev 5: Security and Privacy Controls for Information Systems and Organizations — Control IA-2
• PCI Security Standards Council — PCI DSS v4.0
• FFIEC Authentication in an Internet Banking Environment (2005, updated 2011)
• RFC 6238 — TOTP: Time-Based One-Time Password Algorithm (IETF)
• MITRE ATT&CK Technique T1621: Multi-Factor Authentication Request Generation
• 45 CFR Part 164 — HIPAA Security Rule (eCFR)