PQC for Cloud Providers

What PQC for cloud providers means

Post-quantum cryptography is the primary mitigation described for the future threat posed by large-scale, fault-tolerant quantum computers: cryptography based on mathematical problems that quantum computers are not expected to solve efficiently. The cloud context matters because cloud services concentrate applications, data, identity systems, software delivery, communications, and dependencies on provider-operated infrastructure. A migration therefore has to address both the provider’s service implementation and the customer’s use of that service. This article uses “cloud provider” broadly for organizations delivering cloud-hosted products and services, while also addressing enterprise teams that consume them.1

The scope is broader than encryption of stored data. NIST’s transition material identifies network protocol and security technology standards, software cryptographic libraries, cryptographic hardware, PKI and other infrastructure components, and IT applications and services as migration areas. Applications and services use cryptography for data protection, user authentication, and secure transactions; they may need changes for encryption, digital signatures, and key exchange. Code, protocols, libraries, certificates, firmware, and user interfaces may all be affected.2

Why cloud organizations should act now

The risk is not limited to information created after a future quantum computer becomes available. NIST’s initial public draft says it expects to prioritize quantum-resistant key-establishment schemes to protect against “harvest now, decrypt later” attacks, particularly in interactive protocols such as TLS and IKE. This makes the confidentiality lifetime of data, rather than only the expected service life of today’s infrastructure, an important prioritization factor.2

Cloud dependence also creates a supply-chain and shared-responsibility challenge. The joint CISA, NSA, and NIST guidance says organizations should understand their dependence on quantum-vulnerable cryptography in current IT and OT systems and devices and in their reliance on cloud services. It recommends engaging vendors on quantum-readiness roadmaps and planning contractual changes so new products are delivered with PQC built in and older products can be upgraded in line with transition timelines.3

Cloud customers should not assume that a provider’s public statement or roadmap proves that a specific tenant workload is protected. A service may require a configuration change, a client-library update, a certificate change, an application release, or a protocol negotiation change. The customer remains responsible for discovering how its applications, identities, endpoints, integrations, and stored or transmitted data depend on cryptography.31

A practical cloud migration workflow

A useful workflow begins with governance and discovery, then moves through risk assessment, supplier engagement, design, controlled deployment, and evidence-based assurance. The sequence should be integrated with normal replacement and modernization work rather than run as an isolated algorithm project. The NCSC describes PQC migration as a global-scale change to IT and an opportunity to build broader cyber resilience; the joint fact sheet similarly recommends a project management team to plan and scope migration.31

1. Establish ownership. Form a cross-functional quantum-readiness team including security architecture, cloud platform engineering, application owners, procurement, risk, legal, and relevant operational technology stakeholders.
2. Create a cryptographic inventory. Identify where quantum-vulnerable algorithms are used for encryption, key establishment, digital signatures, certificates, code signing, software and firmware updates, authentication, network protocols, libraries, hardware, and cloud services.
3. Map dependencies and impact. Record the data, business function, tenant or service boundary, client population, provider dependency, confidentiality lifetime, integrity requirement, and replacement or upgrade constraints associated with each use.
4. Prioritize. Give early attention to high-impact systems and data with long-term confidentiality or secrecy needs. Include systems that create or validate digital signatures, because signatures also affect software, firmware, certificates, and trust infrastructure.
5. Engage cloud providers and suppliers. Request the provider’s quantum-readiness roadmap, supported mechanisms, service and region coverage, required configuration or application changes, expected performance and cost effects, testing method, fallback behavior, and retirement plans for traditional algorithms.
6. Design for interoperability and agility. Define interfaces and operational controls that allow cryptographic mechanisms to be replaced or adapted while preserving security and ongoing operations. Avoid embedding algorithm assumptions throughout applications and infrastructure.
7. Pilot and test. Use representative services and clients to test authentication, key establishment, certificates, signing, application behavior, performance, interoperability, failure handling, and rollback. Verify negotiated cryptography rather than relying on configuration intent.
8. Deploy in governed waves. Coordinate provider changes, customer application releases, certificate or PKI changes, and supplier upgrades. Maintain an explicit exception register for systems that cannot yet migrate and document compensating measures.
9. Measure and improve. Track adoption, exceptions, fallback, unresolved dependencies, provider commitments, test results, and the point at which traditional algorithm support can safely be reduced or removed.

The inventory should include both custom-built and commercial off-the-shelf systems. Custom-built products, especially older systems, may require the most effort to make quantum-resistant. For cloud-hosted products, the guidance specifically recommends engaging the cloud service provider to understand its roadmap and, once standards are available, focusing the engagement on how PQC will be enabled through configuration changes or application updates.3

Architecture and operating considerations

Cloud application teams should inspect every cryptographic boundary: client-to-service connections, service-to-service calls, administrative access, APIs, message and document signing, software distribution, backup and archive protection, identity and access management, certificate issuance, and key-management integrations. The cited NIST material does not prescribe one universal cloud architecture; instead, it emphasizes that applications and services must be modified and tested for new algorithms, key sizes, performance characteristics, protocols, and libraries. Teams should therefore assess the complete path rather than treating a provider control-plane feature as sufficient.2

Interoperability is a central operational concern. During transition, cloud services may communicate with legacy clients, third-party systems, private networks, and other providers. Backward compatibility and interoperability are described as crucial to maintaining trust and security. A migration plan should identify which side negotiates the cryptographic mechanism, how unsupported clients are handled, whether fallback is permitted, and what evidence demonstrates that the intended protection was actually selected.21

Performance and size changes must be treated as engineering inputs. NIST notes that applications may need adjustment for changes in key sizes and algorithm performance, alongside code refactoring and extensive testing. In practice, cloud teams should test latency-sensitive paths, connection establishment, certificate chains, storage and transmission overhead, memory and CPU consumption, logging, quotas, and operational tooling. The evidence supports the need for this assessment but does not establish universal performance values; those must be measured for each implementation.2

Integrity deserves equal attention to confidentiality. The NCSC’s industrial-control-system example notes that sensor data may not require strong confidentiality while its integrity can be critical, because faulty readings or commands can cause failures. The same reasoning applies to cloud-connected control, orchestration, software update, and automation systems: signatures and authenticated commands may be as important as encrypted transport.1

Hybrid transition and crypto agility

Hybrid key-establishment techniques and dual signatures can help organizations interoperate while moving away from quantum-vulnerable mechanisms. NIST’s initial public draft says hybrid solutions may provide a path where sector-specific requirements still require legacy algorithms, and that NIST intends to accommodate hybrid techniques in its cryptographic standards where their use is desired. However, NIST also states that hybrid solutions add implementation and architectural complexity, which can increase security risks and costs, and are typically expected to be temporary before a transition to tools using only PQC algorithms.2

A hybrid design should therefore have a documented purpose, defined component algorithms, validation requirements, interoperability tests, operational ownership, and an exit condition. It should not become an indefinite second cryptographic stack. NIST leaves the decision about implementation cost, performance reduction, engineering complexity, and independent security reviews to the specific application when considering hybrid key establishment or dual signatures.2

Crypto agility is the capability to replace and adapt cryptographic algorithms in protocols, applications, software, hardware, firmware, and infrastructure while preserving security and ongoing operations. For cloud providers and customers, this means separating cryptographic policy from business logic where practical, maintaining controlled algorithm configuration, inventorying cryptographic dependencies, testing replacements, and operating change and rollback processes. Agility is an enabling capability, not evidence that a migration is complete.4

Standards, evidence, and limitations

The source set includes NIST IR 8547 IPD, identified as an initial public draft published on November 12, 2024; the CISA, NSA, and NIST Joint Quantum-Readiness Fact Sheet, identified as final and published August 17, 2023; NIST CSWP 39 Update 1, identified as final with publication information dated December 19, 2025 and an update dated June 29, 2026; and the NCSC’s current “Timelines for Migration to Post-Quantum Cryptography,” published March 20, 2025. These statuses matter: the NIST IR passage is draft material and should not be treated as a complete implementation specification.2

The NCSC states that major cloud service and hyperscale providers have roadmaps for deploying PQC into their services. It also notes that standards work for important Internet protocols is underway in the IETF, with final standards described as likely around 2027, while other standards organizations may produce some standards by 2028. These are expectations and planning signals, not guarantees for a particular provider, product, protocol, region, or date. Customers must obtain current, service-specific commitments directly from providers and suppliers.1

The evidence does not provide a universal migration deadline, a complete cloud-provider feature matrix, algorithm-selection advice for every workload, or a quantitative performance benchmark. It also does not establish that every cloud service, client, certificate authority, hardware module, or protocol already supports PQC. A defensible program should preserve these uncertainties in its risk register and validate claims through provider documentation, contracts, testing, and operational evidence.21

How to measure readiness

Successful migration cannot be inferred from service availability alone. The NCSC recommends additional testing to verify that cryptography performs as expected, including checking that systems use standardized PQC cipher suites rather than falling back to traditional cryptography. It also recommends a rigorous assurance process and metrics that quantify how many software clients use PQC and identify those that do not.1

• Inventory coverage: percentage of in-scope applications, services, protocols, certificates, libraries, devices, and provider dependencies with an identified cryptographic use.
• Risk coverage: percentage of high-impact assets and long-confidentiality data with an assessed migration path or documented treatment.
• Provider readiness: percentage of critical cloud services with a documented provider roadmap, supported configuration, testing process, and contractual or operational owner.
• PQC adoption: percentage of clients, connections, certificates, signing operations, or other defined units using the approved PQC or transition mechanism.
• Fallback visibility: number and severity of connections or clients that negotiate traditional cryptography when PQC is intended, with remediation status.
• Exception health: number of unresolved exceptions, their business justification, compensating controls, owner, review date, and planned retirement condition.
• Assurance evidence: proportion of migration waves supported by repeatable test results covering interoperability, performance, failure handling, and actual negotiated behavior.

Metrics should support decisions, not create a misleading sense of precision. A high adoption percentage can conceal one critical legacy dependency, while a complete inventory can still lack a viable provider upgrade. Pair quantitative measures with risk-based review of the most sensitive data, trust anchors, signing paths, administrative access, and externally exposed services.1

Practical next steps for enterprise cloud teams

In the near term, appoint a program owner and establish a cross-functional project team. Begin cryptographic discovery before every provider feature is available, because the inventory and dependency map determine which contracts, application releases, certificates, protocols, and infrastructure changes will be needed. Ask each strategic cloud provider and software supplier for a roadmap that states when and how PQC will be delivered, which customer actions are required, and what costs or limitations are expected.3

Next, select representative workloads for controlled pilots. Include a public-facing service, an internal service-to-service path, an identity or certificate-dependent workflow, a signing or software-update path, and a workload with long-lived sensitive data. Test both supported and unsupported clients, record negotiation and fallback behavior, and confirm that monitoring can distinguish intended PQC use from traditional cryptography. Keep independent security review in scope where hybrid mechanisms or major cryptographic changes are introduced.21

Finally, make readiness part of procurement and architecture governance. Require new products and material cloud services to disclose cryptographic dependencies and transition support; require upgrade and testing commitments where appropriate; and review exceptions as managed risk rather than permanent exemptions. Coordinate PQC changes with ordinary infrastructure maintenance and modernization so that difficult replacements, including constrained or non-upgradeable devices and embedded components, are identified early.31

Conclusion

PQC for cloud providers is a multi-layer transition involving provider services, customer applications, identities, certificates, protocols, libraries, hardware, suppliers, and operational assurance. The practical starting point is discovery and prioritization, followed by provider engagement, crypto-agile design, carefully justified transition mechanisms, testing against fallback, and measurable deployment. Because standards, products, and service roadmaps continue to evolve, organizations should preserve uncertainty, validate provider claims, and use modernization work to reduce quantum risk without compromising today’s security or availability.1342