Key management with KMS and HSM, built for agility
The lifecycle of a cryptographic key (generation, storage, rotation, revocation, destruction) done with KMS and HSMs, and architected so algorithms can change without rewrites.
What to implement
Manage keys through their full lifecycle in a KMS, generate and store high-value keys in HSMs (FIPS 140-3 validated), enforce separation of duties and least privilege on key access, rotate and version keys automatically, log every key operation, and abstract crypto behind an agility layer so algorithms (including future post-quantum ones) can be swapped without touching application code.
Encryption is only as strong as the management of its keys. A leaked or poorly controlled key nullifies otherwise perfect cryptography. A key management system (KMS) centralizes the lifecycle; hardware security modules (HSMs) provide tamper-resistant generation and storage so private keys never exist in plaintext outside the module.
The key lifecycle
- Generation: create keys with a strong RNG inside the HSM/KMS; high-value keys should never be generated in application memory.
- Distribution / use: expose keys through the KMS API for encrypt/decrypt/sign operations; ideally the key never leaves the boundary (the operation comes to the key, not the key to the caller).
- Storage: root and high-value keys in an HSM; envelope encryption for data keys (a KMS-held key encrypts per-object data keys).
- Rotation: rotate on a schedule and on suspicion of compromise; version keys so old ciphertext stays decryptable while new writes use the new key.
- Revocation: be able to disable a key immediately if compromised.
- Destruction: securely destroy retired keys per policy (crypto-shredding data by destroying its key).
Controls around keys
- Separation of duties: split key custodianship; no single person controls a key end to end. Use dual control / M-of-N for the most sensitive operations.
- Least privilege on key access: tightly scope which principals can use which key for which operation, via KMS key policies.
- FIPS 140-3 validated HSMs for keys that require assurance or compliance.
- Comprehensive logging: every key use, admin action, and policy change auditable (e.g. to your SIEM).
- No hardcoded keys: never in source, config files, or container images; pull from the KMS/secrets manager at runtime.
Hardcoded and long-lived keys
Keys committed to a repo or baked into an image are the classic breach. So are keys that never rotate: one leak then exposes years of data. Centralize in a KMS, pull at runtime, and rotate automatically with versioning so rotation doesn't break existing ciphertext.
Build a crypto-agility layer
Applications should call a key/crypto service by key reference and operation, not embed algorithm choices. When the algorithm must change (a weakness is found, or post-quantum ML-KEM/ML-DSA become required), you rotate to a new key with the new algorithm behind the same interface. Without this abstraction, a PQC migration means editing and redeploying every application that touches crypto.
Post-quantum considerations
- Inventory keys and algorithms into a CBOM; know where quantum-vulnerable RSA/ECC keys are used and what they protect.
- Confirm your HSM/KMS roadmap supports post-quantum algorithms (ML-KEM, ML-DSA) before you need them.
- Prioritize migrating keys that protect long-lived confidentiality (harvest-now-decrypt-later exposure) and long-lived signing roots.
- The agility layer above is what makes the eventual swap a rotation rather than a rebuild.
Key management evidence
Maintain: an inventory of keys with owner, purpose, algorithm, and rotation date; confirmation that high-value keys reside in validated HSMs; KMS key-policy review showing least privilege and separation of duties; rotation compliance; a scan result showing no hardcoded secrets in code/images; and a CBOM feeding the PQC roadmap.