This guide shows how to implement cryptographic protections to meet NIST SP 800-171 Rev.2 / CMMC 2.0 Level 2 control SC.L2-3.13.8 — "Employ cryptographic mechanisms to protect the confidentiality of Controlled Unclassified Information (CUI)." It provides practical, step-by-step implementation advice, concrete technical choices, and small-business examples to help you deploy compliant, defensible encryption for data at-rest and in-transit.
What SC.L2-3.13.8 requires (practical interpretation)
At Level 2 / NIST 3.13.8, the objective is straightforward: use approved cryptographic mechanisms to protect CUI wherever confidentiality risks exist — in transit, at rest, and on endpoints. For compliance this means selecting vetted algorithms and implementations (preferably FIPS 140-2/140-3 validated modules when applicable for DoD contracts), applying encryption consistently, and documenting choices, key management, and validation steps so assessors can verify controls are in place.
Step-by-step implementation
Step 1 — Classify CUI and map data flows
Start by inventorying where CUI is created, stored, processed, and transmitted. Create a data-flow diagram that shows systems, storage (S3 buckets, databases, file servers), endpoints (laptops, mobile), and third parties. For each flow classify sensitivity and required protections (e.g., CUI at rest in S3 vs. CUI in email attachments). This mapping drives decisions about where to apply envelope encryption, TLS, VPNs, or full disk encryption.
Step 2 — Choose approved algorithms and configurations
Select modern, well-vetted algorithms: AES-256-GCM or AES-256-CCM (AEAD) for confidentiality+integrity, RSA-3072 or ECDSA (P-256/P-384) for signatures where required, and HMAC-SHA256+ for message authentication. Use TLS 1.2 (with strong ciphers) or TLS 1.3 for in-transit protection; configure servers to prefer ECDHE key exchange and AEAD ciphers (example TLS 1.2 list: ECDHE-ECDSA-AES256-GCM-SHA384, ECDHE-RSA-AES256-GCM-SHA384). Disable weak ciphers (RC4, 3DES, EXPORT suites) and older protocol versions (SSLv2/3, TLS 1.0/1.1). For password-derived keys use strong KDFs (PBKDF2 with high iteration count, bcrypt, or Argon2) for any local secrets.
Step 3 — Implement in-transit protections
For web services and APIs enable TLS 1.2+ with server-side configuration: publish HSTS, use certificates from trusted CAs (or your internal PKI for internal services), and enable forward secrecy via ECDHE. For service-to-service and admin access, use mutual TLS or strong VPNs (IKEv2 with strong transforms, or TLS-based VPNs). Small-business example: a contractor can use a cloud-managed load balancer (AWS ALB, Azure Front Door) with TLS 1.3 enabled and HTTP Strict Transport Security to protect web interfaces without managing certificates manually.
Step 4 — Implement at-rest and endpoint protections
Encrypt databases, object storage, backups, and endpoints. Prefer envelope encryption for cloud object storage (e.g., AWS S3 SSE-KMS with customer-managed CMKs) so data keys are unique per object and protected by a master key. For endpoints deploy full-disk encryption (BitLocker for Windows, FileVault for macOS, LUKS for Linux) and enforce pre-boot authentication or enterprise recovery key escrow (Active Directory or MDM). Example small-business stack: enable RDS/encrypted EBS volumes with KMS CMKs, use S3 with SSE-KMS and bucket policies, and protect employee laptops with BitLocker and MDM-managed keys stored in Azure AD).
Step 5 — Key management and lifecycle
Document and implement key lifecycle policies: generation (use HSM or cloud-KMS), storage (never store plaintext keys in application code or repos), rotation (set rotation cadence — e.g., rotate data keys annually or on compromise; rotate TLS certificates before expiration), backup, and destruction. Use envelope encryption and a centralized KMS (AWS KMS, Azure Key Vault, Google KMS) or an HSM/CloudHSM for high-assurance keys. Enforce separation of duties: administrators can manage keys but cannot access plaintext CUI; application services access only wrapped data keys. Log every KMS operation and integrate with SIEM/CloudTrail for auditability.
Risk of not implementing robust cryptographic controls
Failing to apply SC.L2-3.13.8 exposes CUI to eavesdropping, data theft, and tampering. Consequences include unauthorized disclosure, loss of DoD contracts or subcontracts, negative CMMC assessments, regulatory and contractual penalties, and reputational harm. Practically, an unencrypted backup or improperly configured S3 bucket can immediately lead to a data breach; weak TLS or expired certificates open the door to MitM attacks on remote access and APIs.
Compliance tips and best practices
Document everything: algorithm selection, module validation status (FIPS 140-2/3 where required), key ownership and rotation schedules, and data-flow diagrams. Use managed services to reduce operational risk (e.g., KMS, managed HSM, cloud KMS-backed encryption for databases). Avoid "rolling your own" crypto. Apply defense in depth: encrypt data at rest and in transit, use strong authentication (MFA), and enforce least privilege for KMS IAM policies. Validate with regular scans (config checks for TLS, cipher suites) and tabletop exercises for key compromise. For small businesses, leverage COTS: enable platform encryption (SaaS providers’ encryption settings), use HashiCorp Vault for application secrets, and centralize certificate management to prevent expired certificates and configuration drift.
Summary — implementing SC.L2-3.13.8 is a practical program, not a one-off task: classify CUI, map flows, choose approved algorithms (AES-GCM, strong ECC/RSA), deploy TLS and at-rest encryption, centralize and harden key management, document everything, and monitor. With managed cloud services and clear policies, small businesses can meet NIST SP 800-171 Rev.2 / CMMC 2.0 Level 2 requirements while minimizing operational burden and exposure.
