Key management

The reference framework is NIST SP 800-57 Part 1 Rev. 5 (May 2020). It models a key as moving through states such as pre-activation, active, suspended, deactivated, compromised and destroyed, and ties each transition to an authorised action. Central to it is the cryptoperiod: the time span during which a key may be used, split for symmetric keys into an originator-usage period (when it may protect new data) and a recipient-usage period (when it may still decrypt or verify old data). Cryptoperiods are chosen from the algorithm's strength, the volume of data protected, the exposure of the key and the cost of re-keying, not from a fixed calendar rule.

Architecturally, almost every large system uses a key hierarchy with envelope encryption. Data is encrypted with data-encryption keys (DEKs), which are stored alongside the data only in wrapped form, encrypted under a key-encryption key (KEK) that never leaves a hardware security module or cloud KMS. Rotating the KEK then means re-wrapping small DEKs rather than re-encrypting terabytes, and destroying a KEK renders all data under it unrecoverable, which is the basis of crypto-shredding for deletion. HSMs are validated under FIPS 140-3 (security levels 1 to 4, levels 3 and 4 adding physical tamper response and identity-based authentication), and applications reach them through PKCS#11, KMIP (OASIS) or a cloud provider API. Cloud variants range from provider-managed keys through customer-managed keys to BYOK and hold-your-own-key models, differing in who can technically use the key, which matters for GDPR transfer assessments and sovereignty requirements.

Controls for high-value keys include split knowledge and dual control (no single person can reconstruct or use the key, often implemented as M-of-N key shares, for example with Shamir secret sharing), documented key ceremonies with witnesses and video for CA root keys, separation of the key custodian role from system administration, and tamper-evident audit logs of every use. Backup and escrow must be designed explicitly: a signing key should generally not be escrowed, since copies weaken non-repudiation, whereas a decryption key for archived data must be recoverable or the data is lost.

Audits usually map these practices to ISO/IEC 27001:2022 Annex A control 8.24 (use of cryptography), which expects rules for the whole key life cycle, and to PCI DSS requirement 3 for cardholder data. Frequent real-world failures are keys hard-coded in source code or container images, keys stored on the same host or volume as the data they protect, no inventory of which keys and certificates exist (so nobody notices when one expires or leaks), and no tested procedure for emergency rotation. The post-quantum migration has made a cryptographic inventory a key-management task in its own right. Key management is broader than secrets management: the latter stores and distributes credentials to workloads, while key management governs generation, strength, lifetime and destruction.