What Is BYOK? Bring Your Own Key Encryption Explained
Jan 15, 2025
ArticleBYOK explained for security and risk leaders: when customer-held keys reduce cloud concentration risk and when provider-managed encryption is not enough.
Read articleHold your own key (HYOK) is a cloud encryption model in which the keys that protect your data never leave infrastructure you control. The cloud provider stores only ciphertext and must ask your key service to perform each cryptographic operation, so if your key service refuses, or is unreachable, the provider cannot read the data. Key availability becomes data availability.
That is the difference a board, regulator or data protection officer cares about. With provider-managed keys and with bring your own key (BYOK), the provider holds a usable key, so it can be compelled, breached or misconfigured into decrypting your data. With HYOK, decryption needs a step only you can perform. Legal requests addressed to cloud providers, including under the US CLOUD Act, are one reason "who can decrypt?" is now a procurement question.
This guide compares HYOK with BYOK and provider-managed keys, shows how Microsoft 365, AWS, Google Workspace, Salesforce, Snowflake and Oracle implement it (or don't), based on each vendor's documentation, and ends with a decision table.
Table of Contents
- What Is Hold Your Own Key (HYOK)?
- BYOK vs HYOK vs Provider-Managed Keys
- How HYOK Works
- HYOK by Platform
- Trade-offs: What You Give Up With HYOK
- How to Decide: HYOK, BYOK or Provider Keys
- How DuoKey Supports HYOK and BYOK
- FAQ
What Is Hold Your Own Key (HYOK)?
HYOK rests on three properties:
- The key stays with you. Key material is generated and stored in a key manager you operate or contract for (HSM, KMS or MPC-based key service). It is not imported into the cloud provider.
- The provider requests operations, not keys. When the cloud service needs to wrap or unwrap a data key, it calls your key service, which performs the operation and returns the result.
- Revocation is technical, not contractual. Disable the key or block the endpoint and new decryptions stop.
AWS uses the term directly: operations with a KMS key in an external key store "are performed by your external key manager using your cryptographic key material, a feature known as hold your own keys (HYOKs)," and "your cryptographic key material never leaves your external key manager" (AWS KMS: External key stores).
You will also see CYOK ("control your own key") in vendor material. It isn't a standardized category: some vendors use it as an umbrella for any customer-controlled key, others as a synonym for HYOK. When comparing HYOK vs BYOK vs CYOK offers, ignore the label and ask who holds the key at runtime and who can decrypt without asking you.
BYOK vs HYOK vs Provider-Managed Keys
The models differ less in algorithms than in custody. For BYOK on its own, see what BYOK (bring your own key) is and how it works.
| Provider-managed keys | BYOK (bring your own key) | HYOK (hold your own key) | |
|---|---|---|---|
| Who generates the key | Cloud provider | You, then imported into or created under your policy in the provider's KMS | You, in your own key manager |
| Who holds the key at runtime | Provider | Provider's service, under your policy | Only your key manager; the provider holds ciphertext and key references |
| Who can decrypt | Provider services, on their own | Provider services, using the key you authorized | Provider services only after your key service performs the operation |
| Effect of revocation | Not available to you | Provider stops using the key; caches and purge processes apply per service | New decryptions fail as soon as your service refuses |
| Exposure to legal requests addressed to the provider | Provider can produce plaintext | Provider can usually produce plaintext while the key is active | Provider can produce only ciphertext |
| Operational cost | Lowest | Moderate: lifecycle, rotation, access policy | Highest: you run a highly available, low-latency key service |
| Features kept | All | Almost all (search, indexing, AI features) | Reduced: the provider can't process what it can't read |
BYOK is a real improvement: you own the lifecycle and can revoke. But because the provider uses the key inside its service, BYOK doesn't change who can decrypt while the key is active. HYOK does, and you pay for it in availability responsibility and lost features.
How HYOK Works
Almost every implementation uses envelope encryption:
- The cloud service encrypts your data with a data encryption key (DEK).
- It sends the DEK to your key service, which wraps it with a key that never leaves your control.
- The provider stores the data and the wrapped DEK together.
- To read, the provider sends the wrapped DEK back. Your service checks identity and policy, then unwraps or refuses.
Your key service sits in the read path: it enforces policy, keeps the audit trail, and if it is down, the data is down.
AWS adds double encryption: AWS KMS first encrypts with AWS-held key material, then your external key manager encrypts the result, so "neither AWS KMS nor the owner of the external key material can decrypt double-encrypted ciphertext alone" (AWS KMS). Microsoft's Double Key Encryption follows the same "two keys, both required" logic.
HYOK by Platform
Microsoft 365: Double Key Encryption (HYOK)
Microsoft Purview Double Key Encryption (DKE) "uses two keys to protect data; one key in your control and a second key you store securely in Microsoft Azure," and viewing protected data "requires access to both keys." You host the DKE service on-premises or in the cloud (Microsoft Learn: Double Key Encryption). From the same page:
- Scope: applied through sensitivity labels; requires the Azure Rights Management service. Microsoft positions it for the most sensitive data (about 5% in its own illustration).
- Apps: Microsoft 365 Apps for enterprise on Windows (Word, Excel, PowerPoint, Outlook), plus the Purview file labeler, PowerShell and scanner.
- Licensing: included with Microsoft 365 E5.
- What stops working for protected content: eDiscovery, content search and indexing, mail flow rules that inspect attachments (including anti-malware and spam), Office web apps and co-authoring, and Copilot. DKE labels can't protect Teams meetings, chat or calendar items.
Deployment steps: Microsoft 365 Double Key Encryption setup guide.
Microsoft 365: Customer Key (BYOK, not HYOK)
Customer Key is service encryption under root keys you control, covering Exchange, SharePoint, OneDrive, Teams and Windows 365 Cloud PCs. Microsoft is explicit about who uses the key: "You explicitly authorize Microsoft 365 to use your encryption keys to deliver value-added services like eDiscovery, anti-malware, anti-spam, and search indexing" (Microsoft Learn: Customer Key overview).
That is BYOK. Microsoft 365 services decrypt content in normal operation, which is why every feature keeps working, and each data encryption policy includes an availability key that Microsoft protects. Your control shows at exit: "Revoking access to your keys triggers deletion of the availability key, resulting in cryptographic deletion of your data." Many programmes use Customer Key broadly and DKE for a small labelled slice; see DKE vs Microsoft 365 Customer Key.
AWS: KMS External Key Store (XKS)
Each KMS key in an external key store maps to a 256-bit AES "external key" in your external key manager, reached through an XKS proxy you supply; "AWS KMS cannot create, delete, or manage any external keys." Applications use the same KMS APIs, and AWS services that support customer managed symmetric keys support XKS keys (AWS KMS). AWS documents the trade-offs itself:
- You are responsible for "the availability, durability, and latency of key operations." Revoke access and AWS loses access to your keys until you restore it; some services briefly cache data keys.
- AWS recommends a Region with a round-trip time of 35 ms or less to your key manager.
- Only symmetric keys are supported: no asymmetric or HMAC keys, imported key material, automatic rotation or multi-Region keys.
- For most workloads, AWS says, the operational burden and availability risk "will exceed the perceived security benefits". Use XKS for the regulated workloads that need it.
Details: AWS XKS implementation guide.
Google Workspace: client-side encryption (CSE)
Workspace CSE encrypts content in the client with a DEK, then sends that DEK to your external key service (the Key Access Control List Service, KACLS) to be encrypted; your identity provider authenticates users first (Google Workspace CSE API overview). Google states that "Google servers and third parties can't access your encryption keys and decrypt your data." Coverage includes Drive and Docs editors files, the Gmail body and attachments, Calendar event descriptions, and Meet audio, video and chat; Gmail headers and Calendar titles, times and attendees are not encrypted (Google: Protect your organization's data with CSE). Editions: Frontline Plus, Enterprise Plus, Education Standard and Education Plus (Google: About client-side encryption).
Salesforce: Shield Cache-Only Key Service
The Cache-Only Key Service lets you "store your key material outside of Salesforce and have the Cache-Only Key Service fetch your key on demand from a key service that you control," and "Salesforce doesn't retain or persist your cache-only keys in any system of record or backups." Keys are 256-bit AES, wrapped in JSON Web Encryption and fetched over a named-credential callout; the encrypted cache is flushed at least every 72 hours. It requires Salesforce Shield or Shield Platform Encryption plus the Cache-Only Key Service (Salesforce Platform Encryption Implementation Guide).
To be precise: the key is used inside Salesforce while cached, so this isn't HYOK in the strict XKS sense. What you hold is the off switch: destroy the key and "related data isn't accessible" until you reactivate it.
Snowflake: Tri-Secret Secure (closer to BYOK)
Tri-Secret Secure "combines a Snowflake-maintained key and a customer-managed key (CMK)" into a composite master key. It requires Business Critical edition or higher, and if the CMK is revoked Snowflake can no longer decrypt your data (Snowflake: Tri-Secret Secure). By default the CMK lives in the KMS of the cloud platform hosting your account, and you "must release this key to decrypt data stored in your Snowflake account" (Snowflake: Encryption key management).
Honestly classified, that is BYOK with a kill switch: Snowflake uses your key while you allow it. For AWS-hosted accounts Snowflake documents an external key store behind the CMK, which moves the root closer to HYOK; check Snowflake's current list of tested key managers. Setup: Snowflake Tri-Secret Secure guide.
Oracle Database: TDE with an external keystore
In Oracle Transparent Data Encryption, "the TDE master encryption key protects the TDE table keys and tablespace encryption keys" (Oracle: Configuring TDE). Moving the master key off the database host gives you HYOK-style control wherever the database runs. Oracle's supported external keystores are Oracle Key Vault and OCI Vault. The HSM value of TDE_CONFIGURATION still configures a hardware security module, but Oracle's reference states that "Oracle does not support the use of HSMs for TDE key management" and points to My Oracle Support note KB593570 (Oracle: TDE_CONFIGURATION). Read that note before production. Step by step: Oracle TDE external keystore guide.
Which platform option is really HYOK?
| Platform option | Where the customer key operates | Model |
|---|---|---|
| Microsoft 365 Double Key Encryption | Your DKE service; Microsoft holds the second key | HYOK |
| Microsoft 365 Customer Key | Used by Microsoft 365 services; Microsoft also protects an availability key | BYOK |
| AWS KMS External Key Store | Your external key manager, via your XKS proxy | HYOK |
| Google Workspace CSE | Your external key service (KACLS) | HYOK |
| Salesforce Cache-Only Key Service | Hosted by you; fetched and cached encrypted by Salesforce, not persisted | Between BYOK and HYOK |
| Snowflake Tri-Secret Secure | Your CMK combined with a Snowflake key | BYOK (closer to HYOK with an external key store) |
| Oracle TDE, external keystore | Master key in the external keystore | Customer-held master key (check Oracle's HSM support position) |
Trade-offs: What You Give Up With HYOK
- Availability. Your key service becomes a dependency of the cloud service. Plan redundancy, monitoring and tested recovery; a lost external key means unrecoverable data.
- Latency. Every unwrap is a round trip to your service. Caching hides most of it, but placement matters.
- Features. The provider can't index, scan or summarize what it can't read: Microsoft lists eDiscovery, search, attachment-scanning mail flow rules, web co-authoring and Copilot as unavailable for DKE content.
- Cost. AWS notes you bear "all costs for developing, purchasing, operating, and licensing your external key manager system."
How to Decide: HYOK, BYOK or Provider Keys
Start from the data class and the threat, not the product. This is a planning aid, not legal advice; whether a model satisfies a specific law or contract is a question for your counsel.
| Data class | Main threat | Suggested model |
|---|---|---|
| Public and general business data | Accidental exposure, disk theft | Provider-managed keys |
| Regulated personal or financial data needing full productivity features | Loss of control over key lifecycle; need for exit and cryptographic deletion | BYOK (e.g. Microsoft 365 Customer Key, Snowflake Tri-Secret Secure) |
| Crown-jewel data: M&A, board material, trade secrets | Provider insider access or compromise | HYOK (DKE, Google CSE, AWS XKS) |
| Data the provider must not be able to produce under foreign legal process | Requests addressed to the provider, e.g. under the US CLOUD Act | HYOK, with keys under an operator and jurisdiction you choose |
| Databases you run yourself | Theft of database files, backups or hosts | Master key in an external keystore (e.g. Oracle TDE) |
Why the CLOUD Act row matters: the US Department of Justice explains that the Act covers data "within such provider's possession, custody, or control, regardless of whether such communication, record, or other information is located within or outside of the United States," and calls the Act "encryption neutral" (DOJ white paper: The Purpose and Impact of the CLOUD Act). Data location alone doesn't answer the question; whether the provider holds the key does.
How DuoKey Supports HYOK and BYOK
DuoKey provides the customer-side key service for these platform options from one key management layer. DuoKey KMS splits keys with multi-party computation (MPC), so no cloud provider, operator or compromised host holds a complete key.
- Microsoft 365 DKE: DuoKey for Microsoft 365 Double Key Encryption provides distributed key management with MPC and zero-trust access controls, and is listed on Microsoft AppSource.
- Microsoft 365 Customer Key: DuoKey supplies the key service for Microsoft 365 Customer Key with MPC-backed custody.
- AWS XKS: DuoKey for AWS XKS keeps root key material outside Amazon; applications still call AWS KMS, and AWS never holds a complete key.
- Salesforce: DuoKey EKM for Salesforce works with the Cache-Only Key wrapper.
- Snowflake: DuoKey Tri-Secret Secure for Snowflake.
- Oracle Database: DuoKey for Oracle TDE connects through a PKCS#11 library to an external, tenant-isolated keystore.
- ServiceNow: key management for ServiceNow CLE and Edge Encryption.
- Your own applications: the DuoKey KMS client.
For deployment location, availability design or certifications, contact DuoKey.
FAQ
Q: What is hold your own key (HYOK)?
Hold your own key is a cloud encryption model in which encryption keys stay in a key manager you control, and the cloud provider must ask that key manager to perform each wrap or unwrap operation. The provider stores only ciphertext, so it cannot decrypt without your key service. Revoke access and the data becomes unreadable to the provider.
Q: What is the difference between BYOK and HYOK?
With BYOK you own the key, but the provider's service uses it to decrypt your data in normal operation. With HYOK the key never leaves your infrastructure and the provider can only request operations from it. BYOK gives lifecycle control and revocation; HYOK also removes the provider's ability to decrypt on its own, at the cost of availability responsibility and some features.
Q: Does Microsoft 365 support HYOK?
Yes, through Microsoft Purview Double Key Encryption. DKE protects labelled content with two keys, one in your DKE service and one in Microsoft Azure, and both are needed to open it. It runs in Microsoft 365 Apps for enterprise on Windows and comes with Microsoft 365 E5; protected content can't be searched, co-authored on the web or used by Copilot.
Q: Is Microsoft 365 Customer Key HYOK?
No. Customer Key is service encryption under root keys you control, a BYOK model. Microsoft states that you authorize Microsoft 365 to use your keys for eDiscovery, anti-malware, anti-spam and search indexing. Its main control is revocation, which leads to cryptographic deletion of your data.
Q: What does HYOK vs BYOK vs CYOK mean?
BYOK: you supply the key and the provider uses it. HYOK: you keep the key and the provider requests operations from it. CYOK ("control your own key") isn't standardized, so ask who holds the key at runtime and who can decrypt without your approval.
Q: What happens if my HYOK key service goes down?
New decryptions fail, so protected data is unavailable to the cloud service until the key service returns. Some services cache data keys briefly. HYOK key services therefore need redundancy, monitoring and a tested recovery plan.
Q: Does HYOK protect against the CLOUD Act?
HYOK changes what a provider can technically produce: without a usable key it can hand over only ciphertext. The US Department of Justice describes the Act as encryption neutral. Whether HYOK meets a specific legal requirement is a question for your counsel.
Conclusion: Hold the Key Where It Matters
Use hold your own key when the question is not "is my data encrypted?" but "who can decrypt it?" BYOK covers most regulated workloads; HYOK is for the slice the provider itself must not read.
- Classify data and identify the slice that needs HYOK
- Map each platform option to HYOK or BYOK (DKE and Customer Key differ)
- Confirm protected users can work without the lost features
- Decide who operates the key service, where, and at what availability target
- Define who authorizes, audits and revokes key access
- Test an outage and a revocation before production
References
- Microsoft Learn: Double Key Encryption (DKE)
- Microsoft Learn: Overview of Customer Key
- AWS KMS Developer Guide: External key stores
- Google Workspace Developers: Client-side encryption API overview
- Google Workspace Help: Protect your organization's data with client-side encryption
- Google Workspace Help: About client-side encryption
- Salesforce: Platform Encryption Implementation Guide (Cache-Only Key Service)
- Salesforce (forcedotcom on GitHub): Cache-Only Key Wrapper
- Snowflake Documentation: Tri-Secret Secure
- Snowflake Documentation: Understanding encryption key management
- Oracle Database 19c Advanced Security Guide: Configuring Transparent Data Encryption
- Oracle Database 19c Reference: TDE_CONFIGURATION
- US Department of Justice: The Purpose and Impact of the CLOUD Act (white paper, April 2019)
- US Department of Justice: CLOUD Act resources
Written by
DuoKey Team
Related Resources
Customer-controlled keys in the cloud
Discuss the decisions that matter most to your security programme.
Tell us where control is difficult today. We will help you identify a practical next step.