Skip to content

3.5.4 — Replay-Resistant Auth

Employ replay-resistant authentication mechanisms for network access to privileged and non-privileged accounts.

An attacker sitting on your network captures an authentication exchange. Can they replay it to gain access? If yes, you fail this requirement.

What’s replay-resistant:

  • Time-based one-time passwords (TOTP) — expires in 30 seconds
  • FIDO2 / WebAuthn — challenge-response tied to the specific session
  • Kerberos tickets — time-limited, session-specific
  • Certificate-based authentication — signed challenge-response
  • Windows Hello for Business — hardware-bound, not replayable

What’s NOT replay-resistant:

  • Passwords alone — captured password works forever until changed
  • NTLM authentication — vulnerable to pass-the-hash and relay attacks
  • Long-lived API tokens — captured token works until revoked
  • Basic authentication over HTTP — credentials sent in every request

If you’ve implemented MFA properly (3.5.3) using TOTP, FIDO2, or similar methods, you likely satisfy this requirement as well. The key gap to check: are there any authentication paths still using password-only or legacy protocols?


Your assessor needs a “yes” to every row:

#QuestionWhat “yes” looks like
1Are replay-resistant authentication mechanisms employed for network access to privileged accounts?Admin network authentication uses TOTP, FIDO2, Kerberos, or certificate-based methods
2Are replay-resistant authentication mechanisms employed for network access to non-privileged accounts?Standard user network auth uses replay-resistant methods — MFA satisfies this

Documents they’ll review: Identification and authentication policy; procedures addressing user identification and authentication; system security plan; system design documentation; system configuration settings; system audit logs and records

People they’ll talk to: Personnel with system operations responsibilities; personnel with information security responsibilities; system or network administrators; system developers

Live demos they’ll ask for: Mechanisms supporting or implementing identification and authentication capability


These are the actual questions. Have answers ready.

  • “What authentication protocols are used for network access?”
  • “Is NTLM still enabled in your environment? Where and why?”
  • “Are there any authentication paths using long-lived tokens or basic auth?”
  • “Show me that your MFA method is replay-resistant — how does it work?”
  • “How do you handle API authentication — are tokens time-limited?”

NTLM still enabled. Legacy applications requiring NTLM authentication. Disable where possible, document compensating controls where you can’t.

Basic authentication on email. Exchange still accepting basic auth for IMAP/POP3/SMTP. Disable legacy auth protocols in Entra ID.

Long-lived API tokens. API keys that never expire and can be captured and reused indefinitely. Use OAuth with short-lived tokens and refresh token rotation.

Password-only VPN. VPN authenticating with password only, no MFA — both a 3.5.3 and 3.5.4 failure.



RequirementWhy it matters here
3.5.3 — MFA EverywhereMFA implementation directly provides replay resistance
3.5.10 — Never Plain TextProtects credentials from interception that enables replay
3.13.15 — Protect Session IntegritySession protection complements replay-resistant auth

🔒

Step-by-step guides for Microsoft 365, AWS, Azure, and GCP are available to Ancitus clients.

Start a conversation →

CMMC Practice ID: IA.L2-3.5.4 | SPRS Weight: 1 point | POA&M Eligible: Yes