PKI and Key Management for CMMC

Word count: ~2,010

Specificity markers hit:

1. ✅ NIST/CMMC control references (SC.L2-3.13.8, SC.L2-3.13.10, SC.L2-3.13.11, IA.L2-3.5.10, SC.L2-3.13.15)
2. ✅ Cost/time estimate (HSM costs, CA software costs, rotation timelines)
3. ✅ Tool/product names (Microsoft ADCS, HashiCorp Vault, AWS KMS, Azure Key Vault, YubiHSM)
4. ✅ Common mistakes
5. ✅ Decision point (on-prem CA vs cloud KMS; HSM vs software keys)

---

PKI and Key Management for CMMC

Every CMMC encryption requirement has a key on the back end. The encryption protecting CUI at rest is only as strong as the protection on the key that locks it. The TLS certificate authenticating your server is only as trustworthy as the Certificate Authority that issued it. The digital signature proving a document's authenticity is only meaningful if the private key behind it is protected.

Key management is what most organizations underinvest in when building toward CMMC. They get the encryption right and leave the keys poorly managed. This article covers what CMMC actually requires for PKI and key management, how to build a practical key management structure, and what assessors look for.

What CMMC Requires

Several controls address cryptographic key management directly or implicitly:

SC.L2-3.13.8 — Implement cryptographic mechanisms to prevent unauthorized disclosure of CUI at rest. The key isn't just "use encryption" — it's "protect the mechanism," which includes protecting the keys.

SC.L2-3.13.10 — Employ cryptographic key establishment and management through approved methods. This is the most direct key management control. "Approved methods" refers to NIST SP 800-57 (Recommendation for Key Management), which covers key generation, distribution, storage, use, rotation, and destruction.

SC.L2-3.13.11 — Implement cryptographic mechanisms to prevent unauthorized disclosure of CUI during transmission. Same as above — the keys that protect in-transit encryption must themselves be protected.

SC.L2-3.13.15 — Control and monitor the use of mobile code, and protect communications using cryptographically authenticated sessions. Session authentication depends on certificates and keys being properly managed.

IA.L2-3.5.10 — Employ cryptographic mechanisms to authenticate organizational users, processes, or devices when required. Certificate-based authentication and FIDO2/WebAuthn both use asymmetric key pairs. Those keys must be managed per an approved method.

The practical implication: you need documented key management procedures that cover the full lifecycle of every key used to protect CUI.

What PKI Does for Your CMMC Environment

Public Key Infrastructure (PKI) is the system for issuing, distributing, validating, and revoking digital certificates. Certificates are the mechanism by which public keys get bound to identities — a server certificate says "this public key belongs to server.company.com"; a user certificate says "this public key belongs to user@company.com."

In a CMMC environment, PKI shows up in: - TLS certificates on servers handling CUI (web servers, VPN concentrators, email gateways) - User certificates for S/MIME email encryption, PIV/CAC smart card authentication, or certificate-based VPN authentication - Device certificates for 802.1X network access control and VPN machine authentication - Code signing certificates if you deliver software under DoD contracts - Document signing certificates for authenticated document delivery

Every certificate comes from a CA. For internal certificates, you run your own CA. For external (internet-facing) certificates, you use a trusted public CA.

Building Your PKI

Option 1: Microsoft Active Directory Certificate Services (ADCS)

If your organization runs Active Directory, ADCS is the natural internal CA. It integrates with AD groups for auto-enrollment (machines and users automatically get certificates without manual process), publishes revocation information via LDAP CRL or OCSP, and is free with Windows Server licensing.

A well-designed ADCS setup for a small defense contractor: - Offline root CA: a Windows Server (or VM) that's kept powered off except when issuing subordinate CA certificates. Protects the root key — if it's never connected to the network, it can't be compromised remotely. - Online issuing CA: the CA that users and devices contact day-to-day for certificate issuance. This one stays online. - Certificate templates: define what gets issued (user authentication, computer authentication, VPN, email) and to whom.

The offline root CA is the key management control. The root key is the most sensitive key in your PKI — it signs the subordinate CA certificate, which in turn signs all user and device certificates. Protecting the root key by keeping the root CA offline and physically secured addresses SC.L2-3.13.10.

Setup time for a basic two-tier ADCS hierarchy: 16–24 hours for an experienced Windows admin. Maintenance is low — the offline root CA is powered on a few times per year to renew subordinate CA certificates. The online issuing CA handles day-to-day operations automatically.

Option 2: HashiCorp Vault

For organizations with mixed or cloud-first environments, HashiCorp Vault (open source, with enterprise options) provides secrets management including PKI. Vault can act as an intermediate CA (with your existing root CA signing its certificate), issue short-lived certificates, and integrate with Kubernetes, cloud platforms, and on-premises systems.

Vault's PKI secrets engine issues certificates with very short lifetimes (hours to days), which reduces the risk associated with certificate compromise. If a certificate is stolen, it expires quickly. This is a more advanced approach — it requires more infrastructure and operational discipline — but it's increasingly used for machine-to-machine authentication in complex environments.

HashiCorp Vault Community Edition is free. Vault Enterprise (which adds HSM support, disaster recovery replication, and detailed audit logging) starts at roughly $10,000–$30,000/year depending on usage.

The decision point: ADCS vs cloud KMS: If you're a Windows shop with on-premises systems and a small team, ADCS is the simpler choice. It's already included in your Windows Server licensing, your AD admins know it, and it handles the common use cases (workstation certs, user certs, VPN auth) with minimal configuration. If you're cloud-first, using GCC High or AWS GovCloud, or need to automate certificate issuance for containerized workloads, cloud KMS services (Azure Key Vault, AWS Private CA at ~$400/month per CA) integrate better with your environment.

Hardware Security Modules: When You Need One

A Hardware Security Module (HSM) is a physical device that stores cryptographic keys in tamper-resistant hardware. The key never leaves the HSM in plaintext — operations using the key (sign, decrypt, wrap/unwrap) happen inside the device.

FIPS 140-2 Level 3 HSMs (the threshold relevant for CMMC) provide protection against physical tampering — if someone tries to extract the key, the device destroys it.

For CMMC, HSMs are specifically relevant for: - Protecting CA root and signing keys (the most sensitive keys in your PKI) - Supporting SC.L2-3.13.10 documentation — using an HSM for key storage is the clearest way to demonstrate "approved key establishment and management" - Meeting FedRAMP requirements for cloud services you operate (if relevant)

Small organizations don't necessarily need a full-blown enterprise HSM. Options at different price points: - YubiHSM 2 (~$650) — USB HSM for small deployments. FIPS 140-2 Level 3 validated. Suitable for protecting CA signing keys on a small internal CA. - Thales Luna Network HSM — enterprise-grade, rack-mounted. $20,000–$50,000 range. For organizations running high-volume PKI or requiring multi-party authentication for key access. - Cloud HSM — AWS CloudHSM (~$1.60/hour, roughly $1,150/month for a dedicated HSM cluster) or Azure Dedicated HSM (~$1.65/hour). Fully managed HSM infrastructure, no hardware to maintain.

For most small-to-mid defense contractors, the relevant question is: are you running an internal CA, and can you protect its signing key? A YubiHSM or equivalent network-attached HSM for the offline root CA is a cost-effective and assessor-friendly answer. It demonstrates a clear physical control on the most critical key in your environment.

Key Lifecycle Management

NIST SP 800-57 covers the full key lifecycle. For CMMC documentation purposes, your key management policy needs to address each phase:

Generation — Keys must be generated using FIPS-validated RNG (random number generator) in a FIPS-validated cryptographic module. If you're generating keys on a workstation using a properly configured FIPS-validated library (Windows CNG, OpenSSL FIPS module), this is typically satisfied automatically.

Distribution — How keys move to systems that need them. Certificate-based distribution (PKI) is the standard approach. Private keys should never travel over untrusted networks in plaintext. Key wrapping (encrypting a key with another key for transport) using a FIPS-validated module is acceptable.

Storage — Private keys must be stored with access control. At minimum: encrypted storage (OS-level, PKCS#12 file with strong passphrase), restricted permissions (only the service or user that needs the key), no backup to unprotected locations.

Use — Cryptographic operations should occur in the protected module (software or hardware). Log key usage for privileged or sensitive keys.

Rotation — Keys should be rotated before they reach their crypto period (NIST 800-57 defines these by algorithm and usage). Practical minimums: - TLS server certificates: Annually (most CA practices; Let's Encrypt certificates are 90-day by design) - User authentication certificates: Annually to every 2 years - Encryption keys for data at rest: Annually, or upon suspected compromise - CA signing keys: Every 5–10 years depending on key size and usage

Destruction — When a key is retired, it must be securely destroyed (overwritten with random data, or the storage media sanitized per NIST 800-88). Document the destruction with date, method, and key identifier.

Common Mistakes in Key Management

Mistake 1: Keys in source code or configuration files. API keys, database credentials, and encryption keys stored in git repositories or plaintext config files are a significant finding. Use secrets management (HashiCorp Vault, AWS Secrets Manager, Azure Key Vault) to store credentials and reference them at runtime.

Mistake 2: Shared private keys across multiple systems. Generating one certificate/key pair and installing it on multiple servers. If one server is compromised, all servers that share the key are compromised. Issue unique certificates to each system.

Mistake 3: No documented key rotation schedule. Keys should be rotated proactively, not just when there's a suspected compromise. If you can't tell an assessor when your encryption keys were last rotated and when they'll be rotated next, you have a documentation gap under SC.L2-3.13.10.

Mistake 4: Root CA online. The root CA should not be regularly accessible on the network. An online root CA is a target — if it's compromised, the attacker can issue fraudulent certificates that are trusted throughout your environment. The offline root CA pattern exists specifically to prevent this.

What Your Assessor Expects

For SC.L2-3.13.10 specifically, assessors look for:

• A documented key management policy that covers generation, distribution, storage, use, rotation, and destruction
• Evidence that the policy is followed (rotation logs, certificate inventory with issuance dates, access control documentation for key storage)
• Identification of which FIPS-validated module is used for key operations

For IA.L2-3.5.10 (cryptographic authentication): - Documentation of PKI infrastructure (CA hierarchy, certificate templates) - Certificate inventory with issuance and expiration dates - Evidence that expired certificates are not in active use

For assessors in organizations running internal PKI: - Show the CA hierarchy (offline root, online issuing CA) - Show that the root CA private key is protected (HSM or offline storage) - Show the certificate revocation mechanism (CRL/OCSP) is functioning

The evidence package for key management typically includes: key management policy document, CA hierarchy diagram, certificate inventory (exported from your CA), key rotation schedule, and if using an HSM, the FIPS validation certificate for the device.

---

For how PKI certificates are used in TLS and network encryption, see Network Encryption for CMMC Compliance. For the asymmetric cryptography that underlies PKI, see Asymmetric Encryption for CMMC: Public-Key Cryptography Explained.

Got specific questions about CMMC? Our expert is available around the clock — no waiting, no sales pitch.

Got Questions? Ask our CMMC Expert →

Prefer email? Reach us at ix@isegrim-x.com