BYOK vs HYOK: customer-controlled cloud encryption keys
Lightbridge Cloud defines customer-controlled cloud encryption keys as the practice of governing the keys that protect data, not just the data itself. BYOK, HYOK, and provider-managed keys describe who holds key material and who can decrypt. The model an organization chooses sets the boundary of cloud provider access and shapes its sovereignty and compliance posture.
Customer-controlled keys decide who can decrypt your cloud data, not just where it sits.
Encryption protects data, but the protection is only as strong as the control over the keys. The central question in cloud encryption is custody: who generates the key material, where it lives, and who can use it to decrypt. Three broad models answer that question differently, and the difference is the whole point. Provider-managed keys leave custody with the cloud provider. BYOK, bring your own key, gives the customer control over the key material while the provider still operates it. HYOK, hold your own key, keeps the key material outside the provider entirely.
These models are vendor-neutral concepts. Each major cloud implements them with its own service names and mechanics, but the underlying boundary, whether the provider can decrypt without the customer, is what separates them. Choosing the right model is a requirements exercise tied to sovereignty and compliance, which is why Lightbridge Cloud treats it as a design decision rather than a default setting. The companion data sovereignty guide sets the wider context.
Provider-managed, BYOK, and HYOK draw the provider access boundary in different places.
The three key custody models form a spectrum from least to most customer control. Reading them side by side makes the tradeoff clear: as control rises, so does the operational responsibility the customer takes on. These are the building blocks of any cloud key strategy.
Provider-managed keys
The cloud provider generates, stores, rotates, and controls the key material inside its own key management service. It is the default for most cloud workloads and the lowest operational burden. The provider can technically access the keys, so this model assumes trust in the provider and its jurisdiction.
BYOK: bring your own key
The customer generates or supplies key material, then imports it into the provider key management service where the provider still operates the keys day to day. BYOK gives the customer provenance and rotation control over the material, but the keys live inside the provider boundary, so the provider can still use them to decrypt.
HYOK: hold your own key
Also called an external key store or external key manager. The key material never leaves a customer-controlled hardware security module. The provider must call out to that external store for every cryptographic operation, so it cannot decrypt data without the customer present. Revoking access at the external store cuts off provider access.
External key store integrations
Major clouds expose patterns that bind their native key service to an external HSM the customer runs. The mechanics differ by provider, but the principle is the same: the cloud key service becomes a proxy to a key it cannot itself extract, keeping the root of trust outside the provider boundary.
AWS, Azure, and GovCloud are trademarks of their respective owners; Lightbridge Cloud is independent and not affiliated with, or a partner program member of, any cloud provider. The external key store mechanics named above describe public, documented patterns, not a Lightbridge product.
HYOK keeps the decryption capability outside the cloud provider boundary.
The defining property of HYOK, and of external key stores generally, is that the key material never leaves a customer-controlled hardware security module. When a cloud service needs to encrypt or decrypt, it calls out to that external store. The provider performs the operation through the customer key without ever holding extractable material. This is the structural difference from BYOK, where the imported key still resides inside the provider key management service and the provider can use it.
That boundary is what lets an organization make a strong claim: the cloud provider cannot decrypt its data unilaterally, and revoking access at the external store cuts the provider off. The cost is an availability dependency. If the external key store is unreachable, dependent cloud services can lose access to the data they protect, and the customer must run, secure, and keep the HSM highly available. Lightbridge Cloud designs for that dependency rather than discovering it in production, and operates the result through managed cloud services.
The right key model follows the sovereignty and compliance requirement, not the other way around.
There is no universally correct key custody model. The choice falls out of three questions: what sovereignty mandate applies, what compliance controls must be satisfied, and how much operational risk the organization can absorb. These factors decide where on the spectrum a workload belongs.
Sovereignty requirements
When data must stay under a specific jurisdiction or out of reach of a foreign provider, HYOK keeps the decryption capability inside customer-controlled infrastructure. Provider-managed keys rarely satisfy a strict sovereignty mandate on their own.
Compliance and audit
Frameworks such as NIST SP 800-53, CMMC, and CUI handling under NARA guidance emphasize key custody and access boundaries. BYOK supports key provenance and rotation evidence, while HYOK supports a hard claim that the provider cannot unilaterally decrypt. Verify the exact control mapping against the official source.
Operational tolerance
HYOK introduces availability dependencies: if the external key store is unreachable, dependent cloud services can lose access to data. BYOK and provider-managed keys carry lower operational risk. The right model balances control against the cost of running and protecting your own HSM.
For federal and regulated workloads, government cloud environments and key custody are usually decided together. The government cloud services overview covers the boundary considerations specific to that context.
Key custody is a recurring control across NIST, CMMC, and CUI handling.
Compliance frameworks treat key management as a first-class control rather than an implementation detail. NIST SP 800-53 and SP 800-57 address cryptographic protection and key lifecycle. CMMC builds on NIST SP 800-171 for protecting Controlled Unclassified Information, and CUI handling references NARA guidance. Federal acquisition rules under FAR and DFARS can add data protection clauses, and export-controlled data under ITAR or EAR raises the bar on who may access keys at all. The specific control numbers, applicability dates, and any dollar thresholds shift over time.
Always verify a specific requirement against its official source, for example NIST, the NARA CUI Registry, acquisition.gov for FAR and DFARS, DCSA, or DDTC and BIS for export control, before relying on it. Lightbridge Cloud frames this work as compliance readiness and advisory: it maps a key custody model, BYOK or HYOK, to the controls an organization must satisfy, and it does not hold or claim any certification it helps clients prepare for.
Lightbridge Cloud designs the key custody boundary around the requirement, then operates it.
Lightbridge Cloud is an independent, vendor-neutral cloud advisory and managed services group. On encryption key strategy it starts with the requirement, the sovereignty mandate or the compliance control set, and works back to the model that satisfies it, whether that is provider-managed keys, BYOK, or HYOK with an external key store. Because it is not enrolled in any cloud provider partner program, the recommendation is driven by fit rather than a vendor incentive.
From there the work is concrete: designing the custody boundary, integrating external key stores where they belong, and running the result with the availability and revocation discipline a key model demands. For ongoing operation, see managed cloud services, and for federal and regulated environments, government cloud services. The data sovereignty guide covers how key custody fits the wider residency and jurisdiction picture.
This guide is general guidance, not legal, audit, or accounting advice. Verify any specific regulatory or contractual requirement against its official source and your own advisors before acting.
BYOK and HYOK: frequently asked questions
- What is the difference between BYOK and HYOK?
- BYOK, bring your own key, means the customer generates or supplies the key material and imports it into the cloud provider key management service, where the provider still operates the keys and can technically decrypt data. HYOK, hold your own key, also called an external key store, keeps the key material inside a customer-controlled hardware security module that never leaves that boundary. With HYOK the provider must call the external store for every cryptographic operation, so it cannot decrypt without the customer. The short version: BYOK controls provenance inside the provider boundary, HYOK keeps the decryption capability outside it. Lightbridge Cloud is an independent advisor and helps organizations choose between them on fit, not on a vendor preference.
- What are customer managed keys?
- Customer managed keys is the umbrella term for any model where the customer, rather than the cloud provider alone, governs the encryption keys protecting its data. It spans BYOK, where the customer supplies and controls the key material inside the provider key management service, and HYOK or external key store, where the key material stays in customer-controlled hardware. The contrast is provider-managed keys, where the provider owns the full key lifecycle. Customer managed keys exist to narrow the boundary of who can decrypt and to produce evidence of key custody for auditors. Lightbridge Cloud designs the model around the sovereignty and compliance requirements an organization must satisfy.
- Does BYOK stop the cloud provider from accessing my data?
- Not on its own. With BYOK the imported key material lives inside the provider key management service, so the provider operates the keys and retains the technical ability to perform cryptographic operations, including decryption, with them. BYOK gives the customer control over key provenance, rotation, and revocation of the imported material, which is valuable for audit and lifecycle evidence, but it does not remove the provider from the trust boundary. To make a hard claim that the provider cannot decrypt without you, an external key store or HYOK model is required, because the key material never leaves customer-controlled hardware. Lightbridge Cloud is careful to set this expectation accurately rather than overstate what BYOK delivers.
- When does HYOK or an external key store make sense?
- HYOK fits when an organization must be able to prove the cloud provider cannot decrypt its data unilaterally, typically driven by data sovereignty mandates, sensitive regulated workloads, or a contractual requirement to keep the root of trust outside the provider. It is also used as a hard revocation mechanism: cutting off the external key store removes provider access. The tradeoff is operational. HYOK adds an availability dependency, because if the external hardware security module is unreachable, dependent services can lose data access, and the customer must run and protect that HSM. Lightbridge Cloud weighs the control benefit against that operational burden before recommending HYOK over BYOK.
- How do customer-managed keys relate to data sovereignty?
- Data sovereignty asks who can compel access to data and under whose jurisdiction it sits. Encryption key control is one of the strongest levers for answering that question. Provider-managed keys leave decryption capability with the provider, which rarely satisfies a strict sovereignty mandate. HYOK and external key stores keep the decryption capability inside customer-controlled infrastructure, which is why they appear so often in sovereignty designs. Residency of data alone is not sovereignty: where the keys live and who can use them matters as much as where the bytes sit. Lightbridge Cloud treats key custody and data residency together. See the companion guide on data sovereignty for the full picture.
- Which compliance frameworks care about key custody?
- Many do, though they express it differently. NIST SP 800-53 and SP 800-57 address key management and cryptographic protection as controls. CMMC, which builds on NIST SP 800-171 for protecting Controlled Unclassified Information, expects defined key management practices, and CUI handling references NARA guidance. Sector and federal acquisition rules under FAR and DFARS can add their own data protection clauses. The control language and the exact applicability change over time, so verify any specific requirement against the official source, such as NIST, the NARA CUI Registry, acquisition.gov, or the relevant agency. Lightbridge Cloud frames this work as compliance readiness and advisory, mapping a key model to the controls an organization must satisfy.
- How does Lightbridge Cloud help with customer managed keys?
- Lightbridge Cloud is an independent, vendor-neutral cloud advisory and managed services group. It helps organizations decide between provider-managed keys, BYOK, and HYOK by mapping the decision to real sovereignty and compliance requirements rather than to a single vendor pattern. The work spans designing the key custody boundary, integrating external key stores where they fit, and operating the result through managed cloud services. Lightbridge Cloud does not hold the certifications it helps clients prepare for: it frames CMMC, FedRAMP, and similar work as readiness and advisory, never as a credential it has earned. The goal is a defensible key model that an auditor and a sovereignty review can both accept.
From key custody question to a defensible design.
When the question shifts from what BYOK and HYOK mean to which one your workload needs, Lightbridge Cloud maps the model to your sovereignty and compliance requirements and operates it through managed cloud services.