CoursesAdvanced cloud securityEncryption, keys & secrets

BYOK/HYOK, HSM & key ceremonies

External key stores, FIPS HSMs, and provable custody.

Expert35 min · lesson 8 of 15

For most workloads a customer-managed KMS key is enough. For regulated data or a compliance regime that demands provable custody, you climb the ladder to importing your own key material, external key stores, and hardware security modules. Each rung buys more control and more operational weight — the skill is knowing which rung a given requirement actually needs.

Default vs CMK vs BYOK vs HYOK

A provider-managed key is invisible and uncontrollable. A customer-managed key (CMK/CMEK) gives you the key policy, rotation, and a disable switch, while the provider still generates and holds the material. BYOK (bring your own key) lets you generate the material yourself and import it, so you can prove its origin and destroy the local copy. HYOK / external key stores go furthest: the key material lives in a store you control and every cryptographic operation calls out to it, so revoking your store makes the data unreadable even to the cloud provider.

importing your own key material (BYOK)
# Create a CMK with no provider-generated material, then import yours.
aws kms create-key --origin EXTERNAL --description "byok-app-data"
# KMS hands you a wrapping public key + import token; wrap your material to it.
aws kms get-parameters-for-import --key-id KEYID \
--wrapping-algorithm RSAES_OAEP_SHA_256 --wrapping-key-spec RSA_2048
openssl pkeyutl -encrypt -pubin -inkey wrapping_pub.bin \
-in my_key_material.bin -out wrapped_material.bin \
-pkeyopt rsa_padding_mode:oaep -pkeyopt rsa_oaep_md:sha256
aws kms import-key-material --key-id KEYID \
--encrypted-key-material fileb://wrapped_material.bin \
--import-token fileb://import_token.bin --expiration-model KEY_MATERIAL_DOES_NOT_EXPIRE
# You can now DELETE the local copy: only the wrapped material entered KMS.

HSMs and key ceremonies

A hardware security module keeps key material inside tamper-resistant, FIPS-validated hardware that never exports it in plaintext. When you generate a top-level key there — a root of trust for BYOK, or a CA key — you do it as a key ceremony: multiple custodians, dual control, a witnessed and recorded procedure, and split knowledge so no single person can reconstruct or misuse the key. That ritual is what lets you attest custody to an auditor and survive the "who could have taken the key?" question.

Key custody options and what they cost
less control, less work
provider default key
no policy, no revocation, invisible
customer-managed key
policy + rotation + disable switch
more control, more work
BYOK (import)
you prove origin; provider still operates it
HYOK / external store
ops call out to your store; you can cut access
HSM-backed
FIPS hardware, non-exportable, key ceremony
Climb only as high as the requirement demands. Each rung adds availability risk and operational ritual you must actually sustain.
BYOK is not the same as denying the provider
Importing your own material into the provider KMS proves origin, but the provider still performs the crypto and could, in principle, access the operational key. If your threat model requires that the cloud provider cannot decrypt your data, you need HYOK / an external key store where the material never resides in their KMS — and you must accept the availability dependency on your store.