What IA.L2-3.5.4 Requires
The requirement reads: "Employ replay-resistant authentication mechanisms for network access to privileged and non-privileged accounts."
Every account that authenticates over a network must use a mechanism that prevents a captured credential exchange from being replayed by an attacker at a later time. This applies to both privileged accounts (administrators, system accounts) and non-privileged accounts (standard users). Local console logon is out of scope — the requirement is bounded to network access.
Not the Same as MFA
This is where contractors get into trouble. IA.L2-3.5.4 and IA.L2-3.5.3 (MFA) are adjacent requirements in the same domain, and many people assume satisfying one automatically satisfies the other. That assumption is wrong in both directions.
MFA is about using multiple independent factors to verify identity. Replay resistance is about ensuring that authentication exchanges cannot be captured and reused. These are separate properties. A system can have MFA and still be vulnerable to replay attacks if the underlying protocol permits it. Conversely, some single-factor mechanisms are inherently replay-resistant by design.
Replay resistance asks: could an attacker reuse this authentication exchange later?
In practice, modern MFA implementations almost always satisfy both requirements simultaneously. But the requirements address different threat models and must be documented and assessed separately.
In the CMMC Assessment Guide, these requirements have separate assessment objectives with separate evidence expectations. A C3PAO assessor evaluating 3.5.4 is specifically looking for evidence that authentication mechanisms produce session-unique tokens or time-bounded credentials that cannot be reused — not just that two factors were required.
What a Replay Attack Actually Is
In a replay attack, an adversary intercepts a valid authentication exchange between a user and a system, then retransmits that captured exchange to gain unauthorized access. The attacker does not need to know the user's password. They only need the captured credential data.
Older protocols are particularly vulnerable. NTLM authentication, for example, uses a challenge-response mechanism that can be captured on the network and replayed under certain conditions. Basic HTTP authentication, if transmitted over an unencrypted channel, sends credentials in a form that is trivially replayable. Legacy remote access solutions that rely on static shared secrets face the same problem.
Replay-resistant mechanisms counter this by ensuring each authentication exchange is unique and time-bounded. A captured exchange from five minutes ago cannot be successfully submitted again because the session identifier, timestamp, or one-time credential embedded in it has expired or been consumed.
What Satisfies IA.L2-3.5.4
NIST SP 800-171A identifies several types of mechanisms that satisfy this requirement. The common thread is that each produces authentication data that is specific to a single session, time window, or transaction.
Kerberos
The Kerberos protocol, used natively by Active Directory environments, is inherently replay-resistant. Kerberos tickets are time-stamped and include a timestamp tolerance window (typically five minutes). An authenticator submitted outside that window is rejected. Each ticket-granting exchange produces a session-specific authenticator that cannot be reused. Organizations running Active Directory with Kerberos as their primary authentication protocol are generally in good shape for this requirement — provided clock synchronization is maintained across systems.
TLS with certificate-based authentication
TLS sessions are inherently non-replayable at the session layer. When combined with client certificate authentication, each TLS handshake produces a unique session key derived from ephemeral key exchange. The resulting session cannot be replayed because the session key is never transmitted and is unique to that connection.
TOTP and HOTP (time-based and HMAC-based one-time passwords)
One-time password mechanisms used in most modern MFA solutions (Google Authenticator, Microsoft Authenticator, Duo, YubiKey OTP) generate a credential valid for a narrow time window and, when properly implemented by the verifier, accepted only once. An attacker who captures the authentication exchange gets a code that is time-bounded and should fail on reuse once it has been consumed. This is why properly implemented OTP-based MFA deployments generally satisfy 3.5.4 alongside 3.5.3.
FIDO2 / WebAuthn
FIDO2 authentication is cryptographically replay-resistant by design. Each authentication ceremony produces a signature over a challenge that is unique to that specific authentication request. The challenge cannot be reused, and the private key never leaves the authenticator device. This is among the strongest implementations available for this requirement.
SSH with public key authentication
SSH key-based authentication uses challenge-response with session-unique data, making it replay-resistant. Password-only SSH over an encrypted channel should not be relied on as the replay-resistant mechanism for 3.5.4. The encrypted channel protects confidentiality in transit, but a static password is still not inherently replay-resistant. Key-based authentication is the stronger and preferred implementation.
Common Gaps in Small Contractor Environments
NTLM still active in the environment
Many small contractors running Windows environments have NTLM enabled alongside Kerberos for backward compatibility. Even if Kerberos is preferred, an active NTLM fallback means some authentications are going through a weaker protocol. Assessors may probe whether NTLM is disabled or restricted in Group Policy.
Legacy VPN or remote access with password-only authentication
A VPN solution that authenticates users with only a static password, even over an encrypted tunnel, does not satisfy this requirement because the credential is static and reusable. The solution requires a one-time or session-unique credential layer on top — typically delivered through an MFA integration.
Web applications using session cookies without proper controls
If your in-scope systems include web applications that issue long-lived session cookies without expiration or token rotation, those sessions may be replayable if the cookie is captured. This is a less common finding in traditional small contractor environments but comes up in organizations running internal web-based tools.
Clock synchronization failures
For Kerberos environments, this is a quiet killer. If system clocks drift beyond the five-minute tolerance, Kerberos authentication fails and systems fall back to NTLM. Organizations that rely on Kerberos for replay resistance must ensure NTP is configured and functioning for all in-scope systems.
What Assessors Will Ask
The CMMC Assessment Guide for IA.L2-3.5.4 requires assessors to examine, interview, and test. Expect these lines of inquiry:
| Assessment question | What the assessor is looking for |
|---|---|
| What authentication protocols are in use for network access? | The assessor wants to understand whether Kerberos, NTLM, certificate-based, or other mechanisms are active. |
| Is NTLM disabled or restricted? | If Kerberos is your replay-resistance control, NTLM as an active fallback undermines it. Expect to show Group Policy settings. |
| How does your MFA solution generate credentials? | The assessor will want to confirm that the second factor produces one-time or session-specific data, not a static code. |
| How is NTP configured? | If you're claiming Kerberos as your implementation, clock sync is a dependency the assessor will verify. |
| Can you demonstrate how a captured authentication exchange would fail on resubmission? | Testing may include reviewing protocol configurations or logs showing session-unique behavior. |
SPRS Scoring
IA.L2-3.5.4 carries a point value of 1 under the current CMMC Level 2 scoring methodology. A finding against this requirement reduces your SPRS score by 1 point. It is generally POA&M-eligible, meaning a finding does not automatically prevent contract award, but it must be documented with a remediation plan and milestone dates if used in that context.
In the context of the full IA domain, a 3.5.4 finding is not a major score driver on its own. The bigger concern is architectural: a gap here often signals broader authentication weaknesses that can produce additional findings in adjacent requirements.
How to Document IA.L2-3.5.4 in Your SSP
Your System Security Plan must describe the specific mechanisms in place, not simply restate the requirement language. An assessor reading a generic statement like "we use replay-resistant authentication" will probe harder, not accept it at face value.
A strong SSP statement names the protocol (Kerberos, FIDO2, TOTP-based MFA), the tool that enforces it, the accounts it covers, and how the organization verifies it remains in effect. For Kerberos environments, the statement should reference the NTP configuration and the Group Policy settings that restrict NTLM.
Strong: "Acme Defense Parts uses Kerberos v5 as the primary authentication protocol for all Windows-based network access within the CUI boundary, enforced through Active Directory domain policy. NTLM is restricted via Group Policy (Network Security: LAN Manager Authentication Level set to 'Send NTLMv2 response only. Refuse LM & NTLM'). All in-scope systems synchronize to an internal NTP server (192.168.1.10) maintaining clock drift within the five-minute Kerberos tolerance. Remote access additionally enforces Cisco Duo MFA, which issues one-time push approvals per session. Kerberos configuration is documented in AD Group Policy and reviewed quarterly."
1TEN's Requirements Browser walks you through the exact interview questions assessors use for IA.L2-3.5.4, captures your implementation details, and incorporates them into your auto-generated SSP. You document it once and it flows through to every deliverable your C3PAO needs.