Employ replay-resistant authentication mechanisms for network access to privileged and non-privileged accounts
📖 What This Means
This control requires organizations to implement authentication mechanisms that protect against replay attacks, where an attacker intercepts and retransmits valid authentication data to gain unauthorized access. This means ensuring that each authentication session is unique and cannot be reused by attackers. For example, using one-time passwords (OTP) or time-based tokens ensures that even if an attacker captures the authentication data, it cannot be reused. This applies to all network access, whether by privileged accounts (like administrators) or non-privileged accounts (regular users). Real-world examples include implementing multi-factor authentication (MFA) with time-based one-time passwords (TOTP) or using secure session tokens in web applications.
🎯 Why It Matters
Replay attacks can lead to unauthorized access to sensitive systems and data, potentially resulting in data breaches, financial loss, and reputational damage. For example, in 2017, a replay attack on a major cryptocurrency exchange resulted in the theft of millions of dollars. The DoD emphasizes this control to protect Controlled Unclassified Information (CUI) and ensure the integrity of authentication processes. Without replay-resistant mechanisms, attackers can easily exploit intercepted credentials, leading to significant security incidents.
✅ How to Implement
- Enable MFA for all user accounts in AWS/Azure/GCP.
- Use OAuth 2.0 with PKCE (Proof Key for Code Exchange) for secure token exchange.
- Implement session management with short-lived tokens and token rotation.
- Use AWS Cognito, Azure AD, or Google Identity Platform for secure authentication.
- Enable logging and monitoring for authentication events to detect replay attempts.
📋 Evidence Examples
MFA Configuration Screenshot
Authentication Policy Document
Authentication Logs
MFA Enrollment Report
Testing Results
📝 SSP Guidance
Use this guidance when writing the System Security Plan (SSP) narrative for this control.
How to Write the SSP Narrative
For IA.L2-3.5.4 ("Employ replay-resistant authentication mechanisms for network access to privileged and non-privileged accounts"), your SSP narrative should specifically describe: (1) the tools and technologies you use to implement this control, (2) the configuration or process that enforces it, (3) who is responsible for maintaining it, and (4) what evidence proves it's working. Describe how users, devices, and processes are identified and authenticated, including your IAM platform, password policies, MFA implementation, certificate management, and service account controls. Be specific -- name your actual products, settings, and responsible personnel.
Example SSP Narratives
"IA.L2-3.5.4 is implemented using cloud-native controls. [Organization] uses [specific cloud service/feature] to employ replay-resistant authentication mechanisms for network access to privileg.... The configuration is managed through [Azure Policy/AWS Config/Terraform] and monitored via [SIEM tool]. Responsible party: [IT Security Manager]. Evidence: [specific artifact, e.g., 'Azure AD Conditional Access policy screenshot, CloudTrail logs']."
"IA.L2-3.5.4 is implemented through on-premise infrastructure controls. [Organization] uses [Active Directory/Group Policy/specific tool] to employ replay-resistant authentication mechanisms for network access to privileg.... Configuration is documented in [location] and audited [frequency]. Responsible party: [System Administrator]. Evidence: [specific artifact, e.g., 'Group Policy export, Windows Event logs']."
"IA.L2-3.5.4 is implemented across both cloud and on-premise environments. [Organization] uses [Azure AD Connect/hybrid tool] to ensure consistent enforcement. Cloud resources are managed via [cloud tool] and on-premise systems via [on-prem tool]. Both environments report to [centralized SIEM]. Responsible party: [IT Director]. Evidence: [artifacts from both environments]."
System Boundary Considerations
- • Identify all authentication entry points (local login, VPN, cloud, API)
- • Document the identity provider(s) and authentication flow
- • Specify MFA methods and coverage
- • Ensure this control covers all systems within your defined CUI boundary where employ replay-resistant authentication mechanisms for network access to privileged and non-privileged accounts applies
- • Document any systems where this control is not applicable and explain why
Key Documentation to Reference in SSP
- 📄 Identification and Authentication Policy
- 📄 Password policy configuration
- 📄 MFA enrollment records
- 📄 Service account registry
- 📄 Evidence artifacts specific to IA.L2-3.5.4
- 📄 POA&M entry if control is not fully implemented
What the Assessor Looks For
The assessor will test authentication mechanisms, verify MFA is enforced for required access paths, check password policy configuration, and review service account documentation.
💬 Self-Assessment Questions
Use these questions to assess your compliance. Each "NO" answer provides specific remediation guidance.
Question 1: Is MFA enabled for all user accounts?
Question 2: Are authentication tokens short-lived and rotated?
Question 3: Is logging enabled for authentication events?
Question 4: Is there a documented authentication policy?
Question 5: Have replay-resistant mechanisms been tested?
⚠️ Common Mistakes (What Auditors Flag)
1. Not enabling MFA for all accounts.
2. Using long-lived authentication tokens.
3. Insufficient logging of authentication events.
4. Lack of documented authentication policies.
5. Not testing replay-resistant mechanisms.
📚 Parent Policy
This practice is governed by the Identification and Authentication Policy