Quantum computers are no longer just a research curiosity. The cryptography that protects almost everything we do online was never designed to survive them. That is the simple idea behind the AWS post-quantum cryptography migration plan, a phased roadmap for moving Amazon Web Services to quantum-safe algorithms. If you run anything on AWS, this plan affects you, even if you never open a crypto library yourself.
The pressure is real, even if the exact timing is not. Gartner expects that by 2029, advances in quantum computing will render most of the asymmetric cryptography in use today unsafe to rely on. You do not have to bet on a specific date to take this seriously, because the practical risk is already in play. An attacker can record your encrypted traffic now and decrypt it years later once a powerful enough machine exists. This is the harvest now, decrypt later (HNDL) problem, and it is the reason waiting is the most expensive option.
This guide walks through how AWS is migrating, why it sequenced the work the way it did, and, just as important, what your team needs to do on your side of the line.
What Quantum Actually Breaks, and What It Does Not
To follow the plan, you only need to grasp one core idea. Modern systems lean on two kinds of cryptography. Symmetric cryptography uses one shared secret key to encrypt and decrypt data. AES-256, the workhorse for data at rest, is symmetric. Asymmetric cryptography, also called public-key cryptography, uses a public and private key pair. RSA and elliptic curve cryptography (ECC) are common examples, and they power TLS handshakes, digital certificates, and code signing.
A large quantum computer, often called a cryptographically relevant quantum computer, threatens the asymmetric side. Algorithms like RSA and ECC could be broken, which would undermine how two parties agree on a secret and how they prove who they are. The good news is that strong symmetric encryption such as AES-256 is considered safe against quantum attacks. That single fact shapes the whole AWS plan. Because data at rest in AWS is already protected with 256-bit symmetric keys, there is no need to re-encrypt stored data or swap out those algorithms. The urgent work is in transit, where public-key cryptography negotiates the keys that protect your traffic.
The New Standards AWS is Building On
In August 2024, NIST finalized the first post-quantum standards, and the AWS plan is built directly on them. There are two jobs to cover, so keep them straight:
- FIPS 203 (ML-KEM) is a key encapsulation mechanism. Think of it as the modern, quantum-safe way for two sides to agree on a shared secret key. It started life as CRYSTALS-Kyber.
- FIPS 204 (ML-DSA) is a digital signature algorithm used to prove that software, firmware, a document, or a certificate is authentic. It began as CRYSTALS-Dilithium.
- FIPS 205 (SLH-DSA), formerly SPHINCS+, is a second, stateless hash-based signature scheme that offers a more conservative security foundation as a backup option.
In short, KEMs protect confidentiality (keeping data secret) and signatures protect authenticity (proving identity). The AWS migration tackles both, but not at the same pace, and the reason for that ordering is where the plan gets interesting.
Shared Responsibility Still Applies to PQC
AWS delivers post-quantum cryptography through its shared responsibility model, the same way it handles other security features. Some protections turn on transparently for everyone. Others are options you choose to enable. The split is simple to remember: AWS is responsible for the security of the cloud, and you are responsible for security in the cloud.
In practice, AWS upgrades its own endpoints, libraries, and services to support quantum-safe algorithms. Your side is making sure your clients, SDKs, and applications can actually use them. A server can offer a quantum-safe handshake all day long, but if your client is running an old SDK or is stuck on TLS 1.2, you never get the benefit. Keeping that picture in mind makes the four workstreams below much easier to read.
Inside the Plan: Four Workstreams, in Priority Order
AWS runs its migration as four simultaneous workstreams, ordered by quantum risk. The sequence is the most useful part of the plan to copy, because it reflects where the danger is highest and where the standards are ready. Here is the quick map before we go deeper.
| Workstream | What it protects | Core AWS building blocks | Maturity |
|---|---|---|---|
| 1 | Inventory, standards, and planning | AWS-LC, s2n-tls, internal crypto inventory | Ongoing |
| 2 | Confidentiality of data in transit | Hybrid ML-KEM TLS 1.3 on ELB, CloudFront, KMS, S3 | Broadly available |
| 3 | Long-lived roots of trust for signing | ML-DSA in AWS KMS, AWS Private CA | Available |
| 4 | Session authentication with certificates | Public and private CA certificate validation | Standards pending |
Workstream 1: Inventory, Standards, and Planning
Everything starts with knowing what you have. AWS looked across every place it uses cryptography and set the migration order, and it treats this as ongoing work because more standards are still coming for how PQC fits specific protocols. The headline decision was to prioritize encryption in transit over encryption at rest. Data at rest in AWS already uses 256-bit symmetric keys, which a quantum computer does not meaningfully threaten, so it needs no re-encryption.
The real exposure is public-key cryptography, which negotiates the shared secrets that protect data moving across untrusted networks. That single insight set the order of the next three workstreams: secure key negotiation with AWS endpoints first (Workstream 2), then long-term signing roots of trust (Workstream 3), then the short-lived keys behind certificate authentication (Workstream 4).
AWS contributes to the underlying standards through open-source projects like AWS-LC and s2n-tls. For your own roadmap, it points to public guidance such as the preliminary draft NIST SP 1800-38 practice guide and CISA quantum-readiness guidance. It flags two moves to make now. First, build the agility to push software updates quickly, since you will need it to pick up new post-quantum versions of the AWS CLI, SDKs, and any third-party libraries that talk to AWS. Second, adopt TLS 1.3 across the organization, because it is the only version that can carry PQC at all.
Workstream 2: Protecting Data in Transit with Hybrid TLS
This is the workstream most customers feel first, and the core idea is hybrid post-quantum key agreement. Rather than betting on one new algorithm, AWS combines a classic key exchange (Elliptic Curve Diffie-Hellman) with the post-quantum ML-KEM and mixes both results into the session keys. An attacker would have to break both pieces to read the traffic, so you keep all of today’s security while gaining protection against tomorrow’s threats. This hybrid approach is standardized in the IETF draft draft-ietf-tls-hybrid-design. AWS built this on ML-KEM inside AWS-LC, its FIPS 140-3 validated library, which feeds s2n-tls, the TLS engine behind its HTTPS endpoints.
The rollout follows the standards. The IETF is finalizing how TLS carries post-quantum key exchange, and as that lands, AWS aligns s2n-tls and deploys ML-KEM across its public HTTPS endpoints, which are most services you reach through the SDK or CLI. Endpoints that speak other protocols, such as SFTP, IPsec, or SSH, get ML-KEM later, as standards bodies publish guidance for each one. For the resources you own, this will allow you to use the same digital certificates that you’ve been using with these services and let them negotiate the server-side TLS session using ML-KEM on your behalf.
AWS service endpoints support hybrid ML-KEM TLS today, and for the resources you own, Elastic Load Balancing and Amazon CloudFront support it as well, with Amazon API Gateway and others to follow.
To keep all of these implementations interoperable, AWS is working with industry groups including the Linux Foundation’s Post-Quantum Cryptography Alliance, the NCCoE migration project, and the Rust TLS project. The shift is already visible in production: AWS Secrets Manager supports hybrid post-quantum TLS for opt-in clients, and AWS is phasing out the pre-standard CRYSTALS-Kyber in favor of standardized ML-KEM during 2026, with older clients falling back to ordinary TLS rather than breaking.
Workstream 3: Long-Lived Roots of Trust for Signing
Some keys have to stay trustworthy for a very long time. Manufacturers sign firmware, operating systems, and bundled apps with a public-key root of trust, and some of those devices, such as set-top boxes, industrial sensors, or satellites, run for 10 or more years and may never be patched. In many cases, the root of trust is burned into the hardware at manufacturing and can never be changed. If it relies on RSA or ECC, a future quantum computer could forge updates that look legitimate, with no way to fix it after the device ships.
To close this gap, AWS now supports ML-DSA, a signature algorithm believed to resist quantum attacks. You can generate and use ML-DSA keys created and used for signing inside FIPS 140-3 Level 3 validated hardware security modules. ML-DSA in AWS KMS has been generally available since June 2025 in three key sizes: ML-DSA-44, ML-DSA-65, and ML-DSA-87. Amazon relies on this same capability to protect its own roots of trust, and paired with AWS Private CA , it already enables post-quantum code signing. Because the standards and building blocks are ready, this is the workstream to act on now if you manufacture hardware or sign software.
Workstream 4: Quantum-Safe Authentication in Certificates
The final workstream protects authenticity rather than secrecy. TLS and SSH use digital signatures and certificates from a trusted certificate authority to prove that a server or client is who it claims to be. Swapping those signatures for PQC is the hardest step, because validating a publicly trusted certificate means a client has to check every signature in the certificate chain, and that depends on a large web of internet infrastructure all agreeing on the format and the rules.
Those rules are set by the CA/Browser Forum, whose members set policy through the Baseline Requirements (BR), which they must update to define how PQC certificates are issued and validated; Amazon Trust Services is a member helping drive that work and the interoperability testing behind it. A signature only needs to hold during the life of the session it protects. Private certificates are not strictly bound by those public rules, so customers who control the software on both ends have the freedom to implement both the client and server portions of a PQC authentication scheme themselves.
Now that ML-DSA is available for signing through AWS KMS, AWS Private CA issues ML-DSA certificates for customers ready to adopt it on their private networking channels. And the open-source AWS-LC and s2n-tls are available so you can build the PQC certificate validation functions into your own clients and servers if need be.
How does This Impact You?
On paper, the migration looks like AWS’s project. In practice, the shared responsibility model quietly hands a large part of the work to you, and the impact shows up in places that are easy to miss. Here is what actually changes on your side of the line.
The biggest operational shift is that post-quantum protection depends on both AWS enabling ML-KEM and your clients negotiating it successfully. AWS can switch ML-KEM on at its endpoints, but a handshake only becomes quantum-safe if your SDK, CLI, or TLS library advertises ML-KEM when it connects. That makes version hygiene the real lever you control. Teams that keep their AWS SDKs and TLS stacks current get post-quantum protection almost for free, while teams running older clients stay exposed even though the AWS side fully supports it.
There is also no error or warning when this happens, so the connection simply stays on classical encryption. It is worth checking from time to time that your connections are actually using ML-KEM, rather than assuming they are.
That silent behavior creates a trap for early adopters. If you opted into the pre-standard CRYSTALS-Kyber a year or two ago to get ahead, those connections will fall back to TLS using a classical key exchange once AWS removes Kyber in 2026, again with no warning. Being early is not the same as being finished. There is no automatic switch from Kyber to ML-KEM, so you have to make a deliberate move by upgrading your AWS SDK or TLS client to a current version that supports it, or you lose the protection you thought you already had.
AWS also measured the cost of the hybrid handshake so you can plan for it: it adds roughly 1,600 extra bytes and about 80 to 150 microseconds per connection. For almost every workload that is invisible, but for very high connection-rate or latency-sensitive systems, it is worth a quick benchmark before you enable it everywhere.
There is a second blind spot on the resources you own. For your own load balancers and edge, post-quantum TLS is a configuration choice, not an automatic upgrade. Amazon CloudFront enables it by default for client-to-edge connections, but your Application and Network Load Balancers only get it once you apply a post-quantum TLS security policy, and AWS is explicit that this step is on your side. End-to-end confidentiality means checking both hops, the connection from your client to AWS and the connection from your users to your workloads, rather than assuming one covers the other.
For some teams, the impact reaches past IT and into the product roadmap. If you ship firmware, devices, or signed software, a root of trust you embed today on RSA or ECC cannot be swapped after the product is in the field. That turns the decision to pilot ML-DSA in AWS KMS and AWS Private CA into a product and manufacturing decision, not just a security one, and the window to make it is now while those keys are still being designed.
Finally, the deadlines are now on the calendar. The U.S. CNSA 2.0 suite sets national-security timelines, and other regions have published their own, with Australia targeting completion by 2030 and Canada phasing through 2031 to 2035. Under CNSA 2.0, new National Security System acquisitions must support ML-KEM-1024 and ML-DSA-87 from January 2027, non-compliant equipment must be phased out by December 2030, and CNSA 2.0 becomes mandatory across all systems by December 2031.
If you operate across jurisdictions, you inherit the strictest clock. Underneath all of it, crypto-agility stops being a nice-to-have and becomes an architectural requirement, because this is not one switch. It is ML-KEM today, certificate and authentication changes later, and stronger parameters later still, and your systems need to absorb each of those by upgrading rather than re-architecting.
None of this is hard in isolation. The challenge is doing it consistently across a wide range of applications, clouds, and compliance regimes, which is exactly where Encryption Consulting can help.
How Encryption Consulting Can Help
If you are wondering where and how to begin your post-quantum journey, Encryption Consulting is here to support you. You can count on us as your expert PKI, HSMs, and compliance-mapped PQC partner, and we will guide you through every step with clarity, confidence, and real-world expertise.
PQC Assessment
We start by mapping your current cryptographic landscape. This involves discovering and inventorying all cryptographic assets like certificates, keys, and related dependencies. We then evaluate which systems are vulnerable to quantum threats and review the readiness of your PKI, HSMs, and applications. This leads to a detailed cryptographic inventory, quantum risk impact analysis, and a clear, prioritized action plan.
PQC Strategy & Roadmap
Next, we design a tailored migration strategy aligned with your business goals. This includes updating cryptographic policies in line with NIST and NSA guidelines, creating governance frameworks, and embedding crypto agility principles so your systems remain adaptable. This leads to a comprehensive PQC strategy, a crypto-agility framework, and a phased migration roadmap built around your priorities and timelines.
Vendor Evaluation & Proof of Concept
Selecting the right solutions is critical. We help you define RFP/RFI requirements, shortlist the most suitable vendors for PQC algorithms, key management, and PKI, and conduct proof-of-concept testing in your environment. This gives you a vendor comparison report and tailored recommendations to support informed decision-making.
PQC Implementation
With the plan in place, we assist in deploying post-quantum algorithms within your infrastructure: PKI, enterprise apps, or broader ecosystems. We also enable hybrid cryptography models, ensuring seamless integration across cloud, on-prem, and hybrid environments. This helps in validated interoperability, strong documentation, and hands-on training so your team can manage and maintain the system confidently.
Pilot Testing & Scaling
Before enterprise-wide deployment, we run controlled pilot tests to validate performance and resolve integration issues. Once optimized, we support a phased rollout to replace legacy algorithms, minimize disruption, and maintain compliance. This enables smooth, scalable deployment with ongoing monitoring and optimization to keep your systems secure and future safe.
Conclusion
The AWS post-quantum cryptography migration plan is valuable as a clear way to think about sequencing. Protect data in transit first, because the HNDL risk applies the moment data leaves your network. Secure long-lived signing roots next, because those keys cannot be changed once devices ship. Save certificate-based authentication for last, because it depends on industry-wide standards that are still being settled. Underneath all of it sits one principle: data at rest with strong symmetric encryption is fine, so put your energy where public-key cryptography is actually exposed.
The practical message is encouraging. Most of the early moves, building an inventory, adopting TLS 1.3, and keeping your tooling current, improve your security posture right now and make the eventual switch far smoother. The teams that start early will treat the quantum transition as routine maintenance rather than an emergency. If you want help turning this into a concrete, audit-ready PQC migration roadmap for your environment, Encryption Consulting can guide your quantum-safe architecture and crypto-agility journey from inventory to implementation.
