Key Custody

Key custody describes the responsibility and technical controls surrounding cryptographic key material. A custody design identifies who generates the material, which systems hold copies, who can authorize cryptographic operations, and who can recover or destroy it. These responsibilities can belong to different parties. An organization might control access policies while a cloud provider holds the material inside hardware security modules (HSMs). Administrative control does not necessarily mean physical possession or the ability to export a key.

In cloud systems, distinguish the logical key resource from its cryptographic material. The resource carries an identifier, policies, metadata, and lifecycle settings; the material performs encryption, decryption, signing, or other operations. Calling a key customer-managed generally describes customer control over that resource, not necessarily customer generation or exclusive possession of its material.

AWS Key Management Service (AWS KMS) illustrates the difference between provider-generated and imported material. With an AWS KMS-generated symmetric encryption key, AWS KMS creates and protects the material within its managed cryptographic infrastructure. Customers authorize operations through policies and grants but cannot export that symmetric key material. This reduces the customer's responsibility for generating, transporting, and backing up the underlying material. It also means the customer cannot recover a permanently deleted KMS key by supplying an independently retained copy.

With imported material, the customer generates the material outside AWS KMS and transfers it through the supported import process, using a wrapping public key and import token obtained from AWS KMS. AWS KMS then holds a protected copy and performs authorized cryptographic operations with it. Importing therefore does not mean that the material remains outside the provider. AWS KMS cannot export the imported material back to the customer, so any required external backup must be retained securely before import.

Imported material introduces additional lifecycle responsibilities. A customer can configure an expiration time during import or choose no expiration, and can explicitly delete imported material without immediately deleting the logical KMS key. If required material expires or is deleted, operations that depend on it fail. Recovery requires restoring the matching material to the original surviving KMS key under the applicable import rules. Replacing it with unrelated material does not decrypt existing ciphertext, and retaining an external copy does not make a permanently deleted KMS key recoverable.

For example, an organization may require its security team to generate encryption material in an approved HSM and retain a protected recovery copy before importing it into a cloud key service. That design satisfies a provenance and backup requirement, but it also creates duties to protect every retained copy, monitor expiration, test restoration, and restrict import and deletion permissions. A team without those requirements may prefer provider-generated material to reduce handling and recovery risks. Rotation capabilities depend on the service, key type, and origin; do not assume identical rotation procedures for generated and imported keys.

Exclusive external custody is a different architecture from importing material. With an external key store, the external key material remains in an external key manager rather than being imported into the cloud key service. This can provide an independent control boundary, but adds network, latency, availability, and operational dependencies. In any model, separate key administrators from key users, audit sensitive operations, and test failure scenarios. Revocation blocks future operations that require the key; it does not erase plaintext or data keys already obtained by an application.