Replay-resistant authentication is one of the simpler practices if you’re using modern authentication methods. Most contractors aren’t sitting around using unencrypted authentication protocols, so this is generally a non-issue. The assessor usually moves on quickly once they see you’re using Kerberos or MFA. But you need to explain what you’re doing and why it prevents replays. This builds on the MFA and authentication mechanisms covered in IA.L2-3.5.2 and IA.L2-3.5.3.
A replay attack means the attacker captures a valid authentication packet and replays it to authenticate themselves. Basic HTTP authentication sent over HTTPS is vulnerable to replay if you don’t have additional protections. Kerberos built into Windows is not, because it uses timestamps and session keys. MFA is not, because it requires a live challenge-response. The assessor wants to know you understand this distinction and have configured your systems accordingly.
What the assessor is actually evaluating
The assessor is checking that you understand what replay attacks are and that your authentication system prevents them. They want to hear that you’re using an authentication protocol that includes time-based or challenge-response elements, not one where a static credential can be captured and reused.
Most of the time, this is straightforward. Windows domain authentication uses Kerberos. Kerberos includes timestamps. It resists replay attacks. MFA by definition requires a live challenge. Cloud services use OAuth or SAML with similar protections. If you’re not using obviously broken authentication (sending passwords in the clear, basic auth without additional protections), this practice is fine.
The assessor might ask how you authenticate to cloud systems or what protocol remote access uses. They’re looking for the mention of Kerberos, TLS with session tokens, SAML, OAuth, MFA, or other mechanisms that make it difficult for a captured credential to be reused. If you say “we use Kerberos for domain access and MFA for cloud access,” you’re done with this practice.
What a realistic SSP definition looks like
Practice IA.L2-3.5.4: Replay-Resistant Authentication Mechanisms
Authentication protocols used in our environment are resistant to replay attacks through the use of time-bound tokens and session-based authentication.
Domain Authentication: Users authenticate to the Windows domain using Kerberos authentication. Kerberos uses timestamped session tickets that are valid for a limited time period. Each session ticket contains a unique session key that is bound to the user’s account and the specific system being accessed. Captured authentication traffic cannot be replayed because the session ticket is time-limited and tied to a specific session.
Cloud/Remote Access: Access to Microsoft 365 and cloud resources is mediated through Azure AD using OAuth and SAML protocols. These protocols use session tokens with short lifespans and unique identifiers that prevent replay. MFA is required for all cloud access, adding an additional layer that makes captured credentials unusable.
VPN Access: Remote access through VPN uses TLS encryption with session-based authentication. VPN sessions are time-limited and terminate automatically after [X hours] of inactivity. Users must re-authenticate to establish a new session. Session tokens are not reusable across time periods.
Basic Authentication: We do not use basic HTTP authentication or other password-transmission-only methods for access to systems containing CUI. All authentication mechanisms in our environment include time-based or session-based replay protection.
This is clear and specific. The assessor reads it and knows you’re using Kerberos, OAuth, and TLS. All three prevent replays. No guessing required.
How to present your evidence
- Network architecture or security policy documenting authentication protocols used
- Configuration showing Kerberos, OAuth, SAML, TLS, or MFA is enforced
- Documentation explaining how each protocol prevents replay attacks
- Your SSP statement covering authentication mechanisms
Your evidence is mostly documentation and configuration. You need:
Network architecture or security policy documentation showing what authentication protocols you use and where. Something like “Windows domain users use Kerberos” or “Cloud access uses Azure AD with OAuth.”
Configuration of your authentication systems. For Active Directory, you don’t need to show anything special. Kerberos is the default and you’re using it. For cloud systems, show your Azure AD or identity provider configuration. For VPN, show your VPN server settings showing TLS enforcement and session timeout.
Your SSP statement (above). This is sufficient on its own for most assessors.
The assessor is unlikely to dig deeply here unless you’ve mentioned using a non-standard authentication method. If you’re using domain authentication plus cloud access, you’re fine.
Keep answers short. Show the evidence, don't describe it. Let the assessor drive. For more on how to present in the assessment room, see How to Present Evidence in the Assessment Room.
Common failures
Short, practical breakdowns of what assessors actually ask and how to answer. No compliance jargon, no sales pitch. Subscribe free on Substack.
If you use an MSP or MSSP
Your MSSP configures your authentication systems. They should be able to describe the protocols you’re using and explain how they prevent replay attacks. In the assessment, they can speak to the technical implementation. If your MSSP can’t explain replay-resistant authentication clearly, that’s a skill gap you might want to address before the assessment.
This practice is straightforward enough that if your MSSP says “we use Kerberos and MFA,” you’re done. Most mature MSPs do this without thinking. This shouldn’t be a pain point in the assessment.
This guidance is based on assessment room experience and reflects one practitioner’s interpretation of CMMC Level 2 requirements. It is not legal or compliance advice. Always consult your compliance team and official CMMC documentation for final guidance.