- AWS Cloud Security›
- Post-Quantum Cryptography›
- Migration to quantum-resistant cryptography
Migration to quantum-resistant cryptography
How can I migrate my AWS workloads to use PQC?
Amazon Web Services (AWS) is migrating to post-quantum cryptography (PQC), and helping our customers do the same under a shared responsibility model. You can read in depth about our research & development, industry engagement, and algorithmic advances on the AWS post-quantum cryptography page.
As AWS delivers PQC capabilities under our shared responsibility model, some PQC features will be transparently enabled for all customers while others will be options that customers can choose to implement to help meet their requirements. This page provides information on capabilities AWS has already delivered, and how you can use these capabilities.
Workloads that maximize reliance on AWS managed services generally incur the least effort for PQC migrations. You may explore migrating or modernizing your workloads to AWS, as part of your holistic PQC upgrade strategy.
Overview
Sufficiently large quantum computers of the future might compromise traditional asymmetric cryptography. Post-quantum 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. This is addressed by adding support for post-quantum key exchange (PQ key exchange) to TLS connections (PQ-TLS), either alongside traditional key exchange (hybrid PQ-TLS) or standalone. AWS uses the ML-KEM algorithm for this purpose.
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. This is addressed with post-quantum signatures and post-quantum roots of trust. AWS uses the ML-DSA algorithm for this purpose.
Post-quantum cryptography in AWS
Launched services, builder tools, and how to use them
Services whose endpoints support PQ-TLS
The following AWS services support PQ key exchange using ML-KEM in their public service endpoints:
- AWS Key Management Service (KMS): Documentation, AWS blog post
- AWS Certificate Manager (ACM): AWS blog post
- AWS Secrets Manager: Documentation, AWS blog post. Additionally, v2.0+ of the Secrets Manager Agent enables and prefers ML-KEM by default.
- AWS Payment Cryptography: Documentation, Launch announcement
- Amazon Simple Storage Service (S3): Documentation, Launch announcement
Client-Side Considerations
You are responsible for updating your client-side components to versions that support ML-KEM. The update process, which varies by language and platform for each AWS SDK, is described in online documentation. PQ-ready clients are backwards compatible, so you can begin client-side updates even if some services you use have not yet launched PQ support. Once a service launches PQ support, it will automatically enforce its use with any updated client.
Services which allow customers to select PQ-TLS policies
The following AWS services offer encryption in transit policies that support hybrid PQ-key exchange using ML-KEM. Customers are responsible for applying PQ-TLS policies to new and existing customer-owned, AWS-managed resources.
- Elastic Load Balancers: Application Load Balancer (ALB) Documentation, Network Load Balancer (NLB) Documentation, Joint launch announcement
- API Gateway: Documentation, AWS blog post
- CloudFront: Documentation, Launch announcement. For client-to-edge connections, PQC support is available on all existing security policies by default, requiring no re-configuration by customers.
- Transfer Family: Documentation, Launch announcement, AWS blog post
Updating the policy configuration for resources you create through these services is on your side of the shared responsibility model. You can make these updates using service APIs or the AWS console, as described in service documentation.
To keep your environment upgraded over time, you may also consider the following best practices:
- Explicitly specify desired TLS policy wherever your infrastructure-as-code creates or updates customer-configurable resources. Leaving policy choice default or blank may cause regressions to backwards-compatible policies that do not include support for TLS 1.3. Each service's documentation describes default and recommended policies.
- Consider the use of IAM resource control policies that only allow the use of TLS policies you have allowlisted for your organization. This will prevent regressions due to programmer errors when creating or updating resources.
Digital signatures and certificates using ML-DSA
For devices that require quantum-resistant roots of trust, AWS Private Certificate Authority (Private CA) supports ML-DSA for certificate authorities and certificate issuance (launch announcement).
A detailed discussion of considerations to upgrade your PKI infrastructure to post-quantum cryptography, and to use ML-DSA for quantum-resistant code signing using Private CA and AWS Key Management service, is provided in this AWS blog post.
You might also use certificates to authenticate into AWS environments using AWS IAM Roles Anywhere. IAM Roles Anywhere supports the use of ML-DSA PKIs as trust anchors. An ML-DSA certificate issued by Private CA can also be used with any standard-compliant mTLS client or IKEv2/IPsec peer.
Keys and Key-based operations in AWS services
Some AWS data protection services offer direct access to cryptographic key and key-based functions. Post-quantum cryptographic support available in these services includes:
- AWS Key Management Service (KMS) offers support for ML-DSA key pair generation and ML-DSA signatures using standard AWS SDKs or the encryption SDK (Launch announcement, AWS blog post, Documentation)
- AWS CloudHSM support for ML-DSA key pair generation and ML-DSA signatures is in preview.
FAQs
Post-quantum cryptography (PQC) refers to cryptographic algorithms that are designed to withstand attacks from both classical and quantum computers. While quantum computers powerful enough to break today's cryptographic algorithms don't exist yet, the threat against an adversary collecting data transmitted over public networks today and storing until such a quantum computer that can break the cryptographic controls means we must act now. In this scenario, adversaries can collect and store encrypted data today, waiting to decrypt it once quantum computers become capable - potentially exposing data that requires long-term confidentiality.
Traditional public key cryptography, which secures most of today's internet communications, could become vulnerable to quantum computing attacks. However, symmetric key algorithms (like those AWS uses for encryption at rest) with sufficient key lengths remain quantum resistant. This is why 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.
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).
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 service can minimize your PQ-related efforts under our shared responsibility model
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. 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. We shared a detailed analysis of performance for PQ confidentiality in our first launch blog for hybrid PQ-TLS.
We've continued to focus on optimizing our PQC implementation to minimize cost of data security improvements to 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.
Interested?
To learn more about post-quantum cryptography with AWS