1Overview
IA.L2-3.5.3 is one of the highest-value requirements in the framework and among the most consequential. It requires multifactor authentication for local and network access to privileged accounts and for network access to non-privileged accounts, so that a stolen password alone is not enough to gain access. It is a five-point requirement that cannot be deferred on a plan of action.
Passwords fail constantly, through phishing, reuse, and breaches, and an attacker with a valid password walks straight in unless something more is required. Multifactor authentication adds a second, independent factor, something the user has or is, so that a compromised password is not a compromised account. This control requires MFA across the paths that matter most: all access to privileged accounts, and network access to ordinary ones. It is one of the strongest single controls against account compromise, which is why it carries the full five-point weight and cannot be deferred.
Use multifactor authentication for local and network access to privileged accounts and for network access to non-privileged accounts.
The requirement covers two scenarios with different scope, and the distinction is where most mistakes happen. Privileged accounts require MFA for both local and network access, because their compromise is most damaging. Non-privileged accounts require MFA for network access, the remote path an attacker would use. A common error is to implement MFA only for administrators and assume everyone is covered, or to treat the two scenarios as one. On scoring, this control allows partial credit: if MFA is implemented for some users but not all, the deduction is three points rather than five, but the requirement still cannot be placed on a plan of action, so it has to be fully met to certify.
2The Assessment Objectives
NIST SP 800-171A decomposes 3.5.3 into four objectives: identify privileged accounts, then require MFA for local privileged access, network privileged access, and network non-privileged access.
Privileged accounts are identified. The organization knows which accounts are privileged.
Multifactor authentication is implemented for local access to privileged accounts. Privileged local access requires more than a password.
Multifactor authentication is implemented for network access to privileged accounts. Privileged network access requires more than a password.
Multifactor authentication is implemented for network access to non-privileged accounts. Ordinary network access requires more than a password.
The four objectives identify privileged accounts and then apply MFA across the three required paths. The common gap is at objective [d], MFA for network access to non-privileged accounts, which is often overlooked when MFA is set up only for administrators. The assessor looks for MFA across all the required scenarios, not just privileged accounts.
3Failure Patterns
The failures are about partial MFA coverage and misreading the two scenarios.
MFA for administrators only
Implementing MFA for privileged accounts but not for network access by ordinary users leaves objective [d] unmet, and it is the most common mistake with this control. Non-privileged network access requires MFA too.
Missing local privileged MFA
Covering network access but not local access to privileged accounts leaves objective [b] unmet. Privileged accounts require MFA for both local and network access.
Weaker authenticators treated as equivalent
Some second factors are stronger than others. SMS is a weaker, restricted option under NIST guidance because of interception risks, though it is not expressly prohibited under current Level 2 guidance; an authenticator app or hardware token is preferable where practical.
Partial credit mistaken for compliance
Partial MFA reduces the deduction from five points to three, but the requirement still cannot be placed on a plan of action, so partial coverage does not allow certification. Full coverage across the required paths is what the control requires.
4Ownership
This is an IT-owned technical control, delivered through the identity platform's MFA capability.
| Role | Responsibility for this control |
|---|---|
| IT and system administrator | Identifies privileged accounts and implements MFA across local privileged, network privileged, and network non-privileged access. Owns the technical evidence. |
| Security or compliance lead | Confirms MFA covers all required scenarios and that authenticator strength is appropriate. |
| Program lead | Ensures full coverage before assessment, since partial coverage cannot be deferred, and retains the evidence. |
5Tooling
The control is delivered by MFA across the identity platform and the access paths in scope.
| Objectives | Tooling | What it provides |
|---|---|---|
| [a] | Privileged account inventory | Identification of the accounts requiring the stricter MFA scope. |
| [b] | Windows Hello for Business, device-bound MFA | MFA for local access to privileged accounts. |
| [c], [d] | Identity provider MFA, authenticator apps, hardware tokens | MFA for network access to privileged and non-privileged accounts. |
| Strength | App push or hardware token over SMS | Stronger second factors where practical. |
The caveat is that coverage has to span all the required paths and cannot be deferred. Partial MFA scores three rather than five but still blocks certification, so the practical requirement is full coverage before assessment. The assessor examines each scenario, so MFA for administrators alone does not satisfy the control.
6Evidence
The satisfied version of 3.5.3 shows MFA across every required access path.
| Evidence | What it demonstrates |
|---|---|
| Privileged account list | Objective [a]. Identification of privileged accounts. |
| MFA configuration for privileged access | Objectives [b], [c]. MFA for local and network privileged access. |
| MFA configuration for network access | Objective [d]. MFA for network access to non-privileged accounts. |
The evidence should show MFA implemented across privileged local, privileged network, and non-privileged network access, backed by an identification of privileged accounts. The MFA configuration covering every required path is the clearest demonstration, and because this control cannot sit on a plan of action, full coverage has to be real at the time of assessment.
A stolen password should not be a stolen account
MFA is among the strongest defenses against account compromise, and this five-point control requires it across privileged access and network access alike, not just for administrators. Reading the two scenarios correctly and covering every required path is part of the onsite readiness work this practice does, and it is one of the controls that must be met rather than deferred.
Start CMMC Readiness or call 802-335-26627Sources
- NIST Special Publication 800-171 Rev 2, Protecting Controlled Unclassified Information in Nonfederal Systems and Organizations, requirement 3.5.3. csrc.nist.gov
- NIST Special Publication 800-171A, Assessing Security Requirements for Controlled Unclassified Information, assessment objectives 3.5.3[a] through 3.5.3[d]. csrc.nist.gov
- 32 CFR 170.24, CMMC Scoring Methodology, listing IA.L2-3.5.3 as a five-point requirement with partial credit of three points. ecfr.gov
- 32 CFR 170.21, Plan of Action and Milestones Requirements, under which requirements above one point, including IA.L2-3.5.3, cannot be placed on a POA&M. ecfr.gov