Introduction to Key Management

Cryptographic key management is pivotal for ensuring the confidentiality and integrity of sensitive data. In the era of cloud computing, information sharing of access and data between multi-cloud environments has become common. While key management in single-provider implementations is relatively straightforward, managing keys across multiple cloud service providers (CSPs) is significantly more complex. Key management services and solutions (KMS) are critical for information protection throughout the key and certificate lifecycle, including the creation, storage, exchange, usage, rotation, and deletion of the certificates and keys.

The Cloud Security Alliance (CSA) Cloud Key Management Working Group has published this paper to share their recommendations for multi-cloud KMS. This document analyzes the security, regulatory, technical, and business considerations associated with key management in multi-cloud environments and recommends considerations for safeguarding symmetric and asymmetric keys, certificates, and secrets in such implementations.

This paper’s recommendations align with established key management frameworks including NIST SP 800-57 (Recommendation for Key Management) and NIST SP 800-130 (A Framework for Designing Cryptographic Key Management Systems), which provide comprehensive guidance applicable throughout multi-cloud environments.

Purpose

When cryptographic operations should be performed across multiple cloud models, providers, or deployments, key management complexity is significantly increased. Such operations may include encrypting and decrypting information to uphold confidentiality, signing and validating signed data to protect data integrity, or securely authenticating between platforms to establish trust.

Disparate CSPs, applications, environments, and cloud models vary significantly in governance, responsibility, deployment model (e.g., public, private, hybrid), and risks. CSPs often design their KMS to protect sensitive encryption keys from export, further complicating the synchronization and usage of symmetric keys or asymmetric key pairs between multiple providers. On the other hand, Bring-Your-Own-Key (BYOK) and Hold-Your-Own-Key (HYOK) responsibility models require organizational maturity and key management expertise. Third-party KMS solutions may solve many of these issues but also introduce secondary risks (security and operational risks) by introducing a vendor to mitigate these challenges. This paper addresses the common risks and challenges by suggesting strategies and solutions based on best practices for maintaining and using keys securely.

Scope

The scope of this paper is limited to understanding implementations common in multi-cloud architectures where the sharing or usage of keys, key material, and secrets affect more than one CSP entity, service provider, hybrid usage, or modality and how distinct KMS approaches address identified risks.

Usage of This Document

This paper includes security, technical, regulatory, and business considerations associated with various key management models in multi-cloud environments. To aid the reader in first understanding key management complexities as they relate to key management models and relevant multi-cloud patterns, several such usages are presented, identifying where keys, key material, and secrets may involve multiple providers throughout the key management lifecycle (Figure 1). Following a review of these models and use cases, this document briefly discusses the critical risks or other business factors that may impact key management practices. In addition, three common key management approaches are discussed, sharing how each addresses identified risks or is otherwise suited for organizations based on the identified determinants. This approach is intended to allow the reader to relate to one or more models best suited for their environment and architecture, with a clear understanding of impacts and residual risks.

Target Audience

This document is designed for cloud architects and key management teams who must secure and access sensitive information across heterogeneous cloud environments; governance teams and auditors seeking to evaluate controls against industry best practice criteria; and vendor management teams who need to navigate complex technical and business factors that contribute to selection of solutions to aid in delivery of these services.

Figure 1: Key Management Lifecycle

Best Practices for Multi-Cloud Key Management

It is important to understand the complexity of managing keys to understand key management models and how multi-cloud architectures can affect the key lifecycle, access to key materials, locus of cryptographic operations, capabilities, limitations, and responsibilities for underlying key material.

Additionally, concepts related to key management models, patterns, and architectures may overlap or use similar terminology. An example of this is the term BYOK, commonly used in reference to a key type (external origin), a KMS architecture (customer on-premises KMS), and a key responsibility model (the implied responsibilities associated with the usage of such keys and system).

While multi-cloud use cases, risks, and architectures are discussed herein, key management best practices for these implementations are explored in further depth in other CSA resources. The authors recommend reviewing the following CSA resources about best practices before proceeding:

• Key Management in Cloud Services (Section 2, KMS Foundations)
• Key Management Lifecycle Best Practices (Section 2.3, KMS Overview)
• Key Responsibility Models

Identifying Multi-Cloud Key Management Use Cases

The first step in identifying the best approach for key management between cloud providers is to document the use cases involving key usage and flow within and between the various cloud providers. It is recommended that the entity analyze each use case, where all relevant cryptographic operations should be performed, which keys should be present, and document these findings.

This exercise should include identifying each distinct key as part of a documented cryptosystem containing, at minimum, the key name, unique identification (e.g., resource name), cryptography details (e.g., cipher, cryptographic algorithm, bit strength), origin, lifecycle protections, and allowed usage. It is then important to identify how keys are used by each application/service, how keys are managed, and how risks are mitigated through access limitations. A full understanding of how each key is managed, shared, used, and monitored with respect to this multi-cloud environment is required to determine the least privileges necessary to perform activities and risks associated with each, and also understand where other factors such as latency, storage limitations, key access, or regulatory compliance factors may influence architecture.

An example analysis is included below, whereby a custom application is deployed to one cloud provider, a Platform-as-a-Service (PaaS) provider (CSP1), and information is processed from a relational database (RD) then delivered to a SaaS application (App) for further processing, which is hosted by a second PaaS provider (CSP2). Once processing is complete, the results are forwarded to CSP1 for storage in a data warehouse service (DW). In this example, unique CSP- and customer-managed keys may be present for each applied protection.

This information above may be captured in tabular form, similar to the example in Table 1:

Step#	Environment From	Component From	Type	Environment To	Component To	Key	Key Responsibility
1	CSP1	RD	at rest	-	-	Key1	CSP1
2	CSP1	RD	in transit	CSP1	App	Key2	Customer
3	CSP1	App	in transit	CSP2	SaaS	Key3	Customer
4	CSP2	SaaS	at rest	CSP2	SaaS storage	Key4	CSP2
5	CSP2	SaaS	in transit	CSP1	App	Key5	Customer
6	CSP1	App	at rest	CSP1	DW	Key6	CSP1

Table 1: Example Analysis of a Multi-Cloud KMS Use Case

Architecture and Key Usage Examples

This discussion considers the following common multi-cloud architectures, models, and patterns. In each example, unique factors such as key attributes, key ownership, data portability, or management responsibilities may impact the reader’s ultimate recommendations and decisions for managing keys and data across multiple cloud providers. Before considering how KMS architecture models affect an organization’s operations, it is important to understand how the key lifecycle itself may be affected by the entity’s multi-cloud implementation models and the risks these activities commonly incur.

The following section reviews common multi-cloud architectures and the critical key management considerations in the context of each workload.

Data Lakes

KMS is crucial for ensuring data security stored in the data lake. It manages the generation, storage, rotation, and access of encryption keys that protect sensitive information both at rest and in transit. KMS integrates with the cloud provider’s identity and access management (IAM) to enforce access control policies.

When managing keys for data lake services, it is important to consider the compatibility of the KMS and desired data lake services. During the data lake provisioning process, customer-provided key preferences should be specified, and encryption keys in KMS should be created to meet all applicable security requirements for data protection and encryption keys¹. For all subsequent data access, the key is required with every data read/write to ensure transparent data encryption/decryption; however, modern implementations often use envelope encryption where a data encryption key (DEK) is cached temporarily after KMS-authorized decryption.

Data is encrypted using a DEK, which is itself encrypted with a master key, or Key Encryption Key (KEK), managed in the KMS. Clients fetch the encrypted DEK securely, and the KMS handles decryption under strict access policies. Envelope encryption minimizes key exposure to applications. Client-side encryption implementations should retrieve keys from KMS rather than managing keys independently, as shown in Figures 2 and 3.

In addition, the data lake provider often natively supports its own encryption at rest through its native tooling, with or without customer access to such keys. While native tooling secures the infrastructure, customers usually lack direct control over those keys and it should be an important consideration while building regulatory-compliant data lakes.

Figure 2: Server-Side Transparent Encryption Pattern (Data Lakes Encryption Patterns)

Figure 3: Client-Side Application Encryption (Application-Managed DEK with KMS Integration)

Step	Server-Side	Client-Side
Key Fetch	Data lake -> KMS	Application -> KMS
Encryption	Data lake (transparent)	Application (explicit)
Storage	Encrypted data + CiphertextBlob	Encrypted data (pre-encrypted)
Decryption	Data lake -> KMS for DEK	Application -> KMS for DEK

Table 2: Comparison of Server-Side and Client-Side

In addition to these complexities, data lakes may implement additional data protection techniques:

• Dynamic Data Masking: Presents redacted views of sensitive data based on user privileges. This is typically an access control layer managed through the data lake’s policy engine and does not involve separate cryptographic key management

• Tokenization: Replaces sensitive data elements (e.g., payment card numbers) with non-sensitive, non-mathematically-derived tokens. A secure token vault maintains the mapping between tokens and original values. In multi-cloud environments, ensuring consistent access, security, and lifecycle management for the tokenization keys and vault becomes a critical key management challenge. This infrastructure should be integrated with or governed by the same KMS strategies discussed in Section 4 to maintain a unified security posture

Additionally, using key strengths appropriate to the protected data classification is recommended for enhanced data security within the data lake.

Operational Considerations at Scale

When implementing customer-managed encryption for data lakes at petabyte scale, several operational trade-offs emerge:

• KMS API Call Patterns: While envelope encryption minimizes KMS interactions by caching decrypted DEKs in memory, large-scale data lakes still generate significant KMS traffic. A typical scenario involves decrypting DEKs once per cache expiration period (e.g., every 5–60 minutes) per processing node, but with thousands of distributed workers processing diverse datasets with multiple DEKs, aggregate KMS API volume can reach tens or hundreds of thousands of calls per hour

• Performance Considerations: KMS API latency (10–50ms same-region, 50–200ms+ cross-region/cross-cloud) affects job startup time and cold-start scenarios

  • KMS rate limits (e.g., AWS KMS ~50,000 req/sec per region) can become bottlenecks during burst scenarios such as massive job launches or cluster scaling events. DEK cache misses during high-throughput operations can create performance variability

• Cost Implications: Cloud KMS services charge per API call ($0.03–$0.15 per 10,000 requests depending on provider/operation). For data lakes with hundreds or thousands of processing nodes continuously refreshing DEK caches, monthly KMS costs can range from hundreds to thousands of dollars, becoming a significant operational expense at scale

• DEK Caching Trade-Offs: Organizations should balance:

  • Longer cache TTL = reduced KMS costs and latency but slower response to key rotation or revocation
  • Shorter cache TTL = faster security response but higher costs and potential performance impacts
  • Distributed cache synchronization challenges across ephemeral compute nodes (e.g., Spark clusters, Lambda functions, container workloads)

• Cross-Cloud Amplification: Multi-cloud data lakes face additional complexity:

  • Higher latency for cross-cloud KMS calls (100–300ms+)
  • Data sovereignty requirements may mandate region-specific KMS instances
  • Multiple KMS platforms require consistent cache policies and monitoring
  • Network costs for cross-cloud KMS API traffic

• Key Rotation at Scale: Rotating KEKs for petabyte-scale data lakes requires re-encrypting potentially millions of DEKs (not the data itself), which demands careful orchestration to avoid cache invalidation storms and service disruptions

These trade-offs inform the architectural decisions discussed in Section 4, where solutions like customer-held keys (Section 4.2) may provide different performance/cost/control balances optimized for specific scale and compliance requirements.

Data Pipelines

Data pipelines process and transmit large volumes of data across multiple stages (ingestion, transformation, aggregation, and storage). All sensitive data flowing through pipelines requires encryption key management strategy aligned with data sensitivity and compliance requirements.

The focus of this section is on the encryption of data in motion and ensuring confidentiality and integrity with the help of KMS. While data masking or tokenization² is a suitable approach for privacy-preserving, these concepts were intentionally left out to maintain focus.

Encryption Architecture Decisions

Encryption levels for KMS include:

• Session-Level Encryption: Data in transit between pipeline components (e.g., Kafka to Spark to data lake) should be protected using Transport Layer Security (TLS) 1.2+ or mutual TLS (mTLS) for mutual authentication. This protects against network interception but assumes trust in pipeline processing environments

• Application-Level Encryption: For zero-trust or high-security scenarios, encrypt data before it enters the pipeline using approved algorithms (AES-256-GCM)

Encrypted data remains protected even if pipeline infrastructure is compromised, the CSP administrators access systems, and even if data temporarily lands in lower-security intermediate storage.

Application-level encryption requires each pipeline stage to:

1. Retrieve decryption keys from KMS with appropriate authorization.
2. Decrypt data for processing (plaintext exists only in secure memory).
3. Re-encrypt output before passing to the next stage.
4. Discard keys from memory after processing.

One trade-off would be that, although application-level encryption provides stronger confidentiality, it increases complexity (key distribution to all pipeline stages) and may impact performance (encrypt/decrypt overhead at each stage).

In multi-cloud key management, when pipelines span multiple CSPs (e.g., ingest in AWS, process in Azure, store in GCP), key management becomes complex and the following considerations should be taken into account as per examples:

• Disparate Authorization Models: AWS IAM policies ≠ Azure RBAC ≠ GCP IAM, requiring consistent access control translation across providers

• Key Synchronization: Ensure pipeline stages in different clouds can access the same encryption keys through unified KMS or federated key access

• Independent Keys per Cloud: Alternatively, use separate keys per CSP to contain blast radius, re-encrypting data when crossing cloud boundaries

• Centralized Key Management: Unified KMS across the pipeline enables consistent key rotation, centralized audit logging, and simplified compliance (e.g., single audit trail vs. correlating logs from multiple CSPs)

Best Practice: Match encryption strength to data classification. Financial transactions and PII require AES-256 with application-level encryption; operational metrics may need only TLS in transit with CSP-native encryption at rest.

Data Streaming

Data streaming involves the continuous flow of data from producers through brokers (e.g., Apache Kafka, AWS Kinesis, Azure Event Hubs, Google Pub/Sub) to consumers. In multi-cloud environments, producers and consumers may operate across different cloud platforms, introducing complexities in managing cryptographic keys and certificates for secure communication.

Streaming systems employ multiple layers of encryption, each addressing different threat models:

• Transport Encryption (TLS/mTLS): All communication channels between producers, brokers, and consumers should use TLS 1.2 or higher to protect data in transit. For Zero Trust architectures, the mutual transport layer security (mTLS) provides bidirectional authentication where both clients and brokers present certificates, enabling cryptographic verification of service identity. Many managed streaming services support Bring-Your-Own-Certificate (BYOC), allowing organizations to use certificates issued by enterprise or third-party Public Key Infrastructure (PKI) services rather than CSP-generated certificates [1], [2]. This enables control over certificate lifecycle management (issuance, rotation, revocation), consistent certificate policies across multi-cloud brokers, and integration with existing enterprise PKI infrastructure

  • Multi-Cloud Consideration: When brokers span multiple clouds, certificate distribution and validation become complex. Organizations should ensure producers and consumers in AWS, Azure, and GCP can all validate certificates from a common certificate authority (CA) or federated trust chain. Certificate revocation mechanisms (OCSP, CRL) should be accessible across cloud boundaries

• Broker Encryption at Rest: Messages persisted by brokers for durability and replay (e.g., Kafka logs, Kinesis shards, Event Hubs partitions) should be encrypted at rest. Organizations can choose between CSP-managed keys or customer-managed keys (CMEK/BYOK). Customer-managed keys provide independent key control separate from the CSP, the ability to revoke broker access to historical messages, and compliance with regulations requiring customer-held encryption keys. Broker encryption protects against unauthorized access to storage media but does not protect data from the broker service itself or CSP administrators

• Application-Level Encryption (End-to-End): For highly sensitive data (e.g., PII, financial transactions, healthcare records), organizations should encrypt message payloads before publishing to the broker, ensuring data remains protected even while stored or processed by the broker as shown in Figure 4.

Figure 4: Application-Level Encryption in Multi-Cloud Streaming Architecture

Figure 4, shows an End-to-end encryption workflow showing how producers encrypt message payloads with DEKs obtained from a multi-cloud KMS before publishing to streaming brokers. The encrypted message travels with a wrapped (encrypted) DEK that enables authorized consumers to decrypt the payload via KMS, while the broker handles only ciphertext throughout. This pattern ensures data confidentiality even if broker infrastructure or CSP administrators are compromised.

This pattern protects data even if the broker is compromised, prevents CSP administrators from accessing message content, and meets compliance requirements for end-to-end encryption.

Trade-Offs: Brokers cannot perform content-based routing, filtering, or analytics on encrypted payloads. Both producers and consumers require KMS access, adding latency to message processing. Key rotation requires coordination across all producers and consumers to prevent message loss or processing failures.

Challenges for Multi-Cloud Data Streaming

Multi-cloud key management challenges include:

• Cross-Cloud Key Access: When producers in one cloud publish to brokers in another cloud, with consumers in a third cloud, all components need access to encryption keys. Options include:

  • Unified KMS: Use a third-party multi-cloud KMS (Section 3.4) or customer-held KMS (Section 3.2) accessible from all cloud providers via API.
  • Federated Key Access: Replicate keys across CSP KMS instances (AWS KMS, Google Cloud KMS, Azure Key Vault) with consistent key IDs and access policies.
  • Re-Encryption at Boundaries: Re-encrypt messages with destination cloud’s keys when crossing cloud boundaries, trading complexity for key isolation.

• Key Rotation with Active Streams: Unlike batch processing, streams operate continuously. Key rotation should account for:

  • In-flight messages: Messages encrypted with old keys may still be in transit or queued when rotation occurs.
  • Consumer lag: Consumers processing historical messages need access to old key versions during catch-up.
  • Gradual migration: Producers should transition to new keys gradually while consumers maintain the ability to decrypt both old and new keys during rotation windows (typically 24-48 hours).
  • Message ordering: Key rotation procedures should not disrupt delivery guarantees or message ordering.

• Performance Considerations: High-throughput streams (millions of messages per second) make encryption overhead significant:

  • TLS session reuse and connection pooling reduce handshake overhead.
  • Producer and consumer key caching (with appropriate TTL, typically 5-60 minutes) reduces KMS API calls.
  • Hardware acceleration (AES-NI instruction sets) improves cryptographic performance.
  • Batching messages before encryption reduces the per-message cost of cryptographic operations by spreading fixed overhead across multiple messages.

Key caching should balance performance (longer cache periods reduce KMS calls) against security (shorter cache periods enable faster key rotation response).

Best Practice: Use TLS 1.2+ or mTLS for all producer-broker-consumer connections. Apply broker encryption at rest for regulatory compliance and data durability. Implement application-level encryption for highly sensitive data where brokers should not access plaintext. For multi-cloud streaming architectures, evaluate centralized KMS solutions or customer-held KMS to simplify key distribution, rotation, and access control across cloud providers.

Key Exchange

When users conduct online transactions such as shopping, streaming videos, or sending emails, key exchange protocols secure data and communication between the consumer and provider. Key exchange is also commonly performed between separate cloud services and providers, where negotiated keys using PKI enable the establishment of trust and protection of data transmission via application- or packet-level encryption [1]. Common examples include TLS handshakes (described in Section 2.2.5) and IPsec VPNs using IKE protocol for key exchange. While VPC peering enables network connectivity between clouds, it does not perform key exchange and relies on the cloud provider’s existing security controls.

Key exchange algorithms such as RSA [3] and Diffie-Hellman (DH) face potential vulnerabilities from quantum computing. RSA’s security depends on the computational difficulty of factoring large prime products, while DH’s security relies on the discrete logarithm problem. Shor’s algorithm, executable on sufficiently powerful quantum computers, can efficiently solve both problems, rendering current public-key exchange methods vulnerable.

To address quantum threats, organizations are transitioning to post-quantum cryptographic (PQC) algorithms. Key Encapsulation Mechanisms (KEMs) provide quantum-resistant key exchange based on mathematical problems believed to be hard for both classical and quantum computers, including lattice-based problems (e.g., Kyber, selected as NIST’s ML-KEM standard), code-based cryptography, and hash-based signatures. KEMs enable two entities to establish a shared secret key that can subsequently be used with symmetric algorithms (e.g., AES-256) for bulk encryption. Symmetric algorithms like AES require only increased key sizes to maintain security against quantum attacks (Grover’s algorithm provides quadratic speedup, making AES-256 equivalent to AES-128 against quantum computers). Organizations implementing multi-cloud architectures should evaluate PQC readiness across cloud providers, as adoption timelines and supported algorithms vary between AWS, Azure, and Google Cloud.

For management of the public and private keys used to establish trust for these operations, the use of a cloud certificate manager is required, which is a specialized KMS used for managing certificates, usage, and trust. Cloud-native certificate managers (e.g., AWS Certificate Manager, Google Certificate Authority Service, Azure Key Vault Certificates) typically operate within a single CSP’s environment, performing critical functions such as generating, signing, storing, managing, and retiring cryptographic keys and certificates.

In a multi-cloud environment, extending key and certificate management capabilities across cloud platforms presents distinct challenges for each function. For key management interoperability, organizations should consider solutions that support Public Key Cryptographic Standard #11 (PKCS#11) and/or Key Management Interoperability Protocol (KMIP), OASIS standards that enable heterogeneous KMS to communicate using a common message format and protocol. These interoperability standards allow centralized or federated key lifecycle operations, including generation, rotation, and destruction that may otherwise use incompatible native APIs or protocols.

For certificate management across multiple clouds, organizations face the challenge of coordinating trust between independent PKI systems, each with its own certificate authorities, validation policies, cryptographic algorithm support, and lifecycle rules. While cloud-native certificate managers operate within a single provider’s trust boundary, multi-cloud deployments require mechanisms to ensure consistent certificate issuance, renewal, and revocation. Automated Certificate Management Environment (ACME, RFC 8555) provides standardized automation for certificate lifecycle operations and is supported by multiple certificate authorities, though organizations should verify provider-specific implementations. Certificate Management Protocol (CMP, RFC 4210) and Enrollment over Secure Transport (EST, RFC 7030) offer additional options for certificate enrollment and management across heterogeneous environments.

Regardless of the approach, multi-cloud key and certificate management requires a centralized policy orchestration layer to enforce uniform security controls across providers. This includes consistent key rotation schedules, synchronized revocation checking, consolidated audit logging, and coordinated incident response procedures. Organizations should evaluate whether their multi-cloud KMS or certificate management solution can integrate with each cloud’s native services while maintaining compliance with applicable regulatory frameworks across all deployment locations.

TLS Transmission

TLS is a common protocol used for many forms of secure authentication and communication, facilitating secure online transactions, web browsing, credit card payments, sending/receiving emails, file uploads, and more. TLS is also commonly used to authenticate and securely transmit sensitive data between multiple cloud providers. TLS versions 1.2 and 1.3 are currently considered secure for sensitive data transmission.

When TLS communication is initialized between two systems, the TLS handshake process performs acknowledgment, verifies and establishes cryptographic algorithms, and exchanges the symmetric session keys used to encrypt communications, as described in Section 2.2.4. The TLS protocol ensures non-repudiation authenticity and protects data integrity and confidentiality.

Where multi-cloud implementations require authentication, one server may need to generate a public and private key, send the public key to a CA service to be signed (usually as a PKCS#12 certificate signing request or CSR), and then transmit the public key to server or service to which it will ultimately authenticate (usually as an X.509 certificate). Similarly, where a service provides a TLS-secured endpoint, a key pair should be randomly generated, the public key should be signed as described above, and the signed certificate should be loaded into the certificate manager and provided to the remote client at the time of connection.

Table 3 lists several examples of the use of TLS in a multi-cloud scenario:

Type	Details
The end-user connects to the cloud application via HTTPS	HTTPS uses TLS to encrypt traffic from the end-user to the application web interface
Cloud application communicates with backend system via API	API communication to the second cloud provider uses transport encryption, leveraging TLS. This connection may take place over a public or private connection.
Email is sent by one cloud service using external mail servers provided by another cloud provider	TLS is often used to encrypt data in transit for transport security. At the same time, other protocols, such as Secure/Multipurpose Internet Mail Extensions (S/MIME), may also be used to provide authentication and storage at rest.
Data replication between storage services in different CSPs	TLS is used to secure the transfer of replicated storage blocks or objects between two cloud providers to prevent interception or tampering during migration, synchronization, or backup operations.
Federated identity authentication across multiple clouds	TLS secures the exchange of authentication tokens and SAML/OpenID Connect (OIDC) assertions between Identity Providers (IdPs) and Service Providers (SPs) across different CSPs, ensuring confidentiality and integrity of identity claims.

Table 3: Examples of TLS in a Multi-Cloud Scenario

mTLS for Workload Identity

In multi-cloud environments, TLS is typically used to protect data in transit. However, when establishing trust between services, brokers, or workloads across cloud providers, mTLS provides an additional level of assurance by requiring both parties to authenticate using X.509 certificates.

mTLS ensures cryptographically-verified workload identity, enabling secure service-to-service communication and greatly reducing the risk of impersonation or unauthorized access. In environments where data flows across cloud boundaries or involves multiple messaging layers, mTLS helps verify the identity of brokers and endpoints before granting access to protected resources or signing keys. Many Zero Trust architectures consider mTLS a foundational control for cross-cloud communication.
Key management considerations for mTLS in multi-cloud:

• Certificate lifecycle management for potentially thousands of service identities
• Secure storage of private keys for both client and server certificates
• CA hierarchy design (single root CA vs. federated trust across clouds)
• Automated certificate rotation for short-lived credentials
• Integration with service mesh platforms (e.g., Istio, Linkerd) or API gateways
• Certificate revocation mechanisms that function across cloud boundaries

Example: A microservice in AWS needs to call an API hosted in Google Cloud. Both services are issued certificates from a shared CA or trusted CA federation. During connection establishment, both present their certificates, enabling cryptographic verification of service identity without storing shared secrets or managing API keys.

Signing/Verification

An X.509 certificate binds an identity to a public key using a digital signature issued by a trusted CA. When verifying a certificate, the CA’s signature ensures the authenticity and integrity of the binding. When verifying signed data, the certificate’s public key confirms the data’s integrity and that it was signed by the entity holding the corresponding private key.

A certificate helps with signing and verification in multi-cloud environments by providing a way to establish trust between workloads hosted by separate providers. This signature is crucial for establishing trust across systems and cloud providers in a multi-cloud environment.

Some common examples of signing in a multi-cloud environment may include signing messages by one cloud service, which a secondary system should verify in another cloud context. In a multi-cloud environment, there are a few security best practices to be followed:

• Determine all certificates and secrets used by the system. This process should be continuous, especially in multi-cloud environments, where there may be multiple layers (e.g., application, network, storage) requiring certificates or secrets

• Maintain an inventory of various certificates/secrets used by the system and various layers for proper management and renewal of certificates, while working across multiple cloud providers

• Use Hardware Security Modules (HSM) or secure vaults to provide tamper-resistant storage and cryptographic operations for private keys, integrated with KMS that automate lifecycle activities (creation, storage, rotation, revocation) across different cloud environments

• Implement multi-layer access control based on least privilege, a “need to know” basis, and role-based access control (RBAC) across all layers (network, application, and system) can help minimize unauthorized access to certificates, secrets, or key management tools. Just-in-time access can further enhance security. Attribute Based Access Control (ABAC) provides access based on attributes such as the user’s location, time of access, or security clearance, which ensures access is granted only under specific conditions, adhering to the “need to know” Zero Trust principle

• Log all signing and verification operations to provide a comprehensive audit trail, including which keys were used, what data was signed, timestamps, requesting entities, and verification outcomes. For integration with Security Information and Event Management (SIEM) systems, logs should be delivered at an appropriate level of detail in near real-time to enable detection of unauthorized signing attempts, verification failures, or suspicious patterns across cloud boundaries

• Monitor for changes or anomalies detected by key management tools (such as unexpected key usage). Integrating real-time alerts can help organizations respond quickly to security incidents. Logging consolidation, monitoring, and alerting can also be part of a SIEM solution

• Perform authenticated³ vulnerability scans [5] to assess security posture, especially for systems interacting across cloud boundaries. Vulnerability scans should cover all parts of the key management infrastructure to identify potential weaknesses

• Establish workload identity through mTLS (see Section 2.2.5) to further strengthen signing and verification workflows by ensuring that only authenticated services can request signing operations or verify signed data across cloud boundaries. For example, between data brokers in a streaming pipeline or API endpoints in different clouds. By requiring both the client and server to present and validate X.509 certificates, mTLS prevents impersonation and man-in-the-middle attacks, creating a secure foundation of trust upon which access control and signing decisions can be made

Privacy/Usage/Propagate Directives

In the realm of multi-cloud KMS, privacy, usage, and propagation directives play a critical role in ensuring the security and integrity of data across diverse cloud environments.

Privacy directives safeguard sensitive information by defining stringent access controls, encryption standards, and compliance with data protection regulations such as General Data Protection Regulation (GDPR) and California Consumer Privacy Act (CCPA). These directives mandate that cryptographic keys be managed to prevent unauthorized access from internal and external threats. By leveraging strong encryption protocols and robust key management practices, organizations can ensure these data remain confidential and protected from disclosure, even when stored across multiple cloud providers segregated by region. Strong encryption can also mitigate the risks associated with cross-border data transfers.

Common privacy provisions that are relevant to multi-cloud KMS, such as those found under CCPA, include:

• Right to Know: Consumers can request information about collecting, using, and sharing their data. Multi-cloud KMS should support this by providing detailed logs and audit trails that show how encryption keys are used and which data they protect

• Right to Delete: Consumers can request the deletion of their data. Where data is securely encrypted and secure deletion of the underlying data is not feasible, KMS may facilitate this by ensuring that encryption keys associated with the data are securely deleted, rendering the data inaccessible and effectively removed from all cloud environments

• Right to Opt-Out: Consumers can opt out of the sale of their data. KMS should enable businesses to enforce this by managing encryption keys in a way that restricts unauthorized access and prevents data sharing without consumer consent

• Data Minimization and Purpose Limitation: Personal data should only be collected and processed for specified, explicit, and legitimate purposes. Multi-cloud KMS should enforce encryption policies that align with these principles, ensuring that only necessary data is encrypted and accessed

• Non-Discrimination: Businesses cannot discriminate against consumers who exercise their CCPA rights. Multi-cloud KMS should support equal data protection, ensuring that security measures are applied consistently regardless of consumer actions

• Data Security: Businesses should implement reasonable security measures to protect personal data. Multi-cloud KMS should provide robust encryption and key management practices, including regular key rotation, strong access controls, and secure key storage to prevent unauthorized access and data breaches

• Service Providers and Third Parties: If a business shares personal data with service providers or third parties, they should ensure these entities comply with CCPA requirements. Multi-cloud KMS should include secure key sharing and usage monitoring mechanisms to ensure that third parties adhere to the same privacy standards

Usage directives specify the permissible actions that can be performed with encryption keys, such as encryption, decryption, and key rotation, ensuring that keys are used strictly according to predefined security policies.

Propagation directives outline the mechanisms for securely distributing and replicating encryption keys across multiple cloud platforms. These directives ensure that keys are consistently and securely managed, minimizing the risk of key compromise during transfer and synchronization processes. By implementing robust usage and propagation directives, organizations can maintain high control over their cryptographic keys, enhancing their overall security posture in a multi-cloud infrastructure.

E2EE/Application Encryption

Encryption within applications (as opposed to relying strictly on transport encryption) for transmission between multiple cloud providers provides greater flexibility for managing the time and location of decryption.

Application encryption, however, requires that sensitive decryption keys be stored or accessible when decryption and/or re-encryption is required. However, enabling decryption or re-encryption across multiple clouds or within client applications requires exposing decryption keys in those environments, which can significantly increase the risk of key leakage or compromise.

Key Sharing

Organizations require coordinated key management across multiple CSPs to support disaster recovery, data portability during cloud migrations, and hybrid workloads where applications in one environment should access data protected by keys managed in another. However, coordinating cryptographic key operations across cloud boundaries introduces significant interoperability, security, and compliance challenges due to divergent KMS architectures, incompatible authentication models, and inconsistent key lifecycle implementations.

Important Note: This section addresses key management coordination, not literal key material replication. In standard cloud architectures using envelope encryption, KEKs remain within their native CSP KMS and are never replicated or synchronized across cloud boundaries. Such replication is generally considered an anti-pattern that increases security risk and may violate organizational security boundaries. Instead, DEKs are generated locally to encrypt data, then wrapped (encrypted) by the CSP’s KEK. What requires coordination across CSPs is not the KEK material itself, but rather: IAM policies and access controls that enable cross-cloud cryptographic operations (e.g., applications in AWS invoking Azure Key Vault APIs); key lifecycle policies such as rotation schedules and crypto-periods; DEK wrapping and rewrapping workflows when data moves between clouds; and unified audit logging and monitoring.

Organizations address multi-cloud key coordination through several approaches: CSP-native KMS services with orchestration layers, third-party cloud-agnostic KMS platforms, or custom key brokering services. While KMIP exists as a standardized protocol, it sees limited adoption in cloud-native architectures where CSPs provide proprietary APIs instead (e.g., AWS KMS, Azure Key Vault, GCP Cloud KMS).

Organizations should implement granular IAM policies across all CSP environments to enforce least-privilege access to key management APIs. Each CSP employs distinct authorization models⁴, requiring careful policy translation to maintain consistent security posture. Native CSP KMS do not expose KMIP endpoints, relying instead on proprietary REST/gRPC APIs. Organizations seeking protocol standardization typically deploy third-party KMS platforms (e.g., HashiCorp Vault, Thales CipherTrust) that abstract CSP-specific differences, though this introduces additional architectural complexity and operational overhead. Maintaining consistent security posture across these heterogeneous systems requires continuous policy synchronization and regular access reviews to prevent authorization drift.

Another prominent challenge is coordinating key lifecycle operations across CSPs with different architectures and API semantics. Coordinating key rotation schedules across CSPs can reduce operational complexity, but automated lifecycle orchestration tools cannot eliminate timing discrepancies that create windows where keys exist in different states across environments. Organizations should implement near-real-time coordination using event-driven architectures (e.g., AWS EventBridge, Azure Event Grid, GCP Pub/Sub) with monitoring and alerting for lifecycle state divergence exceeding defined thresholds. However, network latency, API rate limits, and transient failures make zero-latency coordination impossible, requiring applications to handle temporary key state inconsistency gracefully [27].

A frequently proposed solution to the interoperability challenge is the adoption of standardized protocols like KMIP. However, in practice, the native KMS services of major cloud providers (e.g., AWS KMS, Azure Key Vault, GCP Cloud KMS) are built around proprietary APIs and are not primarily accessed via KMIP. KMIP sees its most relevant use in hybrid scenarios, such as connecting on-premises HSMs to cloud resources, or within some third-party multi-cloud KMS solutions that use it as an internal transport. Consequently, the dominant challenge for most multi-cloud deployments is not protocol-level interoperability but the management of divergent identity and access management (IAM), policy, and key lifecycle models across these proprietary cloud-native KMS APIs.

Addressing the interoperability challenge, therefore, requires implementing a consistent governance and abstraction layer that can manage these inherent disparities.

Challenges and Considerations for Multi-Cloud Key Management

Multi-Cloud Key Management Risks

When considering the multi-cloud implementation for the architectures discussed in Section 2.2, it is essential to understand the various risks relevant to key management, use, and exposure across multiple providers. These may vary greatly for different organizations and implementations. The following may be considered determinants when evaluating the key management options and decision-making for an entity’s chosen solution.

Confidentiality

As a rule, keys should never be exposed in the clear. Where there is business justification, clear-text keys and key material should be made available only to authorized applications and users on a need-to-know basis following a strict process.

The foundation of any cryptographic system is the secrecy of the keys used within that system throughout its lifecycle. In the event of suspected key compromise, standard practice requires immediate revocation of all associated keys (including any keys protected by such keys) as a containment measure, followed by investigation into the cause, rekeying,⁵ and re-encryption of all associated data with new keys to re-establish secrecy of the data in the system.

Protecting key confidentiality in multi-cloud environments requires layered controls addressing both key material protection and access control:

• Envelope Encryption: The primary confidentiality mechanism for key material itself is envelope encryption, where DEKs are encrypted by non-exportable KEKs. In multi-cloud architectures, KEKs typically remain within secure KMS infrastructure (whether customer-managed, customer-held HSMs, or third-party platforms), while encrypted DEKs can be stored with data across any cloud provider. This ensures plaintext key material never leaves the KMS boundary, even as encrypted data moves between clouds

  • Client-side encryption with envelope encryption provides a solution by allowing applications to encrypt data once using a unified KMS, then store the encrypted data across any cloud storage service. As illustrated in Figure 5, the application requests a DEK from the centralized KMS, encrypts data locally, and stores the encrypted package (ciphertext and wrapped DEK) across multiple cloud providers. This pattern can be implemented using different KMS architectural approaches, each with distinct trade-offs in control, complexity, and operational responsibility

• Access Control: Least-privilege IAM and key policies ensure only authorized principals can access key operations (encrypt, decrypt, generate). In multi-cloud environments, this requires translating access control models across providers (e.g., AWS KMS key policies, GCP IAM roles, Azure Key Vault access policies) as each uses different syntaxes and permission models. Organizations should implement consistent least-privilege principles across these heterogeneous systems while accounting for provider-specific capabilities and limitations

• Key Isolation: Dedicated keys per tenant, workload, or data classification limit blast radius in the event of compromise. Multi-tenant applications should use separate KEKs per customer rather than shared keys, preventing cross-tenant data access if a single key is compromised. Similarly, isolating keys by sensitivity level (e.g., separate keys for PII vs. non-sensitive data) contains exposure

• HSMs: Cloud-native HSMs (e.g., AWS CloudHSM, Google Cloud HSM, Azure Dedicated HSM) or customer-held HSMs provide tamper-resistant storage for KEKs, with FIPS validation ensuring cryptographic boundary protection. For customer-held KMS models, HSMs prevent even the organization’s administrators from extracting plaintext key material

• Key Rotation: Regular automatic key rotation (see Section 3.3) limits the exposure window for any single key version, reducing the impact of undetected key compromise

• Audit and Monitoring: Comprehensive logging of all key access operations enables detection of unauthorized access attempts or anomalous usage patterns across cloud boundaries (see Section 3.2)

• Key Wrapping Standards: When keys must be exported or transmitted between systems (such as transferring DEKs between clouds or backing up keys), they should be wrapped using approved algorithms (such as AES Key Wrap per NIST SP 800-38F or RSA-OAEP [3]) with keys that have equivalent or greater strength than the wrapped key. Unwrapped keys should exist only in secure execution environments (HSMs, secure enclaves) or encrypted memory.

These controls are implemented differently across customer-managed (Section 4.1), customer-held, hybrid, and third-party multi-cloud KMS approaches, with varying trade-offs in implementation complexity, operational overhead, and security assurance.

Figure 5: Illustration of Encryption Pattern Enabling Multi-Cloud Data Storage with Unified Key Governance

The application encrypts data once and stores the encrypted package (data + wrapped DEK) across multiple clouds, all managed through a central KMS.

Confidentiality measures are designed to protect sensitive data from unauthorized parties. As referenced in this paper, a typical online transaction may involve multiple entities, CSPs, technologies, and protocols. The complexity and diversity of multi-cloud environments result in infrastructure sprawl, increasing the attack surface and confidentiality risks. Each CSP has unique services, APIs, key policies, and configurations that complicate key management. Implementing standardized encryption and key management practices for the on-prem cloud and across different CSPs is challenging.

Integrity

The core principle of integrity requires that key values be protected from tampering throughout their lifecycle, that any such attempt is detected and investigated, and that mechanisms exist to perform proactive confirmation of key integrity throughout their lifecycle.

Suppose key values can be tampered with, even without clear key exposure. In that case, the cryptographic system relying on those keys can no longer be relied upon to protect the confidentiality of the underlying data. In addition, substituted keys may also result in unexpected failures, such as the inability to decrypt data, establish trust between systems due to invalid signatures, or encryption failures.

To ensure and validate the integrity of key values in a multi-cloud KMS environment, several mechanisms and practices can be put in place:

• Cryptographic Signatures and Hashes: Each critical data associated with the key (such as metadata, usage policies, or versioning info) should have a cryptographic hash or digital signature applied when generated. At each use, the signature or hash can be validated against a trusted, immutable baseline to confirm no tampering. This approach ensures key values maintain integrity throughout their lifecycle across different cloud environments [7]

• Immutable Storage for Key Metadata: Immutable storage for storing key metadata and lifecycle events needs to be used, ideally in a system that provides tamper-evidence features (e.g., blockchain-based or write-once, read-many (WORM) storage). Immutable records allow for traceability and non-repudiation, critical in detecting unauthorized changes or breaches [8], [10]

• Multi-Region, Multi-Provider Consistency Checks: Key values, versions, and metadata across the multiple cloud providers involved should be compared periodically or in real-time. This can be achieved by synchronizing KMS state data between clouds and alerting them of discrepancies. Third-party tools or custom scripts that cross-verify between providers can identify inconsistencies that might indicate tampering [9]

• HSMs or Cloud HSM Services: Using HSMs, either on-premises or cloud-based, provides tamper-resistant environments that store and manage keys with strict access control and integrity monitoring. HSMs can add a layer of protection against key tampering by enforcing key access and modification policies and providing evidence for audits. For more details on HSMs, please consult the previously published paper on HSM-as-a-Service Use Cases, Considerations, and Best Practices [11], [12], [13]

• Continuous Monitoring and Logging: Detailed logging and monitoring for all key operations, including creation, rotation, and deletion, in each cloud provider need to be enabled. Administrators can detect tampering attempts by centralizing and continuously analyzing these logs for anomalies or unexpected changes in key metadata [14]

• Attestation Services: For this, an organization should use cloud provider or third-party attestation services that provide reports on the integrity and compliance of cryptographic operations within the multi-cloud environment. Attestation services allow administrators to verify that keys and cryptographic materials are managed according to the expected security standards and are not tampered with [15] [16]

Each of the above methods contributes to a layered approach for validating key integrity in a multi-cloud environment, helps to establish trust, and ensures security across potentially disparate KMS implementations [17], [18], [19].

When integrity violations are detected through the mechanisms above, investigating the incident in multi-cloud environments presents unique challenges that inform architectural decisions:

• Log Format Heterogeneity: For example, AWS CloudTrail, Google Cloud Audit Logs, and Azure Monitor use different schemas, field names, and detail levels, requiring log normalization and centralized SIEM platforms with multi-cloud connectors

• Fragmented Telemetry: Key usage spans multiple providers with no unified view, complicating timeline reconstruction and requiring real-time log aggregation rather than post-incident manual correlation

• Cross-Cloud Attribution: Tracing attack paths through federated identities, service accounts, and cross-cloud permissions requires understanding each provider’s IAM model and maintaining consistent identity tagging

• Limited Retention: CSP-native log retention (typically 90–400 days) may be insufficient for investigations, driving architectural need for long-term immutable log storage

These challenges explain why multi-cloud environments require more sophisticated monitoring architectures, standardized key tagging conventions, and proactive log centralization compared to single-cloud deployments.

Maintaining the integrity of cryptographic key material in a multi-cloud setting represents a complex challenge due to the number of locations where key material may be used and/or updated, and thus the potential for accidental or malicious modifications. Varying key management processes, software bugs across different cloud platforms, and increased risk of accidental deletion can create discrepancies in key versions, rotations, or updates. Such discrepancies may result in corruption of keys, versioning issues, challenges in key revocation, and use of expired, weak, or known keys, thus compromising data confidentiality.

Availability

Key availability, either through KMS or broader system-level resiliency, may be part of an organization’s strategy to ensure systems have access to key material when required and access to business functions that rely on this data.

While access to encryption keys should be restricted, systems that rely on them should have access when needed to support business functions. If keys are not available when needed, whether due to service disruption, configuration errors, or accidental/malicious loss or deletion, business processes may be interrupted. This includes the inability to encrypt or decrypt data, verify identity, or establish trusted communications. In more severe cases, extended downtime or data inaccessibility may occur, significantly impacting service continuity.

Operating across distributed and multi-cloud environments further amplifies this risk, as complex topologies and fragmented key control can increase both the likelihood and impact of key availability failures.

Ransomware and Destructive Attacks Targeting KMS

Multi-cloud KMS represent high-value targets for ransomware and destructive attacks. Unlike traditional ransomware that encrypts files, attacks targeting KMS infrastructure focus on key destruction to cause permanent, unrecoverable data loss.

Common attack patterns include:

• Mass Key Deletion: Compromised administrative credentials used to delete or schedule deletion of KEKs across multiple cloud providers, rendering encrypted data permanently inaccessible across the entire multi-cloud environment

• Selective Key Version Destruction: Deletion of specific key versions to corrupt data from particular time periods while leaving recent data accessible, complicating recovery efforts and detection

• Cross-Cloud Attack Propagation: Single compromised credential set for a multi-cloud KMS platform enables coordinated key deletion across AWS, Azure, and GCP simultaneously, maximizing damage

• Metadata Tampering: Modification of key aliases, rotation schedules, or access policies to disrupt operations without deleting key material, potentially evading detection The impact multiplier effect is significant: deleting a single KEK can render thousands of DEK-encrypted objects permanently inaccessible. Unlike encrypted files that may eventually be decrypted, deleted cryptographic keys typically cannot be recovered without prior backups or escrow arrangements

Organizations should implement KMS-specific defenses including: key immutability periods that prevent deletion within a defined window; multi-person approval requirements for deletion operations (see Section 3.1.5); real-time monitoring and alerting for key lifecycle changes such as ScheduleKeyDeletion or DisableKey operations; offline or air-gapped key backups for customer-held KMS models; and cross-cloud monitoring to detect coordinated attacks. These considerations inform architectural decisions when selecting between customer-managed (Section 4.1), customer-held, hybrid, and third-party multi-cloud KMS approaches.

The distributed nature of multi-cloud environments may introduce inherent availability risks for encryption keys due to connection requirements that may be susceptible to network outages. Such connectivity issues, whether between service providers, between the KMS and the CSP, or between on-premises systems and cloud workloads, may impact the ability to access encrypted data and services, resulting in issues with availability⁶. Furthermore, different KMS implementations across cloud providers may use incompatible key synchronization mechanisms, leading to state inconsistencies or version conflicts. These synchronization failures can result in key corruption, access limitations, or service disruptions, particularly when keys must be accessed across multiple clouds simultaneously.

Business continuity planning (BCP) is a business process that builds on prior risk and impact assessments to implement mitigations that ensure the timely resumption of critical business operations during or after a disruption⁷. BCP is a planning process that assumes risks have already been assessed through risk or business impact analysis. It focuses on maintaining or restoring operations, not identifying threats or implementing real-time mitigations.

Where business-critical operations depend on multi-cloud architectural components or the continued operation of KMS, these architectural dependencies should be factored into business continuity planning. A disruption in key management operations can result from a compromise of key confidentiality (e.g., unauthorized disclosure), loss of key integrity (e.g., tampering, corruption), or unavailability (e.g., due to system outage). Mitigations should be tailored accordingly: key backups or escrow arrangements help recover from loss or accidental deletion; integrity mechanisms like key checksums, hash validations, or cryptographic signatures can detect unauthorized alterations; and synchronization or replication across regions, coupled with high-availability networking, ensures keys remain accessible even during localized failures.

Designing for these conditions is essential to minimize operational downtime and data loss.

Portability

Key portability refers to the ability to transfer cryptographic key material between KMS, cloud providers, or geographic locations while maintaining key integrity, security properties, and associated metadata. In multi-cloud environments, portability enables organizations to avoid vendor lock-in, implement disaster recovery procedures, and execute cloud exit strategies.

However, key portability in cloud KMS environments presents inherent limitations. Cloud-native KMS platforms typically manage KEKs or Customer Master Keys (CMKs) within HSMs, where keys are non-exportable by design. These KEKs protect DEKs through envelope encryption, and while DEKs can be exported (in wrapped form), the root keys protecting them generally cannot. This architectural pattern means that direct key portability between CSP KMS platforms is often neither feasible nor necessary for day-to-day operations.

Cloud-native KMS platforms are designed with key material non-exportability as a fundamental security property. For example, AWS KMS key material “is never exported or transmitted in AWS KMS API operations,” with the exception of multi-region key replication within AWS [50].

Similarly, “Azure Key Vault and Azure Managed HSM do not allow the export of keys, to protect the key material and ensure that the HSM properties of the keys can’t be changed” [51].

Consequently, migrating encrypted data between cloud providers, or exiting a cloud platform entirely, requires decrypting data using the source provider’s KMS, transferring the data over a secure channel, and re-encrypting using the destination provider’s keys. For data directly encrypted by keys in a KMS, “all data must be read, decrypted, and encrypted with the new key,” which may require significant time and careful handling of temporarily exposed plaintext (Microsoft, 2025) [51].

AWS similarly acknowledges that “moving encrypted data at scale can often take a few additional steps due to the need to decrypt and re-encrypt objects as part of the replication process” [52].

This architectural constraint reinforces the importance of evaluating key portability requirements before selecting an encryption strategy, particularly for organizations with cloud exit planning or multi-cloud data mobility requirements.

Where true key portability is required (e.g., for regulatory compliance, multi-cloud consistency, or cloud exit planning) organizations should consider BYOK architectures with keys originating from an external HSM or multi-cloud KMS solution. This approach allows the same key material to be imported (wrapped) into multiple CSP KMS platforms, though import procedures and supported wrapping algorithms vary by provider.

Additional portability barriers include differences in key serialization formats (PKCS#8, PKCS#12, JWK), wrapping algorithm parameters, and compliance restrictions such as data sovereignty regulations that may prohibit cross-border key movement. The KMIP provides standardized operations for key lifecycle management across heterogeneous systems, though CSP-native KMS platforms have limited KMIP support.

Separation of Duties

Similar to many enterprise processes, systems, and controls, a clear separation of duties is required for KMS to limit the ability for collusion or other insider threats, which may lead to compromise the integrity, or availability of cryptographic keys.

KMS should ensure that users can be limited in performing sensitive key management tasks, such as generating, importing, using, updating, or deleting keys. These systems should be capable of requiring dual control when appropriate, ensuring that access to such functions can only be performed by a quorum of systems or key custodians authorized to perform these tasks.

Separation of duties (SoD) is a foundational security control for KMS, ensuring no individual has end-to-end authority over key lifecycle operations. Standard guidance on SoD implementation is provided in NIST SP 800-57 Part 2.

From a multi-cloud KMS perspective, enforcing SoD becomes more challenging due to the distributed nature of services, varied access control models, and different administrative boundaries across CSPs. Organizations should ensure that SoD policies are consistently applied across all participating KMS instances, whether native to a specific CSP or part of a unified multi-cloud KMS solution. This requires harmonizing IAM policies, integrating centralized authentication with federated identity systems, and ensuring that dual control or quorum-based approvals can be enforced even when involved custodians operate in different cloud environments.

Usage Limitation

Application or infrastructure systems should enforce scope limitations that associate a key to a specific task. These limitations can be defined by parameters such as the application ID, specific user roles, or permitted time windows. These can be registered directly within the KMS policy database. When a service requests a key, the KMS checks these registered attributes against the caller’s current context; if they do not match, access is denied. This ensures that even if a key is intercepted, its ‘blast radius’ is strictly limited to its original, single purpose. The following table outlines the common risk categories for not limiting the key usage and associated security impact.

Risk Category	Security Impact
Over-Use and Reuse	Increases the cryptographic attack surface and the likelihood of successful cryptanalysis.
Lack of Segregation	Enables cross-environment contamination (e.g., development vulnerabilities exposing production data).
Regulatory Non-Compliance	Leads to audit failures, legal liability, and loss of industry certifications.
Malicious Misuse	Allows an attacker to pivot and decrypt broad datasets following a single service compromise.

Table 4: Common Risk Categories

User/System Access

Multi-cloud user and system access risks arise from divergent IAM authorization models across cloud providers (e.g., AWS IAM policies, Azure RBAC, GCP IAM) and inconsistent privilege/role mappings. Terminated users may retain KMS access in one cloud while properly revoked in others, service accounts with identical names receive different privileges across providers, and cross-cloud privilege escalation becomes possible through misaligned trust relationships, enabling unauthorized key operations.

As the number of providers and consumers of services grows in a multi-cloud environment, the complexity of managing privileged credentials, secrets, and keys also increases. This effect is pronounced for multiple CSPs utilizing disparate cloud services (e.g., HSM, KMS, secrets management, other workloads). In these cases, it is highly recommended to use a centralized IAM or authentication service to ensure credentials and permissions are synchronized across multiple providers. A standard method of handling IAM across clouds is via federation. This is done by establishing trust between the identity providers in each cloud and with the IAM of the other clouds they are communicating with the IAM of each cloud authenticates identities of workloads in other clouds, usually via OpenID Connect (OIDC) or through certs.

Rotation/Destruction

Managing key rotation and destruction in a multi-cloud environment is challenging due to the unique requirements of each cloud provider’s solutions and services. A well-defined strategy that includes establishing a centralized KMS is one method to address these challenges; however, in some environments a fully centralized, cross-provider KMS may be infeasible due to architectural, API, or service disparities. In such cases, rotation and destruction should be coordinated and enforced on a case-by-case basis per provider, while maintaining equivalent security objectives. If there isn’t a centralized KMS, mitigation strategies are still necessary; however, all the strategies should be coordinated on-prem and across each cloud provider, increasing the complexity of key management and risk to data. Additionally, key destruction decisions require careful evaluation of disaster recovery and business continuity requirements, as some organizations elect not to destroy retired or even compromised keys to avoid the risk of irrecoverable encrypted data.

Key Rotation

Keys are rotated to limit the impact of key compromise, mitigate the risk of cryptanalysis, and manage key longevity (overuse), among other risks:

• Centralized Key Management: The platform should provide centralized controls for managing key rotation across all cloud providers. This includes setting rotation intervals, automatically initiating key rotations, and ensuring newly rotated keys are integrated into existing workflows

• Key Retirement: The platform should ensure that old keys are securely retired and that the transition to new keys is smooth with no service disruption

• Logging and Compliance: All rotation activities should be logged, providing a clear audit trail according to organizational policies and documented for audit and compliance purposes

• Periodicity: NIST SP 800‑57 Part 1 provides cryptoperiod recommendations tailored to federal systems. While industry and regulatory norms, such as PCI DSS, AWS KMS, and modern DevOps practices, often impose shorter rotation periods (e.g., risk-defined crypto‑periods or annual default rotations) to further mitigate exposure risk, it is up to the organization to evaluate and determine the correct rotation period for them

The following table summarizes multi-cloud risks related to key rotation:

Multi-Cloud Risk	Potential Impact	Mitigation Strategy
Inconsistent key rotation policies across multiple cloud providers lead to potential security gaps.	Inconsistent key rotation can lead to vulnerabilities in some environments, increasing the risk of key compromise. Attackers may exploit weakly rotated keys in one environment while stronger policies exist in another.	Implement a Centralized Key Management Platform that enforces consistent key rotation policies across all cloud providers. Ensure the platform supports policy enforcement at the granular level to manage all keys and monitor uniformity.
Failure to implement automated key rotation processes uniformly across different cloud environments.	Manual key rotation increases the likelihood of human error, missed rotations, and security gaps. Missed rotations could lead to stale or overused cryptographic keys, which are more vulnerable to attacks like brute force or cryptanalysis.	Automate key rotation processes using a centralized KMS across all cloud providers. Ensure each cloud environment follows the same automation rules for key creation, rotation, and retirement. Synchronize automation schedules to prevent mismatched intervals.
Lack of comprehensive logging and monitoring for key rotation activities across all cloud providers.	With centralized logging, unauthorized key rotations or policy changes may be protected. This poses serious risks for compliance, security audits, and real-time breach detection.	Use a Centralized Monitoring System integrated with your key management to log all key rotation events in one place. Implement real-time monitoring and alerting for suspicious activities. Centralized logging ensures a complete, detailed audit trail, supporting security and compliance efforts.
Failures in key transition due to inconsistencies in rotation mechanisms across cloud platforms.	Service disruptions and downtime can occur if the transition from old to new keys is not managed correctly. Inconsistent mechanisms might lead to decryption issues when old keys are retired too quickly, causing data access problems.	Implement a platform that ensures seamless key transitions during rotation. Enforce a consistent rotation mechanism across all platforms, allowing old and new keys to function parallel (dual-use) during the transition phase. Implement rollback procedures to recover from any rotation failures.
Extended key usage or inconsistent rotation intervals across cloud providers, causing non-uniform security postures.	Extended key usage or inconsistent rotation policies across clouds can expose specific keys to cryptanalysis or compromise, undermining overall system security.	Enforce frequent key rotation through a centralized KMS, reducing the lifespan of cryptographic keys and minimizing the risk of exposure to cryptanalysis. Ensure uniform and frequent rotations across all cloud environments.

Table 5: Key Rotation Potential Risks and Mitigation Strategies

Key Destruction

Keys are destroyed to prevent unauthorized access, reduce the risk of key compromise, and mitigate key reuse (overuse), among other risks. However, irreversible key destruction can render any data still protected by that key permanently inaccessible, potentially triggering invocation of the disaster recovery plan. Organizations should evaluate alternative methods to prevent key reuse without requiring destruction, including securely retiring, tagging, archiving, and vaulting keys with past usage, for cases where key material must remain recoverable. In environments where deterministic key re-creation from preserved metadata is feasible, such mechanisms may be used to support controlled recovery scenarios. Destruction decisions should be based on documented risk assessments, business continuity requirements, and legal/regulatory constraints, and remain unrelated to transient or session keys.⁸

• Centralized Control: The platform should provide centralized controls for managing key destruction across all cloud providers. This includes defining criteria for when keys should be destroyed, automatically initiating the destruction process when keys are no longer needed, and ensuring that keys are securely deleted from all environments

• Secure Deletion: The platform should ensure seamless destruction, with all key materials irrecoverably erased according to the organization’s destruction policy

• Audit and Compliance: All destruction activities should be logged, providing a clear audit trail. These events should be carried out according to organizational policies and documented for audit and compliance purposes

The following table summarizes multi-cloud risks related to key destruction:

Multi-Cloud Risk	Potential Impact	Mitigation Strategy
Inconsistent key destruction policies across cloud environments expose keys to potential unauthorized access.	Inconsistent key destruction can result in old, unused keys being retained longer than necessary, exposing the organization to potential unauthorized access if those keys are compromised.	Use a Centralized Key Management Platform that enforces uniform key destruction policies across all cloud providers. Ensure automated destruction of unused or expired keys to eliminate any residual risk.
Incomplete or improper key destruction methods lead to residual key material that can be exploited.	If keys are not fully destroyed, attackers could retrieve and exploit remnants. This poses significant security risks, as even small fragments of key material can be reconstructed.	Implement automated and thorough key destruction processes using cryptographic erasure mechanisms. Ensure destruction is verified, irrecoverable, and compliant with each provider’s secure erasure standards. Run post-destruction checks to ensure no key material remains.
The absence of centralized logging for key destruction activities makes auditing or detecting unauthorized activities or errors difficult.	Without centralized logging, unauthorized access to keys or failures in key destruction processes may go unnoticed, making it difficult to track incidents or perform audits.	Use a Centralized Logging System for all key destruction activities. This should be integrated into the audit infrastructure, ensuring traceability and detecting any anomalies or unauthorized actions.
Delays in key destruction due to differing criteria or processes across cloud providers, increasing risk exposure.	Prolonged key retention increases the risk of compromise. If destruction is delayed in certain environments due to differing criteria, unauthorized access could be gained through unused or expired keys.	Define uniform key destruction criteria that are applied consistently across all cloud providers. Automate key destruction based on predefined lifecycles, ensuring no keys are retained longer than necessary. Set up alerts for delayed or missed key destruction events.
Cloud-specific limitations or variations in secure deletion methods lead to possible failures in key destruction.	Some cloud providers may have different secure deletion methods or lack certain features, leading to incomplete key destruction. This creates vulnerabilities and potential compliance issues.	Verify that the Centralized Key Management Platform supports and enforces secure deletion across all cloud providers. Ensure each provider’s deletion process complies with industry standards for cryptographic erasure and is verified upon completion. Conduct regular reviews and updates to ensure compatibility.
Risk of irreversible data loss due to destruction of keys still required for recovery or regulatory/forensic purposes.	Invoking disaster recovery plans, inability to decrypt retained data, loss of forensic evidence, regulatory non-compliance.	Apply secure retirement, archival, or vaulting of used keys rather than destruction when required for DR/BC, regulatory retention, or forensic purposes. Base destruction vs. retention decisions on documented risk assessments and cryptoperiod guidance.

Table 6: Key Destruction Potential Risks and Mitigation Strategies

Third-Party Risk

Third-party risk in a multi-cloud KMS refers to the potential for security breaches, service disruptions, or compliance failures originating from external entities such as CSPs, managed security vendors, or software-as-a-service (SaaS) providers. In a multi-cloud KMS, third-party risks are significantly amplified due to the intricate web of interactions between various CSPs, service providers, and end-users or consumers of the solution. The involvement of inherited and transient fourth-party relationships further compounds the complexity. For instance, a SaaS provider might leverage a PaaS KMS from a different CSP, creating a layered dependency that can obscure the visibility and control over key management practices. The CSPs might have different security postures, policies, and compliance levels, leading to inconsistencies and vulnerabilities in key management across the multi-cloud environment. This can impact the security of the keys as each layer of service may introduce unique risks and potential points of failure.

In evaluating third- and fourth-party risk, cloud service providers and customers may wish to consider the following as they relate to the selected KMS model:

• Inherited relationships, such as a SaaS provider using a PaaS KMS, further complicate these risks as they introduce additional layers where security practices should be rigorously vetted and managed to prevent breaches and ensure data integrity across all levels of the service stack
• Where possible, service providers should work with users to define and agree on a clear designation of assigned responsibilities and avoid a lack of accountability between all involved actors
• Cloud service customers (CSCs) should navigate these complexities by ensuring that their chosen service providers adhere to best practices in key management and have clear policies for handling third-party and fourth-party dependencies

KMS Considerations

Performance and Availability Considerations

Architectural decisions for multi-cloud key management have significant operational implications beyond security and governance. Organizations should evaluate performance characteristics, availability requirements, and operational constraints when selecting between centralized and federated approaches.

Transaction Latency

The choice between centralized and CSP-native KMS architectures directly impacts cryptographic operation latency. Centralized third-party KMS platforms (e.g., on-premises HSMs, centralized cloud-hosted KMS solutions) introduce additional network round-trip time for every encrypt, decrypt, or key generation operation. Depending on geographic distance between applications and the centralized KMS, this overhead typically ranges from 10–50ms [28] for same-region deployments to 100–300ms for cross-continental scenarios [29]. For applications performing frequent cryptographic operations, such as high-throughput data pipelines or real-time transaction processing, this added latency can significantly impact performance.

In contrast, CSP-native federated approaches using AWS KMS, Azure Key Vault, or GCP Cloud KMS for in-region operations typically exhibit sub-10ms latency for cryptographic API calls [30], [31], [32]. However, cross-cloud scenarios where an application in one CSP must invoke another CSP’s KMS introduce similar latency penalties as centralized architectures (50–200ms depending on geography), plus the overhead of authentication federation [33].

Organizations should establish latency budgets based on application requirements. For example, synchronous encryption in user-facing web applications may tolerate only 10–20ms of added latency, while batch processing workloads can accommodate hundreds of milliseconds. Latency can be partially mitigated through envelope encryption patterns (minimizing KMS API calls by encrypting DEKs locally) and caching of wrapped DEKs [34].

API Rate Limits and Throttling

Each CSP imposes rate limits on KMS operations that can become bottlenecks in high-throughput scenarios. Centralized KMS architectures aggregate all CSP cryptographic requests through a single platform, potentially creating a central bottleneck. If the centralized KMS has lower throughput capacity than the sum of CSP-specific limits, it becomes the constraining factor.

Mitigation strategies include:

• Request Batching: Where supported, batch multiple operations into single API calls [35]

• Local Caching: Cache wrapped DEKs to reduce KMS API calls for repeated encryption/decryption [34]

• Key Hierarchy Design: Use fewer master keys to wrap many DEKs, concentrating KMS load on specific operations [35]

• Asynchronous Processing: Decouple cryptographic operations from user-facing transactions where possible

• Rate Limit Monitoring: Implement alerting on approaching rate limit thresholds before throttling occurs [36]

Disaster Recovery Patterns

For multi-cloud key management, disaster recovery (DR) strategies should address several scenarios [37]:

• Cross-CSP Failover: If the primary application environment (e.g., CSP #1) becomes unavailable, enabling the failover environment (e.g., CSP #2) to access necessary cryptographic keys, requires either:
  • Pre-positioning of wrapped DEKs in secondary CSP
  • Federation enabling secondary CSP to call primary CSP’s KMS (requires primary CSP availability) [33]
  • Multi-region centralized KMS accessible from both CSPs
• KMS Service Outage: While rare, CSP KMS regional outages do occur. Mitigation options include:
  • CSP Multi-Region Keys: For example, AWS multi-region KMS keys allow failover to related keys in alternate regions [38]
  • Cached DEKs: Applications with cached wrapped DEKs can continue operating during brief KMS unavailability [34]
  • Degraded Operation Mode: Design applications to gracefully degrade (e.g., skip encryption for non-sensitive data) during KMS outages if business requirements permit [39]
• Key Material Escrow: For business-critical scenarios requiring absolute data recoverability, some organizations maintain encrypted key escrow in multiple independent locations, though this introduces significant security and compliance complexity [40]

Cost Considerations

Performance and availability choices have direct cost implications. Centralized KMS platforms typically involve capital expenditure for hardware/software and ongoing operational costs for High Availability (HA) infrastructure. CSP-native KMS services use consumption-based pricing (per API call and key storage), which can become expensive at high transaction volumes but eliminate infrastructure management costs [41], [42]. Organizations should model Total Cost of Ownership (TCO) including infrastructure, operational overhead, and API call volume when comparing approaches.

Organizations should evaluate these trade-offs against specific application requirements, compliance constraints, and operational maturity when designing multi-cloud key management architectures [43]. There is no universally optimal approach, as the choice depends on balancing security, performance, availability, and operational complexity for each organization’s unique context.

Other Considerations

In addition to the considerations discussed above, it is essential to understand other factors that may influence the selection of multi-cloud KMS solutions, which may vary greatly for different organizations and KMS implementations. Each of the following may be considered a determinant when evaluating the key management options and in the decision-making process for an entity’s chosen solution:

• Complexity of key management
• Technical knowledge and capabilities
• Time and resource requirements
• Regulatory compliance constraints, including demonstrating compliance
• Stakeholder requirements
• Service availability/business continuity planning

Multi-Cloud KMS Approaches

In hybrid or multi-cloud environments where cryptographic workloads are housed on-premises or in disparate CSP environments, the KMS implementation should facilitate the secure generation, storage, distribution, and management of cryptographic keys with each CSP and/or on-premises systems.

The chosen approach should address the security challenge of maintaining consistent security policies and controls across diverse environments. Disparate environments may have distinct sets of tools, protocols, and security measures, leading to potential discrepancies in how keys are managed and secured. For instance, AWS KMS, Google Cloud KMS, and Azure Key Vault have different APIs, management interfaces, and encryption standards, complicating uniform key management. This fragmentation can introduce security vulnerabilities if keys are not adequately protected at all times, or if there are gaps in the key lifecycle management processes that may lead to exposure of sensitive data. Additionally, synchronization between disparate KMS demands robust network security to prevent man-in-the-middle attacks during key transfers. Furthermore, ensuring compliance with regulatory requirements across multiple jurisdictions becomes more complex.

Multiple strategies exist to manage cryptographic keys across various heterogeneous cloud environments. These are generally categorized into customer-managed KMS, customer-held KMS, or multi-cloud KMS. Each is described below, with considerations for implementation, security, and cost.

Customer-Managed KMS

Customer-managed KMS is a key management solution model in which the CSC performs the key management operations directly with the CSP-specific key management services, leveraging exportable CMK (or BYOK) to provide portability of keys between cloud providers. In this model, each CSP operates the underlying KMS infrastructure applicable to the service provided, while the CSC controls key configuration, lifecycle, usage policies, and access permissions using the CSP-provided UI, API, or SDK, third-party software, or management devices that integrate to these interfaces. This approach may give organizations more control over their data security or help the customer evidence compliance requirements, but may also incur more direct risk and requires operational discipline and organizational maturity, especially in larger enterprises or when dealing with complex cryptosystems.

• Control: Organizations fully control the creation, use, rotation, and destruction of their cryptographic keys. This is called key lifecycle management

• Access and Separation of Duties: Customers may define and enforce granular access controls through IAM policies

• Compliance: Customer-managed KMS may allow for greater transparency over the movement of keys, in some cases making it easier to demonstrate compliance with regulatory requirements that mandate demonstrable governance over sensitive keys and key operations, such as GDPR, HIPAA, or PCI DSS (although this is highly dependent upon the CSC’s ability to implement logging and monitoring of key usage and demonstrate these processes effectively)

• Security: Customer-managed KMS adds an extra layer of security, as the cloud provider doesn’t have sole access to the keys that protect customer data
• Flexibility: BYOK allows for consistent key management across hybrid and multi-cloud environments

Cloud computing offers several approaches to implement BYOK⁹ security. Major cloud providers provide native BYOK solutions through their key management services, allowing customers to import or generate their encryption keys. Third-party key management systems offer centralized control across different cloud platforms for multi-cloud environments. Organizations requiring the highest level of security often turn to HSMs, either on-premises or as cloud services, for secure key generation and storage. A hybrid approach, combining cloud-native services with on-premises HSMs and third-party management tools, is common for balancing security and operational efficiency. Some enterprises opt for specialized key orchestration platforms to manage keys across diverse environments, while others develop custom solutions using cloud provider APIs for maximum flexibility. The choice of approach depends on factors such as existing infrastructure, compliance requirements, technical expertise, and budget constraints.

For organizations utilizing HSMs or third-party solutions, interoperability and compliance of the KMS with standards like FIPS 140-3 (Level 3 or higher) may be important.

Customer-Held KMS

A customer-held KMS provides key management and cryptographic services that support the HYOK responsibility model, which enables organizations to maintain control over their encryption keys. The customer-held KMS stores and manages all keys entirely, either on-premises, in a co-location, or by an unrelated CSP (e.g., leased HSMs).

HYOK implementations in cloud environments offer various sophisticated approaches to provide organizations with maximum control over their encryption keys. On-premises HSMs deliver the highest level of security by providing dedicated physical devices for key storage and cryptographic operations. However, these HSMs come with significant management complexity and cost. For organizations requiring flexibility, virtual KMS (when deployed on-premises) provide a software-based alternative that balances security with scalability. Our recommended approach is to use standardized key management processes that facilitate seamless integration with multiple cloud services while adhering to HYOK principles. One such technology, KMIP, has been employed, but more commonly, CSPs perform vendor-specific API calls to their customer-held KMS or HSM. Some enterprises, particularly those with unique requirements, opt for custom-built KMS, which give them unparalleled flexibility but demand substantial development and maintenance resources.

Customer-held KMS key hierarchies commonly rely on multi-hierarchy key-wrapping, ensuring the DEK is encrypted by a KEK, which is mapped to a key owned and managed by the customer on the KMS solution of their choice. The sensitive wrapping/unwrapping processes should be managed and performed within the KMS solution, without sharing the keys with the CSP.
Hybrid approaches attempt to balance stringent on-premises key control and the benefits of cloud-based encryption services. Advanced cryptographic techniques such as Multi-Party Computation (MPC), implemented in solutions, are pushing the boundaries of key management by allowing cryptographic operations without exposing the keys themselves. Where the sharing of keys from the customer-held KMS to the CSP is required, external key management proxies may be required to share these keys with the CSP.

Regardless of the chosen approach, successful customer-held KMS implementations require meticulous attention to network security, ensuring high availability of key access, implementing robust compliance monitoring and auditing, establishing secure procedures for regular key rotation, and developing comprehensive disaster recovery plans to safeguard against potential key loss or compromise. As such, implementing customer-held KMS requires significant investment in infrastructure, expertise, and ongoing management to ensure the security and availability of keys.

The choice to implement customer-held KMS in support of HYOK may depend on an organization’s specific security needs, compliance requirements, and operational considerations, using HYOK for their most sensitive data and BYOK for less critical information.

Third-Party KMS

Third-Party Multi-Cloud KMS, often abbreviated MCKMS, offers a compelling alternative to customer-managed or customer-held KMS approaches¹⁰ and may help avoid platform-specific implementation limitations. A third-party KMS service may be provided as a physical or virtual appliance to be hosted within the organization’s infrastructure or be provided as a SaaS offering.

MCKMS offers a centralized key management solution, enabling organizations to securely store, manage, and control their cryptographic keys across multiple cloud and on-premises environments. These systems are offered by independent vendors and provide an alternative to using the native key management services of individual CSPs. An MCKMS can be deployed as a physical or virtual appliance within an organization’s own data center or consumed as a SaaS offering.

The primary goal of an MCKMS is to provide organizations with direct control over their keys, independent of the CSP infrastructure where their data resides. By abstracting key management from individual cloud platforms, these solutions can support various key responsibility models, including BYOK and HYOK.

Depending upon CSC requirements, as discussed in the previous sections, it may be beneficial for keys to be stored and managed outside the CSP and the associated encryption operations. CSPs can support this by offering BYOK or HYOK services to enable customer control of the keys used to encrypt their data. Customer control of the keys allows for the creation, ownership, and control, including revocation of encryption keys or tenant secrets used to create the keys, and other tools such as rate limits to mitigate brute force attempts, enabling the complete lifecycle to be managed according to internal security policies. Visibility of cloud encryption keys reduces key management complexity and operational costs.

Cloud Key Management Platforms can increase efficiency by reducing the operational burden of key management for both external-origin keys and native keys, giving customers lifecycle control, and centralized management within and among clouds. Customers report that they stepped away from managing keys across a heterogeneous environment and invested in cloud key management to enable them to move securely to the cloud, and their cloud use is growing exponentially, reducing management overhead and the potential for security holes.

MCKMS Features

• Secure Key Storage and Origination: Secure storage is the foundation of any KMS. An MCKMS often utilizes HSMs as a well-established approach for protecting cryptographic keys in a secure, tamper-resistant environment. These HSMs may be certified against security standards like FIPS 140-3 Level 3 or higher, providing a high level of assurance for key generation and cryptographic operations. This architecture maintains a logical and physical separation between the keys and the cloud-hosted data they protect

• Centralized Key Lifecycle Management: An MCKMS should be able to centrally manage keys across their entire lifecycle, including secure generation, backup/restore, clustering, deactivation, and deletion. Many systems offer policy-based automation for these tasks, such as automated key rotation, to reduce manual overhead and consistently enforce security requirements

• Broad Interoperability with Third-Party Systems: To work with the multitude of systems that require encryption, MCKMS solutions typically support major interoperability standards. These protocols enable the key management server to communicate with various clients (e.g., servers, storage devices, databases) that use keys for authentication, digital signing, or data encryption. Key standards include:

  • OASIS KMIP: A network-based protocol for client-to-server communication between applications and remote key management servers over TCP/IP. Commonly used for integrating enterprise applications with centralized KMS infrastructure

  • PKCS#11: An API standard that enables applications to communicate with local cryptographic devices (such as HSM drivers, smart cards, or USB tokens) for performing cryptographic operations. The PKCS#11 interface allows applications to access HSM functionality through standardized function calls without requiring vendor-specific code¹¹

  • Cryptographic APIs: Higher-level interfaces that enable applications, such as databases with Transparent Data Encryption (TDE), to communicate with third-party key management servers. Examples include vendor-specific REST/gRPC APIs and cloud provider SDK integrations

• Unified Management and Visibility: These systems often provide a “single pane of glass,” or a single interface, for administering keys across different cloud providers (IaaS, PaaS, SaaS), regions, accounts, and subscriptions. This simplifies administration, offers consistent visibility, and aids in the uniform application of security policies. Automated synchronization can ensure that key operations performed directly in a cloud console are reflected in the centralized management view

• Flexible Deployment and Scalability: As an organization’s IT infrastructure grows and changes, an MCKMS should be flexible enough to adapt. Solutions are available in various formats to suit different requirements, including on-premises physical appliances, virtual appliances for cloud or private infrastructure, and as-a-service models. This allows the MCKMS to be deployed on-premises, in a public cloud, or in a hybrid model

• Auditing, Compliance, and Programmatic Access: An MCKMS delivers centralized logging and reporting of all key management activities. This provides a consolidated audit trail necessary for demonstrating compliance with regulatory frameworks like GDPR, NIST, HIPAA, and PCI DSS, and an MCKMS can often integrate with an organization’s SIEM tools. Additionally, many platforms offer RESTful APIs, enabling programmatic access to key management functions to support automation and self-service initiatives

MCMKS Limitations and Tradeoffs

One consideration with third-party MCKMS is the architectural tradeoff between centralized control and native cloud telemetry. Organizations should evaluate whether their MCKMS solution:

• Integrates via CMK/BYOK: May retain or enhance native audit capabilities while adding cross-cloud centralization

• Operates Externally: Provides centralized audit trails but may have gaps in CSP-native telemetry, control-plane alerts, or real-time access logs

Many enterprise MCKMS platforms support hybrid approaches, combining CMEK integration with centralized policy management. Organizations should assess whether event forwarding, native log ingestion, and policy reconciliation are supported to maintain comprehensive detection and compliance posture [45].

While centralized control improves consistency, organizations should understand the audit visibility implications of different MCKMS architectures:

• CMK/BYOK with Envelope Encryption: CSP platforms maintain comprehensive audit logs of all cryptographic operations (encrypt, decrypt, key usage) even when using customer-managed keys, as these operations occur within the CSP control plane and leverage the DEK/KEK hierarchy. Third-party MCKMS solutions can aggregate these native logs across multiple CSPs for centralized visibility [45]

• Pure External Key Management (HYOK): Keys managed entirely outside the CSP may have limited visibility into key lifecycle events (rotation, policy changes, deletion) from the CSP perspective, as these operations occur outside the cloud provider’s control plane. Organizations should ensure their external KMS provides comprehensive audit trails and integrates with SIEM tools

Organizations should assess whether their MCKMS supports event forwarding, native log ingestion, and policy reconciliation across clouds to maintain complete detection and compliance posture [46], [47].

Control Cloud Encryption Keys

Leverage the value of BYOK and HYOK models with full-lifecycle cloud encryption key management. Enhance operational efficiency with centralized key management across hybrid, single- and multi-cloud environments, including key discovery¹², management of native cloud keys, and automated key rotation. Comply with the most stringent data protection mandates with secure key origination. Extend the value of native keys by using a robust multi-cloud platform with outstanding UI.

Essentials of Enterprise Key Management

As organizations deploy an ever-increasing number of encryption solutions, they can decrease the risk of a breach or non-compliance by using a centralized key management solution that enables them to securely store and backup/restore the encryption keys, define consistent access control policies, audit all key management operations and separate encryption tasks from key management tasks. Here are the essential elements of a robust enterprise key management solution that can help address data security challenges:

• Secure Key Storage: Secure key storage is the foundation for any enterprise KMS. HSMs is a well-established approach for protecting encryption keys. Mandated in government and certain financial/payment markets, HSMs protect cryptographic keys and perform various cryptographic functions in a secure tamper-resistant environment. Enterprise KMS implementations should provide options to support built-in HSMs, external network-attached HSMs, or a cloud-based HSM-as-a-service based on the level of assurance a company needs (e.g., whether FIPS 140-3 L3 or L4)¹³

• Centralized Key Lifecycle Management: The KMS should be able to centrally manage keys across their entire lifecycle, including secure key generation, backup/restore, clustering, deactivation, and deletion. The KMS should also provide policy-based access control to keys (e.g., RBAC, enforce SoD), support various authentication providers (e.g., Active Directory, LDAP, OIDC, SAML), and support robust auditing of all key management operations

• Enabling Scalability and Flexibility: As the complexity of an organization’s IT infrastructure grows from a single onsite data center to external hosted environments to multiple CSPs, the enterprise key management solution should be flexible enough to adapt to changing requirements for sensitive data. A flexible key management solution supports on-premises infrastructure. It is deployable as a virtual appliance in public cloud environments such as AWS, Azure, Google Cloud, Oracle, Salesforce, and SAP; private clouds such as VMware vSphere, Microsoft Hyper-V, and Nutanix AHV; and hybrid clouds such as Azure Stack

• Interoperability with Third-Party Systems: Recommended enterprise KMS support the following three major interoperability standards that enable you to work with multiple server, storage, and device vendors who use the keys for authentication, digital signing, or encrypting data:

  • PKCS#11: PKCS#11 Specifies an API for devices to interoperate with HSMs and smart cards that hold cryptographic tokens. PKCS#11 is also used to access signing keys from CAs or to enroll user certificates for digital signing and encryption using asymmetric keys. As an example, Oracle TDE uses PKCS#11

• EKM/MSCAPI: Extensible Key Management (EKM) using the Microsoft Cryptographic APIs (MSCAPI), enables MS SQL Server to communicate with third-party key management servers. The keys should be exported from a provider before they are stored in the database. This approach enables key management that includes an encryption key hierarchy and key backup for Microsoft SQL Server Transparent Data Encryption

• OASIS KMIP: KMIP, maintained by the Organization for Advancing Open Standards for the Information Society (OASIS), defines the standard protocol for any key management server to communicate with clients (e.g., storage devices, databases) that use the keys for embedded encryption. KMIP enables interoperability for key lifecycle management between encryption systems and enterprise applications

Conclusion and Future Outlook

Multi-cloud adoption has transformed how organizations manage cryptographic keys, but it has also introduced significant security, operational, and compliance challenges. The lack of standardization across CSPs, inconsistent security models, and the complexity of key lifecycle management demand a strategic approach to encryption key management.

A critical takeaway is that key ownership and control remain at the core of security and compliance decisions. While CSP-managed key solutions offer convenience, they limit customer control over cryptographic operations, making them unsuitable for highly regulated industries. Customer-managed and hybrid approaches provide greater autonomy but require advanced security maturity, governance, and operational capabilities.

Interoperability and performance are also pressing challenges in multi-cloud key management. Vendor lock-in, key portability, and policy enforcement across heterogeneous environments may warrant evaluation of solutions that support standardization efforts. Historically, on-premises solutions adopt an OASIS standard like KMIP and PKCS#11 to support these efforts, but cloud-based solutions generally rely on CSP-specific APIs. Resiliency impacts, latency, and CSC management requirements will also factor into these decisions.

Regulatory and compliance pressures are also shaping multi-cloud key management strategies. Organizations handling sensitive data across jurisdictions should ensure encryption key storage, access control, and lifecycle policies comply with industry regulations such as GDPR, PCI DSS, HIPAA, and CCPA. This often necessitates hybrid or third-party KMS to maintain compliance while enabling seamless cloud adoption.

Looking ahead, organizations should adopt a risk-based, layered approach to key management in multi-cloud environments. Centralized key visibility, automation for lifecycle management, access controls, and secure key synchronization mechanisms will be critical in mitigating security risks while maintaining business agility. Aligning key management strategies with security, operational, and compliance requirements, organizations can secure their multi-cloud environments while ensuring resilience, scalability, and regulatory adherence in an evolving threat landscape.

Future Outlook

The evolution of key management will be driven by advancements in cryptographic technologies, regulatory changes, and the growing adoption of cloud-native security models. Several key trends are expected to shape the future of multi-cloud key management:

• Increased Adoption of PQC: With quantum computing advancements posing a potential threat to traditional cryptographic algorithms, enterprises will need to transition towards a quantum-resistant KMS. As organizations assess transition requirements (e.g., key size, algorithm, processing requirements, limitations) for adoption of PQC-compatible key management, KMS options will impact future-proofing of encryption strategies

• Enhanced Automation and AI-Driven Key Management: AI and machine learning are increasingly being leveraged for security automation. Future KMS approaches will likely integrate AI to enhance key lifecycle automation, anomaly detection, and risk-based key usage policies, reducing the operational burden on security teams

• Growth of Confidential Computing and Homomorphic Encryption: As organizations seek to process sensitive data without exposing it, confidential computing and homomorphic encryption will play a more significant role. This will necessitate new approaches for managing encryption keys in environments where computation occurs on encrypted data

• Standardization of Multi-Cloud Key Management Interoperability: The lack of interoperability between CSP-specific KMS solutions remains a challenge. Emerging industry standards, such as the KMIP, will likely see wider adoption, enabling seamless key portability and synchronization across cloud environments

• Regulatory and Compliance Evolution: Data sovereignty laws and regulatory requirements continue to evolve globally. Future regulatory frameworks may introduce stricter controls on key ownership, key destruction policies, and cloud-provider independence, further driving demand for external KMS

• Expansion of Decentralized Key Management Models: Blockchain and decentralized identity technologies are influencing the future of key management. Decentralized key management models may emerge as a viable alternative for organizations seeking to enhance user control and reduce dependency on central authority key stores

• Greater Emphasis on Supply Chain Security in KMS Design: Growing awareness of supply chain threats will lead to enhanced scrutiny of KMS vendor dependencies, firmware integrity, and HSM provenance, ensuring that cryptographic operations are not undermined by compromised supply chain components

• Self-Healing and Resilient KMS Architectures: Future systems may employ distributed ledger technology, redundancy models, and autonomous recovery mechanisms that can reconstitute keys or trust anchors in the event of a catastrophic failure, ransomware attack, or insider compromise

• KMS-as-a-Service Federation Models: Federated KMS-as-a-Service offerings could emerge, allowing organizations to leverage a unified policy and control layer across multiple providers without centralizing all cryptographic material in a single environment

• Securing AI Pipelines: As organizations operationalize large language models (LLMs) and AI pipelines across cloud environments, managing key material and secrets becomes more complex. Authentication certificates, access tokens for foundation models, API keys for inference services and credentials for vector stores often traverse multiple systems and orchestrators. These data are typically managed by the CSPs that provide the AI services and fall outside traditional key rotation processes and are rarely integrated into KMS governance. Future key management strategies should include support for ephemeral identity, automated revocation, and runtime-bound secret scopes tailored to LLM and AI workloads

As cloud security challenges continue to evolve, organizations should proactively adapt their key management strategies to align with emerging technologies and regulatory landscapes. By implementing resilient, scalable, and interoperable KMS, enterprises can ensure the security and integrity of their cryptographic assets across multi-cloud environments.

Glossary

All the used terms in this document can be found in the CSA Glossary, except from the following, to which definitions follow below:

BCP: Business Continuity Planning: A process for ensuring that critical operations can continue during, or recover promptly from, a disruption – including disruptions to key management infrastructure.

BYOC: Bring-Your-Own-Certificate: Model in which an enterprise provides its own certificates to the CSP, rather than using CSP-generated certificates.

BYOK: Key responsibility model characterized by customer-managed keys with External Key Origination, commonly used to highlight customer control over the key management lifecycle prior and/or concurrent with its use within the CSP environment. [20] BYOK commonly describes scenarios where organizations generate and manage cryptographic keys outside the CSP’s environment, and are subsequently imported into the provider’s KMS. For more information, view the CSA Key Responsibility Models resource (https://cloudsecurityalliance.org/artifacts/key-responsibility-models).

CMK: Customer Master Keys: Sometimes called Customer-Managed Encryption Keys (CMEKs), this architecture allows the CSP to direct the entire lifecycle of the key. For more information, view the CSA Key Responsibility Models resource. (https://cloudsecurityalliance.org/artifacts/key-responsibility-models).

DR: Disaster Recovery: A set of plans, policies, tools, and procedures to enable recovery of critical systems following a catastrophic event.

HYOK: Hold-Your-Own-Key: Key responsibility model that enables the CSP to maintain control of keys within their own KMS solution (e.g., onsite or colocated HSM). The customer-managed KMS handles encryption key operations and requests. This means that the customer retains control over the cryptographic keys used to protect their data, even when that data is stored in a CSP’s environment. For more information, view the CSA Key Responsibility Models resource. (https://cloudsecurityalliance.org/artifacts/key-responsibility-models).

KEM: Key Encapsulation Mechanisms: Cryptographic primitive used to securely establish shared symmetric keys between parties across untrusted channels, including algorithms for key generation, encapsulation, and decapsulation.

MCKMS: Multi-Cloud KMS: Centralized key management system or platform designed to manage cryptographic keys across two or more CSPs.

TDE: Transparent Data Encryption: Database encryption approach in which data is automatically encrypted at rest by the database management system. Because these operations occur automatically at the physical storage level, this approach is transparent to the user, and can be managed without requiring changes to applications interacting with the database .

References

[1] Internet Engineering Task Force (IETF). (2008). RFC 5280: Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile. https://datatracker.ietf.org/doc/html/rfc5280

[2] Internet Engineering Task Force (IETF). (2013). Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile. https://datatracker.ietf.org/doc/html/rfc6818

[3] Internet Engineering Task Force (IETF). (2016). Public-Key Cryptography Standards (PKCS). https://datatracker.ietf.org/doc/rfc8017/

[4] Internet Engineering Task Force (IETF). (2026). Implementation Guidance for the PKCS #1 RSA Cryptography Specification. https://datatracker.ietf.org/doc/draft-irtf-cfrg-rsa-guidance/

[5] Internet Engineering Task Force (IETF). (2024). Updates to X.509 Policy Validation. https://datatracker.ietf.org/doc/html/rfc9618

[6] Internet Engineering Task Force (IETF). (2024). No Revocation Available for X.509 Public Key Certificates. https://datatracker.ietf.org/doc/html/rfc9608

[7] Internet Engineering Task Force (IETF). (2024). Internationalized Email Addresses in X.509 Certificates. https://datatracker.ietf.org/doc/html/rfc9598

[8] Internet Engineering Task Force (IETF). (2024). Internationalization Updates to RFC 5280. https://datatracker.ietf.org/doc/html/rfc9549

[9] Payment Card Industry Security Standards Council (PCI SSC). (2024). Payment Card Industry Data Security Standard: Requirements and Security Assessment Procedures, Version 4.0.1. docs-prv.pcisecuritystandards.org/PCI%20DSS/Standard/PCI-DSS-v4_0_1.pdf

[10] National Institute of Standards and Technology (NIST). (2020). Recommendation for Key Management: Part 1 – General. NIST Special Publication 800-57 Part 1, Revision 5. https://doi.org/10.6028/NIST.SP.800-57pt1r5

[11] International Organization for Standardization (ISO) (2015). ISO/IEC 27040: Storage Security. Geneva: ISO. https://www.iso.org/standard/44404.html

[12] Cloud Security Alliance (CSA). (2017). Security Guidance for Critical Areas of Focus in Cloud Computing v4.0. Cloud Security Alliance. https://cloudsecurityalliance.org/research/guidance

[13] International Organization for Standardization (ISO). (2024). ISO/IEC 27040:2024: Information Technology – Security Techniques – Storage Security. 2nd ed. Geneva: ISO. https://www.iso.org/standard/80194.html

[14] Payment Card Industry Security Standards Council (PCI SSC). (2021). PCI PTS HSM Standard v4.0: Hardware Security Module Security Requirements. Wakefield: PCI SSC. https://docs-prv.pcisecuritystandards.org/PTS/Standard/PCI_HSM_Security_Requirements_v4.pdf

[15] Microsoft. (2023). What’s new in Azure Database for PostgreSQL Flexible Server. Microsoft Tech Community. https://techcommunity.microsoft.com/t5/azure-database-for-postgresql/what-s-new-in-azure-database-for-postgresql-flexible-server/ba-p/3840810

[16] Thales. (2024). The Luna HSM. Thales Group Documentation. https://thalesdocs.com/gphsm/luna/7/docs/network/Content/Product_Overview/the_luna_hsm.html

[17] International Organization for Standardization (ISO). (2022). ISO/IEC 27002: Information security, cybersecurity and privacy protection — Information security controls. Geneva: ISO. https://www.iso.org/standard/73906.html

[18] National Institute of Standards and Technology (NIST). (2018). Platform Firmware Resiliency Guidelines. NIST Special Publication 800-193. https://doi.org/10.6028/NIST.SP.800-193

[19] Google Cloud. (2024). Attest a key using Key Management Service. Google Cloud Documentation. https://cloud.google.com/kms/docs/attest-key

[20] Google Cloud. (2023). Key Management: A Deep Dive into Google Cloud Security Practices. Google Cloud Documentation. https://cloud.google.com/docs/security/key-management-deep-dive

[21] Dar, A. (2023). How to Effectively Implement KMS in a Multi-Cloud Environment. LinkedIn. https://www.linkedin.com/pulse/how-effectively-implement-kms-multi-cloud-environment-dar/

[22] Thales Trusted Cyber Technologies. (2022). Best Practices for Cloud Data Protection and Key Management. Thales Trusted Cyber Technologies. https://www.thalestct.com/wp-content/uploads/2022/09/Best-Practices-Cloud-Data-Protection-and-Key-Management-TCT-WP.pdf

[23] Cloud Security Alliance (CSA). (2020). Key Management in Cloud Services. https://cloudsecurityalliance.org/artifacts/key-management-in-cloud-services

[24] Amazon Web Services (AWS). (2024). Summary of the Amazon Kinesis Data Streams Service Event in Northern Virginia (US-EAST-1) Region. https://aws.amazon.com/message/073024/

[25] GBHackers. (2025). Google Cloud Suffers Major Disruption After API Management Error. https://gbhackers.com/google-cloud-suffers-major-disruption/

[26] Digital Identity Rights Framework. (2025).
https://cloudsecurityalliance.org/blog/2025/08/27/introducing-dirf-a-comprehensive-framework-for-protecting-digital-identities-in-agentic-ai-systems

[27] National Institute of Standards and Technology. (2025). Considerations for achieving cryptographic agility (CSWP 39). U.S. Department of Commerce.
https://csrc.nist.gov/pubs/cswp/39/final

• Google Cloud. (2025). Cloud KMS resource consistency. Google Cloud Documentation.
  https://cloud.google.com/kms/docs/resource-consistency

• Amazon Web Services. (2024). Rotating AWS KMS keys. AWS Documentation.
  https://docs.aws.amazon.com/kms/latest/developerguide/rotate-keys.html

[28] Amazon Web Services (AWS). “External Key Stores - Performance Considerations,” AWS KMS Developer Guide. https://docs.aws.amazon.com/kms/latest/developerguide/keystore-external.html

[29] GCPing. “Google Cloud Platform Network Latency Measurements.” https://gcping.com/

[30] Amazon Web Services (AWS). “AWS Key Management Service Best Practices,” AWS Whitepaper. https://docs.aws.amazon.com/kms/latest/developerguide/best-practices.html

[31] Microsoft Azure. “Azure Key Vault Performance Guidelines.” https://learn.microsoft.com/en-us/azure/key-vault/general/overview

[32] Google Cloud. “Cloud KMS Performance.” https://cloud.google.com/kms/docs/key-states

[33] Amazon Web Services (AWS). “Automating OpenID Connect-based AWS IAM Web Identity Roles with Microsoft Entra ID.” https://aws.amazon.com/blogs/apn/automating-openid-connect-based-aws-iam-web-identity-roles-with-microsoft-entra-id/

[34] Amazon Web Services (AWS). “Envelope Encryption,” AWS KMS Developer Guide. https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#enveloping

[35] NIST Special Publication 800-57 Part 1 Rev. 5. (2020). “Recommendation for Key Management: Part 1 - General,” May 2020. https://csrc.nist.gov/pubs/sp/800/57/pt1/r5/final

[36] Amazon Web Services (AWS). “Monitoring AWS KMS with Amazon CloudWatch.” https://docs.aws.amazon.com/kms/latest/developerguide/monitoring-cloudwatch.html

[37] Google Cloud. Business continuity patterns. Google Cloud Architecture Center. Retrieved October 2025 from: https://cloud.google.com/architecture/hybrid-multicloud-patterns-and-practices/business-continuity-patterns

[38] Amazon Web Services (AWS). “Multi-Region Keys in AWS KMS.” https://docs.aws.amazon.com/kms/latest/developerguide/multi-region-keys-overview.html

[39] WWPass. (2025). “Distributed key management for cloud apps.” WWPass Blog. https://www.wwpass.com/blog/distributed-key-management-for-cloud-apps/

• Amazon Web Services (AWS). (2021). “AWS Encryption SDK: How to decide if data key caching is right for your application.” AWS Security Blog. https://aws.amazon.com/blogs/security/aws-encryption-sdk-how-to-decide-if-data-key-caching-is-right-for-your-application/

[40] Pant, D., Kumar, A., Lohani, S., & Wason, M. (2025). A threshold cryptography framework for secure and resilient symmetric key management in multi-cloud environments. International Journal of Global Innovations and Solutions, 2. https://doi.org/10.63412/65na4629

[41] Amazon Web Services (AWS). “AWS KMS Pricing.” https://aws.amazon.com/kms/pricing/

• Microsoft Azure. “Key Vault Pricing.” https://azure.microsoft.com/en-us/pricing/details/key-vault/

[42] Google Cloud. “Cloud KMS Pricing.” https://cloud.google.com/kms/pricing

[43] National Institute of Standards and Technology. (2025). Considerations for achieving cryptographic agility. (NIST Cybersecurity White Paper CSWP 39). U.S. Department of Commerce. https://csrc.nist.gov/pubs/cswp/39/considerations-for-achieving-cryptographic-agility/2pd

[44] Thales. (2025). PKCS#11. Thales Docs. Accessed November 3, 2025: https://thalesdocs.com/gphsm/ptk/5.9/docs/Content/PTK-C_Program/intro_PKCS11.htm

[45] Google Cloud. (2024). Customer-managed encryption keys (CMEK). Cloud KMS Documentation. https://cloud.google.com/kms/docs/cmek

[46] Amazon Web Services. Logging AWS KMS API calls with AWS CloudTrail. AWS Key Management Service Developer Guide. https://docs.aws.amazon.com/kms/latest/developerguide/logging-using-cloudtrail.html

[47] Microsoft. Logging Azure Key Vault. Azure Key Vault Documentation. https://learn.microsoft.com/en-us/azure/key-vault/general/logging?tabs=Vault

[48] NIST. Special Publication 800-57, “Recommendation for Key Management.”

[49] NIST. Special Publication 800-130, “A Framework for Designing Cryptographic Key Management Systems.”

[50] Amazon Web Services (AWS). “Data protection in AWS Key Management Service,” AWS KMS Developer Guide. https://docs.aws.amazon.com/kms/latest/developerguide/data-protection.html

[51] Microsoft. “How to migrate key workloads,” Azure Key Vault Documentation. https://learn.microsoft.com/en-us/azure/key-vault/general/migrate-key-workloads

[52] Amazon Web Services (AWS). (2024). “Large scale migration of encrypted objects in Amazon S3 using S3 Batch Operations,” AWS Storage Blog, August 2024. https://aws.amazon.com/blogs/storage/large-scale-migration-of-encrypted-objects-in-amazon-s3-using-s3-batch-operations/

[53] NIST. Cryptographic primitive. https://csrc.nist.gov/glossary/term/cryptographic_primitive

Helpful Links

Netmaker, Security Risks of Multi-Cloud Setups & How to Mitigate Them
https://www.netmaker.io/resources/multi-cloud-security

Thales, Key Management as a Service (KMaaS) Explained https://cpl.thalesgroup.com/blog/encryption/key-management-as-a-service-guide

Thales, CipherTrust Cloud Key Management - Product Brief
https://cpl.thalesgroup.com/resources/encryption/ciphertrust-cloud-key-manager-product-brief

IBM, Cloud Hyper Protect Crypto Services
https://www.ibm.com/products/hyper-protect-crypto