Customer-Managed Key (CMK)

The defining characteristic of a CMK is that the customer, not the cloud provider, governs the entire cryptographic lifecycle. This includes:

• Key Generation: Created inside a customer-controlled Hardware Security Module (HSM) or key management server.
• Rotation: Automated periodic replacement of cryptographic material without provider intervention.
• Revocation: The ability to instantly destroy the key, rendering all dependent data cryptographically inaccessible (crypto-shredding).
• Disablement: Temporarily suspending key access to pause all encryption/decryption operations immediately.

A CMK is governed by a resource-based policy document defined and managed exclusively by the customer. This policy enforces the principle of least privilege by:

• Defining which principals (users, roles, services) can administer the key versus use the key.
• Enforcing separation of duties: a user with 'usage' permissions cannot delete or modify the key's schedule.
• Requiring explicit authorization for cross-account access, preventing the cloud provider's administrative root accounts from decrypting data.
• Integrating with external authorization systems to mandate just-in-time approval workflows before key usage.

For true sovereignty, the CMK's authoritative copy must reside outside the cloud provider's default infrastructure. This is achieved by:

• External Key Store (XKS): The key material is generated and stored in an on-premises HSM or a sovereign cloud HSM.
• Proxy Architecture: The cloud service communicates with the external HSM via a secure, authenticated API to request cryptographic operations.
• No Key Export: The private key material never leaves the customer's HSM boundary; only the results of cryptographic operations are returned.
• This architecture ensures that even if the cloud's control plane is compromised, the key material remains physically isolated.

CMKs rarely encrypt bulk data directly due to performance constraints. Instead, they operate within an envelope encryption hierarchy:

• Data Encryption Keys (DEKs) are generated locally to encrypt the actual data at high speed.
• The CMK acts as a Key Encryption Key (KEK) that wraps (encrypts) the DEK.
• This creates a secure, efficient system where the CMK protects a hierarchy of thousands of data keys.
• Rotating the CMK only requires re-wrapping the DEKs, not re-encrypting petabytes of stored data, enabling seamless cryptographic agility without massive data processing jobs.

Every operation involving a CMK generates an immutable audit record, providing the forensic trail required for regulatory compliance. Key logging characteristics include:

• Write-Once-Read-Many (WORM) storage for all key access logs to prevent tampering.
• Recording of every Encrypt, Decrypt, ReEncrypt, and Rotate API call, including the requesting principal and source IP.
• Integration with Security Information and Event Management (SIEM) systems to trigger real-time alerts on anomalous key usage patterns.
• This log provides non-repudiation, proving definitively who accessed the key and when, which is critical for data lineage and provenance metadata verification.

A CMK provides a unique security property known as crypto-shredding, which is a highly reliable method for secure data deletion in distributed systems. The process works as follows:

• Instead of attempting to reliably overwrite every replica of a data object across a distributed storage cluster, the data owner simply revokes and deletes the CMK.
• All data encrypted under that CMK, and its derived DEKs, instantly becomes indecipherable ciphertext.
• This is functionally equivalent to deletion but is instantaneous and verifiable via the key management audit log.
• This technique is particularly powerful for enforcing data residency requirements by ensuring that data which accidentally replicated to a non-compliant region is rendered permanently inaccessible.

An encryption architecture where the cryptographic key material is generated and stored entirely within the customer's on-premises or sovereign Hardware Security Module (HSM). Unlike CMK models where the key might be imported into a cloud provider's boundary, HYOK ensures the key never leaves the customer's physical custody. The cloud provider performs cryptographic operations by sending a request to the external HSM, which returns the result without ever exposing the key.

A dedicated, tamper-resistant hardware appliance that safeguards and manages digital keys for strong authentication and provides cryptoprocessing. For a true CMK architecture, the HSM must be FIPS 140-2 Level 3 validated and deployed within the customer's sovereign boundary. It performs all cryptographic operations internally, ensuring that plaintext key material is never exposed to the application or the cloud provider's shared memory.

The standard practice used with CMKs to balance security and performance. A Data Encryption Key (DEK) encrypts the actual data locally, while the CMK (acting as a Key Encryption Key, or KEK) wraps the DEK. This allows large datasets to be encrypted efficiently without constantly calling the HSM. The wrapped DEK is stored alongside the ciphertext, ensuring the data remains inaccessible without the sovereign-controlled CMK.

An automated lifecycle management rule that generates a new version of the CMK at a defined interval (e.g., annually) without re-encrypting the underlying data. The new key version is used for future encryption operations, while older versions remain available for decryption of legacy ciphertext. This limits the blast radius of a potential key compromise and satisfies cryptoperiod requirements defined in NIST SP 800-57.

A precursor to full CMK control where the customer generates a key in their own HSM and securely imports a copy into the cloud provider's key management service. While the customer controls the key origin, the cloud provider technically holds a copy within its infrastructure. This contrasts with a pure CMK model where the key is generated and stored exclusively inside the customer's sovereign boundary, often using an external key store proxy.

A cloud provider API proxy that allows a CMK stored in an external, sovereign HSM to be used for encrypting resources in the cloud without ever copying the key material into the provider's infrastructure. When a cloud service needs to encrypt data, it calls the XKS endpoint. The XKS forwards the request to the sovereign HSM, which performs the operation and returns the ciphertext. This is the critical architectural component for enforcing data plane isolation.