Independent DIB implementation resource — not affiliated with or endorsed by the U.S. Department of WarView the official DoW campaign ↗
Brilliant at the BasicsDIB Resource Center
03.05.03OFFICIAL TITLEPENDING NIST SME REVIEW

03.05.03 — Multi-Factor Authentication

03.05 Identification and Authentication · NIST SP 800-171 Rev. 3

Independent summary of the official requirement

Requires implementing multi-factor authentication for access to privileged accounts and non-privileged accounts.

Rev. 3 requirement text is multi-part and parameterized with organization-defined values, so this site summarizes rather than reproduces it. The summary is independent — read the official publication for the binding wording.

NIST SP 800-171 Rev. 3 — Protecting CUI in Nonfederal Systems ↗NIST SP 800-171A Rev. 3 — Assessing Security Requirements for CUI ↗
Independent interpretation

What this requirement is after

Multi-factor authentication everywhere accounts are used: Rev. 3 drops Rev. 2's carve-out that left local access to ordinary accounts password-only. Privileged or not, local or over the network, signing in takes more than one secret — the single change with the best return against credential theft.

Across revisions

Carried from 3.5.3 and broadened: Rev. 2 required multifactor for local and network access to privileged accounts and network access to non-privileged accounts; Rev. 3 states it for access to both account tiers without the local/network split.

Mapped practices

Brilliant at the Basics practices that support this requirement

Direct implementation supportHigh confidence

Why: Rev. 3 restates the multifactor requirement and widens it to all access to privileged and non-privileged accounts — the same populations this practice enforces first. The practice's method choice (FIDO2, passkeys, PIV) is a stronger selection within the requirement, not an addition to it.

What this does not claim: Rev. 3 does not require phishing-resistant methods by name — choosing them exceeds the stated requirement rather than being compelled by it. The widened scope now reaches local access to non-privileged accounts, a path many MFA rollouts leave for last; the practice supports implementation but does not satisfy the requirement on its own, and an assessor evaluates coverage and evidence, not intent.

Practice-side activities
  • Enroll and enforce phishing-resistant MFA for administrators and remote access first, then the workforce
  • Extend enforcement to local endpoint sign-in through platform authenticators
  • Block legacy authentication protocols that bypass a second factor
  • Track enrollment coverage by privilege tier with dated exceptions
Evidence this produces
  • Identity-provider enforcement policy export covering both account tiers
  • Coverage report: enforced accounts over active accounts, by tier
  • Sign-in logs showing legacy-protocol attempts at or near zero

Where this holds: Holds wherever accounts live in an identity provider that can enforce factor policy; weakens for standalone and appliance-local accounts and for local sign-in paths not yet behind a platform authenticator.

Review status: Technical review complete · Reviewed by inDirectIT practitioner review — CUI security and NIST SP 800-171 engineering · updated 2026-08-06

Doing the work

Implementation considerations and evidence

Implementation considerationsIndependent guidance — tailor to your environment
  • Cover privileged and remote access first, then the workforce, then the awkward tail: local console access, shared shop-floor stations, appliances.
  • Choose phishing-resistant methods — FIDO2, passkeys, PIV — where possible; they sit above the requirement's floor but close the adversary-in-the-middle gap that push prompts and codes leave open.
  • Local access to non-privileged accounts is the new ground relative to Rev. 2; platform authenticators such as Windows Hello for Business are the practical route on endpoints.
What operating evidence looks likeRecords worth retaining, not a submission checklist
  • Enforcement policy exports covering both account tiers and access types
  • Coverage reporting: enforced accounts over active accounts
  • Documented handling for paths that cannot do MFA, with compensations

Suggested owners, derived from the mapped practices and artifacts: Identity administrator · Identity admin. Ownership is a named person in your organization, not a role on a website.

Artifacts

Templates and worksheets with a mapped relationship

TRACKER · REVIEW WEEKLY DURING ROLLOUT; MONTHLY ONCE EVERY POPULATION IS ENFORCEDMFA Deployment Tracker
The other revision

Where this came from in Rev. 2

Provenance

Sources and review status

Primary sourcesNIST SP 800-171 Rev. 3 — Protecting CUI in Nonfederal Systems · NIST SP 800-171A Rev. 3 — Assessing Security Requirements for CUI
Review statusPending NIST SME review
Content version1.0
Updated