How to Deploy AWS/GCP/Azure KMS for Controlled Cryptographic Keys to Meet NIST SP 800-171 REV.2 / CMMC 2.0 Level 2 - Control - SC.L2-3.13.10

This post explains how to deploy AWS KMS, Google Cloud KMS, or Azure Key Vault / Managed HSM to control cryptographic keys in a way that satisfies NIST SP 800-171 Rev.2 / CMMC 2.0 Level 2 control SC.L2-3.13.10 — including concrete configuration steps, commands, risk descriptions, and small-business scenarios for practical implementation.

What SC.L2-3.13.10 requires and the risk of not implementing it

SC.L2-3.13.10 requires that organizations establish and maintain cryptographic keys used to protect Controlled Unclassified Information (CUI) — that means keys must be generated, stored, accessed, rotated, and destroyed under controlled procedures that limit unauthorized disclosure or modification. If you fail to implement controlled key management you face loss of confidentiality and integrity of CUI, breach notifications, contract termination with DoD or federal partners, and potential regulatory penalties. Practically, an exposed or poorly controlled key can let an attacker decrypt backups, impersonate services, or corrupt stored data — all direct compliance failures and business-impacting events.

Choosing a cloud KMS strategy: managed KMS vs HSM-backed keys

Start by deciding whether your CUI requires FIPS-validated HSMs or whether a cloud-managed KMS is sufficient. NIST/CMMC expects cryptographic protection with assurances about key custodianship and protection; in many DoD contracts and NIST-focused environments you will want HSM-backed keys (AWS KMS with AWS CloudHSM or AWS KMS multi-Region keys, GCP keys with protection-level HSM, Azure Managed HSM) or BYOK with attestation. For small businesses, a common practical approach is: use cloud-managed KMS for most workloads, use HSM-backed or imported keys for highly sensitive CUI, and document the rationale and controls in your System Security Plan (SSP). Key selection criteria: FIPS 140-2/3 validation, separation of duties for key management, key origin (generated vs imported), and integration support with services (storage, DBs, secrets managers).

AWS KMS practical details

AWS options: KMS customer master keys (CMKs) — symmetric or asymmetric — and AWS CloudHSM for dedicated HSMs. Practical steps: create a CMK with FIPS-backed origin or import your key material (BYOK) via the KMS import key workflow; enable automatic rotation for symmetric CMKs (aws kms enable-key-rotation --key-id ); define a strict key policy and supplemental IAM policy granting minimum privileges; use grants for limited-time operations (aws kms create-grant). Log all KMS API calls with CloudTrail (ensure management events logged) and push logs to a separate account or S3 with object lock for retention. Example commands:

aws kms create-key --description "CUI CMK" --key-usage ENCRYPT_DECRYPT --origin AWS_KMS

aws kms enable-key-rotation --key-id arn:aws:kms:...

GCP Cloud KMS practical details

GCP Cloud KMS supports software or HSM protection levels and lets you use CMEK for many services. Create a key ring and a key with a rotation period and protection level HSM if required:

gcloud kms keyrings create my-ring --location global
gcloud kms keys create my-key --keyring my-ring --location global --purpose encryption --rotation-period 2592000s --protection-level hsm

Azure Key Vault and Managed HSM practical details

Azure offers Key Vault (software/HSM with multi-tenant HSM) and Managed HSM (single-tenant, dedicated) with RBAC and soft-delete/purge protection. Create a key with HSM protection using the Azure CLI:

az keyvault create -n kv-prod -g rg --location eastus
az keyvault key create --vault-name kv-prod -n cuikey --protection hsm --kty RSA

Step-by-step implementation checklist

Actionable steps you can follow: 1) Inventory CUI and map where it is stored or processed, 2) Define key types per environment (prod CUI -> HSM-backed CMK; dev/test -> software KMS), 3) Create keys with explicit policies and rotation settings, 4) Apply least-privilege IAM/RBAC: separate "key administrators" from "key users", require MFA and break-glass procedures, 5) Use envelope encryption APIs to avoid direct exposure of plaintext data keys in application logs, 6) Enable logging/alerting (CloudTrail / Audit Logs / Diagnostic Settings) and forward to SIEM, 7) Implement secure key destruction and retention policies, 8) Document all procedures, key inventories, and attestations in the SSP and evidence repository. Technical specifics: require "kms:Encrypt" and "kms:Decrypt" only where needed; use aws kms generate-data-key --key-id to perform envelope encryption; enforce key policies that deny root account access for key deletion without an owner-approved process.

Real-world small business scenarios

Scenario A — small DoD subcontractor with limited budget: use cloud-managed KMS for everyday CUI and purchase one Managed HSM or enable HSM-protection for only the most sensitive keys (e.g., signing key for CI). Keep key inventory and chain of custody documented; use CloudTrail and a low-cost Log Analytics workspace for centralized logging. Scenario B — SaaS provider storing CUI across customers: use per-customer CMKs where practical (AWS multi-Account or GCP per-project CMEK) to limit blast radius and show auditors distinct key ownership boundaries. Scenario C — backup encryption: integrate KMS with backup services (e.g., AWS Backup with CMK, Azure Backup with Key Vault) and manage rotation/retention so that decommissioned keys are archived and retained for forensics, with documented destruction procedures when retention ends.

Compliance tips and best practices

Keep evidence ready: key creation timestamps, key policies, rotation schedules, access logs, HSM certificates, and any BYOK attestation. Implement separation of duties and dual control for key deletion or key import operations — e.g., require two administrators or a ticketed, logged approval before a key is destroyed. Regularly perform access reviews and automated alerts on anomalous key usage. Validate cryptographic modules against FIPS 140-2/3 where required and include those certificates in your artifacts. Finally, include key lifecycle steps in your incident response plan (revocation, re-encryption, emergency access) and test them in tabletop exercises so re-key and re-encryption are operationally feasible within SLAs.

Summary: To meet SC.L2-3.13.10 you must deploy KMS/HSM-backed key management with documented procedures for key creation, access control, rotation, logging, and destruction. Use the cloud provider features — AWS KMS + CloudHSM, GCP Cloud KMS HSM, or Azure Key Vault / Managed HSM — apply least privilege, envelope encryption, and strong logging, and maintain an evidence bundle in your SSP. For small businesses, a hybrid approach (cloud-managed KMS for most keys, HSM/BYOK for the crown jewels) balances cost and compliance while providing a demonstrable control posture for auditors and contracting officers.