Key Management
Key management covers the full lifecycle of cryptographic keys: generation, storage, distribution, use, rotation, and destruction, with policy and audit at every step.
Definition
Key management is the disciplined operation of cryptographic key material across its lifecycle, ensuring keys are generated with sufficient entropy, stored in protected hardware, used only for their intended purpose, rotated, and destroyed verifiably.
Context and scope
Use it whenever encryption or signing keys protect data, and treat it as a first-class system rather than a configuration detail.
Common misconceptions
- Key management means storing keys in a vault; lifecycle, access policy, and destruction matter just as much
- One key can serve encryption, signing, and multiple environments safely
- Deleting a key row removes the key; hardware-backed destruction needs verification
Anti-patterns
- Embedding keys in source code, container images, or environment variables committed to Git
- Giving applications export access to master keys
- Sharing a single key across tenants, regions, and environments
Related concepts
Related examples
Authoritative source
Keys have a lifecycle
A key is not a string you generate once. It is created, activated, used, possibly suspended, rotated, and eventually destroyed. Each state has requirements: entropy at generation, hardware protection at rest, least privilege at use, overlap during rotation, and proof at destruction. Auditors care about all of them.
How it works
Mature designs use a hierarchy. A root key stays in an HSM, backs a set of key encryption keys per region or service, and those wrap data keys. Applications never see root material; they call a KMS with an identity and an operation, and the KMS enforces policy and writes an audit record.
Access policy separates roles: security engineers manage key policy, services use keys, auditors read logs, and nobody has both use and export rights. Rotation is scheduled and versioned, with old versions retained for decryption but not for new encryption. Destruction is delayed and dual-controlled to avoid accidental permanent data loss.
When to use it
Any system with encryption at rest, token signing, certificate issuance, or field-level encryption needs key management. Regulated environments often require FIPS 140-3 validated modules and customer-managed keys. Small projects can start with a managed KMS rather than building a hierarchy.
Trade-offs
A central KMS improves control but adds latency and a single point of failure; multi-region replicas and short caching mitigate both. Customer-managed keys increase isolation but shift operational burden to the customer. Hardware modules are slower and costlier than software keys. Every simplification trades away some auditability.
Example and misconceptions
A team stores an AES key in an environment variable and uses it for every tenant. When the variable leaks through a crash dump, all data is exposed and rotation requires re-encrypting everything. A KMS-backed hierarchy would have limited the leak to one wrapped key version.
The common misconception is that key management equals encryption. Encryption is one use; signing, attestation, and certificate issuance depend on the same discipline.
Related concepts: Key Rotation, Envelope Encryption, and Secret Management.