Cryptography & Key Management

Encryption is the control most often claimed and least often understood. “Data is encrypted at rest” appears in every audit response, and it’s frequently true and nearly meaningless, because the security of encryption lives entirely in key management, and that’s the part the claim skips. This page is about what encryption actually buys, which is a question about keys.

What encryption defends against, and what it doesn’t

Being precise here dissolves most of the confusion:

• Encryption at rest defends against physical media compromise: a stolen disk, a decommissioned drive, a raw storage layer accessed directly. It does not defend against an attacker who compromises the application, because the application reads decrypted data through legitimate access. Against most cloud intrusions, encryption at rest is irrelevant, because the intruder is using the app’s own read path.
• Encryption in transit defends against network interception, someone on the wire. It does not protect data at the endpoints, where it’s plaintext.

The uncomfortable implication: “encrypted at rest” is often an audit answer that defends against a threat the organization doesn’t face, while the threat it does face — application compromise reading data through valid access — is untouched. The control is real; the question is whether it addresses your actual risk, and the honest version names what it does and doesn’t cover rather than asserting encryption as a blanket good.

The one case where at-rest encryption earns its keep in cloud is key-scoped access control: if different data is encrypted with different keys and access to those keys is governed by IAM, then reaching the data requires reaching the key, and the key is a separately-controllable boundary. Encryption becomes an access control, not just a checkbox, but only if the keys are actually scoped, which is where most implementations fall down.

Key management is the whole game

Encryption is arithmetic; key management is security. The failure modes cluster:

• The key any compute role can use: a single account-wide key that every workload can decrypt with means the encryption adds nothing against a compromised workload. It just decrypts, like everything else. This is the most common key-management finding, and it’s why “everything is encrypted” can be true and worthless simultaneously.
• KMS and HSM: cloud KMS manages keys and gates their use behind IAM. HSMs (or HSM-backed KMS tiers) protect the key material itself in hardware for high-assurance needs. The security moves from “protect the ciphertext” to “control who can invoke the key,” which is an identity problem, and the right place for it to live.

Key hierarchies and envelope encryption

The pattern that makes key management scale: envelope encryption. A data key encrypts the data; a key-encryption key (KEK) in KMS encrypts the data key; the encrypted data key is stored alongside the ciphertext. To read, you call KMS to decrypt the data key, then decrypt locally.

Why this is the standard rather than encrypting everything directly with a KMS key:

• KMS never sees your data, only the small data key, so you’re not streaming bulk data through KMS.
• Rotating the KEK doesn’t require re-encrypting all the data, only the data keys.
• Access control concentrates on the KEK, one auditable IAM-governed chokepoint. Every decrypt is a KMS call, which is a detection signal.

The hierarchy of data keys under KEKs under a root is what lets you reason about, rotate, and revoke access at the right level without moving the data.

Secrets architecture vs. secrets tooling

Worth separating from the tooling discussion in IAM. A secrets manager is where secrets live; secrets architecture is the design that minimizes how many long-lived secrets exist at all. The best-managed secret is the one that doesn’t exist, which is why federation and workload identity beat any vault: a short-lived, identity-issued credential has no standing secret to manage, rotate, or leak. Reach for a vault for the secrets you can’t eliminate, and treat every long-lived secret as a design smell worth engineering away.

PKI

Certificate management is where cryptographic good intentions go to die operationally. A certificate is a credential with a hard expiry and a trust chain nobody inventoried, and the two canonical failures, the expired certificate that takes down production and the compromised one that can’t be revoked because nothing tracks what trusts it, are both key-management failures wearing a certificate. The full treatment (internal CA design, issuance automation and ACME, why revocation mostly doesn’t work and short lifetimes are the honest substitute, and the expired-cert outage as an availability incident) lives in PKI & Certificate Lifecycle.

Post-quantum: a today problem

Post-quantum cryptography sounds like a future concern and isn’t, because of one specific threat: harvest now, decrypt later. An adversary can capture encrypted traffic today and decrypt it once quantum computers mature, so any data with a long confidentiality lifetime is at risk now, even though the decryption capability doesn’t exist yet. What follows from that (the NIST standards, hybrid key exchange, why the migration is an inventory-and-agility problem before it’s a cryptography problem, and how to sequence it) lives in Post-Quantum Migration.

Where this connects

Key access control is an IAM problem, and secrets architecture is federation done right. What encryption does and doesn’t defend is the honest version of the GRC “encrypted at rest” audit answer, and it governs data-privacy, where §10 owns the data and §8.4 owns the keys. Every KMS call is a detection signal.