BYOK (bring your own key) lets you generate and control the keys a cloud service uses. How it works on Azure, AWS, Google and Microsoft 365. Limits.
BYOK (bring your own key) is a cloud encryption model in which you generate, or control, the root key that a cloud service uses to encrypt your data. The key is created in your own HSM or key manager, or under your policy in the provider's key service, and you decide when it is rotated, disabled or destroyed. The provider's service still uses the key to decrypt your data while it runs, which is what separates BYOK from hold your own key (HYOK).
By default, cloud providers generate, store and manage the keys that protect your data. For regulated data, financial records or intellectual property, many organisations want a say in that key's lifecycle and a technical way to end the provider's access. BYOK gives them both, within limits this guide spells out.
This page is the definition of BYOK. For the stronger model where the provider cannot decrypt without your key service, see BYOK vs HYOK. For Microsoft 365 specifically, see Microsoft Purview Customer Key and Double Key Encryption.
Bring Your Own Key (BYOK) encryption is a cloud security model that allows organizations to generate, control and manage their own encryption keys rather than relying entirely on keys generated by the cloud service provider. The concept originated as enterprises began migrating sensitive workloads to public cloud infrastructure and discovered that default encryption options left them without true key ownership.
In a BYOK architecture, the customer generates master encryption keys using their own hardware security modules (HSMs) or key management systems. These keys are then imported into the cloud provider's key management service, where they encrypt and decrypt data within that environment. Critically, the organization retains a copy of the key material and maintains control over the key lifecycle, including rotation, revocation and destruction.
Default encryption keeps keys inside the cloud provider's infrastructure. External key management (BYOK) moves the root key material to infrastructure you control, outside the provider's reach.
BYOK relies on a process called key wrapping. When you import your key into a cloud platform, your key (the target key) is encrypted using a separate wrapping key provided by the cloud service. This protects your key material during transit. Once imported, your key resides within the cloud provider's HSM infrastructure but was generated under your control.
The standard BYOK workflow follows these steps:
Understanding BYOK's boundaries is essential for security planning. BYOK guarantees that you generated the key material and can revoke access by deleting the key. It does not guarantee that the cloud provider cannot access your key once imported, in most implementations, the provider's infrastructure does have access to the unwrapped key during cryptographic operations.
This distinction matters significantly for compliance and risk assessment. BYOK improves your control posture compared to provider-generated keys, but it does not achieve the same level of isolation as more advanced approaches like Double Key Encryption (DKE) or external key management (EKM), where the provider never holds usable key material.
Each major cloud platform implements BYOK differently, with varying levels of control, supported algorithms and integration patterns. Understanding these platform-specific architectures helps organizations plan realistic deployments.
Azure Key Vault supports BYOK through its key import functionality. Organizations generate RSA-HSM or EC-HSM keys locally and import them into Key Vault's HSM-backed tier. Azure uses a Key Exchange Key (KEK) system where Microsoft provides a public RSA key that wraps your target key for secure import.
Once imported, keys can protect Azure Storage, Azure SQL Database, Azure Disk Encryption and other services. Microsoft's implementation maintains the key within FIPS 140-2 Level 2 or Level 3 HSMs (depending on tier), but Microsoft's infrastructure can access the key for processing operations.
AWS Key Management Service (KMS) implements BYOK through its custom key store and imported key material features. Customers can import 256-bit symmetric keys into KMS, which are then protected by AWS's HSM infrastructure. AWS also offers CloudHSM integration for organizations requiring dedicated, single-tenant hardware.
With imported key material, you keep the original copy outside AWS, and you can delete the imported material or set it to expire. During active use, AWS KMS performs the cryptographic operations inside its own HSMs. The AWS option where key material never enters AWS is the External Key Store (XKS), which is a hold-your-own-key design rather than BYOK.
Google Cloud Platform offers BYOK through Cloud KMS with customer-managed encryption keys (CMEK). Google also provides Cloud HSM for hardware-backed key storage and External Key Manager (EKM) for keys that never enter Google's infrastructure.
The EKM option represents a significant step beyond traditional BYOK, as cryptographic operations occur outside Google's environment. This architecture aligns more closely with true data sovereignty requirements.
Enterprise SaaS platforms have implemented their own BYOK models. Salesforce Shield Platform Encryption lets customers supply tenant secrets and, with the Cache-Only Key Service, fetch key material from a service they host (Salesforce BYOK guide).
Microsoft 365 has two BYOK options and one HYOK option:
The difference matters in an audit: with the two BYOK options, Microsoft's services can still read the data while your key is active. Only DKE removes that.
| BYOK | HYOK | |
|---|---|---|
| Where the key lives at runtime | In the provider's key service (imported or created under your policy) | In your own key manager, outside the provider |
| Who performs decryption | The provider's service | The provider asks your key service for each operation |
| Can the provider decrypt alone while the key is active? | Yes | No |
| Typical examples | Microsoft 365 Customer Key, AWS KMS imported key material, Azure Key Vault BYOK | Microsoft 365 Double Key Encryption, AWS XKS, Google Cloud EKM |
| Cost of the extra control | Lifecycle and backup work | You run a highly available key service, and some provider features stop |
The full comparison, platform by platform, is in Hold Your Own Key (HYOK): BYOK vs HYOK explained.
The choice between BYOK and cloud-native key management involves tradeoffs across control, compliance, operational complexity and cost. Security leaders must evaluate these factors against their specific risk profile and regulatory requirements.
| Aspect | Cloud-Native KMS | BYOK | External Key Management |
|---|---|---|---|
| Key generation | Provider | Customer | Customer |
| Key storage | Provider HSM | Provider HSM | Customer-controlled |
| Cryptographic operations | Provider | Provider | Customer or external service |
| Key access during processing | Provider has access | Provider has access | Provider may not have access |
| Revocation control | Customer-initiated | Customer-initiated | Immediate customer control |
| Audit visibility | Provider logs | Provider logs + customer logs | Full customer visibility |
The fundamental difference between BYOK vs native encryption lies in provenance and lifecycle control. With cloud-native KMS, you trust the provider completely, they generate, store and use the keys. With BYOK, you verify key generation but still trust the provider for storage and use. Only external key management eliminates provider access entirely.
Regulatory frameworks increasingly distinguish between encryption that uses provider-controlled keys and encryption under customer control. GDPR Article 32 requires "appropriate technical measures" for data protection and regulators have begun asking whether provider-held keys satisfy this standard when the provider is subject to foreign government access requests.
BYOK cloud security provides documented evidence that your organization generated the encryption keys, which satisfies some audit requirements. However, for frameworks like TISAX (automotive) or FINMA (Swiss financial services), auditors may require proof that even the cloud provider cannot access key material, pushing organizations toward DKE or external key management architectures.
BYOK introduces operational responsibilities that cloud-native KMS handles automatically:
These requirements demand skilled personnel and mature processes. Organizations without established cryptographic operations capabilities face a significant learning curve.
BYOK enables geographic key sovereignty: your encryption keys can be anchored to specific jurisdictions, ensuring that cross-border data access requests cannot reach the cryptographic root of your data.
Data sovereignty, the concept that data is subject to the laws and governance structures of the jurisdiction where it resides, has become a primary driver for BYOK adoption. Three intersecting forces make this increasingly urgent for European enterprises.
The 2020 Schrems II ruling invalidated the EU-US Privacy Shield and created uncertainty around data transfers to US cloud providers. While the EU-US Data Privacy Framework (2023) provides a new legal basis, its long-term stability remains uncertain. More fundamentally, US laws including the CLOUD Act allow US government agencies to compel US-headquartered companies to produce data stored anywhere in the world.
For organizations bound by GDPR, NIS2, or sector-specific regulations like DORA (financial services), this creates genuine legal exposure. If a US cloud provider holds both your data and your encryption keys, a US legal order could theoretically compel access, regardless of where the data is physically stored.
BYOK provides partial mitigation by ensuring you control key generation and can demonstrate that encryption was implemented under your governance. However, since the provider still accesses the key during processing, BYOK alone may not satisfy strict data sovereignty interpretations.
Most enterprises operate across multiple cloud platforms, Azure for productivity, AWS for infrastructure, Salesforce for CRM. Each platform has its own key management system, creating a fragmented control plane. Centralized cloud encryption key management through an external KMS allows organizations to maintain consistent policy enforcement and audit trails across all environments.
This unified approach delivers several advantages:
Switzerland's position outside the EU and its privacy law make it a common choice of jurisdiction for key management infrastructure. Switzerland has not concluded a CLOUD Act agreement with the United States (US Department of Justice: CLOUD Act resources).
Organizations that host their key management systems in Switzerland, or use Swiss-operated key management services, add a jurisdictional protection layer that purely technical controls cannot provide.
Specific industries face regulatory requirements that make BYOK benefits enterprise-critical rather than optional. Understanding these sector-specific drivers helps prioritize implementation.
The Digital Operational Resilience Act (DORA) has applied to EU financial entities since 17 January 2025. Its Article 9 requires ICT security policies, and the detail sits in Commission Delegated Regulation (EU) 2024/1774, whose Articles 6 and 7 cover encryption and cryptographic key management. See the DORA encryption checklist.
Swiss banks and insurers that outsource to the cloud remain responsible for the outsourced function and the data. Whether BYOK is sufficient for client-identifying data, or whether the key must stay outside the provider, is a question supervisors and auditors examine case by case. See data sovereignty in Switzerland.
HIPAA's Security Rule requires covered entities to implement encryption for electronic protected health information (ePHI). While HIPAA does not mandate specific key management architectures, the Office for Civil Rights has emphasized that encryption is only effective if keys are properly protected.
For healthcare organisations, the practical question is the same as elsewhere: who can use the key that protects ePHI, and can that access be shown in an audit.
The automotive industry's TISAX framework (based on ISO 27001) includes specific controls for information security. Automotive manufacturers and suppliers handling prototype data, engineering specifications, or connected vehicle information often require TISAX certification.
TISAX assessments examine encryption practices in detail, including who controls key material and whether keys could be accessed by unauthorized parties.
BYOK deployments frequently encounter obstacles that delay projects or compromise security outcomes. Anticipating these challenges enables more realistic planning.
Proper BYOK implementation requires FIPS 140-2 (or FIPS 140-3) validated hardware for key generation. On-premises HSMs like Thales Luna or Entrust nShield involve significant capital expense, specialized skills and ongoing maintenance. Cloud HSM services (Azure Dedicated HSM, AWS CloudHSM) reduce operational burden but introduce their own dependencies.
Organizations without existing HSM infrastructure face a critical decision: invest in on-premises hardware, adopt cloud HSM services, or partner with a managed key management provider. Each path has different cost, control and compliance implications.
BYOK transfers responsibility for key lifecycle management to the customer. This includes:
Cryptographic operations add latency. When keys are managed externally, every encryption or decryption operation may require a round-trip to the key management system. For high-throughput workloads, this can impact application performance.
Availability is equally critical. If your key management system is unreachable, cloud applications cannot decrypt data. This creates a single point of failure that must be addressed through redundancy and geographic distribution.
BYOK success depends on skilled personnel and mature processes. Organizations need:
Many organizations underestimate these requirements, leading to implementations that create compliance documentation without delivering actual security improvement.
Selecting the right BYOK approach requires systematic evaluation of your requirements, risk tolerance and operational capabilities.
Begin by answering these foundational questions:
When evaluating BYOK solutions and managed key management providers, examine:
| Criterion | Questions to Ask |
|---|---|
| Key generation | Does the vendor support HSM-backed key generation? What certification levels are supported (FIPS 140-2, FIPS 140-3)? |
| Key storage | Where is key material stored? Is it customer-controlled or provider-controlled? Can keys be stored in your own HSM? |
| Multi-cloud support | Does the solution integrate with all your cloud platforms (Azure, AWS, GCP, Salesforce, Microsoft 365)? |
| Audit and logging | Are all key operations logged? Can logs be exported to your SIEM? Are logs tamper-evident? |
| Compliance documentation | Does the vendor provide compliance reports (SOC 2, ISO 27001)? Have they been assessed against DORA or TISAX requirements? |
| Key lifecycle automation | Does the solution automate rotation, expiration alerts and revocation workflows? |
| Jurisdiction | Where is the vendor incorporated? What laws govern their data access obligations? Do they have Swiss or EU-based operations? |
| Support and SLA | What are the availability guarantees for the key management service? What is the incident response time? |
For organizations with the most stringent sovereignty requirements, traditional BYOK may not be sufficient. External key management (EKM) solutions, where the cloud provider never holds usable key material, offer stronger guarantees than standard BYOK implementations.
DuoKey's approach combines external key management with Multi-Party Computation (MPC) technology, ensuring that no single party, including DuoKey itself, holds complete key material at any point. This architecture addresses the fundamental limitation of standard BYOK: that the cloud provider can access your key during processing.
For organizations operating under Swiss financial regulations (FINMA), automotive industry certification requirements (TISAX), or strict GDPR interpretations, this level of cryptographic separation provides auditable proof that cloud providers cannot access unencrypted data, even under legal compulsion.
Bring Your Own Key encryption represents a significant improvement over cloud-native key management, but it is not a complete solution to data sovereignty challenges. Understanding its boundaries helps organizations make informed decisions:
Organizations that take BYOK seriously, implementing it with proper HSM infrastructure, documented processes and centralized oversight, achieve meaningful risk reduction and stronger compliance posture. Those that treat it as a checkbox exercise gain compliance documentation without genuine security improvement.
The decision to move beyond BYOK to external key management depends on your specific regulatory obligations, risk tolerance and the sensitivity of the data you are protecting. For most enterprises, BYOK is the right starting point. For those operating under the most demanding sovereignty requirements, it is the first step toward a more comprehensive cryptographic control architecture.
What is BYOK in simple terms?
Bring your own key means you supply or control the encryption key a cloud service uses for your data, instead of letting the provider generate and manage it. You decide on rotation and revocation. The provider's service still uses the key to process your data.
Is BYOK the same as customer-managed keys (CMK)?
Close, but not always. Customer-managed key usually means a key in the provider's key service whose policy and lifecycle you control. BYOK adds that you generated the key material yourself and imported it. In both cases the provider's service performs the decryption.
What is the difference between BYOK and HYOK?
With BYOK the provider holds a usable copy of your key while it is active. With HYOK the key stays in your key manager and the provider must ask for each operation, so it cannot decrypt on its own. See BYOK vs HYOK.
Does Microsoft 365 support BYOK?
Yes, through Microsoft Purview Customer Key for service encryption and through BYOK for the Azure Rights Management root key. For content Microsoft must not be able to read alone, Microsoft 365 offers Double Key Encryption. See Microsoft Purview Customer Key.
What happens if I lose a BYOK key?
Data encrypted under it becomes unrecoverable. That is why providers require backups, soft delete or purge protection before they accept a customer key, and why key backup belongs in the project plan from day one.
Written by
DuoKey
Related Resources
Tell us where control is difficult today. We will help you identify a practical next step.
