Category: Identity & Access Management
Multi-Factor Authentication
Also known as: MFA, Multifactor Authentication, Multi-Step Authentication
Simply put
Multi-factor authentication (MFA) is a security method that requires a user to prove their identity in more than one way before gaining access to a system, application, or data. Instead of relying on a password alone, MFA generally combines two or more distinct verification steps, such as something you know plus something you have. This layered approach makes it harder for unauthorized users to gain access even if one factor, like a password, is compromised.
Formal definition
MFA is an authentication system that requires more than one distinct authentication factor for successful authentication, per the NIST CSRC glossary. In practice it enforces a layered approach in which a subject must present a combination of factors drawn from separate categories (commonly characterized as something you know, something you have, and something you are) rather than multiple instances of a single factor. Implementations, factor strength, and phishing resistance vary; readers should confirm the specific authenticator assurance requirements and tailoring applicable to their environment against current authoritative guidance, as this entry does not cover implementation specifics or the assurance-level criteria that may govern a given system.
Why it matters
Passwords alone provide a single, easily compromised barrier to access. Credentials are routinely stolen through phishing, reused across services, guessed, or exposed in breaches, which means an authentication scheme that depends only on something a user knows can be defeated the moment that one secret is disclosed. MFA generally mitigates this by requiring an attacker to defeat more than one distinct factor, so that a compromised password by itself is insufficient to gain access.
Who it's relevant to
Information System Security Managers and System Administrators
Those responsible for configuring and operating access controls generally rely on MFA as a foundational safeguard for protecting systems, applications, and data. Because factor strength, phishing resistance, and applicable authenticator assurance requirements vary by implementation, these practitioners should confirm the specific criteria and tailoring that govern their environment against current authoritative guidance rather than assuming any MFA method satisfies a given requirement.
Compliance Officers and Auditors
Personnel evaluating access control implementations need to distinguish MFA that combines factors from separate categories from schemes that merely add steps within a single factor category, which may not meet the definition of true multi-factor authentication. This entry does not cover the assurance-level criteria or control tailoring that may apply to a particular system, so assessors should verify requirements against the applicable authoritative sources for their environment.
End Users and Account Holders
Individuals accessing protected systems interact with MFA through a multi-step login that requires more than a password, such as entering a code from a registered device or providing a biometric. Understanding that a second factor exists to protect access even if a password is compromised helps users recognize why the additional step is required and why prompts they did not initiate may warrant caution.
Inside MFA
Authentication Factors
MFA generally requires two or more distinct factor types: something you know (a password or PIN), something you have (a hardware token, smart card, or authenticator app), and something you are (a biometric such as a fingerprint or facial recognition). Combining factors from the same category does not typically satisfy MFA requirements.
Multiple Distinct Categories
The core principle is that factors must come from different categories to be considered multi-factor. Two passwords, or a password and a security question, are generally treated as single-factor because both fall under 'something you know.' Readers should confirm the exact factor-combination rules against the applicable control baseline and agency tailoring.
Relationship to Control Baselines
MFA is addressed within identification and authentication control families in federal control catalogs such as NIST SP 800-53 and the CUI-focused NIST SP 800-171. The specific strength, scope (for example, privileged versus non-privileged access, local versus network access), and applicability depend on the impact level and the applicable revision. Verify the current authoritative text for exact requirements.
Phishing Resistance
Not all MFA methods offer equal protection. Certain implementations, such as one-time codes delivered by SMS, are more susceptible to interception or social-engineering attacks, while hardware-based cryptographic authenticators are generally considered more phishing-resistant. The degree of assurance expected can vary by system category and agency guidance.
Scope of Application
Where and to whom MFA applies differs across federal civilian systems under FISMA, DoD systems under the RMF, and systems handling CUI. Requirements may extend to remote access, administrative accounts, and access to sensitive data. State, local, tribal, and territorial obligations may differ and should be confirmed separately.
Common questions
Answers to the questions practitioners most commonly ask about MFA.
Does implementing MFA mean my system is compliant with the applicable control baseline?
No. MFA is one identification and authentication control among many, and deploying it does not by itself establish compliance. Control baselines under frameworks such as NIST SP 800-53 (for federal systems under FISMA) or the requirements derived from NIST SP 800-171 (for CUI in non-federal systems) generally include numerous other controls across access control, audit, configuration management, and other families. Furthermore, compliance is not the same as security: satisfying an MFA requirement on paper does not guarantee the implementation is effective or resistant to compromise. Confirm the specific control requirements and how they are assessed against the current authoritative text applicable to your system.
If our cloud service is FedRAMP authorized and uses MFA, does that automatically satisfy DoD MFA requirements?
Not necessarily. A FedRAMP authorization reflects an assessment and authorization process managed under the FedRAMP program for federal civilian use, and it does not automatically satisfy DoD requirements. DoD systems generally follow the Risk Management Framework as directed by the DoD CIO, and DoD may impose additional or tailored requirements, including its own reciprocity determinations and impact-level considerations. Whether MFA as implemented meets a particular DoD requirement is a determination that must be verified against the applicable DoD guidance and the relevant authorizing official, not assumed from a civilian authorization.
What authentication factors are generally recognized for MFA?
MFA generally requires the use of two or more distinct factor categories, commonly described as something you know (such as a password or PIN), something you have (such as a hardware token, smart card, or authenticator device), and something you are (such as a biometric). Using two instances of the same category, such as a password plus a security question, is typically not considered multi-factor. The specific factor types and their acceptable forms may be constrained by the applicable guidance and agency tailoring, so verify the requirements and any restrictions in the current authoritative text for your system.
How do phishing-resistant authentication expectations affect MFA choices?
Guidance in this area has been evolving toward stronger, phishing-resistant forms of authentication in many federal contexts, which can influence whether certain methods remain acceptable for a given implementation. Because the emphasis and specific expectations differ across frameworks, agency tailoring, and revision levels, and because federal civilian, defense, and national security systems may have differing obligations, you should confirm which authentication methods are required or permitted for your system against the applicable current guidance rather than relying on a general assumption.
Does MFA need to be applied to all accounts and access paths?
The scope of MFA requirements often depends on the account type and access path. Requirements are commonly framed around distinctions such as privileged versus non-privileged accounts and local versus network access, and the applicable baseline may specify different expectations for each. Whether MFA extends to all users, to remote access only, or to specific privileged functions is determined by the relevant control text and any agency tailoring. Confirm the exact scope for your environment against the applicable authoritative source, as this entry does not cover implementation-specific configuration decisions.
How is an MFA control typically verified during an assessment?
During an assessment, an MFA control is generally evaluated by examining the applicable assessment objectives, which may involve reviewing configuration evidence, interviewing personnel, and testing the authentication mechanism. It is important to keep assessment distinct from authorization: an assessor evaluates whether a control is implemented and effective, while an authorizing official makes the risk-based authorization decision. The specific assessment procedures and evidence expectations vary by framework and assessment methodology, so verify them against the current authoritative assessment guidance applicable to your system.
Common misconceptions
Requiring a password plus a security question counts as multi-factor authentication.
Both a password and a security question are 'something you know,' so combining them generally does not meet MFA requirements. True MFA requires factors from at least two distinct categories, such as something you know plus something you have.
Any form of MFA satisfies all federal and defense requirements equally.
The acceptability and required strength of an MFA method can vary by control baseline, impact level, account type, and agency tailoring. Some methods considered more phishing-resistant may be required for higher-assurance scenarios. Practitioners should verify the specific requirement against the applicable revision of the governing publication.
Implementing MFA by itself makes an account or system secure.
MFA is one control among many and reduces certain authentication risks, but implementing it is not equivalent to being secure or compliant. It must be applied within the appropriate scope and combined with other controls, and its presence does not by itself demonstrate overall compliance.
Best practices
Confirm that the factors you deploy come from genuinely distinct categories (know, have, are) rather than combining two factors of the same type.
Prioritize more phishing-resistant authenticators, such as hardware-based cryptographic tokens, over weaker methods like SMS-delivered codes where the assurance level warrants it.
Map MFA implementation to the applicable identification and authentication controls in the relevant baseline (for example NIST SP 800-53 or NIST SP 800-171) and verify requirements against the current revision and any agency tailoring.
Apply MFA to the scopes your requirements demand, giving particular attention to privileged and administrative accounts and to remote and network access.
Distinguish MFA obligations by system category, recognizing that FISMA civilian systems, DoD RMF systems, and CUI environments may impose different requirements, and confirm any state, local, tribal, or territorial variations.
Treat MFA as one layered control rather than a complete security or compliance solution, and validate the deployment against current authoritative sources rather than assuming its presence satisfies broader obligations.