5 Cryptographic Key Management
Learn how to plan, generate, protect, recover, rotate, revoke, and destroy cryptographic keys while preserving security and data availability.
Why key management matters
Cryptographic security depends on protecting keys throughout their lifecycle, not only on using strong algorithms. A key that is exposed, lost, misused, or kept longer than necessary can undermine the security it was intended to provide. Key management includes planning, handling, protecting, and retiring keys and related information.
Plan and identify keys
Before creating a key, define its purpose, authorized users or services, protection requirements, and expected lifetime. Use separate keys for different purposes; for example, do not reuse a data-encryption key for digital signatures.
Maintain a containing each key’s identifier, type, purpose, owner, location, status, creation date, and rotation or expiration schedule. Do not put secret key material in the inventory.
Not every cryptographic mechanism uses a key. A such as SHA-256 does not use a key, whereas a , symmetric encryption, and a digital-signature system use key material and therefore need lifecycle controls.
Generate keys securely
Generate keys with a , using a trusted cryptographic library or cryptographic module. Choose an appropriate algorithm and key size for the key’s purpose and the protection period required. Never create keys by typing random-looking characters, reusing passwords, or modifying another key.
Where practical, generate sensitive keys inside a or managed key-management service so raw key material need not leave the protected system. In public-key cryptography, protect the private key; the corresponding public key can generally be distributed openly.
Store and use keys safely
Store keys in a key vault, hardware security module, or other protected key-management system. Do not store them in source code, version control, container images, or ordinary configuration files. Keep keys separate from the data they protect.
uses a to encrypt data and a separately protected to encrypt or wrap the DEK. For example, a storage service can ask a key-management service to create a DEK and encrypt it under a KEK. The service stores the encrypted data and wrapped DEK together, while the KEK remains separately protected; access to the KEK is restricted and audited.
Apply by giving each person, service, or workload only the key permissions it needs. Prefer systems that perform cryptographic operations without exposing raw keys to application code. Protect access with strong authentication, access controls, audit logs, and monitoring. Avoid placing keys in logs, command histories, or other locations where they might be copied inadvertently.
Back up and recover keys
Back up a key only when recovery is necessary and permitted by its purpose and policy. Losing an encryption key may make its data permanently unreadable, so recovery planning matters. Copying a private signing key creates another point of exposure and may weaken control over who can sign; avoid backing up or escrowing such keys unless applicable policy explicitly allows it.
Protect permitted backups with strong encryption, separate access controls, and secure, preferably independent storage. Restrict who can restore them, log backup and recovery actions, and regularly test restoration procedures. A backup that cannot be securely restored, or that exposes the key, is not a safe recovery plan.
Rotate keys with a migration plan
A key’s is the period during which it is authorized for use. Set rotation rules according to the key’s purpose, the sensitivity of the data, usage volume, the threat model, and system requirements. Rotate keys on schedule, when usage limits are reached, when personnel or systems with access change, or when compromise is suspected. Automating rotation can reduce operational mistakes.
Plan how systems will transition from the old key to the new one. For encrypted data, a system may use the new key for new writes while temporarily retaining the old key for reads. Replacing a KEK often requires re-wrapping DEKs; replacing a DEK for existing data generally requires re-encrypting that data. Keep the old key only as long as needed for authorized recovery or access, and track which key version protects each item.
Revoke, retire, and destroy keys
If a key is compromised, promptly stop or restrict its use, identify affected data and systems, and create replacement keys. Update dependent services and investigate possible misuse. Revocation limits future use, but cannot undo exposure or make copies already obtained by an attacker disappear.
For a compromised certificate, notify the issuing certificate authority and use the applicable revocation mechanism. Systems relying on the certificate must check its status. For other keys, disable or revoke access through the key-management system and update every dependent application or service.
When a key is no longer needed, securely destroy its active copies and any backups according to retention and recovery requirements. Keep only non-secret records needed for audit or to interpret historical data. Destruction should make the key unavailable for future use, including through recoverable backups, once their approved retention period ends.
Connect the lifecycle controls
Manage keys through a planned lifecycle: identify each key and its purpose, generate it with trusted randomness, store and use it under restricted access, back it up only when justified, rotate it with a migration plan, and revoke or destroy it when necessary. Inventory, auditing, and tested recovery procedures help preserve both key confidentiality and the availability of protected data.