What Is Cloud Key Management?

Cloud key management is where encryption stops being a checkbox and starts being a design decision. Every major provider will encrypt your data at rest by default, and that default protects against exactly one thing: someone obtaining the physical disk.

Against every realistic cloud threat — a compromised credential, an over-permissive role, a misconfigured bucket — provider-default encryption offers no protection at all, because the platform transparently decrypts for anyone authorised to read the object. The question that matters is not whether data is encrypted. It is who controls the key and who can use it.

The control models, and what each actually buys

Provider-managed keys require no work and protect against disk theft. Access to the data is governed entirely by the data-layer permissions.

Customer-managed keys put the key in your key service under your policy. This is the meaningful step: key usage becomes a separate permission from data access, key use is logged independently, and you can revoke access to the key and render the data unreadable without touching the data itself.

Customer-supplied or externally held keys go further, with the provider never holding the key material persistently. The protection is stronger and so is the operational risk — if you lose the key, the data is gone, and no support request recovers it.

The separation that makes it worth doing

The value of customer-managed keys comes from splitting two permissions that are otherwise the same: permission to read the object, and permission to use the key that decrypts it. When those are held by different roles and administered by different people, a compromised data-layer credential is no longer sufficient.

That separation is also what makes the key service audit log valuable. Unusual decryption volume is a strong exfiltration signal precisely because it is independent of the data access path an attacker would be manipulating.

Key hierarchy and scope decide the blast radius

A single key protecting everything is operationally simple and concentrates risk: compromise or misuse of that key reaches all of it, and revoking it to contain an incident takes down every system at once.

Separating keys by data classification, by environment and by system limits both. It also makes revocation a usable incident response action rather than a theoretical one — you can render one dataset unreadable without stopping the organisation.

The cost is administration, and the practical middle ground is separation along boundaries that already exist: production from non-production, regulated data from general business data, and any system with a distinct compliance obligation. That usually yields a handful of keys rather than hundreds, which is manageable and still meaningfully contains a compromise.

Where to start

Identify your most sensitive data store and check whether it uses a customer-managed key, and whether the people who administer that key are the same people who can read the data. If they are, the encryption is not providing the protection it appears to.

See encryption in practice. GuardsArm runs cloud security assessments.