Encrypting Controlled Unclassified Information (CUI) at rest and managing the associated cryptographic keys is a core requirement of NIST SP 800-171 Rev.2 and CMMC 2.0 Level 2 (SC.L2-3.13.16); this post gives a practical, step-by-step implementation plan, real-world examples for a small business, specific technical recommendations, and audit-ready evidence to demonstrate compliance.
\n\nThe objective of SC.L2-3.13.16 is to ensure CUI stored on disks, databases, filesystems, object stores, backups, and removable media is protected with strong encryption and that cryptographic keys are managed securely over their lifecycle. For small businesses that handle DoD-related CUI, this means: identifying all CUI at rest, applying FIPS-acceptable algorithms (e.g., AES-256), using hardened key storage (KMS or HSM), enforcing access controls and separation of duties for key usage, logging key operations, and maintaining key rotation/retirement processes with documented evidence.
\n\nStart by inventorying where CUI resides: endpoints (laptops, mobile), servers (file shares, databases), cloud services (S3 buckets, object storage), backups, and removable media. Tag each asset with CUI scope and risk level. Produce a simple CSV or CMDB entry with columns: asset, owner, storage type, encryption status, key type (device TPM, KMS, HSM), and evidence pointer (config file, screenshot).
\n\nFor symmetric data protection, standardize on AES-256 in an authenticated mode (AES-GCM where available). Use envelope encryption: data encrypted with a data key (AES-256) and that data key encrypted (wrapped) by a long-lived master key stored in a Key Management System (KMS) or Hardware Security Module (HSM). For cloud: AWS KMS (customer-managed CMK) or CloudHSM, Azure Key Vault (with HSM-backed keys), GCP Cloud KMS. For on-prem: a FIPS 140-2/3 validated HSM or appliance, or an enterprise KMS that integrates with your applications via KMIP.
\n\nExamples for a small business: full-disk encryption on laptops with BitLocker (Windows) bound to TPM and MDM policy, FileVault on macOS, LUKS2 + TPM on Linux. For file/object storage, enable SSE-KMS (S3 with SSE-KMS) or client-side envelope encryption using your KMS. For databases: enable Transparent Data Encryption (TDE) integrated with your KMS or use application-layer encryption for particularly sensitive fields (PII, financial data). For backups, store only encrypted backup artifacts and escrow the keys securely.
\n\nDefine and document the lifecycle: key generation (use FIPS-validated RNG), distribution (never send plaintext keys in email), activation, rotation, compromise handling, archival, and secure destruction. Enforce least-privilege access to key policies: separate duties so that administrators who can create keys cannot unilaterally export master key material. Require dual control or split knowledge for key recovery and support key escrow mechanisms (e.g., split key shares stored in different secure locations).
\n\nTechnical specifics to implement: generate symmetric data keys of 256 bits, keep master keys at 3072-bit RSA or better (or ECC P-256/P-384) for wrapping if asymmetric is used. For AWS example: create a customer-managed CMK with automatic annual rotation disabled/enabled per policy, attach a least-privilege key policy granting only required IAM roles the kms:Encrypt/kms:Decrypt permissions, and record CloudTrail entries for each Encrypt/Decrypt/GenerateDataKey call as audit evidence. For on-prem, use an HSM with KMIP and ensure it is FIPS 140-2/3 validated; collect HSM certification number in your evidence package.
\n\nLog all key management events centrally (CloudTrail, SIEM) and retain logs per contract requirements (commonly 1–7 years depending on agreements). Create and keep artifacts for audits: key policies, KMS console screenshots, CLI audit outputs, rotation schedules, runbooks for key compromise, and periodic key use reports. For each CUI-bearing asset include configuration notes (e.g., BitLocker policy applied via Intune, LUKS header backup file hash stored in vault). These artifacts demonstrate the \"implementation\" and \"sustained operation\" reviewers look for under NIST/CMMC.
\n\nScenario: a small contractor stores CUI in a PostgreSQL database hosted on AWS RDS and in S3 for document storage. Implementation: enable RDS encryption with a customer-managed CMK in AWS KMS (master key stored with AWS KMS, optionally backed by CloudHSM). Configure the application to use envelope encryption for sensitive columns prior to insertion so database backups contain encrypted fields. For S3, enable SSE-KMS with the same CMK. Document the architecture diagram, the CMK ARN, key policy JSON, rotation schedule, and export CloudTrail logs that show key usage before the assessment.
\n\nFailing to encrypt CUI at rest or poorly managing keys creates high-impact risks: data exfiltration with readable CUI, contract termination, legal exposure, fines, and loss of DoD trust. Common pitfalls include storing keys on the same machine as encrypted data, insufficient rotation or testing of key recovery, using non-authenticated encryption modes (e.g., CBC without integrity), and lack of access controls on key usage. Any of those can lead to undetectable data modification or unauthorized decryption.
\n\nBest practices: (1) maintain a written Key Management Policy and a short key management runbook; (2) use envelope encryption and centralized KMS/HSMs; (3) enable and retain detailed audit logs; (4) implement least privilege and separation of duties for key operations; (5) rotate keys on a documented schedule and test key recovery quarterly; (6) collect and store evidence artifacts for audits. Automate enforcement where possible (IaC, policy-as-code) so configuration drift is minimized.
\n\nSummary: Meeting SC.L2-3.13.16 requires a practical combination of inventory, strong encryption (AES-256 GCM), hardened key storage (KMS/HSM), lifecycle processes (generation, rotation, recovery, destruction), logging, and documented evidence; for a small business, using cloud KMS with envelope encryption, TPM-backed disk encryption on endpoints, and clear policies/runbooks provides a repeatable, auditable implementation path that satisfies NIST SP 800-171 Rev.2 and CMMC 2.0 Level 2 expectations.
", "plain_text": "Encrypting Controlled Unclassified Information (CUI) at rest and managing the associated cryptographic keys is a core requirement of NIST SP 800-171 Rev.2 and CMMC 2.0 Level 2 (SC.L2-3.13.16); this post gives a practical, step-by-step implementation plan, real-world examples for a small business, specific technical recommendations, and audit-ready evidence to demonstrate compliance.\n\nOverview and key objectives\nThe objective of SC.L2-3.13.16 is to ensure CUI stored on disks, databases, filesystems, object stores, backups, and removable media is protected with strong encryption and that cryptographic keys are managed securely over their lifecycle. For small businesses that handle DoD-related CUI, this means: identifying all CUI at rest, applying FIPS-acceptable algorithms (e.g., AES-256), using hardened key storage (KMS or HSM), enforcing access controls and separation of duties for key usage, logging key operations, and maintaining key rotation/retirement processes with documented evidence.\n\nStep-by-step implementation (practical)\nStep 1 — Inventory and classification\nStart by inventorying where CUI resides: endpoints (laptops, mobile), servers (file shares, databases), cloud services (S3 buckets, object storage), backups, and removable media. Tag each asset with CUI scope and risk level. Produce a simple CSV or CMDB entry with columns: asset, owner, storage type, encryption status, key type (device TPM, KMS, HSM), and evidence pointer (config file, screenshot).\n\nStep 2 — Choose encryption and key storage models\nFor symmetric data protection, standardize on AES-256 in an authenticated mode (AES-GCM where available). Use envelope encryption: data encrypted with a data key (AES-256) and that data key encrypted (wrapped) by a long-lived master key stored in a Key Management System (KMS) or Hardware Security Module (HSM). For cloud: AWS KMS (customer-managed CMK) or CloudHSM, Azure Key Vault (with HSM-backed keys), GCP Cloud KMS. For on-prem: a FIPS 140-2/3 validated HSM or appliance, or an enterprise KMS that integrates with your applications via KMIP.\n\nStep 3 — Implement encryption for common asset types\nExamples for a small business: full-disk encryption on laptops with BitLocker (Windows) bound to TPM and MDM policy, FileVault on macOS, LUKS2 + TPM on Linux. For file/object storage, enable SSE-KMS (S3 with SSE-KMS) or client-side envelope encryption using your KMS. For databases: enable Transparent Data Encryption (TDE) integrated with your KMS or use application-layer encryption for particularly sensitive fields (PII, financial data). For backups, store only encrypted backup artifacts and escrow the keys securely.\n\nKey management lifecycle and controls\nDefine and document the lifecycle: key generation (use FIPS-validated RNG), distribution (never send plaintext keys in email), activation, rotation, compromise handling, archival, and secure destruction. Enforce least-privilege access to key policies: separate duties so that administrators who can create keys cannot unilaterally export master key material. Require dual control or split knowledge for key recovery and support key escrow mechanisms (e.g., split key shares stored in different secure locations).\n\nTechnical recommendations and examples\nTechnical specifics to implement: generate symmetric data keys of 256 bits, keep master keys at 3072-bit RSA or better (or ECC P-256/P-384) for wrapping if asymmetric is used. For AWS example: create a customer-managed CMK with automatic annual rotation disabled/enabled per policy, attach a least-privilege key policy granting only required IAM roles the kms:Encrypt/kms:Decrypt permissions, and record CloudTrail entries for each Encrypt/Decrypt/GenerateDataKey call as audit evidence. For on-prem, use an HSM with KMIP and ensure it is FIPS 140-2/3 validated; collect HSM certification number in your evidence package.\n\nOperational practices, logging, and evidence for auditors\nLog all key management events centrally (CloudTrail, SIEM) and retain logs per contract requirements (commonly 1–7 years depending on agreements). Create and keep artifacts for audits: key policies, KMS console screenshots, CLI audit outputs, rotation schedules, runbooks for key compromise, and periodic key use reports. For each CUI-bearing asset include configuration notes (e.g., BitLocker policy applied via Intune, LUKS header backup file hash stored in vault). These artifacts demonstrate the \"implementation\" and \"sustained operation\" reviewers look for under NIST/CMMC.\n\nReal-world small-business scenario\nScenario: a small contractor stores CUI in a PostgreSQL database hosted on AWS RDS and in S3 for document storage. Implementation: enable RDS encryption with a customer-managed CMK in AWS KMS (master key stored with AWS KMS, optionally backed by CloudHSM). Configure the application to use envelope encryption for sensitive columns prior to insertion so database backups contain encrypted fields. For S3, enable SSE-KMS with the same CMK. Document the architecture diagram, the CMK ARN, key policy JSON, rotation schedule, and export CloudTrail logs that show key usage before the assessment.\n\nRisks of non-implementation and common pitfalls\nFailing to encrypt CUI at rest or poorly managing keys creates high-impact risks: data exfiltration with readable CUI, contract termination, legal exposure, fines, and loss of DoD trust. Common pitfalls include storing keys on the same machine as encrypted data, insufficient rotation or testing of key recovery, using non-authenticated encryption modes (e.g., CBC without integrity), and lack of access controls on key usage. Any of those can lead to undetectable data modification or unauthorized decryption.\n\nCompliance tips and best practices\nBest practices: (1) maintain a written Key Management Policy and a short key management runbook; (2) use envelope encryption and centralized KMS/HSMs; (3) enable and retain detailed audit logs; (4) implement least privilege and separation of duties for key operations; (5) rotate keys on a documented schedule and test key recovery quarterly; (6) collect and store evidence artifacts for audits. Automate enforcement where possible (IaC, policy-as-code) so configuration drift is minimized.\n\nSummary: Meeting SC.L2-3.13.16 requires a practical combination of inventory, strong encryption (AES-256 GCM), hardened key storage (KMS/HSM), lifecycle processes (generation, rotation, recovery, destruction), logging, and documented evidence; for a small business, using cloud KMS with envelope encryption, TPM-backed disk encryption on endpoints, and clear policies/runbooks provides a repeatable, auditable implementation path that satisfies NIST SP 800-171 Rev.2 and CMMC 2.0 Level 2 expectations." }, "metadata": { "description": "Step-by-step guidance to encrypt Controlled Unclassified Information (CUI) at rest and implement key management practices to satisfy NIST SP 800-171 Rev.2 / CMMC 2.0 Level 2 (SC.L2-3.13.16).", "permalink": "/how-to-encrypt-and-manage-keys-for-cui-at-rest-step-by-step-implementation-to-meet-nist-sp-800-171-rev2-cmmc-20-level-2-control-scl2-31316.json", "categories": [], "tags": [] } }