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
3.5.3OFFICIAL STATEMENT BELOWDERIVED REQUIREMENTPENDING NIST SME REVIEW

3.5.3 — Multifactor authentication

3.5 Identification and Authentication · NIST SP 800-171 Rev. 2 · The heading label is this site's navigational shorthand; the official language is the statement below.

Official requirement statement (verbatim)

Use multifactor authentication for local and network access to privileged accounts and for network access to non-privileged accounts.

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

What this requirement is after

Multifactor authentication for privileged access from anywhere and for everyone's network access. A password alone — however complex — is a single stolen secret away from account takeover; this requirement removes the single point of failure for the accounts and paths attackers use first.

Across revisions

Carried into Rev. 3 as 03.05.03 with the same substance; Rev. 3 phrases scope through organization-defined parameters rather than the fixed privileged/non-privileged split.

Mapped practices

Brilliant at the Basics practices that support this requirement

Direct implementation supportHigh confidence

Why: The practice's core activity — enforcing phishing-resistant multifactor authentication starting with privileged and remote-access accounts — works on the same population and mechanism this requirement names. The practice's method choice (FIDO2, passkeys, PIV) sits above the requirement's floor.

What this does not claim: Supports implementation of the requirement; it does not satisfy it on its own. The requirement spans every account and access path in the assessed boundary — including local privileged access and systems outside the identity provider — and an assessor evaluates scope and evidence, not intent. Phishing resistance is a method choice within the requirement, not a substitute for its coverage.

Practice-side activities
  • Enroll and enforce phishing-resistant MFA for administrators and remote access first, then the workforce
  • 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
  • Monthly coverage report by privilege 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, which need separate treatment.

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 accounts first (local and network access both), then all network access for everyone else — the requirement's own priority order.
  • Choose factor types deliberately: phishing-resistant methods (FIDO2, passkeys, PIV) exceed the requirement's floor and close the adversary-in-the-middle gap that push prompts and codes leave open.
  • Hunt the bypasses: legacy protocols, break-glass accounts without compensating records, service accounts masquerading as user accounts.
What operating evidence looks likeRecords worth retaining, not a submission checklist
  • Enforcement policy export scoped to privilege tiers
  • Monthly coverage reporting: enrolled and enforced accounts over active accounts, by tier
  • Sign-in log samples showing legacy-authentication attempts trending to zero

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

INVENTORY · REVIEW QUARTERLYPrivileged Account InventoryTRACKER · REVIEW WEEKLY DURING ROLLOUT; MONTHLY ONCE EVERY POPULATION IS ENFORCEDMFA Deployment Tracker
The other revision

Where this lands in Rev. 3

Provenance

Sources and review status

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