NIST SP 800-171 Rev.2 / CMMC 2.0 Level 2 control IA.L2-3.5.4 requires replay-resistant authentication mechanisms for network access — in practice this means replacing one-time passwords or poorly protected token flows that can be captured and replayed with cryptographic challenge-response or mutual-authentication schemes. For small businesses using Azure AD or Okta as identity providers, you can meet this control by enforcing modern, cryptographically strong authentication methods (FIDO2/WebAuthn, client certificates, EAP-TLS) and by hardening access policies and session controls so captured credentials or tokens cannot be replayed to gain access.
Why replay resistance matters and the compliance objective
The objective of IA.L2-3.5.4 is to ensure that an attacker who captures authentication traffic or one-time codes cannot reuse that data to impersonate a user. Replay attacks are practical against poorly designed OTP (SMS/unsynchronized tokens) and basic bearer-token flows. Failure to implement replay-resistant authentication exposes CUI and business systems to credential replay, lateral movement, ransomware, and loss of contractual compliance. For Compliance Framework implementation, you must show that network authentication uses challenge/response or mutual TLS mechanisms, that legacy/basic authentication is blocked, and that policies make token replay ineffective (short session lifetimes, continuous access evaluation, device attestation).
Azure AD: actionable configuration steps
In Azure AD, prioritize built-in passwordless and certificate methods and harden Conditional Access. Practical steps: first, enable FIDO2/WebAuthn and Windows Hello for Business in the Azure portal (Azure Active Directory → Security → Authentication methods → FIDO2 Security Key; enable and scope to groups for phased rollout). Second, enable Certificate-based Authentication (CBA) if you issue client certs (Azure AD supports CBA with uploaded CA chains and user mapping rules; configure under Azure AD → Security → Authentication methods → Certificate-based authentication). Third, create Conditional Access policies that require authentication strength — for high-value apps require 'passwordless' or 'multi-factor' using a FIDO/WebAuthn authenticator and set 'Grant' controls to require compliant devices. Fourth, block legacy authentication (basic auth) at the tenant level (Azure AD → Sign-in risk & legacy auth controls) to prevent replay of simple credentials. Fifth, configure session controls: set sign-in frequency to enforce reauthentication (for example 1 hour for risky scopes), enable Continuous Access Evaluation (CAE) where supported so revoked credentials invalidate tokens quickly, and set persistent browser session to 'Never persist'. Finally, integrate your VPN/Wi‑Fi with certificate-based authentication (EAP-TLS) — use your PKI to issue client certs, and have VPN/RADIUS servers validate certs rather than relying solely on password-based RADIUS.
Okta: practical steps to enforce replay resistance
Okta provides WebAuthn (FIDO2) and certificate-based options you can enforce via authenticators and Sign-On policies. In the Admin Console enable WebAuthn and configure it as a required authenticator for critical apps (Security → Authenticators → WebAuthn; set enrollment and policy). Use Okta Verify (push) and WebAuthn rather than SMS or TOTP for MFA — Okta Verify push uses a signed challenge tied to a session and device to resist replay. Create Sign-On policies (Security → Authentication → Sign-On Policies) that require these authenticators for all network-accessing apps and VPN integrations. For VPN/Wi-Fi, deploy Okta’s RADIUS agent or a RADIUS proxy that validates client certificates (EAP-TLS) against your CA; configure your VPN to use RADIUS + EAP-TLS instead of PAP/CHAP. Also disable legacy authentication endpoints and make API tokens short-lived; enforce device trust with Okta Device Trust for managed devices and require device attestations or MDM enrollment for elevated access. Finally, set session lifetime policies short for sensitive applications and enable token revocation on logout or credential change.
Network-layer specifics (VPN, Wi‑Fi, RADIUS, EAP-TLS)
Replay-resistance at the network layer is best achieved via mutual TLS (EAP-TLS) or other certificate-based EAP methods, not OTP over RADIUS alone. Small business example: replace VPN username/password + RADIUS OTP with EAP-TLS — issue device or user client certificates from your internal CA (or use an enterprise CA service), configure the VPN to accept only certificate authentication, and configure RADIUS to validate certificate revocation lists (CRLs) or OCSP. If using Azure AD integration, avoid relying solely on NPS + SMS OTP — instead use certificate-based (EAP-TLS) authentication or a modern SAML/OIDC flow backed by FIDO2. Test replay resistance by attempting a captured handshake replay; a properly configured EAP-TLS handshake with unique nonces and cert-based mutual auth will fail on replay. Maintain certificate lifecycle: automation for issuance/renewal, documented revocation procedures, and monitoring for expired certs that could create outages.
Monitoring, testing, and evidence for auditors
Show auditors that your tenant rejects replay attempts and that logs reflect cryptographic methods. Enable and retain sign-in logs in Azure AD and System Logs in Okta; forward these to your SIEM (Azure Sentinel, Splunk, etc.). Create detection rules for unusual token reuse, sudden increases in failed FIDO/WebAuthn assertions, repeated certificate authentication failures, and sign-ins from unexpected geolocations. Periodically perform live tests: capture a legitimate authentication exchange and verify that replay is rejected, run red-team exercises on VPN/Wi‑Fi, and document mitigation. For Compliance Framework evidence, export Conditional Access configuration, Sign-On policy settings, authenticator enforcement, and sample logs demonstrating rejected legacy auth or replay attempts.
Compliance tips, best practices and small-business scenarios
For a small business with limited staff: phase rollout by enforcing modern authenticators on high-value accounts first (finance, admins, CUI handlers) and use group-based policies to expand. Require hardware-bound authenticators (security keys) or platform WebAuthn (Windows Hello) for administrators, and issue device client certs for company laptops used for VPN. Keep a break-glass account secured offline with a hardware security key, documented and strictly controlled. Best practices: disable SMS/TOTP as primary MFA for sensitive access, block legacy auth, shorten session lifetimes for web apps, use device compliance (Intune/MDM or Okta Device Trust), automate certificate management, and rotate keys/certs routinely. Train staff on enrolling and using FIDO2 keys and on the reason you’re disabling older MFA methods — staff compliance removes common operational friction and reduces risky workarounds.
In summary, meeting IA.L2-3.5.4 requires replacing replayable authentication mechanisms with cryptographic, challenge-response or mutual-authentication mechanisms and enforcing them via identity-provider policies and network-layer configurations. For Azure AD and Okta, that means enabling and requiring FIDO2/WebAuthn or client certificates, blocking legacy/basic auth, integrating VPN/Wi‑Fi with EAP-TLS, tightening session controls and sign-in frequency, and demonstrating through logs and tests that replay attempts are rejected. Implement these steps iteratively, document configurations and tests for auditors, and combine technical controls with staff training and incident monitoring to maintain ongoing compliance.
