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

3.5.4 — Replay-resistant 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)

Employ replay-resistant authentication mechanisms for network access to privileged and 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

Captured credentials must not be replayable. Authentication for network access has to use mechanisms an eavesdropper cannot record and reuse — which is what rules out password-only schemes and weakly-bound session tokens for these paths.

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 the practice advances this requirement for every access path it converts.

What this does not claim: May partially address the requirement: replay resistance must hold for all network access, including service accounts, legacy protocols, and paths the MFA rollout never touches. Those need their own analysis within the organization's 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
  • Modern federated protocols (SAML, OIDC over TLS) with channel-bound or time-limited assertions carry most of this requirement in cloud-first environments.
  • The gap is usually legacy: NTLM relays, unsigned LDAP binds, cleartext service protocols. Finding and closing those is the real work.
  • FIDO2/WebAuthn authenticators are replay-resistant by construction — one reason phishing-resistant MFA choices do double duty here.
What operating evidence looks likeRecords worth retaining, not a submission checklist
  • Configuration showing legacy authentication protocols disabled or constrained
  • Protocol-level settings (signing, channel binding) for directory services
  • A dated review of network authentication paths against replay exposure

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 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