Retain Control of your Encryption Keys on the Cloud

Retaining control of your encryption keys on the cloud means ensuring your organization, not the cloud provider, holds the authority to create, rotate, disable, and audit the keys protecting your data. It matters because cloud provider-managed keys give you no independent audit trail, no revocation capability, and no way to prove to a regulator that your provider cannot access your data. The recommended action is to move to customer-managed keys (BYOK) for regulated workloads, and to HYOK for workloads where the cloud provider must be excluded from the key trust chain entirely.

Quick Answer: What Does Key Control on the Cloud Mean?

By default, all three major cloud providers (AWS, Azure, GCP) encrypt your data at rest automatically. The question is not whether encryption happens, but who controls the encryption keys. Provider-managed keys mean the cloud provider generates, stores, and rotates the keys on your behalf. You cannot independently disable them, audit individual decryption events tied to specific identities, or prove to an auditor that the provider cannot access your data. Customer-managed keys (BYOK) give you that control. Client-side encryption (HYOK) takes it further by ensuring the key never enters the cloud provider’s infrastructure at all. For most regulated workloads, BYOK with a FIPS 140-2 Level 3 HSM as the key generation source is the standard that satisfies PCI DSS, HIPAA, FedRAMP, and GDPR requirements.

Key Takeaways

• Cloud encryption is on by default; key control is not: Every major cloud provider encrypts data at rest automatically. The compliance-critical question is who controls the keys, not whether encryption is applied.
• Provider-managed keys fail most compliance frameworks: AWS-owned, Azure Microsoft-managed, and GCP Google-managed keys provide no per-operation audit trail, no independent key revocation, and no customer control over key lifecycle. They are insufficient for PCI DSS, HIPAA, FedRAMP, and GDPR regulated data.
• BYOK is the minimum standard for regulated cloud workloads: Bring Your Own Key gives you key provenance (you can prove where the key was generated), per-operation audit trail (every encrypt and decrypt is logged against your key), and immediate independent revocation (disable the key to instantly block access across all cloud services using it).
• HYOK is for workloads where the cloud provider must be excluded entirely: Hold Your Own Key means the cloud stores only ciphertext. The cloud provider cannot decrypt your data under any circumstance. Required for classified data, national sovereignty mandates, and zero-trust architectures.
• Multi-cloud key control requires an explicit governance architecture: Each cloud’s KMS is provider-native and does not extend to other clouds. Multi-cloud organizations need either a centralized BYOK source (a single external HSM feeding all cloud KMSes) or a unified client-side encryption layer (HYOK) to maintain consistent key governance across AWS, Azure, and GCP.

Why Cloud Provider-Managed Keys Are Not Enough

When you enable encryption on a cloud storage bucket, a database, or a virtual disk without specifying a customer-managed key, the cloud provider applies its default encryption using keys it generates, stores, and manages on your behalf. This is better than no encryption, but it leaves three critical gaps that compliance frameworks specifically require organizations to close.

No per-operation audit trail: Provider-managed keys do not generate a log entry for each individual encryption or decryption operation tied to an authenticated identity. You cannot prove to a PCI DSS QSA, a HIPAA auditor, or a FedRAMP assessor exactly who decrypted what data and when. Customer-managed keys generate this log in CloudTrail (AWS), Azure Monitor (Azure), or Cloud Audit Logs (GCP) for every encrypt and decrypt call.

No independent key revocation: With provider-managed keys, you cannot immediately disable or revoke the key to stop all access to your data in response to a security incident, a regulatory order, or a contract termination with a cloud provider. With customer-managed keys, disabling the key in KMS, Key Vault, or Cloud KMS immediately and atomically blocks all further encryption and decryption across every cloud service using that key, without deleting the data.

No cloud provider exclusion from the key trust chain: With provider-managed keys, the cloud provider holds and controls the keys that protect your data. Even with customer-managed keys (BYOK), the cloud provider has operational access to your imported key material while it is in their KMS. Only HYOK (client-side encryption before upload) fully excludes the cloud provider from the key trust chain.

The Three Key Control Models: Native, BYOK, and HYOK

There are three distinct models for managing encryption keys on the cloud, each with different security, compliance, and operational trade-offs.

Model 1: Native Cloud Provider Keys (Provider-Managed)

The cloud provider generates, stores, rotates, and manages all encryption keys. On AWS these are AWS-managed or AWS-owned KMS keys. On Azure these are Microsoft-managed keys. On GCP these are Google-managed encryption keys (GMEK). Encryption happens automatically at no additional cost, but the customer has zero control over the key lifecycle. There is no per-operation audit trail tied to customer identities, no independent revocation capability, and no way to demonstrate to a regulator that the cloud provider cannot access the data. Appropriate only for non-regulated, internal data where the cloud provider’s own security posture is fully within the organization’s trust boundary.

Model 2: BYOK (Bring Your Own Key): Customer-Managed Keys

BYOK means you generate key material outside the cloud provider using your own HSM or key management system, and import it into the cloud provider’s key management service. The best practice is to generate the key material in a FIPS 140-2 Level 3 validated hardware security module (HSM). Level 3 HSMs are designed so that key material cannot be extracted in plaintext even with physical access to the hardware, and they provide tamper evidence if extraction is attempted. You retain the original key material in your HSM. If you delete the imported copy from the cloud KMS, the cloud provider immediately loses the ability to encrypt or decrypt your data.

BYOK gives you three capabilities that provider-managed keys do not: (1) key provenance proof: you can demonstrate to an auditor that the key was generated in your FIPS-validated HSM and the cloud provider did not generate it; (2) per-operation audit trail: every encrypt and decrypt call against your customer-managed key is logged with the requesting identity, timestamp, and key identifier; (3) immediate independent revocation: disabling the key in the cloud KMS blocks access across all services using it without requiring the cloud provider’s cooperation.

The important trade-off with BYOK: the cloud provider still has operational access to the imported key material while it is resident in their KMS. The cloud provider uses your key to perform encryption and decryption operations within their infrastructure. This is not a defect of BYOK design. It is an inherent characteristic of the managed-KMS model. For workloads where even this operational access is unacceptable, HYOK is required.

Model 3: HYOK (Hold Your Own Key): Client-Side Encryption

HYOK means the encryption key never enters the cloud provider’s infrastructure. Your application or data pipeline encrypts data before uploading it to any cloud service. The cloud provider stores only ciphertext and cannot decrypt it under any operational circumstance, including a legal compulsion directed at the provider. This is the only model that fully excludes the cloud provider from the key trust chain.

HYOK is implemented by calling your external key management system or HSM directly from your application for every encrypt and decrypt operation. Every cloud read and write that involves sensitive data requires a call to your external KMS. This means your external KMS must be highly available for your applications to function. Planned or unplanned downtime in your external KMS creates a direct availability dependency for all cloud workloads using HYOK encryption.

HYOK also removes the ability to use cloud-native data processing features that require the cloud provider to access plaintext: server-side search indexing, cloud-native data transformation, analytics queries on encrypted fields, and AI/ML processing. Any cloud feature that operates on the data rather than just storing it requires either plaintext access (impossible with HYOK) or a trusted execution environment. This capability trade-off must be evaluated per workload.

GCP supports a CMEK-integrated HYOK option via Cloud External Key Manager (Cloud EKM), where CMEK-integrated services call your external KMS for every DEK encryption and decryption operation over a TLS-authenticated connection. This brings HYOK sovereignty to CMEK-integrated GCP services without requiring application-level encryption for every object. AWS does not have an equivalent native EKM integration.

BYOK vs. HYOK vs. Native: Decision Table

Dimension	Native (Provider-Managed)	BYOK (Customer-Managed Key in Cloud KMS)	HYOK (Client-Side / External Key)
Who generates the key	Cloud provider	Customer (imported into cloud KMS)	Customer (never enters cloud)
Cloud provider access to key	Yes (full control)	Yes (operational access during use)	No
Per-operation audit trail	No	Yes (in cloud KMS audit logs)	External KMS logs only
Independent key revocation	No	Yes (disable/delete key in cloud KMS)	Yes (revoke at external KMS)
Key provenance proof	No	Yes (from your HSM generation source)	Yes (fully customer-controlled)
Automatic key rotation	Yes (provider schedule)	Yes (cloud KMS schedule); not available for imported material	Fully customer-managed
FIPS 140-2 Level 3 option	No	Yes (via HSM-backed key store or Level 3 generation source)	Depends on external KMS hardware
Native cloud service integration	Yes	Yes	Partial (application-level) or via Cloud EKM (GCP)
Operational complexity	Low	Medium	High
Compliance coverage	Insufficient for PCI DSS, HIPAA, FedRAMP, GDPR	Satisfies most requirements	Satisfies strictest sovereignty requirements
Cost	Included in storage cost	KMS key fee + per-operation fee	External KMS infrastructure cost
Best for	Non-regulated internal data	Most regulated cloud workloads	Classified data, sovereignty mandates, zero-trust

How BYOK Works Across AWS, Azure, and GCP

Every major cloud provider supports BYOK but each implementation has its own key wrapping mechanism, import process, and constraints. Understanding the per-cloud specifics is essential for designing a consistent multi-cloud key governance architecture.

BYOK on AWS (AWS KMS Import Jobs): Create a KMS Import Job for the target key ring and download a wrapping key (RSA 2048 public key or AES-256 symmetric wrapping key). Generate your AES-256 key material in your HSM. Wrap your key material using the downloaded wrapping key. Upload the wrapped material to KMS; the key Origin is set to EXTERNAL. AWS KMS unwraps and stores your key material. You retain the original in your HSM; deleting the imported copy from KMS immediately revokes AWS’s ability to use it. Constraint: automatic rotation is not available for imported keys. See our detailed guide on AWS KMS security for the full trust boundary analysis.

BYOK on Azure (Azure Key Vault Key Import): Generate your RSA key (2048, 3072, or 4096 bit) or AES key in your HSM. Transfer the key to Azure Key Vault using the BYOK transfer package: wrap the key material with the Key Vault exchange key downloaded for your vault. Upload the BYOK package to Azure Key Vault. For hardware-protected keys in Key Vault Premium, the imported key material is stored in an Azure-managed HSM module. You retain the original in your own HSM; deleting the key from Key Vault revokes Azure’s ability to use it for all resources encrypted with that key.

BYOK on GCP (Cloud KMS Import Jobs): Create a Cloud KMS Import Job specifying the target key ring and wrapping algorithm (RSA_OAEP_3072_SHA256 or AES_256_KWP). Download the wrapping key. Generate your AES-256 key material in your HSM. Wrap your material using the wrapping key. Upload the wrapped material via the Cloud KMS API. Cloud KMS unwraps your material (inside the HSM cluster if the target protection level is HSM) and stores it as a key version. Constraint: automatic rotation is not available for keys with imported material. See our guide on Google Cloud data encryption options for the full GCP encryption architecture.

IAM Access Control: Who Can Use and Manage Your Keys

Retaining key control requires not just owning the key material but also controlling who can use the key for cryptographic operations and who can manage the key lifecycle. Each cloud provider’s access control model for keys works differently.

AWS KMS: Access to KMS keys is controlled through a mandatory key resource policy (which must explicitly grant permissions to any principal) and IAM identity policies (a secondary layer that can grant permissions within what the key policy allows). The key policy is the primary control: without an explicit grant in the key policy, no principal can use the key regardless of their IAM permissions. Separate key administrator roles (who can manage the key) from key user roles (who can encrypt and decrypt) to prevent any single identity from both managing and using the key.

Azure Key Vault: Access to Key Vault keys uses Azure RBAC (the recommended model) or legacy access policies. With Azure RBAC, roles such as Key Vault Crypto Officer (manage keys), Key Vault Crypto User (use keys for encrypt/decrypt), and Key Vault Reader (view metadata) separate management from operational use. Apply roles at the key level, not at the vault level, for least-privilege access.

GCP Cloud KMS: Access to Cloud KMS keys uses Google Cloud IAM with two key roles: Cloud KMS Admin (create, delete, manage key policies) and Cloud KMS Crypto Key Encrypter/Decrypter (use keys for encrypt and decrypt). The Cloud KMS Admin role cannot use keys for cryptographic operations, enforcing separation of management from use. Organization Policy constraints can require specific key configurations and prevent services from using non-CMEK encryption.

Across all three clouds, the core principle is the same: separate who manages keys from who uses them, apply least-privilege access at the individual key level rather than at the KMS or Key Vault level, and use audit logging to detect any access that does not conform to the approved access pattern.

Key Rotation: Maintaining Key Control Over Time

Generating a customer-managed key and importing it once is the beginning of key control, not the end. Retaining control over time requires a defined rotation process that keeps keys current and limits the cryptographic exposure window if a key is compromised.

For customer-managed keys with cloud-generated material, all three major cloud providers support automatic key rotation: AWS KMS supports 90-day to 7-year rotation schedules. Azure Key Vault supports configurable rotation policies with notification periods. GCP Cloud KMS supports configurable rotation schedules with a minimum 24-hour rotation period. When rotation occurs, a new key version becomes the primary for new encryption operations while previous versions are retained for decryption of previously encrypted data. No re-encryption of existing data is required for standard key rotation.

For BYOK keys with imported material, automatic rotation is not available from any cloud provider’s KMS (you cannot have the cloud KMS generate new versions of your externally originated key material). You must manage rotation manually: generate new key material in your HSM, import it as a new key version, designate it as the primary version, and plan the transition to ensure in-flight operations complete before the previous version is retired. This is the most operationally demanding aspect of BYOK key management and must be planned before the BYOK deployment, not after.

For HYOK (client-side encryption), rotation requires re-encrypting all data encrypted under the old key with the new key, because the cloud provider stores only ciphertext and cannot transparently handle key versioning on your behalf. This is a significant operational undertaking for large datasets and must be factored into the HYOK architecture design from the start.

Audit Logging: Proving Key Control to Auditors

Retaining key control means more than owning the key. It means being able to prove to a regulator or auditor that you controlled who accessed the key and when every decryption event occurred. This requires audit logging at two levels: storage access logs (who read what data) and key management logs (who used which key to decrypt it).

Key management audit logs by provider:

• AWS KMS + CloudTrail: Every KMS API call generates a CloudTrail event with the key ARN, operation, requesting IAM identity, source IP, region, and timestamp. Management events (key creation, policy changes, ScheduleKeyDeletion) are always on. Data events (GenerateDataKey and Decrypt) must be enabled explicitly for regulated workloads and provide the per-operation evidence required by PCI DSS Requirement 10 and HIPAA Audit Control (45 CFR 164.312(b)).
• Azure Key Vault + Azure Monitor: Key Vault diagnostic logs capture every key operation (WrapKey, UnwrapKey, GetKey, CreateKey, DeleteKey) with the requesting identity, timestamp, and result. Diagnostic settings must be configured to route logs to a Log Analytics workspace or Storage Account. Enable Azure Monitor alerts for key disable, key deletion, and access from unexpected service principals.
• GCP Cloud KMS + Cloud Audit Logs: Admin Activity logs (always on) capture key creation, version management, policy updates, and Import Job events. Data Access logs (must be enabled explicitly) capture every Encrypt and Decrypt call made by GCP services against your CMEK key, including the requesting service account and key version used. Route logs to a separate, write-protected project for long-term retention and tamper protection.

Regardless of cloud provider, route all key management audit logs to a write-protected destination in a separate account or project that cannot be modified or deleted by the same identity that manages the keys. PCI DSS requires 12 months of log retention with 3 months immediately available. Configure real-time alerts for any key disable, key deletion, or decrypt operation from an unauthorized principal.

Multi-Cloud Key Control Architecture

Multi-cloud key control is more complex than single-cloud key control because each cloud provider’s KMS is provider-native: AWS KMS keys cannot be used in Azure or GCP; Azure Key Vault keys cannot be used in AWS or GCP; GCP Cloud KMS keys cannot be used in AWS or Azure. Key material generated in one cloud’s KMS cannot be directly transferred to another cloud’s KMS. Organizations operating across multiple clouds need one of three architectural patterns to maintain consistent key governance.

Pattern 1: Per-cloud customer-managed keys with centralized governance

Use AWS KMS customer-managed keys for AWS workloads, Azure Key Vault customer-managed keys for Azure workloads, and GCP Cloud KMS customer-managed keys for GCP workloads. Each cloud’s data is protected by that cloud’s native KMS, providing native performance and native service integration. A centralized key lifecycle management platform aggregates key inventory, rotation schedules, and audit logs from all three providers into a single governance view. This is the most operationally practical model for most organizations and does not require cross-cloud key distribution.

Pattern 2: Centralized BYOK from a single external HSM source

Generate all encryption key material from a single external FIPS 140-2 Level 3 HSM or HSM as a Service that is independent of all cloud providers. Import derived keys into AWS KMS for AWS workloads (via KMS Import Jobs), into Azure Key Vault for Azure workloads (via BYOK transfer package), and into GCP Cloud KMS for GCP workloads (via Cloud KMS Import Jobs). All encryption across all three clouds traces back to a single authoritative hardware key source. This provides cross-cloud key provenance consistency and a single point of key revocation: deleting the key material from all three cloud KMSes simultaneously blocks access across the entire multi-cloud estate. Encryption Consulting’s HSM as a Service provides the external FIPS 140-2 Level 3 HSM infrastructure for this model, accessible from AWS, Azure, and GCP simultaneously without cloud-provider dependency.

Pattern 3: HYOK with a shared client-side encryption layer

Encrypt data at the application or pipeline layer before it reaches any cloud provider, using a single external key management system that is independent of all cloud providers. AWS, Azure, and GCP each store only ciphertext. The cloud provider is entirely excluded from the key trust chain for all three clouds simultaneously. This provides the strongest cross-cloud sovereignty posture but requires all applications to handle cryptographic operations before any cloud API call, and your external KMS must maintain the availability required by all cloud workloads simultaneously.

For an inventory of all current key configurations, rotation statuses, and access policy gaps across a multi-cloud estate, Encryption Consulting’s CBOM Secure discovers all KMS keys, encryption configurations, and key management policies across AWS, Azure, and GCP accounts and generates a Cryptographic Bill of Materials (CBOM) in CycloneDX format identifying inconsistencies and compliance gaps.

Questions to Ask Your Cloud Provider

Before deploying sensitive data to any cloud service, ask the cloud provider the following questions to verify you are retaining key control:

1. Do you support customer-managed keys (BYOK) for the specific service I am using? Native encryption is available for most services, but BYOK support varies by service. Not every cloud service supports customer-managed keys. Verify BYOK support for the specific service before deployment, not after.
2. What FIPS validation level does the hardware that stores my customer-managed key have? AWS KMS standard is Level 2. AWS CloudHSM custom key store is Level 3. Azure Key Vault Premium uses HSM-backed keys. GCP Cloud HSM is Level 3. For FedRAMP High and PCI DSS Requirement 3.7.1, Level 3 is required.
3. Can I import my own key material and retain the original outside your infrastructure? Confirm BYOK import support and understand the import process, wrapping algorithm, and constraints (especially the automatic rotation limitation for imported keys).
4. If I disable or delete the customer-managed key, how quickly is all access to my data revoked across all services using that key? The answer should be: immediately, without any grace period for the cloud service to access previously decrypted data.
5. Is every encryption and decryption operation against my customer-managed key logged with the requesting identity, key version, and timestamp? Confirm that Data Access audit logs are available and how they must be enabled. Confirm the log format and whether it meets PCI DSS or HIPAA evidence requirements.
6. As the cloud provider, can you access my encryption keys? A provider-managed key answer is yes. A customer-managed key answer should be: we cannot initiate key use without an authenticated API request passing your key policy and IAM checks. A HYOK answer should be: no, we store only ciphertext.

Compliance: PCI DSS, HIPAA, FedRAMP, and GDPR

PCI DSS v4.0.1 (mandatory since March 31, 2025): Requirement 3.5.1 requires protection of stored cardholder data using strong cryptography with key management controls. Provider-managed keys do not satisfy this because the organization does not control the key lifecycle. Customer-managed BYOK keys satisfy 3.5.1. Requirement 3.7.1 requires key generation using a HSM or industry-accepted technology; a FIPS 140-2 Level 3 HSM as the BYOK generation source satisfies this. Requirement 3.7.4 requires periodic key rotation; customer-managed keys with automatic rotation satisfy this. Requirement 10 requires audit logging of all access to cardholder data and associated cryptographic keys; CloudTrail Data Access events for KMS, Azure Key Vault diagnostic logs with UnwrapKey events, and GCP Cloud Audit Logs Data Access events satisfy this.

HIPAA: The HIPAA Technical Safeguard for Encryption and Decryption (45 CFR 164.312(a)(2)(iv)) requires encryption of ePHI at rest. Customer-managed BYOK keys satisfy this for all major cloud providers when the associated Business Associate Agreement (BAA) is in place. The Audit Control standard (45 CFR 164.312(b)) requires audit logs of ePHI access activity; key management data access logs that capture every decrypt call tied to a requesting identity satisfy this standard.

FedRAMP: FedRAMP Moderate requires FIPS 140-2 Level 2 validated cryptographic modules (SC-12, SC-28); standard customer-managed KMS keys on all three major cloud providers satisfy this. FedRAMP High requires FIPS 140-2 Level 3 validated modules; this requires AWS CloudHSM custom key store, Azure Key Vault Managed HSM, or GCP Cloud HSM protection level for the customer-managed key.

GDPR: GDPR Article 32 requires appropriate technical and organizational measures for personal data protection, including encryption. Customer-managed BYOK keys support GDPR’s right to erasure: disabling or destroying the customer-managed key renders all data encrypted with it effectively inaccessible, which can serve as a technical implementation of erasure for data that cannot otherwise be selectively deleted (immutable stores, backups). Customer-managed keys also support GDPR data portability by giving organizations the ability to revoke access instantly when changing cloud providers.

How Encryption Consulting Can Help

Encryption Consulting is an applied cryptography and cloud security firm with ISO/IEC 27001:2022 and SOC 2 certifications. We help organizations design and implement multi-cloud key control architectures from initial strategy through compliance evidence generation.

• Multi-Cloud Key Control Architecture: We assess your current cloud encryption posture across AWS, Azure, and GCP, identify all workloads using provider-managed keys where customer-managed keys are required, design the target BYOK or HYOK architecture (key hierarchy, HSM infrastructure, per-cloud import process, rotation schedule, IAM access model, audit log routing), and implement the migration plan. See our cloud advisory services.
• HSM as a Service for BYOK and HYOK: For BYOK architectures requiring FIPS 140-2 Level 3 key generation from a source independent of all cloud providers, or for HYOK architectures requiring an external key management system, Encryption Consulting’s HSM as a Service provides dedicated HSM infrastructure accessible from AWS, Azure, and GCP simultaneously. All encryption across all clouds traces back to a single authoritative Level 3 hardware source that is not operated by any cloud provider.
• CBOM Secure for Cryptographic Discovery: Organizations that have grown cloud usage organically often have a mix of provider-managed keys, customer-managed keys, imported keys, and unconfigured services across dozens of accounts and projects. Encryption Consulting’s CBOM Secure discovers and inventories all encryption configurations, KMS key configurations, and access policies across AWS, Azure, and GCP, generating a Cryptographic Bill of Materials in CycloneDX format that identifies compliance gaps and supports PCI DSS v4.0.1 Requirement 12.3.3 documentation.
• Compliance Advisory (PCI DSS, HIPAA, FedRAMP, GDPR): We map your multi-cloud key control architecture to the specific requirements of PCI DSS v4.0.1, HIPAA, FedRAMP High, and GDPR. We identify control gaps, design the remediation plan, produce the compliance evidence package, and assist with QSA, HIPAA auditor, and FedRAMP assessor inquiries. See our Compliance Advisory Services.
• PQC Readiness: NIST finalized post-quantum cryptography standards FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), and FIPS 205 (SLH-DSA) in August 2024. NIST IR 8547 points toward deprecating RSA and ECC for new uses around 2030. The RSA and ECC keys used in BYOK wrapping operations and in asymmetric signing across all three clouds will need to transition to post-quantum algorithms. Encryption Consulting’s PQC Readiness service maps your multi-cloud cryptographic key estate against the post-quantum migration timeline.

To discuss your multi-cloud key control strategy, contact Encryption Consulting.

Conclusion

Retaining control of your encryption keys on the cloud is not a configuration detail. It is the foundational architectural decision that determines whether your organization can satisfy compliance frameworks, respond to security incidents, change cloud providers, and demonstrate to auditors that your data is protected on your terms rather than the cloud provider’s terms.

The starting point is moving from provider-managed keys to customer-managed BYOK keys for all regulated workloads. The key should be generated in a FIPS 140-2 Level 3 HSM that your organization controls, imported into each cloud’s KMS using the provider’s BYOK import mechanism, and protected by an IAM access model that separates key administrators from key users. Every encryption and decryption event should be logged in an audit trail that captures the requesting identity and is routed to a tamper-protected destination you control.

For multi-cloud environments, a centralized external HSM as the single BYOK source across all clouds provides both key provenance consistency and cross-cloud revocation capability. For the most sensitive workloads, HYOK with client-side encryption fully excludes all cloud providers from the key trust chain.

For the per-cloud implementation detail on BYOK and CMEK architecture, see our guides on AWS KMS security, Google Cloud data encryption, and our AWS KMS vs. CloudHSM comparison.

Frequently Asked Questions

What does retaining control of encryption keys on the cloud mean?

It means your organization, rather than the cloud provider, holds authority to create, rotate, disable, destroy, and audit the keys protecting your data. Provider-managed keys give you no independent audit trail, no revocation capability, and no ability to prove the cloud provider cannot access your data. Customer-managed keys (BYOK) and client-side encryption (HYOK) restore that control.

What is BYOK (Bring Your Own Key) and how does it work across cloud providers?

BYOK means you generate key material outside the cloud provider using your own HSM, wrap it using the provider’s import mechanism, and import it into the cloud KMS. You retain the original in your HSM; deleting the imported copy immediately revokes the cloud’s ability to use the key. AWS uses KMS Import Jobs (Origin: EXTERNAL), Azure uses the BYOK transfer package for Key Vault, and GCP uses Cloud KMS Import Jobs. All three retain your key in their KMS and use it for operations; the cloud provider has operational access to the imported material while in their KMS.

What is HYOK (Hold Your Own Key) and when should I use it?

HYOK means your key never enters the cloud provider’s infrastructure. Your application encrypts data before upload; the cloud stores only ciphertext. Use HYOK when the cloud provider must be completely excluded from the key trust chain: classified data, national data sovereignty mandates, or zero-trust architectures where no third party is trusted with key material. HYOK requires your external KMS to be highly available for every cloud read and write and removes the ability to use cloud-native data processing features that require plaintext access.

How do I retain key control across multiple cloud providers?

Three patterns: (1) Per-cloud customer-managed keys with a centralized governance platform aggregating audit logs and rotation status. (2) A single external HSM or HSM as a Service as the BYOK source for all clouds, so all encryption traces back to one authoritative hardware root. (3) HYOK with client-side encryption at the application layer before any cloud API call, using a single external KMS independent of all cloud providers.

Does retaining key control satisfy PCI DSS and HIPAA requirements?

Yes, when correctly implemented. For PCI DSS v4.0.1, BYOK with a FIPS 140-2 Level 3 HSM generation source satisfies Requirements 3.5.1, 3.7.1, 3.7.4, and 10 (with Data Access audit logging enabled). For HIPAA, customer-managed BYOK keys satisfy the encryption safeguard (45 CFR 164.312(a)(2)(iv)) and key management audit logs satisfy the Audit Control standard (164.312(b)). Provider-managed keys alone satisfy neither framework.

What questions should I ask my cloud provider about key control?

Ask: (1) Do you support BYOK for the specific service I am using? (2) What FIPS validation level protects my customer-managed key? (3) Can I import my own key material and retain the original outside your infrastructure? (4) How quickly is access revoked if I disable or delete the key? (5) Is every encrypt and decrypt call logged with the requesting identity? (6) Can you, as the cloud provider, access my encryption keys?