Migration to quantum-resistant cryptography

Post-quantum cryptography (PQC) refers to cryptographic algorithms that are designed to withstand attacks from both classical and quantum computers. Sufficiently large quantum computers of the future might compromise traditional asymmetric cryptography. PQC, also known as quantum-resistant cryptography, addresses this risk.

The top priority for PQC is addressing the "harvest now, decrypt later" (HNDL) risk where long-lived sensitive data in transit over public networks can be captured today and decrypted by future quantum computers. Another high priority is adding quantum-resistant roots of trust to long-lived devices shipping today, so they may continue to authenticate data and entities for their entire useful lifetime.

AWS is focusing our PQC efforts on protecting data in transit, particularly where customers communicate with AWS services over the internet. By implementing PQC now, we're helping ensure that your data remains secure not just today, but well into the future. This is particularly critical for industries like healthcare, financial services, and government sectors, where data often requires decades of protection.

For your own custom applications where you cannot delegate cryptography to AWS, we recommend focusing on your own cryptographic agility - the ability to easily update cryptographic algorithms and protocols. This includes maintaining current software versions, implementing automated update processes, and designing systems that can accommodate algorithm changes. If you're building new applications, consider using AWS managed services that handle cryptography on your behalf, as these services will automatically incorporate PQC updates as they become available.

If you're using custom TLS implementations or other cryptographic libraries, review your dependencies and prepare for updates. While AWS manages the server-side implementation of PQC for service endpoints, you'll need to ensure your client-side applications can support these newer cryptographic standards when they become available.

You might consider modernizing legacy applications. Maximizing the use of AWS managed services can minimize your PQ-related efforts under our shared responsibility model.

The regulatory landscape for post-quantum cryptography is broad and depends on your industry, jurisdiction, and the type of data you handle. Regulations and compliance requirements vary across businesses and countries, and are evolving as the quantum threat becomes better understood.

Guidelines for quantum-resistant asymmetric algorithms that should replace traditional asymmetric algorithms varies, with a detailed comparison (from 2025) across regulations at pqcc.org. Guidelines to enable quantum-resistant cryptography, and to deprecate use of traditional asymmetric cryptography, also vary by regulation and by sensitivity of data handled in a product.

Below is a sample of guidance from major regulatory bodies. We recommend consulting your own regulators for requirements specific to your organization. 

United States – NIST published FIPS 203, 204, and 205 in August 2024, standardizing the first post-quantum cryptographic algorithms (ML-KEM, ML-DSA, and SLH-DSA). NIST's IR 8547 (IPD) provides a transition roadmap draft, targeting deprecation of traditional asymmetric algorithms by 2030 and disallowing them after 2035.

European Union – The European Commission published a Recommendation on a Coordinated Implementation Roadmap for the transition to Post-Quantum Cryptography, encouraging EU Member States to develop comprehensive PQC adoption strategies with clear milestones and timelines for public administration systems and critical infrastructure. It outlines that high risk systems (those where data needs to remain private for 10 years), must be migrated by 2030. Everything else should be migrated by 2035.

United Kingdom – The NCSC published a whitepaper on quantum-safe cryptography outlining a three-phase migration: complete cryptographic discovery by 2028, transition of high-priority systems by 2031, and migration complete by 2035.

Germany – The BSI's Technical Guideline TR-02102 recommends hybrid post-quantum cryptography for all deployments, combining traditional and quantum-resistant algorithms during the transition period. Timelines align with the EU guidelines, with high risk systems being migrated by 2030 and no traditional cryptography in use after 2031.

France – ANSSI published a position paper on post-quantum cryptography recommending hybrid PQC approaches. Guidance is that products handling sensitive data should use quantum-resistant algorithms by 2027, and all products on the market should use quantum-resistant algorithms starting 2030.

Australia – The ASD published guidance on Planning for Post-Quantum Cryptography, recommends that organizations complete migration to quantum-resistant cryptography, with no ongoing use of traditional asymmetric cryptography, by 2030. The ASD has higher thresholds compared to other jurisdictions, recommending stronger parameters (such as ML-KEM 1024) after 2030.

Canada – The Canadian Centre for Cyber Security published ITSM.40.001: Roadmap for the migration to post-quantum cryptography for the Government of Canada, outlining a three-phase approach (preparation, identification, transition) for federal departments and agencies. Departments must develop an initial PQC migration plan by April 2026 and report progress annually, with high-priority systems, particularly those susceptible to harvest-now-decrypt-later threats over public networks, migrated by end of 2031, and all remaining systems migrated by end of 2035.

United Arab Emirates – The UAE Cyber Security Council published the National Encryption Policy v1.0, which includes a dedicated section on post-quantum cryptography requiring government entities to inventory all systems using public key cryptography, create transition plans, test PQC standards in lab environments before production deployment, and establish acquisition policies for quantum-resistant products.

Financial Sector – The G7 Cyber Expert Group (CEG) released a coordinated roadmap for the transition to post-quantum cryptography in the financial sector, outlining a phased migration approach and encouraging critical financial systems to complete the transition by 2034. Additionally, the Accredited Standards Committee X9 (ASC X9), an ANSI-accredited body that develops standards for the financial services industry, published a Post Quantum Cryptography Financial Readiness Needs Assessment providing guidance on cryptographic asset inventory, risk-based prioritization, PQC migration planning, and building crypto-agility into financial infrastructure.

Telecommunications - The GSMA Post-Quantum Telco Network Taskforce has published impact assessments, quantum risk management guidelines, and PQC guidelines for telecom use cases. While these do not set binding deadlines, they provide a risk assessment methodology and best-practice framework for operators, vendors, and integrators to plan PQC adoption across 5G and future 6G networks.

You can learn about our approach to shared responsibility for PQC in AWS’s migration plan. You can explore aspects of risk and prioritization, with a detailed discussion of our PQC shared responsibility model, in our PQC demystified video. For architects or platform owners seeking to ensure initial and ongoing PQ readiness of your workloads, consult our crypto-agility guide. For additional customized guidance, you can reach out to your AWS account team for a PQC consultation. 

The most important step you can take today is ensuring your applications use TLS 1.3. This version of TLS is required for PQC support and offers significant security improvements over older versions. For other secure communication protocols supported by AWS services we are working to bring standardized solutions that interoperate with customer 3rd party options. If you're using AWS SDKs, update to the latest versions - our newest SDKs already include PQC support, either enabled by default or as an opt-in feature learn more. If your systems include op.

There are multiple ways to verify your workloads are using post-quantum cryptography to secure data in transit. When your applications communicate with AWS services, you can monitor TLS negotiation details such as version and cipher suite through CloudTrail or service-specific logs. These logs will, over time, additionally include insights on the key exchange used when establishing the TLS session. For example, CloudTrail events for AWS Key Management Service and AWS Payment Cryptography now include keyExchange as a field in tlsDetails. Elastic Load Balancers include keyExchange as a field in connection or access logs. Coverage for keyExchange within tlsDetails will expand over time.  

On the client-side, you can verify the details of TLS connections using a utility like WireShark. You can also use developer tools built-in to all major web browsers to examine the key exchange mechanism used.

No. Our implementation of post-quantum cryptographic algorithms has been optimized to minimize performance impact on your applications. Through extensive testing and optimization of our hybrid approach that combines ML-KEM with traditional cryptography, we've observed minimal latency impact in production environments. For example, large services like CloudFront, S3, and KMS have seen no significant impact to throughput or latency - to customers, or to the service infrastructure itself.

While the computational requirements for hybrid PQ-TLS are generally comparable than classical cryptography alone, we've focused on optimizing the implementation to ensure that security improvements don't come at at a minimal cost of application performance. Our optimized ML-KEM implementation delivers strong performance across different compute architectures - achieving up to 2.7x performance improvements on Graviton cores and 1.8x on x86 instances compared to earlier implementations.

That said, as with any security enhancement, we recommend testing in your specific environment, particularly if you're using custom clients or have specific performance requirements.