Cloud KMS, BYOK, and HYOK: Managing Encryption Keys in the Cloud

Data in AWS, Google Cloud, or Microsoft Azure is often encrypted by default. However, for audits and regulated data, that answer is usually not enough. It is more important to understand not only whether the data is encrypted, but also who manages the key, who can authorize decryption, where the key material resides, and what happens if there is an issue with the key.

Cloud KMS turns a key into a managed object, with access policies, versions, rotation, logs, status, disabling, and deletion. As a result, the key becomes part of data access control, not just a technical encryption setting.

The choice of model typically revolves around four options:

• Provider-managed keys — the keys are primarily managed by the cloud provider, while the customer receives basic encryption with minimal operational overhead.
  
• Customer-managed keys / CMK / CMEK — the customer manages the key object, policies, rotation, and state in the cloud KMS.
  
• BYOK (Bring Your Own Key) — the customer creates key material outside the cloud and imports it into KMS or the provider’s secure module.
  
• HYOK / EKM (Hold Your Own Key / External Key Manager) — key material remains outside the cloud, and cloud services access an external key manager.

The main trade-off is straightforward: the more control you have over the key, the greater the operational requirements. BYOK and HYOK help with separation of duties, auditing, key provenance, and legal requirements. However, an error in an access policy, rotation, or deletion, or problems with an external KMS, can make data unavailable.

Therefore, the key management model should not be chosen on the basis that “the strictest is the best,” but according to the responsibility the company is realistically prepared to support: who manages the key, who approves changes, which events are captured in audit logs, how recovery is performed, and what happens if the KMS fails.

What Cloud KMS Does and Why Default Encryption May Not Be Enough

Cloud KMS should not be treated as a simple “encrypt data” button. It is a management layer for keys and operations performed with them. The data itself is usually encrypted directly by databases, object storage systems, disk subsystems, or application services. KMS is responsible for something else: whether the required key can be used, who is allowed to use it, and how the operation is recorded.

In simplified terms, KMS is less like a vault containing all the data and more like a control system for “master keys.” One analogy is a hotel concierge who gives the right keys only to the right people. Without an authorized key operation, a service may be able to see encrypted data in storage, but it will not be able to decrypt and use it properly.

Cloud KMS typically addresses several tasks:

At that point, the key is no longer a hidden technical detail, but an object with a lifecycle: a name, an identifier, versions, state, access policies, metadata, and an event log. It is also important to distinguish between the key object and the key material—the cryptographic basis, which may be generated inside KMS, imported through BYOK, or kept outside the cloud in stricter models.

Cloud services often use envelope encryption. In simplified terms, the model works as follows:

• Data is encrypted with separate data keys;
• The data keys are protected by a higher-level key;
• Cloud KMS manages this higher level and access to operations on it;
• If a key operation is denied or unavailable, the service will not be able to decrypt the data.

Therefore, access to data is determined not only by permissions on the database, bucket, or disk. The service also needs an authorized key operation. If a policy denies the call, the key is disabled, or KMS is unavailable, the data may remain physically stored but be practically inaccessible.

An HSM—a hardware or otherwise specialized secure module—may be used to protect key material. Its purpose is not to provide “stronger encryption in itself,” but to limit the extraction of key material and show where the boundary of control lies.

This shows why the statement “data is encrypted by default” is not sufficient for an audit. An auditor needs to understand who can use the key, who changed policies, who could have disabled or deleted the key, where the key material is located, and which events can be verified through logs.

This also makes the difference between key management models clearer. They differ not only in where the key material is stored, but also in who accepts the risk of error, failure, deletion, and disputed access to encrypted data.

Four Key Management Models: From Provider-Managed Keys to an External KMS

If a key becomes a separate point of access to data, the next question is who manages that point. It is useful to view these models as a ladder of control: each successive level gives the customer more influence over key material and key-related decisions, while also adding operational responsibilities.

The models do not differ in whether encryption is used. Data can be encrypted under any of these approaches. The difference lies in where the boundary of control is drawn and who is responsible for the consequences: rotation, access policies, disabling, deletion, auditing, and failures.

Provider-managed keys

In this model, keys are primarily managed by the cloud provider. The provider creates and stores the keys and handles most of their lifecycle. The customer typically sees that the service is encrypted and has access to high-level settings, but does not manage the key as a separate object.

This option is suitable for test environments, internal services, and data with no specific requirements for independent control over keys. It reduces operational overhead but provides less transparency for audits and separation of duties.

Customer-managed keys / CMK / CMEK

Customer-managed keys, or CMK/CMEK, give the customer greater control. The key material resides in the provider’s cloud KMS, but the customer manages the key object: access policies, state, rotation, versions, disabling, and deletion.

This model is often suitable for enterprise databases, personal data, and critical production systems where it is important to separate permissions for the data from permissions for the key. CMK/CMEK should not be confused with BYOK: a customer-managed key can be created directly within the cloud KMS and does not necessarily have to be imported from an external source.

BYOK

BYOK means that the customer creates or obtains key material in their own environment, such as a corporate HSM, and then imports it into the provider’s KMS or secure module. This helps demonstrate the key’s origin and show that it was generated according to the company’s internal procedure.

However, after import, the boundary of control changes. The key material, or its protected form, starts being used within the cloud infrastructure. Therefore, BYOK is not the same as HYOK: the customer controls the key’s origin and import, but the key no longer remains entirely outside the cloud environment.

HYOK / EKM

HYOK, or the use of an external key manager, moves the control boundary even further. The key material remains outside the cloud, and cloud services call an external KMS for authorized operations. In documentation, this model may be referred to as EKM — external key manager.

This model may be required by financial institutions, the public sector, or companies with strict requirements for the jurisdiction of keys. However, HYOK should not be seen as automatically the “most secure” option. It adds a dependency on the external KMS, the network, integration, monitoring, and recovery procedures.

The overall difference can be summarized as follows:

The phrase “who holds the key” is useful, but insufficient. In a real architecture, what matters is who can create a new version, who changes the access policy, who disables the key, who confirms deletion, and who demonstrates to the auditor that the procedure was performed correctly.

Therefore, the four models are not a security ranking, but different ways of distributing responsibility. The greater the control, the more mature the processes need to be: permissions, changes, fault tolerance, and actions to take when something goes wrong.

What changes in practice: rotation, auditing, availability, and key loss

After comparing the models, it is important to put control into operation. A key is not only a place where key material is stored, but also a set of procedures: rotation, auditing, disabling, deletion, recovery, and access verification.

The basic trade-off is simple: the more control the customer has, the more operations it must be able to perform without error.

Key rotation does not always mean that the cloud immediately re-encrypts the entire data archive. Often, the new version is used for new operations, while older versions are still needed to read objects that were encrypted earlier. Therefore, risk arises not only when rotation is absent, but also when old versions are disabled too aggressively.

Auditing is also broader than logging encryption and decryption operations. You also need to review events that change the very ability to access data:

• Changes to access policies and roles;
• Import and re-import of key material;
• Key disabling, deletion, and rotation;
• Failed access attempts;
• Actions performed by service accounts and automated processes.

This type of audit shows not only who accessed the data, but also who could have changed the conditions for using the key. This is critical for investigations: sometimes the incident is not the reading of a record, but the granting of a role that would have allowed it to be decrypted.

Availability follows the same principle. A company can deliberately disable a specific customer's key and predictably block access to that customer's data, for example when a contract is terminated. This is a controlled action: it is documented, approved, and can be reversed.

EU Cloud Infrastructure You Control

Run production workloads on dedicated resources across EU data centres. Transparent pricing, no hidden costs. Full control over compute, storage, and networking.

Explore Infrastructure

Predictable Virtual Machines for Production

Dedicated vCPUs, consistent performance, no noisy neighbours. Deploy and scale VMs in minutes. Full root access, fixed pricing.

View VM Plans

Up to €22,000 to Migrate Your Workloads

Cut OPEX when migrating to EU infrastructure. Get migration support, cost assessment, and infrastructure credits with no upfront commitment.

Apply for Bonus

Kubernetes with Full Control

Deploy production-ready clusters with control over node configuration, storage, and networking. Predictable costs and direct access to infrastructure.

Deploy Cluster

However, a similar effect can occur during an outage: the external KMS is unavailable, the network connection between the cloud and the external system is disrupted, the imported material has expired, or the key has been deleted without the possibility of recovery. In that case, the encrypted data remains in place but becomes practically inaccessible.

Key management is therefore not only about managing encryption, but also about managing the trust boundary. Next, it is important to examine separately where that boundary lies in BYOK and HYOK.

Where the control boundary lies in BYOK and HYOK

BYOK: the customer controls key provenance

With BYOK, the customer controls the provenance of the key material: where it was created, which procedures were used to protect it, who approved the import, and how the import into the cloud KMS was recorded. This is useful when policy requires keys to be generated in a corporate HSM, duties to be separated between cloud administrators and key administrators, imports to be documented, and rotation to be reproducible.

After import, however, the boundary changes. The key material, or its protected form, begins to be used within the cloud infrastructure, and cryptographic operations are performed using the provider’s services. As a result, BYOK is well suited to satisfying the requirement that “the key was created under our control,” but it usually does not satisfy the requirement that “the key material was never transferred to the cloud provider.”

HYOK: the key remains outside the cloud

HYOK draws a stricter boundary. The key material remains in an external system operated by the customer or a trusted operator, and the cloud calls the external KMS only for an authorized operation. This gives the customer greater control over the key, but it also introduces a critical dependency: the external KMS, network, access policies, monitoring, and recovery procedures become part of the cloud service’s availability model.

The practical difference between BYOK and HYOK is especially apparent during outages and audits:

For this reason, the choice between BYOK and HYOK cannot be reduced to the formula “HYOK is more secure.” HYOK provides a stricter control boundary, but it requires mature operation of external cryptographic infrastructure. If an organization cannot ensure resilience, monitoring, recovery procedures, and demonstrable auditability for the external KMS, HYOK may increase the risk of data unavailability more than it reduces the risk of unauthorized access.

Legal and Regulatory Requirements: What Affects the Choice of Model

The legal context usually affects not the encryption algorithm itself, but the ability to demonstrate control. A regulator, auditor, or major customer may require evidence of who controls the key material, which jurisdiction it is located in, who can authorize decryption, and how the organization proves deletion or access blocking.

Control over Key Material

If it is sufficient to prove that keys are managed in Cloud KMS with segregated roles and audit logs, customer-managed keys are usually appropriate. If the key must be generated in a customer-controlled environment, this supports the case for BYOK. If transferring key material to the provider is explicitly prohibited, HYOK or an external key manager should be considered.

It is important here not to replace the requirement with a more complex architecture “just in case.” In some cases, an audit requirement can be satisfied with roles, logs, and a managed lifecycle in Cloud KMS. In others, the wording of a contract or regulatory requirement genuinely requires key material to remain outside the cloud.

Jurisdiction and Storage Location

For international companies, it is important to distinguish between where data is stored and where keys are held. Data may reside in one cloud region, while the key must remain in a specific country, with a specific legal entity, or under the control of a separate trusted operator.

In such cases, provider-managed keys are often not transparent enough. CMK/CMEK can meet some requirements for region and administration, BYOK helps verify the key’s provenance, and HYOK is used where the key must remain physically and administratively outside the cloud platform.

Audit, roles, and provable deletion

Many standards and industry requirements do not literally say “use BYOK” or “use HYOK.” More often, they require controls: least privilege, logging, policy change procedures, key protection, managed deletion, and the ability to reconstruct the sequence of events during an incident.

It is therefore important to define in advance:

• Which key model is used for each class of data;
• Why this model is sufficient for the applicable standards, laws, and contracts;
• Who approves policy changes, rotation, key disabling, and key deletion;
• Which logs and reports confirm that the procedures have been followed;
• How backups and deletion delays are verified.

Keys are often used as a mechanism for cryptographic deletion: if the key is destroyed, the data remains in storage but becomes unreadable. For production systems, this requires caution: deletion delays, independent approval, logging, and separate access control for such operations.

The takeaway is simple: choosing a model from a legal standpoint is not about selecting the strictest option, but about matching the requirements to the company’s operational capabilities. If a requirement can be met with managed keys, roles, and logs in Cloud KMS, HYOK may be excessive. If, however, the requirement is specifically about not transferring key material to the provider or keeping keys under an independent jurisdiction, it is difficult to avoid HYOK or an external KMS.

Scenarios for Regulated Data

With the legal framework established, it is useful to look at common scenarios. They do not replace an analysis of a specific law, standard, or contract, but they illustrate the general principle: the stricter the requirement for independent control of key material, the further the model shifts from provider-managed keys toward CMK/CMEK, BYOK, and HYOK.

Financial institutions and payment data

For banks, payment companies, and fintech platforms, separation of duties, audit logging of administrative actions, strict access control, and controlled key rotation are typically important.

Customer-managed keys often become the baseline model: they allow infrastructure administrators to be separated from key administrators, policy changes to be recorded, and the disabling of access to be managed.

BYOK may be required if internal policy or audit requirements mandate generating key material in a corporate HSM. HYOK is considered when keys must not leave the bank’s infrastructure or a specific jurisdiction. In this case, latency, the fault tolerance of the external KMS, and the impact of key unavailability on payment operations are assessed in advance.

Medical Data and PHI

For medical data, least privilege, access logs, controls over administrative actions, and the ability to investigate unauthorized access are critical. In many cases, customer-managed keys in a cloud KMS are sufficient if roles, auditing, rotation, and deletion are configured correctly.

BYOK is appropriate when a healthcare organization or its contractor requires keys to be generated in its own environment and imported through an approved procedure.

HYOK is required less often, but becomes relevant if a contract or policy prohibits transferring key material to the cloud provider. In that case, it is necessary to evaluate not only the cryptographic model but also the availability of clinical systems: a failure of the external KMS may affect physicians’ access to patient data.

Government Data and Public Sector Contractors

For government systems, data residency, control over administrative access, certified environments, and verifiable assurance that keys are under the control of an authorized party are often important.

Provider-managed keys are typically suitable only for low-risk or public data. Customer-managed keys may be sufficient if the cloud region, roles, logs, and procedures meet the requirements of the program or contract.

BYOK adds control over key generation and helps integrate the cloud into existing procedures for managing cryptographic material. HYOK is considered when keys must remain in the separate infrastructure of an agency, contractor, or trusted operator.

Personal Data Subject to Jurisdictional Requirements

A multinational company may store personal data in different regions while also accounting for localization, cross-border transfers, and administrative access to KMS. In this context, it is important to distinguish between the data region, the key region, and the legal entity that manages the key.

For moderate requirements, customer-managed keys with regional scope and strict role assignments are often sufficient. BYOK helps demonstrate that the key was created in the company’s controlled environment before being imported into the cloud.

HYOK is required when the key must remain in a specific country, under the control of a specific legal entity, or with an independent trusted operator, and transferring key material to the cloud provider is not permitted.

Multi-tenant cloud service

A SaaS provider or another multi-tenant platform may store data for many customers in a single system while using separate keys per customer, data group, or service tier.

Customer-managed keys give large customers greater control: a dedicated key, separate logs, and controlled access revocation when the contract ends. BYOK is suitable for customers that require importing their own key material.

HYOK may be an option for the strictest customers, but responsibilities must be defined in advance. If the customer's external KMS is unavailable, this may affect the availability of that customer's data. The contract and architecture should explicitly specify who is responsible for failures of the external key manager and how such incidents are handled.

The overall conclusion is straightforward: regulated data does not always require HYOK. Customer-managed keys, roles, logs, rotation, and clear procedures are often sufficient. BYOK is needed when the origin of the key material matters. HYOK is justified where the key must not leave the external control boundary, but the company is prepared to accept the operational complexity of this model.

Conclusion

A cloud key management model should not be chosen on the principle that “the strictest is the best,” but according to the responsibilities the company is actually prepared to support with its processes. Default encryption covers the baseline level, but it does not always provide the required control over keys, auditing, jurisdiction, and separation of duties.

Cloud KMS and customer-managed keys are suitable when a managed key lifecycle within the cloud is required. BYOK is needed when the provenance of key material and generation in the customer’s own environment are important. HYOK is justified when key material must not be transferred to the cloud provider, but it requires mature operations: fault tolerance, monitoring, recovery, control over deletion, and regular reviews.

FAQ

How do customer-managed keys differ from BYOK?

Customer-managed keys mean that the customer manages the key object in the cloud KMS: policies, rotation, disabling, and deletion. The key material itself, however, may be generated by the cloud KMS.

BYOK is a specific case with an additional requirement: the key material is generated by the customer outside the cloud and then imported into the provider’s KMS or HSM.

Why BYOK Is Not the Same as HYOK

With BYOK, after import, the key material is typically used within the cloud provider’s infrastructure. The customer controls the key’s origin and the import process, but cryptographic operations are performed by the cloud KMS.

With HYOK, the key material remains outside the cloud. The cloud service communicates with an external key manager, so control is greater, but data availability depends on the external system and the communication channel to it.

When are provider-managed keys sufficient?

This option is suitable for test environments, internal services, and data that has no specific requirements for independent key management. It reduces operational overhead: the provider handles most of the key lifecycle.

If an audit requires evidence of who managed the key, who changed access policies, and how rotation was performed, customer-managed keys, BYOK, or HYOK are typically required.

What happens if a key is deleted or disabled?

If a key is disabled, services may lose the ability to decrypt data until it is re-enabled. If a key is permanently deleted or the key material is destroyed, recovery may be impossible.

For this reason, key deletion is often treated as cryptographic data deletion. Production systems need deletion grace periods, approval procedures, and separate permission controls for such operations.

Which events should be logged for KMS auditing?

Recording only encryption and decryption operations is not enough. The audit trail should include changes to access policies, role assignments, imports of key material, rotation, disabling, deletion, failed access attempts, and service account actions.

For investigations, it is important to see not only actual data reads, but also changes that could have made decryption possible.

When is HYOK truly justified?

HYOK is justified when there is an explicit requirement that key material not be transferred to the cloud provider—for example, due to regulatory restrictions, key jurisdiction requirements, internal policy, or conditions for handling highly sensitive data.

If no such requirement exists, HYOK can introduce unnecessary complexity. The external KMS becomes a critical dependency, and its failure can disrupt access to data in the cloud.

Sources

1. Google Cloud — Customer-managed encryption keys

2. Google Cloud — Cloud External Key Manager

3. AWS KMS — Importing key material

4. NIST SP 800-57 Part 1 Rev. 5 — Recommendation for Key Management