NIST SP 800-171 Rev.2 / CMMC 2.0 Level 2 Control IA.L2-3.5.4 requires replay-resistant authentication for network access to privileged and non-privileged accounts — a concrete security control that prevents captured credentials or tokens from being reused by an attacker; this post gives practical, small-business-friendly steps to implement that control for SSH (Linux/Unix) and RDP (Windows) with real-world configuration examples and compliance tips.
What "replay-resistant authentication" means and why it matters for compliance
Replay-resistant authentication uses authentication mechanisms that cannot be duplicated and reused by an attacker who intercepts an authentication exchange. Examples include hardware-backed asymmetric keys (FIDO2/WebAuthn), smartcards (PKI), short-lived certificates, and protocol flows that require cryptographic signatures bound to unique challenges or keys stored in secure hardware. For NIST/CMMC compliance, this reduces the risk of lateral movement and privileged account takeover — two common vectors that lead to Controlled Unclassified Information (CUI) exposure and audit failures.
Hardening SSH: recommended architecture and concrete settings
For SSH, prefer hardware-backed keys (FIDO2 / U2F "sk-" keys), SSH certificates signed by an internal CA, and multi-factor combinations (for example, certificate + hardware key or certificate + OTP) rather than relying on reusable passwords or long-lived static private keys. Implementation path for a small org: 1) deploy an OpenSSH CA for signing user keys, 2) issue short-lived user certificates, 3) require user keys to be FIDO2-backed when possible, and 4) disable password logins and root login. Example SSH server settings (sshd_config):
# /etc/ssh/sshd_config (highlighted changes)
PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes
ChallengeResponseAuthentication no
UsePAM yes
# Accept FIDO2/sk keys (OpenSSH 8.2+)
PubkeyAcceptedKeyTypes sk-ecdsa-sha2-nistp256@openssh.com,sk-ssh-ed25519@openssh.com,ssh-ed25519
# Accept certificates signed by the org CA
TrustedUserCAKeys /etc/ssh/ca_user.pub
# Optionally require publickey + keyboard-interactive (PAM MFA)
AuthenticationMethods publickey,keyboard-interactive
To generate a hardware-backed user key: ssh-keygen -t ed25519-sk -f ~/.ssh/id_ed25519_sk. To sign user keys with your CA: ssh-keygen -s /etc/ssh/ca -I user@example -n username -V +7d user_key.pub (this makes the cert valid for 7 days). Short-lived certificates drastically reduce replay windows; FIDO2 keys produce signatures that cannot be replayed because they require a fresh challenge and the private key is non-exportable.
Hardening RDP: enforce NLA, PKI, and gateway-based controls
For Windows RDP, Network Level Authentication (NLA) alone is not sufficient for replay resistance unless paired with hardware-backed authentication or short-lived credentials. Recommended deployment for compliance: enable NLA, require smart card / certificate-based logon or Windows Hello for Business (FIDO2-backed) for privileged accounts, and force all external RDP through an RD Gateway that requires client authentication and MFA. Key Group Policy settings: Computer Configuration → Administrative Templates → Windows Components → Remote Desktop Services → Remote Desktop Session Host → Security → "Require user authentication for remote connections by using Network Level Authentication" = Enabled, and "Always prompt for password upon connection" = Enabled (where appropriate for your risk model).
To add replay-resistant layers: configure RD Gateway to require SSL/TLS with client certificates (mutual TLS) or require smart card authentication; integrate RD Gateway with an MFA provider (Azure MFA, Duo, or a RADIUS MFA) for second factor. For organizations using Azure AD/hybrid environments, deploy Windows Hello for Business (key-based, TPM-backed) and enable FIDO2 security keys for remote sign-in via Azure AD Conditional Access policies and RD Web/RD Gateway integration.
Small-business scenario: 25 people with mixed Linux and Windows servers
Example phased rollout: Phase 1 (inventory & policy): identify privileged accounts and endpoints; document policy requiring replay-resistant auth for any remote access to those accounts. Phase 2 (SSH): deploy an OpenSSH CA on a bastion server, issue short-lived certs to admins, distribute 1–2 YubiKey/FIDO2 tokens per admin, set sshd_config to disable passwords. Phase 3 (RDP): enable NLA, require smart card/Windows Hello for Business for domain admin and helpdesk accounts, route external connections through an RD Gateway that enforces MFA. Phase 4 (monitoring & rotation): enable centralized logging (syslog/Windows Event Collector), rotate CA keys every 1–3 years, and set certificate validity to days or weeks for users. Total hardware cost is modest (FIDO2 keys ~$30–70 each); use free OpenSSH CA and existing AD Certificate Services if available.
Compliance tips, audit evidence, and best practices
Document your design and decisions: which accounts are covered, which authentication types are allowed/required, and key rotation schedules. Collect audit evidence: sshd_config snapshots, CA public key files, signed certificate issuance logs, GPO configuration exports, RD Gateway logs, and MFA transaction logs. Enforce least privilege and keep a small number of privileged accounts. Use jump/bastion hosts that log all session metadata (and optionally session recordings) for privileged access. Automate certificate issuance (CI/CD workflows or short-lived cert tooling) and include a process for lost hardware tokens (token recovery and revocation).
Failure to implement replay-resistant authentication leaves you vulnerable to credential capture and replay attacks (e.g., pass-the-hash, replaying intercepted OTPs within their valid window, or reusing static SSH keys). For organizations handling CUI, this can lead to unauthorized disclosure, lateral movement to key systems, regulatory non-compliance, expensive forensic response, and loss of customer trust.
In summary, IA.L2-3.5.4 is achievable for small and medium organizations by combining hardware-backed keys (FIDO2/smartcards), short-lived certificates (SSH certs, PKI client certs), and gateway-based controls for RDP; implement through clear policy, concrete configuration changes (sshd_config, GPO/RD Gateway), centralized logging, and documented procedures for key lifecycle and incident response to meet NIST SP 800-171 Rev.2 / CMMC 2.0 Level 2 expectations.
