Multi-factor authentication (MFA) is an authentication method that requires a user to verify their identity using two or more distinct types of authentication factors before gaining access to a system, application, or account. Per NIST SP 800-63B, the three recognized factor types are something you know (a password or PIN), something you have (a hardware token or mobile device), and something you are (a fingerprint or biometric); MFA requires at least two of these from different categories.
Multi-factor authentication (MFA) is an authentication method requiring users to provide two or more distinct verification factors before access is granted. NIST SP 800-63B, the federal standard for digital identity authentication, defines MFA as "an authentication system that requires more than one distinct type of authentication factor for successful authentication." Using a password and a security question does not count — both fall under "something you know." MFA requires factors from different categories.
The three recognized factor categories are:
Two-factor authentication (2FA) is the most common MFA implementation, combining a password with a one-time code from an authenticator app or a push notification. The terms MFA and 2FA are often used interchangeably, though technically 2FA is a subset of the broader MFA category.
When a user tries to log in to a system protected by MFA, the system prompts for the first factor (typically a password). After the password is accepted, the system requires a second factor, usually delivered via an authenticator app (like TOTP codes that rotate every 30 seconds), a hardware key that generates cryptographic responses, a push notification to a registered mobile device, or an SMS code.
Access is only granted when both factors are successfully verified. If an attacker steals or guesses a password, they still cannot log in without the second factor, which requires physical access to the registered device or hardware key.
Not all MFA implementations are equally strong. SMS-based MFA, while far better than no MFA, is vulnerable to SIM-swapping attacks and real-time phishing. Push notification MFA is vulnerable to MFA fatigue attacks, where attackers repeatedly send push requests until a tired user approves one. CISA recommends phishing-resistant MFA for sensitive systems, specifically hardware security keys (like FIDO2/WebAuthn) that cryptographically bind the authentication to a specific website and cannot be intercepted by a phishing proxy.
MFA and secrets management address related but distinct problems. Secrets management handles machine-to-machine authentication: API keys, tokens, and credentials used by services to communicate with each other. MFA handles human authentication: people logging in to systems and applications. Both matter, and both are commonly weak points. A startup might enforce MFA on all employee accounts while leaving hardcoded API keys in source code with no rotation policy, creating an entirely separate credential exposure problem that MFA does not address.
SMS-based MFA is better than a password alone, but it is the weakest form of MFA and has known vulnerabilities. SIM-swapping attacks allow attackers to reroute SMS messages to a phone they control by convincing a carrier to transfer your number. Real-time phishing kits can also intercept SMS codes. For most employee accounts and low-sensitivity systems, SMS MFA is an acceptable baseline. For privileged accounts, admin access, and systems handling sensitive customer data, CISA recommends phishing-resistant MFA using hardware security keys (FIDO2/WebAuthn) or certificate-based authentication, which cannot be intercepted by a phishing proxy.
MFA fatigue is an attack technique where an attacker who already has a user's password repeatedly sends push notification approval requests to their device, hoping the user eventually approves one out of annoyance or confusion. It is increasingly common: the 2025 Verizon DBIR found MFA fatigue in 14% of analyzed security incidents. Defenses include switching high-value accounts to phishing-resistant hardware keys (which are immune to this attack), enabling number matching on push apps (the user must enter a code displayed on screen, not just click approve), and training employees to reject unexpected MFA requests and report them immediately.
Service accounts (accounts used by automated systems and applications rather than humans) cannot use MFA in the traditional sense because there is no human to approve a push notification or enter a TOTP code. The equivalent control for service accounts is secrets management: using short-lived, automatically rotated credentials rather than static passwords or API keys, scoping permissions tightly, and auditing access. MFA addresses human authentication; secrets management and IAM controls address machine authentication. Both need to be addressed, and neglecting service accounts while enforcing MFA on human accounts still leaves a meaningful attack surface open.
