Identification and Authentication 3.5.4 (3.5.4)
Employ replay-resistant authentication mechanisms for network access to privileged and non-privileged accounts.
Get Full GuidanceWhat Is This CMMC Control?
This control requires organizations to use authentication methods that cannot be defeated by an attacker recording and replaying captured login credentials. Common implementations include time-based one-time passwords (TOTP), challenge-response systems, Kerberos tickets with timestamps, and modern protocols like OAuth 2.0 that include nonce values. The goal is to ensure that even if an attacker intercepts authentication traffic, they cannot reuse it to gain unauthorized access.
Control Intent
Prevent unauthorized access by ensuring authentication credentials cannot be captured and reused by attackers through replay attacks.
Who This Control Applies To
- •All network-based authentication for privileged accounts (administrators, system accounts, service accounts with elevated permissions)
- •All network-based authentication for non-privileged user accounts
- •Remote access systems (VPN, remote desktop, SSH)
- •Web applications requiring network authentication
- •API authentication mechanisms
- •Wireless network authentication
- •Cloud service authentication
- •Multi-factor authentication systems
- •Single sign-on (SSO) implementations
- •Service-to-service authentication
Not Applicable When
- •Physical console access with no network component (though MFA may still be required under other controls)
- •Standalone systems with no network connectivity
- •Air-gapped systems with only local authentication
- •Systems that only use inherited authentication from a compliant centralized system
Key Objectives
- 1Implement authentication mechanisms that include time-variant parameters or challenge-response elements that prevent credential reuse.
- 2Ensure both privileged and non-privileged network authentication processes resist replay attacks.
- 3Protect authentication sessions from interception and subsequent unauthorized replay.
Sample Self-Assessment Questions (Partial)
Does your organization use multi-factor authentication (MFA) for all user accounts accessing systems over the network?
What authentication protocols are used for remote access (VPN, remote desktop, cloud applications)?
Implementation Approaches (High-Level)
Multi-Factor Authentication (MFA) with Time-Based One-Time Passwords (TOTP)
Implement MFA using authenticator apps (Microsoft Authenticator, Google Authenticator, Duo) that generate time-synchronized one-time codes. The time-variant nature of TOTP codes makes them replay-resistant.
Kerberos Authentication with Time-Limited Tickets
Use Kerberos protocol for network authentication with properly configured ticket lifetimes and renewal policies. Kerberos tickets include timestamps and are time-limited, providing replay resistance.
OAuth 2.0 and OpenID Connect with Short-Lived Tokens
Implement modern authentication using OAuth 2.0 or OpenID Connect with access tokens that include expiration times and refresh token rotation. Tokens are time-limited and include nonce values to prevent replay.
Challenge-Response Authentication (CHAP, MS-CHAP v2, EAP-TLS)
Use challenge-response protocols where the server sends a unique challenge for each authentication attempt, and the client must respond with a computed value. Each authentication session uses a different challenge, preventing replay.
Hardware Security Keys (FIDO2/WebAuthn)
Deploy hardware security keys that use public key cryptography and challenge-response mechanisms. Each authentication generates a unique cryptographic signature that cannot be replayed.
SSH with Public Key Authentication and Certificate Rotation
Configure SSH to use public key authentication with short-lived certificates or key rotation policies. SSH keys with proper configuration resist replay attacks through cryptographic challenge-response.
SAML Federation with Assertion Expiration
Implement SAML-based single sign-on with properly configured assertion lifetimes and audience restrictions. SAML assertions include timestamps and are time-limited to prevent replay.
API Authentication with Signed Requests and Nonces
Implement API authentication using request signing with nonce values and timestamps. Each API request includes a unique nonce and timestamp that are validated to prevent replay.
WPA3 or WPA2-Enterprise for Wireless Authentication
Deploy wireless networks using WPA3 or WPA2-Enterprise with 802.1X authentication. These protocols include replay protection mechanisms and per-session encryption keys.
Smart Card or PIV Card Authentication
Implement smart card or PIV (Personal Identity Verification) card authentication for workstation login and privileged access. Smart cards use challenge-response cryptography that resists replay attacks.
Evidence & Assessment Notes
Expected Evidence
Organizations should maintain documentation and evidence demonstrating compliance with this control. This may include policy documentation, configuration records, audit logs, access reviews, and other relevant artifacts that show how the control is implemented and maintained.
Plan of Action & Milestones (POA&M)
If MFA is not yet deployed, create a POA&M with milestones for MFA solution selection, pilot deployment, user enrollment, and full enforcement For legacy systems that cannot support replay-resistant authentication, document compensating controls such as network segmentation, enhanced monitoring, or restricted access, and include remediation or replacement timelines If service accounts or API authentication lacks replay resistance, create a POA&M for implementing OAuth, request signing, or certificate-based authentication For wireless networks using WPA2-PSK, create a POA&M for migration to WPA2/WPA3-Enterprise with 802.1X If Kerberos ticket lifetimes are excessive, create a POA&M for Group Policy updates and testing For systems with NTLM or other legacy protocol dependencies, create a POA&M for application updates or replacements to support modern authentication If third-party or vendor access bypasses replay-resistant authentication, create a POA&M for implementing federated access or MFA requirements POA&Ms should include specific technical milestones, not just 'implement MFA' - detail enrollment phases, policy enforcement dates, and legacy protocol disablement Include user training and communication milestones in POA&Ms for authentication changes For large-scale MFA deployments, consider phased POA&Ms by user group (privileged users first, then all users) Ensure POA&M milestones are realistic given procurement, testing, and user adoption timelines (typically 3-12 months for enterprise MFA deployment)
Frequently Asked Questions
Does implementing MFA satisfy the replay-resistant authentication requirement?
Yes, MFA using time-based one-time passwords (TOTP), push notifications, or hardware security keys satisfies this control because these methods include time-variant or challenge-response elements that prevent replay attacks. However, SMS-based MFA is less preferred due to known vulnerabilities, and organizations should use app-based or hardware MFA where possible.
Are service accounts and API keys required to use replay-resistant authentication?
Yes, this control applies to all network authentication for both privileged and non-privileged accounts, which includes service accounts and API authentication. Organizations should implement OAuth tokens with expiration, request signing with nonces, or certificate-based authentication for service accounts and APIs rather than static passwords or API keys.
Can we use password-only authentication for internal systems behind a firewall?
No, the control requires replay-resistant authentication for all network access, regardless of network location. Even internal systems must use mechanisms like MFA, Kerberos, or other replay-resistant protocols. Network segmentation does not exempt systems from this requirement, though it may be considered a compensating control during a POA&M period.
What should we do if a legacy application cannot support MFA or modern authentication?
Document the limitation in your System Security Plan and create a POA&M with a remediation timeline. Implement compensating controls such as network segmentation, enhanced monitoring, IP restrictions, or limiting access to specific users or systems. Work toward application replacement or updates that support replay-resistant authentication. Assessors will evaluate the adequacy of compensating controls and the reasonableness of the remediation timeline.
Is Kerberos authentication sufficient for this control, or do we also need MFA?
Kerberos with properly configured ticket lifetimes is replay-resistant and satisfies this control (3.5.4). However, you may still need MFA to satisfy other controls such as 3.5.3 (multifactor authentication for privileged accounts). Kerberos and MFA address different security objectives and are often implemented together in a defense-in-depth approach.
How do we demonstrate replay resistance for cloud applications like Microsoft 365 or Salesforce?
Provide evidence of MFA enforcement through conditional access policies, sign-on policies, or federation configuration. Show that all users are enrolled in MFA and that authentication logs demonstrate MFA usage. If using federated authentication (SAML, OAuth), provide evidence of the identity provider configuration including token/assertion lifetimes and MFA enforcement at the identity provider level.
How ConformatIQ Helps With CMMC Readiness
ConformatIQ is an AI-assisted CMMC readiness platform designed to help organizations prepare for assessments more efficiently. The platform supports document generation such as SSPs and POA&Ms, guided readiness workflows, centralized evidence tracking, and interview preparation for assessments.
Ready to Get Full Guidance?
Access complete implementation details, detailed assessment questions, evidence requirements, and expert guidance for this control.
Request Full GuidanceInformation sourced from NIST SP 800-171 Rev. 2. See full disclaimer.