Bring Your Own Key (BYOK): Cloud Encryption Key Control

Bring Your Own Key (BYOK) is a cloud encryption model in which the customer — rather than the cloud service provider — generates, owns, and controls the cryptographic keys used to protect data stored or processed in a provider's infrastructure. This page describes the structural definition of BYOK, the technical mechanism by which key control is separated from cloud storage, the regulatory and operational scenarios that drive adoption, and the decision criteria that distinguish BYOK from adjacent models including provider-managed keys and Hold Your Own Key (HYOK) arrangements. The model is directly relevant to compliance obligations under NIST, HIPAA, and FedRAMP.

Definition and scope

BYOK is a key management architecture in which the customer supplies encryption keys to a cloud provider's encryption system, retaining the ability to revoke, rotate, or destroy those keys independently of the provider's operations. The cloud provider's platform uses the customer-supplied key material to perform encryption and decryption operations, but the provider does not hold persistent custody of the root key.

The scope of BYOK spans object storage, database services, virtual machine disk encryption, and SaaS-layer data protection across major cloud platforms. The term applies across all three dominant deployment models — Infrastructure as a Service (IaaS), Platform as a Service (PaaS), and Software as a Service (SaaS) — though the degree of customer key control varies significantly across these tiers.

BYOK must be distinguished from two adjacent models:

• Provider-Managed Keys (PMK): The provider generates, stores, and rotates keys entirely within its own key management infrastructure. The customer has no visibility into key material and cannot independently revoke access.
• Hold Your Own Key (HYOK): The customer retains the key entirely on-premises or in a customer-controlled Hardware Security Module (HSM), and the cloud provider's encryption services query the customer's key store in real time for every cryptographic operation. HYOK imposes higher latency and operational complexity than BYOK.

NIST SP 800-57 Part 1 Rev 5 (NIST SP 800-57) establishes foundational key management recommendations applicable to BYOK implementations, including key generation requirements, lifecycle phases, and separation-of-duties principles that inform how customer-controlled keys should be administered.

How it works

BYOK operates through a structured interaction between the customer's key management system (KMS) and the cloud provider's encryption layer. The sequence follows discrete phases:

1. Key generation: The customer generates a root key or master key in a FIPS 140-2 or FIPS 140-3 validated HSM under customer control. FIPS 140 validation is required for federal systems under FIPS PUB 140-3 and is a practical baseline for HIPAA and PCI DSS environments.
2. Key wrapping and import: The customer wraps (encrypts) the key material using the cloud provider's public key or a provider-supplied wrapping key, then imports the wrapped key into the provider's KMS (such as AWS KMS, Azure Key Vault, or Google Cloud KMS). The provider unwraps and stores the key in its managed HSM fleet, where it is available for cryptographic operations but is not exportable in plaintext.
3. Encryption operations: When data is written to the cloud service, the provider's platform calls the customer-supplied key to encrypt a data encryption key (DEK). This two-tier envelope encryption structure means the customer's key — the key encryption key (KEK) — wraps the DEK, which in turn encrypts the data. AES-256 is the standard algorithm for both tiers, consistent with FIPS 197.
4. Key rotation: The customer rotates the KEK on a schedule consistent with organizational policy or regulatory mandates. PCI DSS v4.0 Requirement 3.7.1 specifies that cryptographic key periods must be defined and enforced; BYOK customers must synchronize rotation with the provider's re-wrapping procedures.
5. Key revocation and deletion: The customer can revoke access to data by deleting or disabling the KEK. Because the DEKs are wrapped under the KEK, destruction of the KEK renders all wrapped DEKs — and the underlying data — cryptographically inaccessible. This mechanism is the primary control that distinguishes BYOK from provider-managed models in high-assurance exit scenarios.

The encryption providers available through this reference network include service providers that support BYOK integrations across IaaS, PaaS, and managed database environments.

Common scenarios

Healthcare and ePHI protection: Under the HIPAA Security Rule (45 CFR § 164.312(a)(2)(iv)), covered entities and business associates storing electronic protected health information (ePHI) in cloud environments use BYOK to maintain demonstrable control over encryption keys as part of their addressable implementation specifications. The U.S. Department of Health and Human Services (HHS) has issued guidance confirming that proper encryption with customer-controlled keys supports the safe harbor provision that eliminates breach notification obligations when key access is restricted.

Payment card data under PCI DSS: PCI DSS v4.0 (PCI Security Standards Council) Requirement 3.7 governs key management for stored primary account numbers (PANs). Merchants and processors deploying BYOK in cloud environments must demonstrate that key custodianship, dual control, and split knowledge requirements are met within the customer's own KMS — not delegated to the provider.

Federal and defense contracting: NIST SP 800-171 Rev 2, §3.13.10 requires cryptographic protection for Controlled Unclassified Information (CUI) on non-federal systems. Organizations pursuing Cybersecurity Maturity Model Certification (CMMC) Level 2 use BYOK to satisfy FIPS-validated encryption requirements while hosting workloads in commercial cloud environments, maintaining the key custody documentation required during assessment. The covers the broader regulatory landscape in which these frameworks operate.

Cloud provider exit and data sovereignty: Organizations subject to data residency requirements — including those imposed by the EU General Data Protection Regulation (GDPR) (EUR-Lex, Regulation 2016/679) — use BYOK as a technical mechanism to ensure that terminating access to the KEK constitutes effective deletion for GDPR Article 17 purposes, where physical deletion cannot be independently verified in a shared cloud environment.

Decision boundaries

Not all cloud encryption use cases are appropriate for BYOK. The decision to implement BYOK versus PMK or HYOK depends on four structural criteria:

Regulatory obligation vs. operational overhead: BYOK introduces key lifecycle management responsibilities — generation, rotation, revocation, auditing — that do not exist when the provider manages keys. Organizations without formal key management programs or qualified cryptographic operations staff may face compliance gaps if BYOK obligations are not resourced correctly. NIST SP 800-57 Part 1 identifies key management as a discipline requiring defined roles, documented procedures, and audit trails.

Threat model scope: BYOK does not protect against threats originating from the cloud provider's compute layer — a compromised provider environment can access plaintext data during active processing regardless of key custody. HYOK mitigates this exposure for static data by requiring real-time key queries to customer infrastructure, but does so at the cost of availability and latency. For workloads requiring protection against a potentially compromised provider, confidential computing environments (covered under NIST IR 8320, Hardware-Enabled Security) provide a stronger boundary than BYOK alone.

Provider capability alignment: BYOK support is not uniform across cloud services. Object storage and virtual machine disk encryption services in major clouds support BYOK broadly; some managed SaaS applications expose only PMK options or impose additional limitations on key rotation frequency. Procurement and architecture assessments must confirm BYOK availability at the specific service tier before designing a compliance program around it.

Exit and portability requirements: BYOK is the appropriate model when contractual or regulatory requirements mandate the ability to render cloud-hosted data inaccessible upon provider termination. The key deletion mechanism — destroying the KEK to invalidate all wrapped DEKs — functions as a practical deletion substitute for encrypted data. Industry professionals navigating provider selection for BYOK-capable services can reference the structured encryption providers for qualified vendor categories.

The how to use this encryption resource page describes how this reference network's coverage maps to compliance scenarios and professional use cases across these decision domains.