Turning on MFA for email does not finish 3.5.3
Multifactor authentication looks like the easy item on the NIST SP 800-171 list. A firm turns it on for cloud email, marks the requirement done and moves on. The requirement reaches further than that, and it carries one of the largest point values in the DoD scoring method.
This guide covers what requirements 3.5.3 and 3.5.4 say, how they are scored under Revision 2, which is the version DoD holds contractors to today, and the places a small firm's rollout most often stops short.
What 3.5.3 and 3.5.4 actually require
Requirement 3.5.3 reads: "Use multifactor authentication for local and network access to privileged accounts and for network access to non-privileged accounts." That sentence splits accounts in two. Privileged accounts need a second factor every way in, including at the console. Ordinary accounts need one whenever the access crosses a network.
NIST defines local access as a direct connection without a network, and network access as anything through a network connection. Remote access is a type of network access. Multifactor means two or more different factors: something you know, something you have, something you are. A password and a security question are both something you know, so together they are still one factor.
Requirement 3.5.4 reads: "Employ replay-resistant authentication mechanisms for network access to privileged and non-privileged accounts." Authentication resists replay when recording and replaying an earlier exchange is impractical. NIST names nonces, challenges and time synchronous or challenge-response one-time authenticators as techniques that do this.
The four things an assessor checks
NIST SP 800-171A breaks 3.5.3 into four objectives. All four have to be satisfied, so build your evidence around them.
- 3.5.3[a]: privileged accounts are identified, which means a written list exists
- 3.5.3[b]: multifactor authentication is implemented for local access to privileged accounts
- 3.5.3[c]: multifactor authentication is implemented for network access to privileged accounts
- 3.5.3[d]: multifactor authentication is implemented for network access to non-privileged accounts
Objective [b] is the one a cloud-only rollout tends to miss. An administrator signing in at a server console or logging on to a workstation with a local admin account is local access to a privileged account.
How DoD scores multifactor authentication
The CMMC scoring rule starts every firm at the maximum of 110, the number of Revision 2 requirements, and subtracts the value of each one not met. Requirement 3.5.3 is one of only two that can earn partial credit.
The DoD Assessment Methodology adds a warning about half-finished rollouts. Its example says that if the initial rollout of 3.5.3 is only 75 percent complete with a plan of action still being carried out, the requirement is considered not implemented.
Why 3.5.3 cannot wait on a plan of action
A Level 2 self-assessment can reach a conditional status with open items, on two conditions that matter here. The score divided by 110 must be at least 0.8, which is 88 points, and no item on the plan of action can carry a point value greater than 1. The one exception is encryption that is in place but not FIPS-validated.
Requirement 3.5.3 is worth 3 or 5, so it cannot sit on that plan. Requirement 3.5.4 is worth 1 and can. If you are sequencing work before an assessment, full MFA coverage goes ahead of most other items.
A rollout order that protects the score
The scoring rule describes the usual sequence itself: remote and privileged users first, because they are fewer in number and matter more, then the general user. That order also moves you from a 5-point deduction to a 3-point deduction as early as possible.
Start with an inventory of every account and every way into the environment. Cover administrators and remote access next, then general staff, then the older applications that resist change. Finish by trying to sign in without a second factor from each path you listed. A test that fails where it should is the best evidence you will collect all year.
Watch for legacy mail protocols and app passwords during that last step, because they can bypass the second factor on many cloud systems. Keep one or two emergency accounts for the day your identity provider is unavailable. They are privileged accounts too, so protect them with a hardware key kept sealed and review every use.
Options that work for a small firm
NIST states that the requirement "should not be interpreted as requiring federal Personal Identity Verification (PIV) card or Department of Defense Common Access Card (CAC)-like solutions." Hard tokens and soft tokens are both named as acceptable places to store credentials.
| Option | Best fit | Watch for |
|---|---|---|
| Hardware security keys | Administrators and anyone with access to sensitive data. Cryptographic keys are the authenticators NIST's identity guidance treats as phishing-resistant. | Issue a spare, write a lost-key process, and confirm your older systems accept them |
| Authenticator apps | General staff. One-time codes and push approvals are low cost and quick to deploy. | NIST's identity guidance says out-of-band methods and manually entered codes are not phishing-resistant, so reserve stronger factors for admins |
| Smart cards | Firms already running a Windows domain with certificate services | A certificate authority is one more system to run and protect |
| SMS or voice codes | Short-term stopgap only | NIST's identity guidance treats the telephone network as a restricted method; plan to replace it |
Pick one primary method for staff and a stronger one for administrators, then apply them through a single identity provider where you can. Two methods are simple to document and simple to audit. Five are neither.
Service accounts need a written answer
A backup job or a scanner account cannot respond to a push prompt, and many hold high privileges. Revision 2's requirement speaks of privileged accounts with no exception for them. Revision 3, which DoD has not adopted, says its requirement applies to user accounts, a useful signal of intent but not the rule you are held to.
Treat each one deliberately. List it, name its owner, block interactive logon, store its secret in a vault, limit where it can connect from and describe the arrangement in your system security plan. An account nobody can explain is the finding to fear.
Shared admin logins break the requirement underneath
Requirements 3.5.1 and 3.5.2 require you to identify and authenticate users. A single "admin" login passed among three technicians identifies nobody, and its token ends up on a desk or in a group text. Give each administrator a named privileged account, separate from the account used for email, and retire the shared one. This also makes your logs mean something during an incident.
VPN and remote tools without a second factor
Remote access is network access, so a VPN that asks only for a password leaves 3.5.3 unmet for everyone who uses it. Walk every way into the environment: VPN, remote desktop gateways, remote support tools used by your IT provider, firewall and switch admin pages, and cloud admin consoles.
The IT provider's tools deserve special attention. A technician who reaches your servers through a remote management agent is exercising privileged network access, and that path is yours to account for.
Email on personal phones is a scope decision
NIST treats personally owned devices as external systems under 3.1.20, and connection of mobile devices is controlled under 3.1.18, which carries 5 points. When CUI arrives by email, a phone that syncs that mailbox becomes a place CUI lives. The choices are a managed device, an app container you control, or blocking mail sync on personal phones altogether.
A phone used only to approve sign-ins is a different question from a phone that syncs CUI email. Keep those two cases separate in your system security plan.
A phone used only to approve sign-ins is a different question from a phone that syncs CUI email.
What to keep as evidence
The DoD methodology lists demonstration of multifactor authentication among the examples of what a High assessment reviews, so expect to show it working. Keep your identity provider's conditional access or sign-in policy export, the list of privileged accounts with owners, enrollment reports showing every user covered, and a short recorded walkthrough of a sign-in on each path. Artifacts must be kept for six years from the CMMC Status Date.
Frequently asked questions
No. NIST says the requirement should not be read as requiring PIV or CAC-like solutions, and commercially available tokens and biometrics can meet it.
Requirement 3.5.3 asks for MFA at local logon only for privileged accounts. Non-privileged users need it for network access, which covers email, file shares, VPN and cloud applications in practice.
Three points are subtracted from 110 until general users are covered, and the item cannot be placed on a plan of action for a conditional status.
NIST's digital identity guidance treats the telephone network as a restricted out-of-band method. Use an authenticator app or a hardware key instead, particularly for administrators.