Cloud Security and Post-Quantum Cryptography: The Migration Your Cloud Provider Has Not Told You About

AWS, Azure, and GCP have been quietly deploying post-quantum cryptography across parts of their infrastructure for several years. AWS added hybrid post-quantum TLS to AWS KMS in 2019. Google deployed hybrid key exchange in Chrome and on internal infrastructure. This is genuine progress and worth acknowledging. It is also incomplete in a specific, consequential way that most cloud engineers have not mapped.

What the cloud providers are migrating is infrastructure within their own responsibility boundary. What they are not migrating, and cannot migrate on your behalf, is everything on the customer side of the shared responsibility model. Customer-managed keys, application-layer cryptography, encrypted backup data, and code-signing infrastructure are all on the customer side of that boundary. For most cloud-hosted organisations, that represents a significant PQC migration obligation that the provider's TLS deployment does nothing to address.

This is the migration your cloud provider has not told you about. Not because they are withholding information, but because it is yours to do.

What Cloud Providers Actually Handle

Understanding where provider responsibility ends requires being specific about what it covers. The three hyperscalers handle post-quantum cryptography for the layers they own and operate.

TLS to their service APIs: connections from customer applications to AWS services, Google Cloud APIs, and Azure management endpoints use TLS at the provider's termination layer. AWS has deployed hybrid key exchange for TLS sessions to AWS KMS. Google has deployed hybrid TLS across Chrome and certain Google Cloud services. Provider-managed TLS means the encryption protecting the transport channel between your application and the provider's service boundary is within the provider's migration scope.

Provider-managed KMS keys: where AWS KMS, Azure Key Vault, or GCP Cloud KMS manages the key material, and the customer has not brought their own key, the provider's key management infrastructure is within the provider's migration scope. When a provider stores and manages the key for S3 encryption with AWS-managed keys, migrating that key to a post-quantum-safe scheme is the provider's responsibility.

IAM and control-plane communications: service-to-service authentication within the provider's infrastructure, identity management API calls, and internal service mesh communications are within the provider's operational boundary.

This is a meaningful amount of protection. An organisation that uses AWS-managed encryption for all storage services and accesses those services only via provider-managed TLS receives meaningful post-quantum protection across those specific channels. The problem is that this is rarely the complete picture of an organisation's cloud cryptographic footprint.

The Shared Responsibility Model Applied to PQC Migration

AWS's shared responsibility model defines AWS's responsibility as "security of the cloud" and the customer's responsibility as "security in the cloud." The model is well understood in the industry for access control, logging, and network security. It is poorly applied to the PQC migration question.

The logical extension is direct. Wherever the customer controls the cryptographic implementation, PQC migration is the customer's responsibility, irrespective of what the provider is doing on its side. The model was designed around classical cryptographic assumptions and has not been formally updated for PQC. But the structural logic applies without modification. Control equals responsibility.

For most cloud-hosted organisations, the customer-side cryptographic surface is larger than any single provider migration will address.

Four Customer-Controlled Exposure Surfaces

Customer-Managed Keys and BYOK

In a BYOK (Bring Your Own Key) or CMK (Customer-Managed Key) configuration, the customer provides or generates the key material. The cloud KMS stores and uses that material but does not control its cryptographic algorithm. If a BYOK configuration uses an RSA-4096 master key for key wrapping, migrating that master key to an ML-KEM (FIPS 203, August 2024) or ML-DSA (FIPS 204, August 2024) based scheme is the customer's responsibility. The KMS will accept a post-quantum-safe key if the customer provides one. It will not prompt for the migration or perform it automatically.

BYOK configurations shift key control to the customer, which is the correct posture for sensitive data. It also means the customer owns the quantum migration for those keys entirely. Greater control equals greater responsibility. This is not a criticism of BYOK; it is the logical consequence of the architecture.

For HNDL risk specifically: an adversary who captured encrypted cloud storage access logs, API session recordings, or data transfers where a BYOK RSA key was used for key wrapping can recover the plaintext post-CRQC by breaking the RSA key wrapping with Shor's algorithm, even if the provider's TLS termination has already been migrated. The two migration perimeters are independent. Provider-side progress does not discharge customer-side exposure.

Application-Layer Cryptography

Customer-deployed application code running on cloud infrastructure that performs cryptographic operations is entirely outside the provider's migration scope. Applications using RSA or ECDH for application-layer TLS, data encryption, or key wrapping need to migrate their cryptographic libraries to NIST-standardised post-quantum algorithms on the customer's schedule.

This includes a wide range of common patterns: application-layer mutual TLS between microservices, encrypted database field operations handled by application code, signed JWTs and OAuth tokens where the signing key is customer-managed, and any API client library that handles its own key exchange independently of the provider's TLS termination.

Encrypted Backups and Archive Data

Every encrypted backup, snapshot, or archived dataset created before quantum-safe re-encryption is a candidate for HNDL exposure. The ciphertext was created with the cryptographic scheme in use at creation time. An adversary who captures that ciphertext can, post-CRQC, break the RSA or ECDH key wrapping and recover the AES session key used to encrypt the payload, then decrypt the payload.

Re-encryption is the customer's responsibility. For organisations with large cloud storage footprints, the practical scale of quantum-safe re-encryption is worth estimating concretely: petabytes of encrypted backups cannot be re-encrypted as a single overnight operation. For many organisations, this is a multi-year programme, not a configuration change. Starting the inventory of what needs re-encrypting and in what priority order is the prerequisite step.

Code-Signing Infrastructure

Code-signing certificates and pipelines commonly use ECDSA or RSA for signing application artefacts, container images, and infrastructure code. The post-quantum digital signatures explainer covers what ML-DSA and SLH-DSA replace in practice. These pipelines typically operate with customer-managed signing keys and certificates. PQC migration for code signing, to ML-DSA (FIPS 204) or SLH-DSA (FIPS 205) signatures, is on the customer's schedule, not the provider's. The provider may operate the CI/CD infrastructure, but the signing keys and certificate authorities are customer-controlled.

The Regulatory Dimension: Jurisdictional Precision Matters

Two EU regulatory frameworks create specific obligations for cloud-hosted cryptographic assets. Getting the jurisdictional scope right is important: these are not universal requirements.

DORA, the Digital Operational Resilience Act (EU Regulation 2022/2554, in force 17 January 2025), applies to EU financial entities and their ICT third-party service providers with significant roles. Article 6 establishes the ICT risk management framework requirement. Article 9 requires protection and prevention measures that explicitly encompass cryptographic controls. EU financial entities subject to DORA cannot rely on their cloud provider's migration to satisfy Article 9 obligations where customer-managed cryptographic assets are in scope. DORA's obligations fall on the financial entity's own cryptographic controls, not merely on the infrastructure they run on.

DORA does not apply to UK financial institutions. UK firms are subject to FCA and PRA operational resilience rules, specifically Supervisory Statement SS1/21 and Policy Statement PS21/3, and Bank of England guidance. An article, a consultant, or an assessment that presents DORA obligations as applicable to a UK-only organisation is incorrect on the jurisdictional scope.

NIS 2 (Directive 2022/2555, Member State transposition deadline October 2024) applies to EU operators of essential services and digital service providers. Article 21(2)(h) requires use of cryptography and encryption as a cybersecurity risk management measure. The shared responsibility model analysis applies: NIS 2 obligations for cryptographic controls extend to the full scope of a covered entity's cryptographic infrastructure, including cloud-hosted assets managed with customer-controlled keys.

For UK entities, the operative framework is the UK NIS Regulations 2018, SI 2018/506. Regulation 10 requires appropriate and proportionate technical and organisational measures to manage risks to network and information systems. As NCSC guidance on quantum risk matures, what counts as appropriate increasingly includes post-quantum migration planning for high-priority systems.

What Customers Need to Do

The sequence follows the standard migration priority logic, but adapted for the cloud-hosted context.

Cryptographic inventory first. Identify every location where customer-controlled cryptographic keys or customer-deployed encryption exists in the cloud estate: BYOK and CMK configurations across all services, application-layer TLS termination in customer code, encrypted backup policies and their key management, code-signing pipeline certificates, and API authentication schemes using customer-managed credentials. You cannot migrate what you have not mapped.

BYOK and CMK key material second. Identify all services using customer-managed keys. Develop a migration plan for each. Confirm with each provider's KMS documentation which PQC key types are currently accepted. The answer varies by provider and service, and it is changing as providers add PQC key support to their KMS platforms.

Application-layer cryptographic libraries third. Audit customer-deployed cryptographic libraries for RSA or ECDH usage at the application layer. Libraries need to migrate to FIPS 203 (ML-KEM for key exchange) and FIPS 204 (ML-DSA for signatures) or FIPS 205 (SLH-DSA as an alternative signature scheme). The target algorithms are standardised and available in major cryptographic libraries.

Backup and archive re-encryption fourth. Classify encrypted backup data against HNDL risk criteria. Long-lived sensitive data with a secrecy horizon extending past 2033-2035 is in the priority tier. Develop a re-encryption roadmap with realistic timelines given storage volumes.

Code-signing infrastructure fifth. Audit all code-signing certificates and CA chains in CI/CD pipelines. Develop a migration plan for the signing key material and certificates to post-quantum-safe schemes, coordinated with any certificate authority refresh cycles.

To map your quantum exposure across cloud-hosted assets, QSECDEF's Q-Day timeline risk calculator provides a structured framework for prioritising the migration scope. For the cryptographic inventory methodology that precedes all migration planning, the published cryptographic inventory guide covers the prerequisite step. For the cloud KMS-specific migration analysis across AWS, Azure, and GCP, the cloud KMS PQC readiness comparison provides provider-by-provider coverage.

The Provider's Migration Is Not Your Migration

The cloud provider's TLS deployment is good news for the infrastructure layer within its boundary. It is not sufficient, and it was never designed to be sufficient, for the customer's complete cryptographic migration obligation.

The organisations that discover this distinction early, during inventory, have time to plan the customer-side migration properly. Those that discover it late, when a regulator or a CISO asks what has been migrated and receives an incomplete answer, face an accelerated programme under constraint. The shared responsibility model has always divided the work. The quantum migration does not change that division. It just makes the customer side of it more consequential.