This post explains how to implement cryptographic protection for remote access sessions to satisfy NIST SP 800-171 Rev.2 / CMMC 2.0 Level 2 control AC.L2-3.1.13, covering practical VPN, TLS, and SASE configurations, implementation evidence, operational controls, and small-business scenarios.
\n\nAC.L2-3.1.13 requires organizations to employ cryptographic mechanisms to protect remote access sessions—meaning all remote connections that access Controlled Unclassified Information (CUI) or other sensitive resources must be encrypted and authenticated using strong, verifiable cryptography. Key objectives: confidentiality and integrity of session traffic, validated endpoints or identities, cryptographic key management, and auditable evidence of configuration and use.
\n\nThere are three common implementation approaches to meet this control: traditional VPN (IPsec, SSL/TLS-based), TLS-based application access (HTTPS/TLS for specific apps or tunnels), and SASE/Zero Trust Network Access (ZTNA) platforms that combine identity, device posture, and cloud-delivered network controls. For small businesses: use a managed SASE/ZTNA when you want simpler operations and centralized policy; use VPNs for well-understood site-to-site or device-to-network needs; use TLS termination + mTLS for specific web applications or APIs.
\n\nFor VPNs, choose modern protocols and strong ciphers—IKEv2/IPsec with AES-256-GCM or OpenVPN/WireGuard with AES-256-GCM or ChaCha20-Poly1305. Require certificate-based authentication or combined certificate + MFA (RADIUS/DUO/IdP). Example configuration items: disable legacy IKEv1, set IKE encryption to AES-256-GCM, integrity to SHA-256 or stronger, DH group to 20/21/31 (or use elliptic curve groups) and use perfect forward secrecy. Example OpenVPN server snippets: tls-version-min 1.2, cipher AES-256-GCM, auth SHA256, tls-cipher TLS-ECDHE-RSA-WITH-AES-256-GCM-SHA384; for WireGuard, use Curve25519 keys and chacha20poly1305. Operational rules: prohibit split tunneling for devices accessing CUI, enforce session timeout (e.g., 15–60 minutes of inactivity), log connection start/stop with username, client IP, certificate serial, and integrate logs into a central SIEM for 1+ year retention per contract requirements.
\n\nWhen remote access is provided by web applications or APIs, enforce TLS 1.2 minimum (prefer TLS 1.3), use strong cipher suites (TLS 1.3 default suites or TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 for TLS 1.2), enable HSTS, and implement mutual TLS (mTLS) for higher assurance where feasible. Use a trusted PKI (commercial CA or private enterprise CA with documented CA hierarchy), rotate certificates before expiry, and publish OCSP/CRL mechanisms for revocation. Evidence of compliance: TLS config screenshots, cipher suite lists, certificate inventory, and mTLS policy documentation showing client certificate requirements for CUI systems.
\n\nSASE providers (Prisma Access, Zscaler, Cloudflare Access, Cisco Umbrella) combine TLS-based tunnels, device posture checks, IdP integration (SAML/OIDC), and CASB capabilities. Configure SASE to terminate client TLS or to broker mTLS between client and service, enforce IdP MFA, require endpoint posture (antivirus, disk encryption), block split tunneling for CUI flows, and apply least-privilege application access policies (just-in-time, just-enough access). For a small business, integrate Azure AD/Okta with Cloudflare Access: require Okta MFA, evaluate device signals (browser, OS), and set session lifetimes aligned to company policy. Keep audit logs of all access decisions and tunneled flows in the SASE console and export to your SIEM for retention and reporting.
\n\nScenario: a 25-person subcontractor handling CUI needs remote access for engineers. Recommended stack: Cloud-hosted SAML IdP (Azure AD) + Cloudflare Access (ZTNA) for application access, and AWS Client VPN (certificate-based + Azure MFA via SAML/RADIUS) for admin tasks requiring full network access. Steps: 1) onboard users to Azure AD and enable conditional access; 2) configure Cloudflare Access to require device posture checks and per-app policies; 3) deploy AWS Client VPN with mutual TLS authentication (server cert from trusted CA, client certs issued via your internal PKI) and disable split tunneling; 4) enforce endpoint MDM for company and BYOD devices. Evidence: IdP policy screenshots, VPN server config file, device posture reports, and consolidated logs showing authenticated sessions to CUI systems.
\n\nDocument policies (remote access, cryptographic, key management, patching), produce configuration snapshots (exported VPN configs, SASE policy exports), collect logs (VPN connection logs, TLS termination logs, SASE access logs) and retain per contract/DFARS requirements—commonly 1 year but adjust to contract terms. Include PKI evidence: CA certificate inventory, certificate issuance records, CRL/OCSP logs, and key rotation schedules. Validate with periodic tests: vulnerability scans focused on exposed VPN/TLS endpoints, configuration reviews against CIS or vendor hardening guides, and tabletop exercises demonstrating revocation and incident response for a compromised client cert or IdP account.
\n\nIf remote sessions are not cryptographically protected or use weak/legacy algorithms you face eavesdropping, session hijacking, credential theft, exfiltration of CUI, contract breaches, loss of federal contracts, and potential regulatory penalties. Practical attack examples include intercepting unencrypted RDP, downgrading weak TLS to capture credentials, or compromising a VPN with expired/weak crypto—each can lead to adversaries accessing CUI and lateral movement into your environment.
\n\nChecklist highlights: enforce TLS 1.2+ (prefer TLS 1.3), choose AES-256-GCM or ChaCha20-Poly1305 ciphers, require certificate-based auth or MFA for all remote logins, disable legacy protocols, prohibit split tunneling for CUI access, enable endpoint posture checks for SASE, integrate logs with SIEM, rotate keys/certs before expiry, and maintain written procedures and evidence for audits. Best practice: adopt defense-in-depth—combine cryptography with identity, endpoint controls, monitoring, and incident response to meet both the letter and intent of AC.L2-3.1.13.
\n\nIn summary, meeting AC.L2-3.1.13 requires selecting modern cryptographic protocols (VPN/TLS/SASE), enforcing strong authentication and device posture, documenting configurations and evidence, and operating continuous monitoring and key management; for small businesses this is achievable with managed SASE or cloud VPN services plus an authoritative IdP and basic PKI practices—implement these steps, capture the required evidence, and periodically test to stay compliant and reduce risk.
", "plain_text": "This post explains how to implement cryptographic protection for remote access sessions to satisfy NIST SP 800-171 Rev.2 / CMMC 2.0 Level 2 control AC.L2-3.1.13, covering practical VPN, TLS, and SASE configurations, implementation evidence, operational controls, and small-business scenarios.\n\nUnderstanding the requirement and key objectives\nAC.L2-3.1.13 requires organizations to employ cryptographic mechanisms to protect remote access sessions—meaning all remote connections that access Controlled Unclassified Information (CUI) or other sensitive resources must be encrypted and authenticated using strong, verifiable cryptography. Key objectives: confidentiality and integrity of session traffic, validated endpoints or identities, cryptographic key management, and auditable evidence of configuration and use.\n\nImplementation options and when to use each\nThere are three common implementation approaches to meet this control: traditional VPN (IPsec, SSL/TLS-based), TLS-based application access (HTTPS/TLS for specific apps or tunnels), and SASE/Zero Trust Network Access (ZTNA) platforms that combine identity, device posture, and cloud-delivered network controls. For small businesses: use a managed SASE/ZTNA when you want simpler operations and centralized policy; use VPNs for well-understood site-to-site or device-to-network needs; use TLS termination + mTLS for specific web applications or APIs.\n\nVPN: practical configuration details\nFor VPNs, choose modern protocols and strong ciphers—IKEv2/IPsec with AES-256-GCM or OpenVPN/WireGuard with AES-256-GCM or ChaCha20-Poly1305. Require certificate-based authentication or combined certificate + MFA (RADIUS/DUO/IdP). Example configuration items: disable legacy IKEv1, set IKE encryption to AES-256-GCM, integrity to SHA-256 or stronger, DH group to 20/21/31 (or use elliptic curve groups) and use perfect forward secrecy. Example OpenVPN server snippets: tls-version-min 1.2, cipher AES-256-GCM, auth SHA256, tls-cipher TLS-ECDHE-RSA-WITH-AES-256-GCM-SHA384; for WireGuard, use Curve25519 keys and chacha20poly1305. Operational rules: prohibit split tunneling for devices accessing CUI, enforce session timeout (e.g., 15–60 minutes of inactivity), log connection start/stop with username, client IP, certificate serial, and integrate logs into a central SIEM for 1+ year retention per contract requirements.\n\nTLS: protecting app-level remote access\nWhen remote access is provided by web applications or APIs, enforce TLS 1.2 minimum (prefer TLS 1.3), use strong cipher suites (TLS 1.3 default suites or TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 for TLS 1.2), enable HSTS, and implement mutual TLS (mTLS) for higher assurance where feasible. Use a trusted PKI (commercial CA or private enterprise CA with documented CA hierarchy), rotate certificates before expiry, and publish OCSP/CRL mechanisms for revocation. Evidence of compliance: TLS config screenshots, cipher suite lists, certificate inventory, and mTLS policy documentation showing client certificate requirements for CUI systems.\n\nSASE / ZTNA: cloud-first approach\nSASE providers (Prisma Access, Zscaler, Cloudflare Access, Cisco Umbrella) combine TLS-based tunnels, device posture checks, IdP integration (SAML/OIDC), and CASB capabilities. Configure SASE to terminate client TLS or to broker mTLS between client and service, enforce IdP MFA, require endpoint posture (antivirus, disk encryption), block split tunneling for CUI flows, and apply least-privilege application access policies (just-in-time, just-enough access). For a small business, integrate Azure AD/Okta with Cloudflare Access: require Okta MFA, evaluate device signals (browser, OS), and set session lifetimes aligned to company policy. Keep audit logs of all access decisions and tunneled flows in the SASE console and export to your SIEM for retention and reporting.\n\nSmall-business scenario: practical deployment example\nScenario: a 25-person subcontractor handling CUI needs remote access for engineers. Recommended stack: Cloud-hosted SAML IdP (Azure AD) + Cloudflare Access (ZTNA) for application access, and AWS Client VPN (certificate-based + Azure MFA via SAML/RADIUS) for admin tasks requiring full network access. Steps: 1) onboard users to Azure AD and enable conditional access; 2) configure Cloudflare Access to require device posture checks and per-app policies; 3) deploy AWS Client VPN with mutual TLS authentication (server cert from trusted CA, client certs issued via your internal PKI) and disable split tunneling; 4) enforce endpoint MDM for company and BYOD devices. Evidence: IdP policy screenshots, VPN server config file, device posture reports, and consolidated logs showing authenticated sessions to CUI systems.\n\nCompliance tips, controls, and evidence collection\nDocument policies (remote access, cryptographic, key management, patching), produce configuration snapshots (exported VPN configs, SASE policy exports), collect logs (VPN connection logs, TLS termination logs, SASE access logs) and retain per contract/DFARS requirements—commonly 1 year but adjust to contract terms. Include PKI evidence: CA certificate inventory, certificate issuance records, CRL/OCSP logs, and key rotation schedules. Validate with periodic tests: vulnerability scans focused on exposed VPN/TLS endpoints, configuration reviews against CIS or vendor hardening guides, and tabletop exercises demonstrating revocation and incident response for a compromised client cert or IdP account.\n\nRisks of not implementing proper cryptographic protection\nIf remote sessions are not cryptographically protected or use weak/legacy algorithms you face eavesdropping, session hijacking, credential theft, exfiltration of CUI, contract breaches, loss of federal contracts, and potential regulatory penalties. Practical attack examples include intercepting unencrypted RDP, downgrading weak TLS to capture credentials, or compromising a VPN with expired/weak crypto—each can lead to adversaries accessing CUI and lateral movement into your environment.\n\nChecklist and best practices\nChecklist highlights: enforce TLS 1.2+ (prefer TLS 1.3), choose AES-256-GCM or ChaCha20-Poly1305 ciphers, require certificate-based auth or MFA for all remote logins, disable legacy protocols, prohibit split tunneling for CUI access, enable endpoint posture checks for SASE, integrate logs with SIEM, rotate keys/certs before expiry, and maintain written procedures and evidence for audits. Best practice: adopt defense-in-depth—combine cryptography with identity, endpoint controls, monitoring, and incident response to meet both the letter and intent of AC.L2-3.1.13.\n\nIn summary, meeting AC.L2-3.1.13 requires selecting modern cryptographic protocols (VPN/TLS/SASE), enforcing strong authentication and device posture, documenting configurations and evidence, and operating continuous monitoring and key management; for small businesses this is achievable with managed SASE or cloud VPN services plus an authoritative IdP and basic PKI practices—implement these steps, capture the required evidence, and periodically test to stay compliant and reduce risk." }, "metadata": { "description": "Step-by-step guidance to encrypt cloud remote access sessions (VPN, TLS, SASE) to meet NIST SP 800-171 Rev.2 / CMMC 2.0 Level 2 AC.L2-3.1.13 requirements, with actionable configurations and small-business examples.", "permalink": "/how-to-configure-cloud-remote-access-encryption-vpn-tls-and-sase-for-nist-sp-800-171-rev2-cmmc-20-level-2-control-acl2-3113-compliance.json", "categories": [], "tags": [] } }