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.04OFFICIAL TITLEPENDING NIST SME REVIEW

03.05.04 — Replay-Resistant Authentication

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

Independent summary of the official requirement

Requires implementing replay-resistant authentication mechanisms 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

An attacker who records an authentication exchange must not be able to replay it later and get in. Modern federated sign-in mostly clears this bar; the failures live in the legacy corners — NTLM relays, unsigned directory binds, cleartext service logins on appliances.

Across revisions

Carried from 3.5.4 with scope phrased as access to privileged and non-privileged accounts, matching 03.05.03's framing rather than Rev. 2's network-access wording.

Mapped practices

Brilliant at the Basics practices that support this requirement

Partial implementation supportHigh confidence

Why: FIDO2 and passkey authenticators — the methods this practice deploys — are replay-resistant by construction, so every access path the rollout converts advances this requirement as a side effect of the factor choice.

What this does not claim: Rev. 3 phrases the requirement across all access to accounts, and replay resistance must hold on paths the MFA rollout never touches — service accounts, legacy protocols, appliance logins. May partially address the requirement; the untouched paths need their own analysis within the defined system boundary.

Practice-side activities
  • Prefer WebAuthn-based factors over push or code-based ones during rollout
  • Disable NTLM and other replayable legacy protocols as enforcement expands
Evidence this produces
  • Authentication-method policy showing WebAuthn factors
  • Legacy-protocol disablement configuration

Review status: Pending NIST SME review · Reviewed by Brilliant at the Basics editorial — practitioner-authored; NIST SME review pending · updated 2026-08-06

Doing the work

Implementation considerations and evidence

Implementation considerationsIndependent guidance — tailor to your environment
  • Federated protocols (SAML, OIDC over TLS) with time-limited, audience-bound assertions carry most cloud-first estates; verify rather than assume for anything self-hosted.
  • The real work is retiring the replayable: NTLM, unsigned LDAP, and cleartext protocols on appliances and OT gateways.
  • FIDO2/WebAuthn factors are replay-resistant by construction — the same rollout that advances 03.05.03 advances this requirement.
What operating evidence looks likeRecords worth retaining, not a submission checklist
  • Configuration showing legacy replayable protocols disabled or constrained
  • Directory protocol settings — signing and channel binding

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

Artifacts

Templates and worksheets with a mapped relationship

No artifact in the library names this requirement yet. The library index groups everything by category and practice.

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