03.05.04: Replay-Resistant Authentication

Implement the 03.05.04: replay-resistant authentication requirement by ensuring your authentication flows cannot be replayed from captured credentials or tokens. Operationally, that means using protocols and controls that bind authentication to freshness (nonces/challenges), time (short-lived tokens), and channel/session context, then retaining proof through configuration, test results, and access-system logs. ¹

Key takeaways:

• Replay resistance is an authentication property: captured secrets or tokens should not work again. ¹
• Most organizations satisfy 03.05.04 through MFA plus challenge-response or short-lived, audience-bound tokens, with replay detection where feasible. ¹
• Auditors will look for “show me” evidence: IdP settings, protocol choices, token lifetimes, and authentication logs that demonstrate the control operates. ¹

03.05.04: replay-resistant authentication requirement work is easiest when you treat it as an engineering constraint on every login and token-issuance path, not as a policy statement. If an attacker can capture an authentication transaction (a password, a one-time code, a session cookie, an API token, a Kerberos ticket, a SAML assertion) and successfully “play it back,” you have a replay problem.

For federal contractors and other organizations handling Controlled Unclassified Information (CUI), replay weaknesses show up in practical places: legacy VPNs and remote access gateways, service accounts calling internal APIs, long-lived bearer tokens in CI/CD systems, shared admin credentials, and poorly configured single sign-on. 03.05.04 pushes you to make authentication events provably fresh and hard to reuse.

This page translates the requirement into concrete build-and-check steps a Compliance Officer, CCO, or GRC lead can assign, track, and evidence quickly. It also flags where teams commonly get stuck (for example, “we have MFA, so we’re done”) and what assessors typically ask to validate the control. ¹

Regulatory text

Requirement: “NIST SP 800-171 Rev. 3 requirement 03.05.04 (Replay-Resistant Authentication).” ¹

Operator meaning: You must implement authentication mechanisms that prevent an attacker from reusing captured authentication data to gain access later. Replay resistance usually comes from one or more of the following design properties:

• Challenge-response / nonce-based flows (proof is valid only for a unique, one-time challenge).
• Short validity windows (tokens expire quickly, and are hard to reuse outside that window).
• Context binding (token is bound to client, session, audience, or channel so it fails if replayed elsewhere).
• Server-side replay detection (the system detects reuse of a token/assertion/jti and blocks it).

Your job as the control owner is to (1) identify all authentication paths into your CUI environment, (2) confirm each path has replay-resistant properties, (3) disable or compensate for paths that do not, and (4) retain evidence that an assessor can verify. ¹

Plain-English interpretation

Replay-resistant authentication means: recording an authentication attempt should not enable a second successful login. If an attacker copies a password, a one-time code, a SAML response, an access token, or a session cookie, they should not be able to “replay” it to authenticate again.

This requirement is broader than “use encryption” and narrower than “have MFA.” You can have MFA and still have replay exposure if you issue long-lived bearer tokens, accept reused assertions, or permit protocols that do not provide freshness guarantees. ¹

Who it applies to

Entity scope

• Federal contractors and other nonfederal organizations with systems that process, store, or transmit CUI. ¹

Operational scope (where replay resistance must hold)

• Workforce interactive access: SSO/IdP logins, VPN, VDI, bastions, privileged access.
• Administrative interfaces: hypervisors, cloud consoles, network devices, security tools.
• Application authentication: web sessions, mobile authentication, API access, machine-to-machine tokens.
• Third-party access: vendors/third parties connecting to CUI environments through remote access, support tools, or federated identity. ¹

What you actually need to do (step-by-step)

Step 1: Inventory “ways in” to the CUI boundary

Create an Authentication Entry Point Register for:

• IdPs (Entra ID/Okta/ADFS), on-prem directory auth, RADIUS/TACACS+, VPN gateways
• SSH/RDP gateways and bastions
• Application auth endpoints and token issuers (OIDC/OAuth authorization server)
• API gateways and service-to-service auth
• Any exceptions: local accounts, break-glass, legacy protocols

Minimum fields: system, owner, users (workforce/third party/service), protocol (SAML/OIDC/Kerberos/etc.), token/cookie type, token lifetime, MFA enforced (Y/N), replay controls present (Y/N), evidence link.

Step 2: Classify each entry point by replay risk

Use a simple decision matrix:

Entry point type	Typical replay risk	What “good” looks like
Password-only login	High	MFA + rate limits + secure session handling
MFA with OTP codes	Medium	OTP is one-time; session cookies hardened; no long-lived bearer tokens
SAML SSO	Medium	Signed assertions, strict audience/recipient, short assertion validity, replay detection if supported
OIDC/OAuth tokens	Medium/High	Short-lived access tokens, rotation, sender-constrained tokens where possible, validate iss/aud/exp/nbf
Kerberos	Lower (when correctly configured)	Ticketing with lifetimes; strong config; no fallback to weaker protocols

This matrix is for triage and assignment. Your assessment still needs system-specific validation. ¹

Step 3: Confirm protocols and settings enforce freshness and binding

For each entry point, collect and validate:

Workforce SSO (SAML/OIDC)

• Enforce MFA for CUI apps and admin portals.
• Set conservative token/assertion lifetimes.
• Validate token claims strictly (issuer, audience, time bounds).
• Prefer mechanisms that reduce replay value (for example, token rotation and session binding where your platform supports it).

VPN / remote access

• Require MFA.
• Disable weak/legacy authentication where feasible.
• Confirm the VPN auth exchange and session management are not vulnerable to simple credential replay (for example, captured static credentials without a second factor).

APIs and service accounts

• Eliminate long-lived static API keys for CUI-facing services where feasible.
• Use short-lived tokens issued by a centralized authorization service.
• Require TLS and validate tokens server-side with strict expiry and audience checks.
• Add replay detection controls where you have transaction identifiers (for example, reject reused jti/nonce values at the API gateway).

Step 4: Add compensating controls for exceptions you cannot modernize quickly

Legacy systems happen. If an entry point cannot support modern replay-resistant mechanisms:

• Put it behind a replay-resistant front door (SSO gateway, VPN with MFA, bastion with strong session controls).
• Restrict by network, device posture, and least privilege.
• Increase monitoring on authentication and token use for that pathway.
• Document an approved exception with an end state plan. ¹

Step 5: Test the control like an assessor would

Run a basic validation plan per entry point:

• Capture a token/assertion/session artifact in a controlled test and attempt reuse.
• Confirm token expiry and audience checks work.
• Confirm terminated sessions cannot be resumed with old cookies/tokens.
• Confirm logs show rejected replays (where detection exists) or show that the artifact becomes invalid after use/after time window.

Record results and link them to the register.

Step 6: Operationalize: monitoring + change control

Make replay resistance durable:

• Add configuration baselines for IdP/app token settings.
• Put token lifetime, protocol changes, and MFA policy changes under change control.
• Create alerts for abnormal token reuse patterns if your stack supports it.
• Review third-party access methods for replay properties before granting connectivity. ¹

Required evidence and artifacts to retain

Aim for evidence that answers: “Which systems are in scope, what did you configure, and how do you know it works?”

Core artifacts

• Authentication Entry Point Register (current, owned, reviewed)
• MFA and conditional access policies (exports/screenshots + date)
• IdP configuration for SAML/OIDC (token lifetimes, signing, audience restrictions)
• VPN/bastion configuration evidence (MFA enforcement, protocol settings)
• API gateway/auth server configuration (token TTLs, validation rules, replay detection settings if present)
• Test evidence: replay attempts blocked or rendered invalid (test plan + results)
• Logs: authentication events, token issuance, rejected token validations, anomalous re-auth patterns
• Exceptions register: legacy pathways, compensating controls, approvals, and remediation plan

Third-party due diligence add-on

• Contracts / access method documentation showing how third parties authenticate into CUI systems
• Access reviews showing third-party accounts and methods remain aligned to replay-resistant controls

Common exam/audit questions and hangups

Expect questions framed as “prove it”:

1. “List every authentication mechanism into the CUI environment.”
   Hangup: teams list only workforce SSO and forget APIs, service accounts, admin consoles.

2. “How do your tokens/assertions prevent replay?”
   Hangup: answers like “TLS” or “we sign tokens” without addressing expiry, binding, or reuse prevention.

3. “Show the configuration.”
   Hangup: policy statements without screenshots/exports and no linkage to in-scope systems.

4. “What about third parties?”
   Hangup: third-party remote access set up ad hoc, outside standard identity controls.

5. “How do you validate it keeps working after changes?”
   Hangup: no change control triggers for IdP token settings, app auth libraries, or VPN configuration.

Frequent implementation mistakes (and how to avoid them)

• Mistake: Treating MFA as automatically replay-resistant.
  Fix: Verify what happens after MFA. If you mint a long-lived bearer token, the replay target becomes the token, not the factor.

• Mistake: Missing machine-to-machine authentication.
  Fix: Put API keys, service tokens, CI/CD credentials, and integration accounts in scope from day one.

• Mistake: Accepting tokens without strict validation.
  Fix: Require issuer and audience validation and enforce expiration and not-before checks consistently across apps.

• Mistake: No evidence trail.
  Fix: Store exports/screenshots, config baselines, and test results in a single evidence folder mapped to 03.05.04.

• Mistake: Exception sprawl.
  Fix: Time-box exceptions with compensating controls and an explicit migration path, then track them like vulnerabilities. ¹

Risk implications (why assessors care)

Replay attacks bypass user intent. They can turn one captured secret into persistent access, which is exactly the failure mode you want to prevent around CUI. Operationally, replay weaknesses increase the chance that:

• an intercepted token grants access outside approved devices or sessions,
• a stolen session cookie becomes an authenticated session,
• a third party’s credentials become a quiet foothold into CUI systems. ¹

Practical 30/60/90-day execution plan

First 30 days (stabilize and scope)

• Name a control owner and technical owner for authentication (IdP/security engineering).
• Build the Authentication Entry Point Register for all CUI-boundary systems.
• Identify obvious replay risks: password-only paths, long-lived API keys, legacy remote access.
• Start evidence collection: current IdP policies, VPN configs, token settings, logs samples. ¹

By 60 days (implement and validate)

• Enforce MFA on all workforce and third-party interactive access into CUI systems.
• Standardize token/assertion settings for in-scope apps (expiry, audience, signing).
• Replace high-risk static secrets for key service integrations with short-lived tokens where feasible.
• Execute replay-focused tests on priority entry points and store results as audit evidence. ¹

By 90 days (operationalize and harden)

• Put auth configuration under change control with a required security review.
• Add monitoring for suspicious authentication and token usage patterns.
• Finalize exceptions with compensating controls and a tracked remediation plan.
• Make evidence recurring: monthly exports, quarterly tests, and access reviews tied to 03.05.04. ¹

Where Daydream fits: Daydream helps you map 03.05.04 to specific systems, assign control tasks, and run recurring evidence collection so your register, configurations, and test artifacts stay current for assessments. ¹

Frequently Asked Questions

Does MFA automatically satisfy 03.05.04?

MFA helps, but you still need to confirm that the post-authentication artifacts (sessions, tokens, assertions) cannot be replayed successfully. Review token lifetimes, validation rules, and session handling for each in-scope app. ¹

What systems should I scope first?

Start with remote access (VPN/bastions), SSO into CUI apps, and any API gateway or token issuer used by CUI systems. Those paths tend to cover most authentication volume and most replay exposure. ¹

How do I evidence “replay resistance” without specialized tooling?

Keep configuration exports (IdP token settings, VPN auth methods) and document a simple test where you attempt to reuse a captured token or session artifact and record the failure. Pair that with logs showing issuance and validation behavior. ¹

What about third parties who need support access?

Require them to enter through the same replay-resistant pathways as employees (SSO + MFA, bastion, or managed remote access), and document the method in the third-party access record. Avoid shared accounts and long-lived credentials. ¹

We have legacy apps that can’t do modern auth. What’s acceptable?

Put the legacy app behind a modern access layer (bastion, SSO proxy, or VPN with MFA) and restrict network access tightly. Document the exception, compensating controls, and the plan to migrate off the legacy auth path. ¹

What’s the fastest way to fail an assessment on 03.05.04?

Having no inventory of authentication entry points and no evidence that your token/session mechanisms resist replay. Assessors commonly treat “we think it’s configured” as a gap unless you can show settings and test results. ¹

Footnotes

1. NIST SP 800-171 Rev. 3