# Cryptographic Key Management
Cryptographic key management is the operational discipline of generating, distributing, storing, rotating, revoking, and destroying the cryptographic keys that encryption depends on. Encryption without key management is a lock without control over who has the key. The strongest encryption algorithm (AES-256, RSA-4096) provides zero protection if the keys are stored in plaintext on a shared drive, never rotated, accessible to unauthorized users, or unrecoverable when needed.
Key management is the operational layer that makes encryption functional. The encryption algorithm provides the mathematical protection. Key management provides the operational infrastructure: who can access the key, where the key is stored, how often the key changes, what happens when a key is compromised, and how keys are retired when they are no longer needed.
The failure mode is consistent: organizations invest in encryption technology and neglect key management. The database is encrypted with TDE (Transparent Data Encryption), but the encryption key is stored in the same directory as the database. The cloud storage is encrypted, but the provider manages the key (meaning the provider can decrypt the data). The VPN uses AES-256, but the pre-shared key has not changed in three years. Each is an encryption deployment that key management failures render partially or fully ineffective.
Every cryptographic key passes through a defined lifecycle:
Generation. Keys must be generated using cryptographically secure random number generators (CSPRNGs). Keys generated from predictable sources (timestamps, sequential numbers, weak random generators) can be reproduced by an attacker who understands the generation method. HSMs (Hardware Security Modules) and cloud KMS platforms provide certified random number generation that meets NIST SP 800-90A requirements.
Key generation also includes selecting the appropriate algorithm and key length: AES-256 for symmetric encryption, RSA-2048 minimum (RSA-4096 recommended) or ECC P-256/P-384 for asymmetric encryption, and post-quantum algorithms (ML-KEM, ML-DSA) for systems requiring long-term protection against quantum computing threats.
Distribution. Keys must be distributed to the systems and users that need them through secure channels. Symmetric keys cannot be transmitted in plaintext (an intercepted key compromises all data encrypted with it). Asymmetric key pairs distribute the public key openly and protect the private key. Key distribution protocols (Diffie-Hellman key exchange, TLS handshake, envelope encryption) address the distribution problem without transmitting symmetric keys in the clear.
In cloud environments, envelope encryption is the standard pattern: data is encrypted with a data encryption key (DEK), and the DEK is encrypted with a key encryption key (KEK) managed by the KMS. The encrypted DEK is stored alongside the encrypted data. Only the KMS can decrypt the DEK, which then decrypts the data. This pattern enables encryption at scale (each data object has its own DEK) while centralizing key management (all DEKs are protected by a single KEK hierarchy).
Storage. Keys must be stored in a manner that protects their confidentiality and integrity. Key storage options, ordered from strongest to weakest:
Hardware Security Modules (HSMs): purpose-built, tamper-resistant hardware devices that store keys in a secure enclave. Keys generated in an HSM can be configured to never leave the HSM (the HSM performs cryptographic operations internally without exporting the key material). HSMs meet FIPS 140-2 Level 3 or Level 4 certification requirements. Cloud HSM services (AWS CloudHSM, Azure Dedicated HSM, Google Cloud HSM) provide managed HSM infrastructure.
Cloud KMS (Key Management Service): managed key storage and cryptographic operations provided by cloud platforms (AWS KMS, Azure Key Vault, GCP Cloud KMS). Cloud KMS stores keys in software-protected or HSM-backed storage (depending on the service tier). Cloud KMS provides centralized key management with API-based access, automatic rotation, and audit logging.
Software-based key stores: key material stored in encrypted files, databases, or application-level key management. Software key stores are easier to deploy than HSMs but provide weaker protection because the keys exist in software and can be extracted by an attacker who compromises the system.
Plaintext storage: keys stored in configuration files, environment variables, source code, or documentation in plaintext. This is not key management. It is key abandonment. A key stored in plaintext is available to anyone who can access the storage location.
Rotation. Keys must be rotated (replaced with new keys) on a defined schedule and immediately after suspected compromise. Rotation limits the impact of key compromise: if a key is compromised, the data encrypted with that key is exposed, but data encrypted with the new key after rotation is protected.
Rotation frequency depends on the key's risk exposure and the data's sensitivity. Recommended rotation schedules:
| Key Type | Rotation Frequency | |----------|-------------------| | Data encryption keys (DEKs) | 90 days to 1 year | | Key encryption keys (KEKs) | 1 to 2 years | | TLS certificates | 90 days (Let's Encrypt default) to 1 year | | SSH keys | 6 months to 1 year | | Service account API keys | 90 days | | Root CA keys | 5 to 10 years (with offline storage) |
Automated rotation (supported by cloud KMS platforms and PAM systems) eliminates the operational burden of manual rotation and ensures rotation occurs on schedule regardless of personnel changes or workload.
Revocation. When a key is compromised or no longer needed, it must be revoked: marked as invalid so that systems no longer accept it for cryptographic operations. Certificate revocation uses Certificate Revocation Lists (CRLs) or the Online Certificate Status Protocol (OCSP). Key revocation in KMS platforms disables the key, preventing further cryptographic operations.
Revocation must be timely. A compromised key that is not revoked for 48 hours provides the attacker 48 hours of access to data encrypted with that key. Automated revocation triggered by compromise detection (a key exposed in a public repository, a certificate detected on an unauthorized server) reduces the window.
Destruction. When a key reaches end-of-life (the data it protected has been re-encrypted with a new key, or the data itself has been destroyed), the key must be securely destroyed: overwritten in memory, deleted from the key store, and logged as destroyed. HSMs provide certified key destruction (the key material is zeroized within the tamper-resistant module). Software key stores require secure deletion procedures that overwrite the key material rather than simply deleting the file reference.
Centralized KMS. All keys are managed through a single key management system that provides generation, storage, rotation, access control, and audit logging. Centralized KMS is the standard for cloud environments (AWS KMS, Azure Key Vault, GCP Cloud KMS) and for organizations that need unified key governance across multiple applications and infrastructure.
Hierarchical key structure. Keys are organized in a hierarchy: root keys protect key encryption keys, key encryption keys protect data encryption keys, and data encryption keys protect data. The hierarchy limits the blast radius of key compromise (compromising a DEK exposes one data object, not the entire key hierarchy) and simplifies rotation (rotating a KEK does not require re-encrypting all underlying data, only re-encrypting the DEKs with the new KEK).
Separation of duties. Key management roles must be separated: the administrator who generates keys should not be the same person who uses them, and neither should be the same person who audits key usage. HSM configurations enforce separation through role-based access: the HSM Security Officer initializes the module, the Crypto Officer manages keys, and the Auditor reviews logs. No single role has complete control.
Bring Your Own Key (BYOK) and Hold Your Own Key (HYOK). For cloud environments where data sovereignty requires customer control over encryption keys. BYOK imports a customer-generated key into the cloud provider's KMS (the key is in the provider's infrastructure but was generated by the customer). HYOK keeps the key entirely in the customer's HSM, with the cloud provider calling the customer's HSM for each cryptographic operation (the key never enters the provider's infrastructure).
CDA's Sovereign Data Protocol (SDP) position: "Your data lives where you decide. Period." For Restricted data, HYOK provides the strongest sovereignty guarantee because the cloud provider never possesses the key material. For Confidential data, BYOK or customer-managed keys in the provider's KMS provide acceptable sovereignty with lower operational complexity.
An organization that deploys AES-256 encryption with keys stored in plaintext configuration files has not implemented encryption in any meaningful sense. The encryption algorithm is strong. The key management is absent. An attacker who accesses the configuration file has the key and can decrypt all data. Key management is the difference between "we encrypt our data" (a marketing statement) and "our data is cryptographically protected" (an operational reality).
Key management is explicitly required by compliance frameworks. PCI DSS Requirement 3.6 (Cryptographic Key Management) specifies requirements for key generation, distribution, storage, rotation, retirement, and destruction. NIST SP 800-57 (Recommendation for Key Management) provides comprehensive key management guidance referenced by multiple frameworks. ISO 27001 A.8.24 (Use of Cryptography) requires a cryptographic key management policy. HIPAA requires that ePHI encryption keys be managed with appropriate safeguards.
Auditors examine key management as a distinct control set: are keys generated securely? Where are they stored? What is the rotation schedule? Who has access to key material? Are key lifecycle events logged? An organization that encrypts data but cannot answer these questions has a key management finding.
The transition to post-quantum cryptography requires crypto-agility: the ability to migrate encryption algorithms and key types without redesigning the entire cryptographic infrastructure. Organizations with centralized key management (KMS with API-based access) can migrate by updating the KMS configuration and re-encrypting data with new algorithms. Organizations with decentralized, application-embedded key management must modify every application individually. Centralized key management is a prerequisite for practical post-quantum migration.
Key management sits in the DPS (Data Protection and Sovereignty) domain of the Planetary Defense Model. DPS is the geological core: the innermost layer protecting the organization's data. Key management is the mechanism that determines whether the geological vault is locked (proper key management) or propped open (keys stored in plaintext, never rotated, accessible to unauthorized users).
CDA's Sovereign Data Protocol (SDP) treats key management as the operational expression of data sovereignty. Encryption is the technology. Key management is the governance. Sovereignty requires both: the data is encrypted, and the organization controls the keys. If a third party controls the keys, the third party controls the data, regardless of what the contract says.
DPS-H03 (Key Management Hardening, 24 estimated hours) addresses key management as a dedicated hardening mission: implement HSMs or cloud KMS for critical key material, automate key rotation, audit access to key management systems, develop crypto-agility plans for post-quantum migration, and establish separation of duties for key management roles.
The interaction with IAT is direct: PAM controls govern who can access key management systems. The key management administrator's credentials must be vaulted, JIT-provisioned, and session-recorded through PAM, because the key management administrator can decrypt any data the keys protect. Compromising the key management administrator is functionally equivalent to compromising the data itself.
Word count: 1,958