Encryption architecture and key management

Where data needs protecting

Encryption at rest provided transparently by a platform protects lost media, but anyone with valid access to the running system still sees plaintext. For sensitive fields, consider application-level encryption, where the application encrypts specific fields, such as national ID numbers, before they reach the database.

Envelope encryption and key hierarchy

Encrypting large data directly with a central key would send huge volumes through the key service. Instead, systems use envelope encryption: a fresh data encryption key (DEK) encrypts the data locally, then a key encryption key (KEK) held in the key service encrypts, or wraps, the DEK. The wrapped DEK is stored beside the data. To decrypt, the application asks the key service to unwrap the DEK, which is logged and access-controlled.

Benefits: the master key never leaves secure hardware, rotation of the KEK does not require re-encrypting all data, and every unwrap is an auditable event.

Where keys live

• Hardware security modules (HSMs): tamper-resistant devices validated to standards such as FIPS 140-3. Keys can be used inside but not exported.
• Cloud key management services (KMS): managed services backed by HSMs, such as AWS KMS or Azure Key Vault, with IAM policies and audit logs (see AWS KMS and Azure Key Vault).
• Customer-managed and external keys: options such as bring your own key (BYOK) or hold your own key give more control, at the cost of more responsibility.
• Secrets managers: store passwords, API keys and certificates, not to be confused with encryption keys, though often in the same platform.

Key lifecycle and governance

1. Generate keys with a secure random source, inside the HSM or KMS where possible.
2. Separate duties: people who manage keys should not be the same people who can read the data.
3. Grant use of each key to specific workloads only; review policies regularly.
4. Rotate on a schedule and immediately on suspected compromise; keep old versions for decryption only.
5. Back up keys securely, or you can lose all data encrypted with them.
6. Log every key operation to your SIEM and alert on unusual use, such as a spike in decrypt calls.
7. Destroy keys deliberately, which is also a way to make data unrecoverable (crypto-shredding).

Plan for crypto-agility. NIST published its first post-quantum standards in 2024, including FIPS 203 (ML-KEM) for key establishment. Keep an inventory of where and how you use cryptography, so you can move to new algorithms without redesigning systems (see post-quantum migration).

Tip: the most common failure is not weak algorithms but poor key handling, such as keys in source code, shared admin access to the KMS, or backups encrypted with a key that is stored in the same place.