Cloud KMS + CMK vs BYOK (AWS, GCP, Azure)

In the last lesson we ended on the insight that for encryption at rest, the algorithm is rarely the interesting part — the key is. This lesson is about where those keys live and who controls them. Every major cloud runs a Key Management Service (KMS): a hardened, audited service that creates keys, wraps and unwraps data keys, enforces who may use a key, and logs every use. When an auditor tests "data is encrypted at rest," what they are really testing is your KMS configuration: which key encrypts what, who can decrypt, how often the key rotates, and where the access log is.

By the end you will be able to read a cloud encryption setup the way an auditor does — distinguishing provider-managed keys from customer-managed keys from bring-your-own-key, and knowing which questions each choice forces you to answer.

Auditor: 'Who can decrypt this data?' — you, ten minutes in

The three cloud key managers

The three services do the same job with different names. You should recognize all three because real environments are rarely single-cloud.

Cloud	Service	Key object	Native rotation
AWS	Key Management Service (KMS)	KMS key (formerly "CMK")	Automatic annual rotation for AWS-managed material
GCP	Cloud KMS	CryptoKey (with versions)	Configurable automatic rotation period
Azure	Key Vault / Managed HSM	Key	Configurable rotation policy

All three perform envelope encryption (from the previous lesson): a key encryption key never leaves the service, data keys are wrapped and unwrapped on demand, and every operation is authenticated, authorized, and logged. Behind the most sensitive tiers sits a hardware security module (HSM) — a tamper-resistant device, validated to FIPS 140-2/140-3, that performs key operations so the raw key material never exists in ordinary memory. When a control requires "keys protected in an HSM," that maps to AWS KMS / CloudHSM, GCP Cloud KMS HSM protection level, or Azure Managed HSM.

Who controls the key: the spectrum that matters

The single distinction that drives most compliance conversations is how much control you, the customer, have over the key. It runs along a spectrum, and the vocabulary is worth getting exactly right because vendors blur it.

Provider-managed keys (default encryption). The cloud creates and controls the key; your data is encrypted, but you cannot set the key policy, choose the rotation cadence, or revoke access independently of the resource. It satisfies "encrypted at rest" for many purposes and requires almost no work. What you give up is control and granular auditability — you cannot, by yourself, make the data unreadable by cutting the key.
Customer-managed keys (CMK). You create the key in the cloud's KMS and own its key policy: who can encrypt, who can decrypt, who can administer it. You set rotation. You get a dedicated trail of every use. Crucially, you can disable or schedule deletion of the key, which renders the data it protects unreadable — a powerful, auditable control (and a powerful foot-gun). This is the tier most regulated workloads land on, because it makes "who can decrypt" an explicit, reviewable permission.
Bring-your-own-key (BYOK). You generate the key material outside the cloud (often in your own HSM) and import it into the cloud KMS. The cloud still operates the key, but you control its origin and can claim provenance. BYOK answers contractual or regulatory demands that key material originate under your control — but be honest about what it does not give you: the cloud still uses the key in its environment.
Hold-your-own-key / external key stores (HYOK). The key stays in your external key manager and the cloud calls out to it for every operation (AWS External Key Store, GCP External Key Manager, Azure Key Vault with external backing). You can cut access by taking your key manager offline. This is the strongest control and the highest operational burden and latency — reserved for the most sensitive or sovereignty-constrained data.

Control vs. operational burden across the key-ownership spectrum

BYOK is about origin, not custody

A common mistake is treating BYOK as "the cloud can't see our key." It usually cannot mean that — with BYOK the cloud still operates the key inside its KMS to do the encryption. What BYOK gives you is control over the key's origin and provenance. If the requirement is genuinely "the provider must never be able to use the key without us," that is HYOK / external key store territory, with the latency and availability cost that implies. Map the customer's actual demand to the right tier; do not let "BYOK" paper over a sovereignty requirement it does not meet.

The controls an auditor actually checks

For encryption at rest, four KMS properties carry most of the evidentiary weight — and all four are exportable:

Coverage — is encryption enabled on every data store (databases, object storage, disks, snapshots, backups)? Unencrypted snapshots and backups are a classic gap. Cloud config tools (AWS Config, GCP Security Command Center, Azure Policy) report this fleet-wide.
Key ownership — provider-managed or customer-managed? For regulated data, the expectation is increasingly CMK so the key policy is reviewable.
Rotation — is automatic rotation enabled, and on what cadence? "Keys are rotated annually, enforced by the KMS rotation policy" is a clean control statement; "we rotate manually when we remember" is a finding.
Access (who can decrypt) — the key policy and IAM grants define who can call decrypt/unwrap. This is the real access control on the data. Separation of duties matters here: the people who administer the key (change its policy) should not be the same people who can use it to decrypt, and neither should be a single unaccountable admin.

The highest-leverage artifact is the key-access log — AWS CloudTrail KMS events, GCP Cloud Audit Logs, Azure Key Vault logs. It answers "who decrypted this data, and when" with timestamps, which is exactly the evidence that turns "access is controlled" from an assertion into a demonstration.

Quick check

A regulated SaaS stores customer financial records in a managed database. Leadership wants to be able to prove, and to independently enforce, exactly who can decrypt that data — and to be able to cut off all access to it in an emergency without deleting the database. Which key approach best fits, and why?

Provider-managed default encryption — it is encrypted at rest, which is all that is needed

A customer-managed key (CMK) with a tightly scoped key policy and separation between key admins and key users; decrypt access is an explicit, logged permission, and disabling the key makes the data unreadable on demand

Hashing the records with SHA-256 so they cannot be read

BYOK, because importing the key means the cloud provider can never use it

Mapping to frameworks

These controls map cleanly and the same KMS evidence is reusable across them:

SOC 2 — CC6.1 (logical access to data) and CC6.7 (protecting data, including in transit and at rest); the key policy and access logs are core evidence.
ISO 27001:2022 — Annex A 8.24 (use of cryptography) and the cryptographic key-management practices it implies; rotation and key-access control are exactly what's expected.
PCI DSS / regulated data — explicit key-management requirements (split knowledge, dual control, documented rotation) that CMK/HSM tiers are built to satisfy.

One KMS configuration, exported once, answers all of them — which is why getting the key tier and the key policy right is among the highest-leverage data-protection decisions you will review.

GRC Engineer's lens

When you review encryption at rest, do not stop at the green "encrypted" checkmark — interrogate the key. Ask: provider-managed or CMK? Rotation enabled and on what cadence? Who is in the key policy, and are admin and use separated? Where is the key-access log, and can we pull "who decrypted this, when"? For each regulated data store you should be able to name the key that protects it and the report that proves who can use it. That fluency lets you write an accurate control narrative and answer the auditor's inevitable follow-up — "show me who can decrypt this" — without a fire drill.

What to carry forward

Every cloud encrypts at rest through a KMS doing envelope encryption; the meaningful choice is who controls the key, on a spectrum from provider-managed → CMK → BYOK → HYOK, trading control and auditability against operational burden. The four properties worth verifying are coverage, ownership, rotation, and decrypt-access, and the highest-value artifact is the key-access log. You will put exactly this judgment to work in the next lesson, designing an encryption-at-rest strategy for a regulated SaaS — deciding, data store by data store, which key tier and key policy the requirements actually demand.