This post provides a focused, actionable configuration checklist to implement network and application-layer cryptography required to meet NIST SP 800-171 Rev.2 / CMMC 2.0 Level 2 control SC.L2-3.13.8, with step-by-step implementation notes, real-world small-business scenarios, and compliance evidence you can use during assessment.
Why this control matters and the risk of non‑implementation
SC.L2-3.13.8 requires that Controlled Unclassified Information (CUI) be protected during transmission using cryptographic mechanisms; failing to implement it exposes CUI to eavesdropping, man-in-the-middle attacks, and tampering — risks that can lead to contract loss, regulatory penalties, and reputational damage for small contractors. For auditors, missing or weak crypto configurations are often immediate failures because they demonstrate an inability to preserve confidentiality and integrity of CUI in transit.
High‑level implementation checklist (practical steps)
Inventory endpoints and flows: identify every service, API, remote access method, and inter-service channel that transmits or can access CUI. For each item capture hostname/IP, protocol (HTTPS, SSH, VPN, SMTP, API), certificate issuer, TLS version, cipher suites, and key management method. Next, enforce modern transport protections: require TLS 1.2 or TLS 1.3 (prefer TLS 1.3), disable SSLv2/SSLv3/TLS1.0/TLS1.1, enable forward secrecy (ECDHE or DHE with sufficiently large groups), and allow only AEAD ciphers (AES‑GCM, ChaCha20‑Poly1305). Document these requirements in your cryptography policy and map them to the System Security Plan (SSP) and POA&M entries.
Concrete server and application configurations
Web servers and load balancers — nginx/Apache/ALB/CloudFront: set ssl_protocols TLSv1.2 TLSv1.3; prefer AEAD ciphers such as ECDHE+AESGCM and ChaCha20-Poly1305; enable HSTS (Strict-Transport-Security: max-age=31536000; includeSubDomains); enable OCSP stapling and TLS session ticket protection. Example (nginx): ssl_protocols TLSv1.2 TLSv1.3; ssl_prefer_server_ciphers on; ssl_ciphers 'ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:...:CHACHA20-POLY1305'; Always test with SSL Labs or testssl.sh and include the scans as evidence. For SSH, use Protocol 2 only, disable password authentication (PasswordAuthentication no), disallow root login (PermitRootLogin no), use key-based auth with ed25519 or ecdsa keys, and remove weak KEX and MAC algorithms.
Key management and certificates — practical controls
Small businesses should centralize keys and certificates — use a cloud KMS (AWS KMS/Azure Key Vault/GCP KMS) or an HSM for root CA keys if you operate your own PKI. Enforce minimum key lengths (RSA >= 2048 but prefer 3072 or ECDSA P-256/P-384 for new keys) and rotate keys and certificates on a schedule (e.g., certificates every 90 days for public TLS, annually for internal if allowed). Implement automated certificate issuance and renewal (ACME/Let's Encrypt or ACM) and monitor expirations with alerts. For machine-to-machine communication consider mTLS (mutual TLS) and short-lived client certificates to reduce exposure of leaked keys.
Application-level cryptography and secure design
When transports are not sufficient or additional protections are needed, use application-layer crypto: JSON Web Encryption (JWE) for payload encryption, JSON Web Signature (JWS) for integrity, or TLS+field-level encryption for particularly sensitive CUI. Store keys in KMS/HSM, avoid hard-coding secrets in code or containers, use environment secrets managers (HashiCorp Vault, AWS Secrets Manager), and ensure libraries are up to date (OpenSSL, libsodium). Use authenticated encryption (AES-GCM, ChaCha20-Poly1305) rather than legacy modes like CBC when encrypting data.
Operational controls, continuous monitoring, and audit evidence
Operationalize checks: run automated scanners (testssl.sh, SSL Labs, Nessus) weekly or as part of CI/CD to detect weak ciphers or expired certs. Maintain a certificate inventory and rotation log, save config snapshots (nginx.conf, sshd_config), and keep scan reports and change control notes in your evidence pack for assessors. For CMMC audit readiness, include your SSP entries detailing cryptographic protections, a procedure for key lifecycle management, POA&M items for any gaps, and screenshots or output of successful mTLS/SSH tests demonstrating correct behavior.
Small-business scenarios and pragmatic choices
Example 1 — small defense subcontractor hosting a web portal with CUI on AWS: use an Application Load Balancer with an AWS-managed certificate (ACM), set TLS policy to restrict to TLS 1.2/1.3, enable ALB access logs, and store backend keys in AWS KMS with automatic rotation. Example 2 — remote engineers connecting to on-prem servers: require VPN with IKEv2/IPsec or TLS VPN (OpenVPN/Cloud VPN), enforce certificate-based authentication and client posture checks, or use SSH bastion with enforced key-based authentication and session recording. These are practical, lower-cost approaches that meet SC.L2-3.13.8 when documented and tested.
Compliance tips and best practices
Keep configurations as code (Ansible/Terraform) to ensure repeatability and to produce versioned evidence. Favor managed services (ACM, Cloud KMS, Vault) to reduce operational overhead but document trust boundaries and access controls. Train devs on safe crypto use, disable legacy protocols by default, and capture periodic penetration test or scan results. Map each implemented control to the specific language in your SSP and include cross-references to evidence artifacts so assessors can verify implementation efficiently.
Summary: To comply with NIST SP 800-171 Rev.2 / CMMC 2.0 Level 2 SC.L2-3.13.8, inventory all CUI flows, enforce modern TLS/SSH/VPN configurations (TLS1.2/1.3, AEAD ciphers, forward secrecy), centralize key management, automate certificate lifecycle, and produce scan/config evidence mapped to your SSP and POA&M — practical steps any small business can apply to reduce risk and pass assessment.
