Key Management in Multi-Cloud Environments

Key management in multi-cloud environments means bringing AWS KMS, Azure Key Vault, and Google Cloud KMS under one consistent policy, rotation schedule, and audit trail instead of managing three disconnected native key managers independently. For any organization running workloads across two or more cloud providers, the recommended action is to inventory existing cryptographic material first, then layer BYOK, HYOK, or a centralized KMaaS platform on top based on your sovereignty requirements and compliance obligations.

A leaked encryption key does not stay contained to one cloud. If that key protects data in AWS S3 and the same organization also runs workloads in Azure and Google Cloud, the blast radius follows the data. The encryption is only as strong as the weakest key management practice across every environment.

Key Takeaways

• AWS, Azure, and Google Cloud each ship a separate, non-interoperable key manager built around proprietary APIs, with no shared standard such as KMIP between them.
• BYOK imports your key material into a cloud KMS; HYOK keeps that material entirely outside the cloud for every cryptographic operation. HYOK is the stronger sovereignty model; BYOK is simpler to operate.
• NIST moves every remaining FIPS 140-2 certificate to Historical status on September 21, 2026, making FIPS 140-3 Level 3 the required specification for any new HSM or KMS procurement.
• NIST published FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), and FIPS 205 (SLH-DSA) in August 2024. Every cloud KMS will need to support these post-quantum algorithms before NIST IR 8547’s RSA and ECC deprecation window around 2030.
• Gartner expects more than 60% of organizations to adopt a centralized multi-cloud Key Management as a Service (KMaaS) by 2027 as data residency rules tighten globally.
• A complete cryptographic inventory is the mandatory first step before selecting or deploying any centralized key management layer. Starting a KMaaS rollout without it creates a new blind spot on top of an existing one.

Why Is Multi-Cloud Key Management a Board-Level Problem Now?

Flexera’s 2026 State of the Cloud Report found that 73% of organizations run a hybrid cloud model and a further 14% run multi-cloud without any private cloud component. The large majority of enterprises are already managing keys across more environments than a single native key manager was designed to handle.

Each major cloud provider ships its own key manager, and none of them were built to interoperate. AWS Key Management Service (AWS KMS) sits in its own dedicated console under Security, Identity, and Compliance, tied to IAM policies. Azure Key Vault stores keys, secrets, and certificates in one service. Google Cloud KMS organizes keys hierarchically from organization down to individual key version. All three work well inside their own walls. None was designed to give one policy, one audit trail, or one rotation schedule across all three simultaneously.

The compliance frameworks have caught up to this reality. GDPR, DORA Article 9, and PCI DSS v4.0 Requirement 3.6 all require organizations to prove who controls encryption keys, where they reside, and whether key material can be retrieved independently of a single provider. Three separate native key managers make that proof difficult and sometimes impossible to produce cleanly.

Native vs. External Key Control: What the Choice Actually Means

When you use a cloud provider’s native key manager without additional controls, the provider generates, stores, and processes keys on infrastructure they operate. You can set IAM policies restricting which identities can use a key, but the key material itself never leaves the provider’s hardware. This is the default for most cloud workloads and is adequate for many use cases.

External key control changes that relationship. With external key management, you retain custody of the key encryption key (KEK), the key that wraps all the data encryption keys the cloud service uses. The cloud provider holds encrypted key material but cannot decrypt it without calling out to your infrastructure for the wrapping key. This is the architecture behind AWS KMS External Key Store (XKS), Azure Managed HSM with an EKM Proxy, and Google Cloud External Key Manager (Cloud EKM).

The practical difference is accountability. With native key control, the provider is both the key custodian and the processor. With external key control, those roles are separated: you are the custodian, the provider is the processor. That separation is what GDPR’s data sovereignty principle, DORA’s key control requirements, and CMMC’s cryptographic separation-of-duties controls are looking for.

AWS KMS vs. Azure Key Vault vs. Google Cloud KMS: A 2026 Comparison

Here is how the three native services compare on the capabilities that matter most for a multi-cloud key strategy:

Capability	AWS KMS	Azure Key Vault	Google Cloud KMS
External key management (HYOK)	External Key Store (XKS), generally available	Managed HSM EKM Proxy, public preview as of mid-2026	Cloud External Key Manager (Cloud EKM), generally available
Bring Your Own Key (BYOK)	Yes, key import into KMS	Yes, key import into Key Vault	Yes, key import into Cloud KMS
HSM-backed keys	Yes, KMS custom key store or CloudHSM	Yes, Managed HSM or Key Vault Premium	Yes, Cloud HSM
FIPS validation (HSM tier)	FIPS 140-3 Level 3	FIPS 140-3 Level 3 (Managed HSM)	FIPS 140-2 Level 3 (Cloud HSM)
Native cross-cloud standard (KMIP)	No, proprietary API only	No, proprietary API only	No, proprietary API only
Automatic key rotation	Yes, configurable annually or custom schedule	Yes, configurable rotation policy	Yes, automatic rotation with configurable period
Audit logging	AWS CloudTrail, near-real-time	Azure Monitor and Diagnostic Logs	Cloud Audit Logs, Admin Activity and Data Access

BYOK, HYOK, and External Key Stores: What Each Controls

None of the three hyperscalers adopted KMIP as a native interface, so bridging them requires a deliberate architecture decision rather than a configuration change. Two sovereignty models dominate the market:

Bring Your Own Key (BYOK) means you generate key material yourself, typically in an on-premises HSM or a dedicated cloud HSM, and then import an encrypted copy into the cloud provider’s KMS. The cloud provider stores and uses that copy. You control where the original was generated and when it was imported, but after import, cryptographic operations happen inside the provider’s infrastructure. The convenience trade-off: simpler to operate, but the cloud provider’s HSM processes your data encryption keys at rest and in use.

Hold Your Own Key (HYOK) means the key material never enters the cloud at all. Every encrypt and decrypt operation the cloud service needs to perform calls out to your external key manager, such as AWS XKS, Azure Managed HSM EKM Proxy, or Google Cloud EKM, for the wrapping key. The cloud cannot perform any cryptographic operation without your external system approving it in real time. HYOK gives you the strongest sovereignty story and the cleanest answer to a regulator asking who controls the key. The trade-off is latency: every operation requires a round trip to your external KMS, which adds overhead and introduces your external system as a dependency for availability.

For most organizations, the right answer is workload-by-workload: HYOK for data subject to strict data residency rules or defense-related contracts, BYOK for workloads where operational simplicity matters more than proving the cloud never touched the key in transit. For a deeper look at the underlying architecture, see our AWS KMS and CloudHSM overview and our guide to retaining control of encryption keys in the cloud.

IAM Models Across Clouds: Where Key Access Policy Lives

Each cloud’s IAM model governs who can use, manage, or administer encryption keys, but the three models are different enough that a policy written for one provider does not translate directly to another.

In AWS, KMS key policies are resource-level: each key has its own key policy that explicitly grants or denies access, supplemented by IAM identity policies on roles and users. A principal needs permission in both the key policy and their IAM identity policy for the most sensitive operations. This dual-layer model is intentional and provides defense in depth, but it also means that cross-account access to a KMS key requires grants in both the source account’s IAM policy and the destination account’s key policy.

In Azure, Key Vault access is controlled by one of two models: the legacy Access Policies model, which grants permissions at the vault level per principal, or the newer Azure RBAC model, which grants permissions at the vault, certificate, key, or secret level using standard Azure role assignments. Microsoft recommends RBAC for new deployments. Managed HSM uses a separate RBAC model with local roles scoped to the HSM, not the broader Azure RBAC system.

In Google Cloud, Cloud KMS permissions are enforced through standard Google Cloud IAM: roles are granted at the project, key ring, or individual key level. Google also supports organization-level policies that can deny key operations across an entire resource hierarchy, which is useful for enforcing data residency rules centrally.

In a multi-cloud environment, the practical implication is that you need a normalized policy layer. Most organizations implement this through a centralized key management platform that translates one master access policy into the provider-specific permissions for each cloud, rather than maintaining three separate IAM rule sets that can drift out of alignment.

Key Rotation Across Cloud Environments: What Each Provider Does and Where the Gaps Are

Key rotation is the practice of replacing an encryption key with a new one on a defined schedule without re-encrypting all data, by creating a new key version that handles new encryption operations while older versions remain available to decrypt data they previously protected.

AWS KMS supports automatic key rotation for symmetric KMS keys with a rotation period between 90 and 2,560 days. Rotation creates a new key material version; the key ID stays the same, so applications need no changes. AWS retains all prior key versions for decryption of previously protected data.

Azure Key Vault supports rotation policies on individual keys with configurable expiry periods and automatic rotation notifications. The Managed HSM tier mirrors this capability. Certificate and secret rotation requires separate automation using Key Vault event triggers and Azure Functions or similar automation.

Google Cloud KMS rotates keys by creating a new key version and designating it as the primary version for new encryption. You can set an automatic rotation period at key creation, and all prior versions remain available for decryption. Google’s Cloud KMS does not re-encrypt existing ciphertext automatically; if your compliance program requires periodic re-encryption of data under the new key version, that must be implemented separately.

The multi-cloud rotation problem is not that each provider lacks rotation capability. It is that rotation schedules, version naming conventions, grace periods for old versions, and audit log formats differ across all three. Without a centralized orchestration layer, enforcing a single 90-day rotation policy across all key material in all three clouds requires manual coordination or custom automation for each provider’s API. A centralized KMaaS platform handles this translation, triggering rotation on schedule and logging the result in one consolidated audit trail.

Audit Logging Across Cloud Environments: What You Need to See

Compliance frameworks including PCI DSS v4.0, DORA Article 9, HIPAA, and ISO/IEC 27001 require audit logs that record every key use, every key management operation, and every administrative action affecting the key manager. In a multi-cloud environment, these logs are generated separately by each provider and are not aggregated by default.

AWS CloudTrail records every KMS API call, including who called it, from which IP address, when, and whether it succeeded. CloudTrail events for KMS operations are stored in your designated S3 bucket and can be streamed to a SIEM in near real time.

Azure Key Vault generates Diagnostic Logs through Azure Monitor, capturing request logs for every vault or Managed HSM operation. These can be routed to a Log Analytics Workspace, an Event Hub for SIEM streaming, or directly to an Azure Storage account for archival.

Google Cloud Audit Logs record Admin Activity events (key creation, deletion, policy changes) and Data Access events (key use for encryption and decryption operations) for Cloud KMS. Both log types can be exported to Cloud Logging sinks that route to BigQuery, Cloud Storage, or a Pub/Sub topic for SIEM integration.

In practice, most compliance-driven organizations route all three log streams to a single SIEM platform and build normalized alert rules against the combined feed. The alternative is maintaining three separate alerting configurations with three different query languages, which is the operational tax that multi-cloud key management without a centralization strategy imposes.

Cost of Multi-Cloud Key Management: What Organizations Actually Pay

Cloud key management costs are typically low per key, but they scale with the number of cryptographic operations, the HSM tier selected, and whether external key management is in scope.

AWS KMS charges per key per month for customer-managed keys, plus per-request charges for cryptographic operations. KMS custom key store with CloudHSM adds dedicated HSM cluster costs on top. AWS XKS operations for HYOK deployments add a per-request charge for the external key store calls.

Azure Key Vault charges per operation for the standard tier, with Managed HSM priced at an hourly rate per HSM pool regardless of operation volume. The Managed HSM tier is materially more expensive than standard Key Vault, but it is the tier required for FIPS 140-3 Level 3 validation.

Google Cloud KMS charges per active key version per month, plus per-operation fees for cryptographic API calls. Cloud HSM versions are priced higher than software-protected versions. Cloud EKM for HYOK deployments adds per-operation fees for the external key management calls.

The hidden cost that most organizations underestimate is engineering overhead: the time spent maintaining three separate IAM configurations, investigating three separate audit log formats, reconciling three separate rotation schedules, and onboarding new services to each provider’s key manager independently. A centralized KMaaS platform introduces a subscription cost but removes most of that engineering overhead and the operational risk that comes with it.

Multi-Cloud Key Management Architecture Patterns

There are three practical architecture patterns for managing keys across multiple cloud providers. Each has a different cost, complexity, and sovereignty profile:

Pattern 1: Native KMS per cloud, centralized audit aggregation: Each cloud uses its own native KMS with no external key control. All audit logs are routed to a SIEM for centralized alerting. This is the lowest-cost and lowest-complexity option and is appropriate when data sovereignty is not a primary requirement and compliance frameworks do not mandate external key control. The limitation is that there is no single policy enforcement point: rotation schedules, IAM rules, and key lifecycle policies must be managed separately in each cloud.

Pattern 2: BYOK per cloud, centralized key origin: All key material is generated in one controlled location, typically an on-premises HSM or a dedicated cloud HSM, and imported via BYOK into each cloud’s KMS. This gives the organization control over key origin and an importable copy of every key, while cloud providers handle key storage and cryptographic operations. Rotation requires generating a new key version in the source HSM and reimporting it to each cloud, which can be automated but requires orchestration. This pattern is appropriate for organizations that need to prove where key material originated and retain an independent copy outside the cloud, without the latency overhead of HYOK.

Pattern 3: Centralized KMaaS with HYOK per cloud: A central key management platform, backed by FIPS 140-3 validated HSMs, serves as the external key manager for all three cloud providers simultaneously. AWS XKS, Google Cloud EKM, and Azure Managed HSM EKM Proxy all connect to the same central platform. Every encrypt and decrypt operation across every cloud calls out to the central KMaaS for the wrapping key. This gives the strongest sovereignty posture and a single policy, rotation, and audit log for all clouds, at the cost of higher latency, a dependency on the central KMaaS for availability, and higher operational complexity. It is the required pattern for organizations subject to strict data residency mandates, defense contracts, or financial regulations requiring demonstrable key separation from cloud infrastructure.

How to Build a Multi-Cloud Key Management Strategy: A Numbered Process

Most organizations try to pick a key management platform before they have completed the prerequisite steps. This is the sequencing that actually works:

1. Run a cryptographic inventory: Identify every key, certificate, algorithm, and key manager currently in use across every cloud account and on-premises environment. Without this baseline, any centralization strategy starts from a guess. Tools like CBOM Secure automate this discovery and produce a Cryptographic Bill of Materials (CBOM) that maps keys to the workloads and services they protect.
2. Classify workloads by sovereignty requirement: For each workload, determine whether native key control, BYOK, or HYOK is required. Regulatory obligations (GDPR data residency, DORA key control requirements, CMMC CUI protection), contractual obligations (defense contracts, financial agreements), and internal risk tolerance all drive this classification.
3. Define a single key lifecycle policy: Decide on rotation period, key algorithm (RSA 2048+, AES-256, or post-quantum hybrid), naming convention, and approved key origin before selecting any tooling. A centralized KMaaS can only enforce a policy you have already defined.
4. Select an architecture pattern: Map your workload classifications from step 2 to one of the three architecture patterns above: native with centralized audit, BYOK with centralized origin, or centralized KMaaS with HYOK. Most organizations end up with a hybrid of patterns 1 and 2, with pattern 3 applied only to the subset of workloads that genuinely require HYOK sovereignty.
5. Implement a centralized audit log pipeline: Route AWS CloudTrail, Azure Diagnostic Logs, and Google Cloud Audit Logs to a single SIEM before deploying any key management changes. This establishes a baseline and ensures every subsequent change is logged from day one.
6. Automate rotation and lifecycle enforcement: Configure rotation policies in each cloud’s KMS (or in the centralized KMaaS if using pattern 3), verify that rotation events are logged in the SIEM, and confirm that old key versions are retained or deleted according to your defined policy.
7. Assess PQC readiness for key material and HSMs: For any HSM or KMS that will need to support FIPS 203, 204, or 205 before 2030, confirm firmware support or plan hardware replacement. Update key lifecycle policy to include a migration path for each key type from classical to post-quantum or hybrid algorithms.

What Makes Multi-Cloud Key Management Harder Than It Looks

The four challenges below are the ones that cause projects to stall after the initial deployment:

Interoperability between providers: No hyperscaler adopted KMIP as a native interface, so every cross-cloud workflow requires a translation layer, whether custom code, a centralized KMaaS platform, or a combination of both. REST APIs differ enough between providers that scripts built for AWS KMS are not directly portable to Azure or Google Cloud.

Rotation complexity across platforms: Each provider handles rotation scheduling, version numbering, and grace periods for retired key versions differently. A single organizational rotation policy requires either accepting three different implementations or building orchestration that normalizes them, which is non-trivial to test and maintain.

Key sprawl from incomplete inventory: Most organizations discover that they have significantly more encryption keys spread across cloud accounts than anyone expected once they run a real discovery pass. Keys provisioned by development teams, by cloud-managed services, and by third-party integrations accumulate without central visibility. A KMaaS layer on top of an incomplete inventory adds another management tool without removing the sprawl underneath it.

Compliance evidence fragmentation: Auditors increasingly want a single evidence package showing key custody, rotation history, and access control logs for all cloud environments. Producing that from three separate audit log systems with different formats, different retention settings, and different query interfaces is the primary compliance tax of multi-cloud key management without a centralized strategy.

How to Choose a Multi-Cloud Key Management Partner

A few questions are worth answering honestly before signing any contract with a key management vendor or platform provider:

• What is your current usage of encryption across every cloud account, and where are you not using it because of complexity or tooling gaps?
• How many cryptographic objects will the platform need to support today and in three years? Will it scale with your cloud footprint without requiring re-architecture?
• Does it automate key lifecycle operations end to end, or does it introduce a manual step into workflows that are otherwise fully automated in DevOps pipelines?
• Does it integrate natively with the tools you already run, such as your SIEM, your secrets manager, your CI/CD platform, and your MDM, or does it require building custom connectors for each?
• Does the vendor hold SOC 2 Type II, ISO/IEC 27001:2022, and FIPS 140-3 Level 3 certification for the HSMs backing the service? Can they provide current copies of each certification?
• What happens to your key material if the vendor is acquired, goes offline, or you need to exit the contract? Is there a documented, testable export procedure?

Post-Quantum Cryptography and Multi-Cloud Key Management

NIST published FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), and FIPS 205 (SLH-DSA) in August 2024. NIST IR 8547 guidance points toward deprecating RSA and ECC around 2030, with full disallowance by 2035. Each cloud KMS will need to support these algorithms before that deadline arrives.

For multi-cloud environments, PQC migration has an additional dependency: HSMs. If your BYOK or HYOK deployment relies on on-premises HSMs for key generation or wrapping, those HSMs must support ML-KEM and ML-DSA key types through firmware updates or hardware replacement before they can serve as the key origin for post-quantum key material. Verifying HSM firmware roadmaps across vendors is a practical first step.

The cryptographic inventory from step 1 of the strategy process above is the mandatory input for PQC migration planning. You cannot migrate cryptographic material you cannot see, and in a multi-cloud environment with independent native key managers, seeing all of it requires deliberate discovery tooling rather than manual enumeration. For a full assessment of your organization’s PQC readiness and a migration roadmap aligned to NIST IR 8547, see Encryption Consulting’s PQC Readiness service and PQC Center of Excellence.

How Encryption Consulting Can Help

Encryption Consulting is an ISO/IEC 27001:2022 and SOC 2 certified applied-cryptography firm. We help organizations design, implement, and operate key management strategies across AWS, Azure, Google Cloud, on-premises, and hybrid environments.

• CBOM Secure: Our cryptographic discovery and inventory platform runs a discovery pass across your cloud accounts and on-premises infrastructure to produce a complete Cryptographic Bill of Materials. This is the inventory baseline that every multi-cloud key management strategy requires before any centralization tooling is deployed.
• HSM as a Service: Encryption Consulting’s HSM-as-a-Service (HSMaaS) provides FIPS 140-3 Level 3 validated HSM capacity that integrates with AWS KMS External Key Store, Azure Managed HSM EKM Proxy, and Google Cloud EKM to serve as the centralized key origin for BYOK or HYOK deployments across all three clouds.
• Cloud Key Management Advisory: Our Encryption Advisory Services include architecture review, key lifecycle policy design, IAM model normalization across cloud providers, and audit log pipeline design, giving your team a defensible, documented strategy before any tooling is deployed.
• PQC Readiness: Our PQC Readiness service assesses the quantum exposure of your current key material and HSM infrastructure across every cloud and on-premises environment, and produces a migration roadmap calibrated to the NIST IR 8547 timeline and your specific workload profile.
• CertSecure Manager: For organizations that also need to manage the certificate layer across cloud environments alongside key management, CertSecure Manager provides CA-agnostic discovery, automated renewal via ACME, EST, and SCEP, and centralized certificate inventory across cloud-native CAs and self-managed PKI.

Conclusion

Multi-cloud key management stops being optional once production workloads span more than one hyperscaler, and Flexera’s data says most organizations are already there. The answer is not picking a single best key manager. It is deciding, workload by workload, whether native control, BYOK’s convenience, or HYOK’s sovereignty fits the requirement, backing that decision with an accurate inventory, and layering a centralized policy and audit layer on top only once that groundwork is complete.

The FIPS 140-3 transition deadline of September 2026, the NIST PQC standards already finalized, and compliance frameworks like DORA and GDPR that increasingly demand demonstrable key control all point in the same direction: the cost of treating multi-cloud key management as an afterthought is rising, and the window to get the architecture right before the next compliance audit or the next cloud migration is narrowing.

Start with the inventory. Everything else follows from knowing what you actually have.

Last reviewed and updated: September 1, 2026. Encryption Consulting reviews this post whenever NIST updates FIPS 140-3 transition guidance, the CMVP updates validation status for major cloud HSM modules, or NIST IR 8547 PQC deprecation timelines are revised. For questions about your organization’s specific multi-cloud key management requirements, contact our team.

Frequently Asked Questions

What is key management in multi-cloud environments?

Key management in multi-cloud environments is the practice of generating, storing, rotating, and governing encryption keys consistently across two or more cloud providers such as AWS, Azure, and Google Cloud, instead of letting each provider’s native, non-interoperable key manager operate in isolation. It typically layers BYOK, HYOK, or a centralized key management platform on top of each cloud’s native KMS so that policy, rotation, and audit logging stay consistent everywhere.

Why is key management harder in multi-cloud than in a single cloud?

Each cloud provider built its key manager around proprietary APIs, its own IAM model, and its own console, with no shared standard between them. That means separate rotation schedules, separate audit logs, and separate access policies for the same organization. Flexera’s 2026 State of the Cloud Report found 73% of organizations already run a hybrid or multi-cloud model, so the large majority of enterprises are managing keys across more environments than a single native KMS was designed for.

What is the difference between BYOK and HYOK?

With Bring Your Own Key (BYOK), you generate key material yourself and import a copy into the cloud provider’s KMS, which stores and uses that copy. The cloud provider still processes cryptographic operations. With Hold Your Own Key (HYOK), the key material never enters the cloud at all. Every cryptographic operation calls out to your external key manager for approval. HYOK gives the strongest key sovereignty; BYOK is simpler to operate day to day.

Which FIPS validation level should cloud HSM services meet?

FIPS 140-3 Level 3 is the current standard. AWS KMS HSM tier and Azure Key Vault Managed HSM are both FIPS 140-3 Level 3 validated. Google Cloud HSM is FIPS 140-2 Level 3 validated. NIST moves every remaining FIPS 140-2 certificate to Historical status on September 21, 2026, so new procurements should require FIPS 140-3 validated modules wherever your compliance program mandates an active certificate.

Can I use the same encryption key across AWS, Azure, and Google Cloud?

Not directly. Keys generated inside a cloud provider’s native KMS are non-exportable by design. You can import the same key material into multiple providers via BYOK, or keep the material outside every cloud via HYOK, but there is no built-in mechanism for one key object to reside natively inside two hyperscalers simultaneously. A centralized key management layer is the standard approach for enforcing one policy across all three.

What is Key Management as a Service (KMaaS)?

KMaaS is a centralized key management layer that sits above native cloud KMS tools and provides one policy engine, one audit log, and one key inventory across every cloud and on-premises HSM in scope. Gartner expects more than 60% of organizations to adopt a centralized multi-cloud KMaaS by 2027 as data residency and privacy regulations tighten. You likely need it once managing three or more native key managers by hand becomes the operational bottleneck.

How does multi-cloud key management affect compliance with GDPR, DORA, or PCI DSS?

GDPR, DORA Article 9, and PCI DSS v4.0 Requirement 3.6 all require organizations to prove who controls encryption keys, where they reside, and whether they can be retrieved independently of a single cloud provider. A documented BYOK, HYOK, or KMaaS strategy with exportable audit logs gives auditors a clear, verifiable answer to those questions.

How does post-quantum cryptography affect multi-cloud key management?

NIST published FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), and FIPS 205 (SLH-DSA) in August 2024. NIST IR 8547 guidance points toward deprecating RSA and ECC around 2030. Every cloud KMS will need to support these algorithms before that deadline. A complete cryptographic inventory across every cloud in scope is the practical starting point for PQC migration planning, because you cannot migrate cryptographic material you cannot see.