3.5.4 — Replay-Resistant Auth

The One-Liner

If an attacker captures your authentication token and can reuse it to log in as you, your authentication is fundamentally broken.

What It Says

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

What It Actually Means

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?

---

Pass or Fail

Your assessor needs a “yes” to every row:

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

---

What to Have Ready on Assessment Day

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

---

The Assessor’s Playbook

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

Real-World Example

A contractor has disabled NTLM across their Entra ID environment and enforced modern authentication only. All user authentication uses Entra ID with TOTP-based MFA — each code expires in 30 seconds and can’t be reused. Admin accounts use FIDO2 keys with challenge-response. API integrations use OAuth 2.0 with short-lived access tokens (1-hour lifetime). The assessor asks about legacy protocols — IT shows the Entra sign-in logs filtered to ‘legacy authentication’ showing zero successful logins.

---

Where Companies Trip Up

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.

---

How to Talk About This

To a CEO or Board

Our authentication methods are designed so that even if someone intercepts a login exchange, they can’t replay it. Every authentication is time-limited and session-specific.

To an Engineering Team

MFA via TOTP/FIDO2 provides replay resistance. Kerberos for internal AD auth. NTLM disabled via Entra security defaults. OAuth 2.0 with 1-hour token lifetime for APIs. Legacy auth protocols blocked. No basic auth anywhere.

---

Connected Requirements

Requirement	Why it matters here
3.5.3 — MFA Everywhere	MFA implementation directly provides replay resistance
3.5.10 — Never Plain Text	Protects credentials from interception that enables replay
3.13.15 — Protect Session Integrity	Session protection complements replay-resistant auth

---

Implementation (coming soon)

Step-by-step setup for Microsoft 365 / Entra ID, AWS, Azure, and GCP — console steps, CLI commands, and evidence screenshots.

---

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