Post-Quantum Cryptography Standardization Timeline and Migration on AWS - From Algorithm Selection to Service Support
First Published:
Last Updated:
Two questions come up constantly when an organization starts planning a cryptographic migration, and they are almost never answered in the same place. The first is "what has actually been standardized, and when?" - a question whose primary sources are excellent but scattered across NIST round-specific subpages, individual FIPS publication records, and IETF datatracker entries. The second is "which of the services I already run supports any of this today?" - a question whose answer changes several times a year. This article is my attempt to answer both in a single reference, with every row linked to a primary source.
The timeline distinguishes explicitly between three things that are easy to conflate: a selection (NIST announcing that an algorithm will be standardized), a published standard (the FIPS, SP, or RFC actually being issued), and a draft (a document released for public comment and still subject to change). Conflating them is the most common error in secondary write-ups of this subject, and it matters, because "selected" and "you can build a compliance argument on it" are years apart.
Two things this article deliberately does not do. It does not predict when a cryptographically relevant quantum computer will exist, and it does not offer an independent assessment of how hard any algorithm is to break. Where the "harvest now, decrypt later" risk is discussed, it is presented as the framing that public bodies and AWS have themselves published, with attribution. Where an algorithm was broken during the competition, only the fact of the published result is recorded, linked to the original paper - the point is that a public competition worked as designed, not that anyone made a mistake.
Definitions of the underlying primitives - KEM, KDF, forward secrecy, the individual algorithm families - are deliberately delegated to my cryptography glossary rather than repeated here.
Companion articles on hidekazu-konishi.com:
- Cryptography Glossary for Engineers
- AWS History and Timeline regarding AWS KMS - Overview, Functions, Features, Summary of Updates, and Introduction to KMS
- HTTP Security Headers Complete Reference
- AWS Zero Trust Network Architecture Guide
- TLS Certificate Ecosystem History and Timeline
- Major Security Vulnerabilities History and Timeline
- AWS KMS Envelope Encryption and Data Key Caching Patterns
Background and Method of Creating the Post-Quantum Cryptography Standardization Timeline
The reason for building this timeline is that post-quantum cryptography has an unusually long and unusually well-documented public record, and yet that record is almost impossible to hold in your head. The NIST process has run for a decade across four evaluation rounds plus a separate signature track; the algorithms changed names when they were standardized; the protocol work that makes them usable happened at the IETF on a different clock; and cloud providers began shipping pre-standard versions years before the standards existed and then replaced them. An engineer asked to produce a migration plan has to reconcile all of that.What this timeline is built from:
- The NIST Post-Quantum Cryptography project pages and news archive - the authoritative record of calls, round announcements, and selections. Post-Quantum Cryptography | CSRC
- NIST publication records - the FIPS, SP, and internal report (IR) pages, which carry the exact publication and revision dates in their document history. Post-Quantum Cryptography Standardization
- The IETF datatracker - for the exact publication date and status of each relevant RFC, and for the current state of work still in progress.
- Original research papers - the IACR Cryptology ePrint Archive, for the cryptanalytic results published during the competition.
- Official guidance from public bodies - included only where the body itself published a dated document, named explicitly and described neutrally.
- AWS official sources - the AWS Security Blog, AWS What's New announcements, and AWS service documentation, for everything in the AWS section. Post-Quantum Cryptography - AWS Cloud Security
What is included: official process milestones (calls, round selections, status reports), the actual publication of standards and RFCs, drafts released for public comment, published cryptanalytic results affecting candidates in the process, and dated migration-policy documents from public bodies.
What is excluded: any prediction of when quantum computers will threaten deployed cryptography; any independent assessment of algorithm security; the mathematical construction of the algorithms; attack techniques or reproduction steps; pricing; and product comparisons between vendors.
On dates: every row uses strict
YYYY-MM-DD format. Where a milestone was only ever published at month precision - the call for additional signature schemes in September 2022 is the main example - it is not given its own row; it is folded into the supporting text of a row whose date is precisely documented.On algorithm names: the algorithms were submitted under one name and standardized under another. Both are given, because both are still in circulation - in code, in configuration, and in older documentation. A dedicated table of name pairs appears in the Current Overview section.
On confirmation dates: the standardization side of this article was confirmed against primary sources on 2026-07-31. The AWS side was confirmed against AWS official sources on 2026-07-31. The AWS side in particular moves quickly, and any statement about service support should be re-checked against the linked official page before it is used in a design decision.
Note: the content posted is limited to the milestones necessary to understand the standardization process and its deployment status. In other words, please note that the items on this timeline are not every event in the process, but representative milestones that I have picked out.
Post-Quantum Cryptography Standardization Timeline (Updates from February 3, 2016)
2016 | 2017 | 2018 | 2019 | 2020 | 2022 | 2023 | 2024 | 2025 | 2026
* You can sort the table by clicking on the column name.| Date | Summary |
|---|---|
| 2016-02-03 | [Draft] NIST releases a draft of NISTIR 8105 for public comment. The draft report set out NIST's initial view of the threat that quantum computing poses to deployed public-key cryptography and its intention to begin a standardization effort. References: NIST Announce the Release of DRAFT NISTIR 8105. |
| 2016-04-28 | [Report] NIST publishes NISTIR 8105, Report on Post-Quantum Cryptography. The final report identified which deployed algorithm families would be affected and described NIST's initial plan to move forward, making it the formal starting point of the process. References: NISTIR 8105, Report on Post-Quantum Cryptography. |
| 2016-08-02 | [Process] NIST posts proposed submission requirements and evaluation criteria for public review. This established the ground rules - security categories, performance expectations, and intellectual property terms - before the call itself was issued. References: Post-Quantum Cryptography: Proposed Requirements and Evaluation Criteria. |
| 2016-12-20 | [Call] NIST publishes the call for proposals in the Federal Register. The notice requested nominations for public-key post-quantum cryptographic algorithms covering digital signatures, public-key encryption, and key establishment, and the accompanying Call for Proposals document set the submission deadline. References: Announcing Request for Nominations for Public-Key Post-Quantum Cryptographic Algorithms. |
| 2017-11-30 | [Process] The submission deadline passes with 82 candidate algorithms submitted. NIST subsequently reviewed each submission against the minimum acceptance criteria and the completeness requirements. References: Post-Quantum Cryptography Standardization: Call for Proposals. |
| 2017-12-20 | [Selection] NIST accepts 69 submissions as First-Round Candidates. Of the 82 algorithms submitted in November 2017, 69 met both the minimum acceptance criteria and the submission requirements, formally beginning the first round of evaluation. References: NISTIR 8240, Status Report on the First Round of the NIST Post-Quantum Cryptography Standardization Process. |
| 2018-05-31 | [Standard published] RFC 8391 specifies XMSS, a stateful hash-based signature scheme. Published on the IRTF stream as Informational, XMSS is one of the two stateful hash-based schemes that were available for long-lived signing use before the lattice-based signature standards existed. References: RFC 8391: XMSS: eXtended Merkle Signature Scheme. |
| 2019-01-30 | [Selection] NIST announces 26 second-round candidates. The set comprised 17 candidates for public-key encryption and key establishment and 9 for digital signatures. References: PQC Standardization Process: Second Round Candidate Announcement. |
| 2019-01-31 | [Report] NIST publishes NISTIR 8240, the first-round status report. The report documents the evaluation criteria and the reasoning behind the second-round selection. References: NIST Publishes NISTIR 8240: PQC Round 1 Status Report. |
| 2019-04-29 | [Standard published] RFC 8554 specifies Leighton-Micali hash-based signatures (LMS). Like XMSS, LMS is stateful, and its state-management requirement is the practical constraint that shapes where it can be used. References: RFC 8554: Leighton-Micali Hash-Based Signatures. |
| 2020-06-30 | [Standard published] RFC 8784 defines a way to mix preshared keys into IKEv2 for post-quantum security. This gave IPsec deployments an interim option that did not depend on any new public-key algorithm being standardized first. References: RFC 8784: Mixing Preshared Keys in the Internet Key Exchange Protocol Version 2 (IKEv2) for Post-quantum Security. |
| 2020-07-22 | [Selection] NIST announces seven third-round finalists and eight alternate candidates. The finalists were Classic McEliece, CRYSTALS-KYBER, NTRU, and SABER for encryption and key establishment, and CRYSTALS-DILITHIUM, FALCON, and Rainbow for signatures; the alternates were BIKE, FrodoKEM, HQC, NTRU Prime, SIKE, GeMSS, Picnic, and SPHINCS+. The rationale is documented in NISTIR 8309. References: PQC Third Round Candidate Announcement, NISTIR 8309, Status Report on the Second Round. |
| 2022-02-25 | [Cryptanalysis] A key-recovery result against Rainbow is received by the IACR Cryptology ePrint Archive. Rainbow was a third-round signature finalist at the time; the paper is recorded here as a fact of the public evaluation process, which is precisely what a multi-year open competition is designed to surface. References: Breaking Rainbow Takes a Weekend on a Laptop. |
| 2022-05-04 | [Policy] The United States issues National Security Memorandum 10. NSM-10 establishes 2035 as the primary target for completing the migration to post-quantum cryptography across federal systems, and NIST IR 8547 later cites it directly as the basis for its own transition timing. References: National Security Memorandum on Promoting United States Leadership in Quantum Computing While Mitigating Risks to Vulnerable Cryptographic Systems. |
| 2022-07-05 | [Selection] NIST announces the first four algorithms to be standardized and four fourth-round candidates. CRYSTALS-KYBER was selected for key establishment and CRYSTALS-Dilithium, FALCON, and SPHINCS+ for digital signatures; BIKE, Classic McEliece, HQC, and SIKE advanced to a fourth round for key establishment. The reasoning is documented in NIST IR 8413, which received an erratum update on 2022-09-26. References: Announcing PQC Candidates to be Standardized, Plus Fourth Round Candidates, NIST IR 8413, Status Report on the Third Round. |
| 2022-07-30 | [Cryptanalysis] An efficient key-recovery attack on SIDH is received by the IACR Cryptology ePrint Archive. SIKE, which was built on SIDH, was a fourth-round key-establishment candidate at the time. NIST IR 8545 later recorded that HQC was the only fourth-round key-establishment algorithm that would be standardized. References: An efficient key recovery attack on SIDH. |
| 2023-05-22 | [Standard published] RFC 9370 extends IKEv2 to negotiate multiple key exchanges. This is the mechanism that lets an IPsec association combine a classical key exchange with a post-quantum one, rather than replacing the classical exchange outright. References: RFC 9370: Multiple Key Exchanges in the Internet Key Exchange Protocol Version 2 (IKEv2). |
| 2023-06-01 | [Process] The call for additional digital signature schemes closes with 40 algorithms entering the first round. NIST had issued the call in September 2022 to diversify its signature portfolio, expressing particular interest in general-purpose schemes not based on structured lattices and in schemes with short signatures and fast verification. References: Post-Quantum Cryptography: Additional Digital Signature Schemes. |
| 2023-08-24 | [Draft] NIST releases three draft FIPS for public comment. The drafts covered the key-encapsulation mechanism and the two signature schemes derived from CRYSTALS-KYBER, CRYSTALS-Dilithium, and SPHINCS+. References: Three Draft FIPS for Post-Quantum Cryptography. |
| 2024-04-11 | [Policy] The European Commission adopts Recommendation (EU) 2024/1101 on a coordinated implementation roadmap for the transition to post-quantum cryptography. The recommendation asks Member States to develop PQC transition strategies with defined milestones. References: Commission Recommendation (EU) 2024/1101 on a Coordinated Implementation Roadmap for the transition to Post-Quantum Cryptography. |
| 2024-08-13 | [Standard published] NIST publishes FIPS 203, FIPS 204, and FIPS 205. FIPS 203 specifies ML-KEM (derived from CRYSTALS-KYBER) with the parameter sets ML-KEM-512, ML-KEM-768, and ML-KEM-1024; FIPS 204 specifies ML-DSA (derived from CRYSTALS-Dilithium); FIPS 205 specifies SLH-DSA (derived from SPHINCS+). This is the point at which post-quantum algorithms became citable standards rather than selections. References: Post-Quantum Cryptography FIPS Approved, FIPS 203, Module-Lattice-Based Key-Encapsulation Mechanism Standard, FIPS 204, Module-Lattice-Based Digital Signature Standard, FIPS 205, Stateless Hash-Based Digital Signature Standard. |
| 2024-10-24 | [Selection] NIST publishes NIST IR 8528 and announces 14 second-round candidates in the additional signature track. The candidates were CROSS, FAEST, HAWK, LESS, MAYO, Mirath, MQOM, PERK, QR-UOV, RYDE, SDitH, SNOVA, SQIsign, and UOV. References: NIST IR 8528, Status Report on the First Round of the Additional Digital Signature Schemes. |
| 2024-11-12 | [Draft] NIST releases the initial public draft of NIST IR 8547, Transition to Post-Quantum Cryptography Standards. The draft describes NIST's expected approach to moving off quantum-vulnerable algorithms. Its transition tables state that ECDSA and RSA at 112 bits of security strength are to be deprecated after 2030 and disallowed after 2035, that EdDSA at 128 bits is to be disallowed after 2035, and that finite-field and elliptic-curve Diffie-Hellman at 112 bits follow the same deprecation and disallowance dates. References: Draft NIST IR 8547 is Available for Comment, NIST IR 8547 (Initial Public Draft), Transition to Post-Quantum Cryptography Standards. |
| 2025-01-07 | [Draft] NIST releases a draft of SP 800-227 for public comment. The document provides recommendations for the use of key-encapsulation mechanisms, which is the guidance layer that sits above FIPS 203 itself. References: Draft SP 800-227 is Available for Comment. |
| 2025-03-11 | [Selection] NIST selects HQC for standardization from the fourth round. NIST IR 8545 records that HQC was the only fourth-round key-establishment algorithm selected. NIST stated that it would draft a standard for HQC and release it for public comment, with the final version published approximately two years later. References: HQC Announced as a 4th Round Selection, NIST IR 8545, Status Report on the Fourth Round. |
| 2025-06-13 | [Standard published] RFC 9794 establishes common terminology for post-quantum and traditional hybrid schemes. Having agreed vocabulary matters more than it sounds: "hybrid" had been used for several distinct constructions across different working groups. References: RFC 9794: Terminology for Post-Quantum Traditional Hybrid Schemes. |
| 2025-06-13 | [Standard published] RFC 9763 defines related certificates for use in multiple authentications within a protocol. This is one of the PKI-side mechanisms proposed for carrying a traditional and a post-quantum credential through the same authentication. References: RFC 9763: Related Certificates for Use in Multiple Authentications within a Protocol. |
| 2025-09-18 | [Standard published] NIST finalizes SP 800-227, Recommendations for Key-Encapsulation Mechanisms. The document history records the draft on 2025-01-07 and the final version on 2025-09-18. References: SP 800-227, Recommendations for Key-Encapsulation Mechanisms. |
| 2025-10-30 | [Standard published] RFC 9881 defines the X.509 algorithm identifiers for ML-DSA. Until certificate encodings are specified, a signature algorithm cannot appear in a certificate chain at all, which makes this the gating item for post-quantum PKI. References: RFC 9881: Internet X.509 Public Key Infrastructure - Algorithm Identifiers for ML-DSA. |
| 2026-03-06 | [Standard published] RFC 9935 defines the X.509 algorithm identifiers for ML-KEM. This covers the use of ML-KEM public keys in X.509 certificates and revocation lists. References: RFC 9935: Internet X.509 Public Key Infrastructure - Algorithm Identifiers for ML-KEM. |
| 2026-03-06 | [Standard published] RFC 9936 specifies the use of ML-KEM in the Cryptographic Message Syntax. CMS underpins S/MIME and a range of signed and enveloped-data formats. References: RFC 9936: Use of ML-KEM in the Cryptographic Message Syntax (CMS). |
| 2026-05-14 | [Selection] NIST announces nine third-round candidates in the additional signature track and publishes NIST IR 8610. The candidates are FAEST, HAWK, MAYO, MQOM, QR-UOV, SDitH, SNOVA, SQIsign, and UOV; NIST's page subsequently records that the submission team has withdrawn HAWK from the process. References: NIST IR 8610, Status Report on the Second Round of the Additional Digital Signature Schemes, Round 3 Additional Signatures. |
| 2026-06-18 | [Standard published] RFC 9958, Post-Quantum Cryptography for Engineers, is published. The document is an Informational engineering orientation to the algorithms and their deployment considerations rather than a protocol specification. References: RFC 9958: Post-Quantum Cryptography for Engineers. |
| 2026-06-30 | [Standard published] RFC 9980 specifies post-quantum cryptography in OpenPGP. References: RFC 9980: Post-Quantum Cryptography in OpenPGP. |
| 2026-07-15 | [Standard published] RFC 9954 specifies hybrid key exchange in TLS 1.3. This is the construction that combines a traditional key exchange with a post-quantum one so that the session remains confidential unless both are broken. It began life as draft-ietf-tls-hybrid-design, and cloud providers had been shipping implementations of its earlier drafts for years before publication. References: RFC 9954: Hybrid Key Exchange in TLS 1.3. |
This timeline will be updated as post-quantum cryptography standardization continues to evolve.
Post-Quantum Cryptography on AWS
This section covers the second half of the question: given the standards above, what is actually available on AWS, and what does a migration look like in practice. Everything here was confirmed against AWS official sources on 2026-07-31.Two structural points are worth stating before the tables. First, AWS's published migration plan divides the work into workstreams, and the one that reaches customers first is the one covering TLS to AWS service endpoints - the plan states that AWS implemented ML-KEM in AWS-LC, its FIPS 140-3 validated cryptographic library, which is used by s2n-tls, the TLS implementation behind AWS service endpoints. Second, AWS frames all of this under a shared responsibility model: some capabilities are enabled transparently, others require you to select a TLS policy or update a client, and the distinction determines how much work lands on your side.
AWS Post-Quantum Cryptography Milestones
AWS began shipping hybrid post-quantum key exchange years before the standards existed, which means the AWS history includes a generation of pre-standard algorithms that were subsequently replaced. That replacement is itself the most useful part of the story for anyone designing for crypto agility.* You can sort the table by clicking on the column name.
| Date | Summary |
|---|---|
| 2019-11-04 | AWS KMS adds hybrid post-quantum TLS using s2n. The initial implementation used first-round versions of BIKE and SIKE, combined with a classical key exchange so that the connection was never weaker than the classical baseline alone. References: Post-quantum TLS now supported in AWS KMS. |
| 2020-11-16 | AWS KMS adds second-round hybrid post-quantum key exchange algorithms. The second-round versions of Kyber, BIKE, and SIKE were added at a higher preference than the first-round versions, which were retained for compatibility. References: Round 2 post-quantum TLS is now supported in AWS KMS. |
| 2022-03-16 | AWS KMS and ACM add third-round hybrid post-quantum TLS ciphers. References: AWS KMS and ACM now support the latest hybrid post-quantum TLS ciphers. |
| 2022-07-25 | Post-quantum key exchange becomes available for QUIC through the s2n-quic library. References: Enable post-quantum key exchange in QUIC with the s2n-quic library. |
| 2022-08-02 | AWS Secrets Manager connections add hybrid post-quantum TLS with Kyber. References: AWS Secrets Manager connections now support the latest hybrid post-quantum TLS with Kyber. |
| 2023-06-12 | AWS Transfer Family adds quantum-safe key exchange for SFTP. This extended hybrid key exchange beyond TLS to the SSH-based file transfer path. References: AWS Transfer Family announces quantum-safe key exchange for SFTP. |
| 2024-10-03 | AWS publishes guidance on compliance and verification during the migration. The guidance covers how a server prioritizes post-quantum hybrid key exchange for clients that offer it while remaining backward compatible for clients that do not. References: Customer compliance and security during the post-quantum cryptographic migration. |
| 2024-12-05 | AWS publishes its post-quantum cryptography migration plan. The plan sets out the workstreams AWS is executing and states the intention to deploy ML-KEM-based hybrid key agreement across AWS public HTTPS endpoints over the following years, and to enable services that terminate TLS on customers' behalf - Elastic Load Balancing, Amazon API Gateway, and Amazon CloudFront - to negotiate ML-KEM server-side. References: AWS post-quantum cryptography migration plan. |
| 2024-12-10 | AWS-LC FIPS 3.0 includes ML-KEM in its FIPS 140-3 validation. References: AWS-LC FIPS 3.0: First cryptographic library to include ML-KEM in FIPS 140-3 validation. |
| 2025-04-07 | AWS KMS, ACM, and AWS Secrets Manager add ML-KEM-based hybrid post-quantum TLS. This replaced the earlier pre-standard Kyber support with the standardized algorithm from FIPS 203, and is the clearest single illustration of why crypto agility is the design goal rather than any particular algorithm. References: ML-KEM post-quantum TLS now supported in AWS KMS, ACM, and Secrets Manager. |
| 2025-05-21 | AWS Transfer Family adds ML-KEM key exchange for SFTP. AWS's documentation notes that its SFTP and SSH implementation follows a draft submitted to the IETF and that the key exchange method names may change as that draft advances. References: AWS Transfer Family announces ML-KEM quantum-resistant key exchange for SFTP. |
| 2025-06-13 | AWS KMS adds ML-DSA post-quantum digital signature keys. Three key specs - ML_DSA_44, ML_DSA_65, and ML_DSA_87 - work with the ML_DSA_SHAKE_256 signing algorithm through the existing CreateKey and Sign APIs, so existing IAM policies, auditing, and tagging workflows continue to apply. References: AWS KMS now supports ML-DSA post-quantum digital signatures, How to create post-quantum signatures using AWS KMS and ML-DSA. |
| 2025-09-05 | Amazon CloudFront adds hybrid post-quantum key establishment across its existing TLS security policies. For client-to-edge connections this is enabled on existing security policies without reconfiguration. References: Amazon CloudFront announces post-quantum support and a TLS 1.3 only security policy. |
| 2025-11-10 | AWS Private CA adds support for issuing ML-DSA certificate authorities and certificates. This covers CA creation, certificate issuance, revocation lists, and OCSP responders. References: AWS Private CA now supports post-quantum digital certificates. |
| 2025-11-19 | Amazon S3 adds post-quantum TLS key exchange on its endpoints, and Amazon API Gateway adds TLS security policies that include a post-quantum option. The S3 support covers regional, S3 Tables, and S3 Express One Zone endpoints. References: Amazon S3 now supports post-quantum TLS key exchange on S3 endpoints, Amazon API Gateway now supports additional TLS security policies for REST APIs. |
| 2025-11-21 | Application Load Balancers and Network Load Balancers add post-quantum TLS security policies, and AWS Payment Cryptography adds hybrid post-quantum TLS. The load balancer policies require you to select a PQ-TLS policy on the listener; usage can be observed through ALB connection logs and NLB access logs. References: AWS Application and Network Load Balancers Now Support Post-Quantum Key Exchange for TLS, AWS Payments Cryptography announces support for post-quantum cryptography to secure data in transit. |
| 2026-03-09 | AWS IAM Roles Anywhere adds support for ML-DSA. ML-DSA-signed CA certificates can be used as trust anchors, and end-entity certificates can be bound to ML-DSA keys. References: IAM Roles Anywhere now supports post-quantum digital certificates. |
| 2026-04-14 | AWS Secrets Manager enables ML-KEM by default in its client components. Secrets Manager Agent 2.0.0 and later, the AWS Lambda extension version 19 and later, and the AWS Secrets and Configuration Provider 2.0.0 and later enable and prefer hybrid post-quantum key exchange without code changes. References: AWS Secrets Manager clients now support hybrid post-quantum TLS to protect secrets from quantum risks. |
| 2026-05-14 | AWS publishes guidance on automating post-quantum readiness checks using AWS Config. References: Automating post-quantum cryptography readiness using AWS Config. |
| 2026-07-08 | AWS publishes guidance on post-quantum mandates and migrations for security leadership. References: The CISO's guide to post-quantum mandates and migrations. |
Service Support Status as of July 31, 2026
The table below follows the structure AWS itself uses on its migration page: resources where you choose the TLS policy, service endpoints where AWS operates the server side, and services that expose post-quantum signing or certificate issuance directly. Status is as of the confirmation date and applies to what AWS has publicly announced; it is not a claim that any service lacks support merely because it is absent from the table.* You can sort the table by clicking on the column name.
| Service | Post-quantum capability | Status as of 2026-07-31 | Basis |
|---|---|---|---|
| Elastic Load Balancing (ALB, NLB) | Hybrid PQ key exchange with ML-KEM through TLS security policies | Available. You select a PQ-TLS policy on the listener. ALB documentation lists SecP256r1MLKEM768, SecP384r1MLKEM1024, and X25519MLKEM768 as the supported hybrid groups, and gives ELBSecurityPolicy-TLS13-1-2-Res-PQ-2025-09 as the console default for new HTTPS listeners | Security policies for your Application Load Balancer; launch announcement (2025-11-21) |
| Amazon API Gateway | TLS security policies that include a post-quantum option for REST APIs and custom domain names | Available in the Regions listed in the announcement | launch announcement (2025-11-19) |
| Amazon CloudFront | Hybrid PQ key establishment for viewer connections | Available on all existing security policies by default, requiring no reconfiguration | launch announcement (2025-09-05); AWS PQC migration page |
| AWS Transfer Family | Hybrid PQ key exchange with ML-KEM for SFTP | Available through post-quantum security policies. AWS notes the method names follow an IETF draft and may change | Using hybrid post-quantum key exchange with AWS Transfer Family; launch announcement (2025-05-21) |
| AWS KMS | PQ key exchange with ML-KEM on the service endpoint | Available. Verifiable through the keyExchange field in the tlsDetails section of the CloudTrail record | Using hybrid post-quantum TLS with AWS KMS; launch blog (2025-04-07) |
| AWS Certificate Manager | PQ key exchange with ML-KEM on the service endpoint | Available | launch blog (2025-04-07) |
| AWS Secrets Manager | PQ key exchange with ML-KEM on the service endpoint | Available. Secrets Manager Agent 2.0.0 and later, the Lambda extension version 19 and later, and the AWS Secrets and Configuration Provider 2.0.0 and later enable and prefer ML-KEM by default. Documentation states PQ-TLS is supported in all Regions except the China Regions | Post-quantum TLS in AWS Secrets Manager; announcement (2026-04-14) |
| AWS Payment Cryptography | PQ key exchange with ML-KEM on the service endpoint | Available | Using hybrid post-quantum TLS; launch announcement (2025-11-21) |
| Amazon S3 | PQ-TLS key exchange with ML-KEM on regional, S3 Tables, and S3 Express One Zone endpoints | Available | launch announcement (2025-11-19) |
| AWS Private CA | ML-DSA certificate authorities and certificate issuance, including CRLs and OCSP | Available | launch announcement (2025-11-10) |
| AWS KMS | ML-DSA key pair generation and signing (ML_DSA_44, ML_DSA_65, ML_DSA_87 with ML_DSA_SHAKE_256) | Available. Keys are generated and used inside FIPS 140-3 Security Level 3 validated HSMs | ML-DSA keys in AWS KMS; launch announcement (2025-06-13) |
| AWS IAM Roles Anywhere | ML-DSA PKIs as trust anchors, and end-entity certificates bound to ML-DSA keys | Available | launch announcement (2026-03-09) |
| AWS CloudHSM | ML-DSA key pair generation and signing | In preview, per the AWS post-quantum cryptography migration page | AWS PQC migration page |
| Amazon Linux 2023 | System-wide PQ crypto subpolicy enabling ML-KEM hybrid key exchange and ML-DSA signatures | Available on AL2023.12 and later through update-crypto-policies --set DEFAULT:PQ. AWS documentation notes that OpenSSH on AL2023 does not currently support ML-KEM hybrid key exchange | Enable Post-Quantum Cryptography (PQC) on AL2023 |
Two caveats about how to read this table. First, on the client side, a server that supports ML-KEM will only use it if the client offers it - AWS states explicitly that customers are responsible for updating TLS clients and SDKs, and that PQ-ready clients remain backward compatible, so client updates can begin before every service has launched support. Second, AWS's migration plan describes the intent to reach every AWS HTTPS endpoint over the coming years; a service not listed above should be treated as "not yet announced," not as "will not support it."
Migration Design Considerations
The engineering content of a post-quantum migration is mostly not about algorithms. It is about knowing what you have, deciding what to move first, and being able to move again later.Crypto agility is the actual deliverable. The AWS timeline above contains a complete generational replacement inside six years: first-round BIKE and SIKE in 2019, second-round algorithms in 2020, third-round Kyber in 2022, and standardized ML-KEM in 2025. Any system that could absorb those changes by upgrading a library and a policy setting had a cheap migration; any system that hard-coded a cipher suite list, pinned an algorithm identifier in a protocol message, or embedded a public key in firmware did not. AWS's own guidance for custom applications makes the same point: focus on the ability to update algorithms - current software versions, automated update processes, and designs that accommodate algorithm changes - rather than on any single algorithm choice.
Build a cryptographic inventory before choosing a target. You cannot prioritize what you have not enumerated. The inventory that matters is not just "which TLS versions do we allow" but where long-lived asymmetric keys exist: device identity certificates, code-signing keys, document signatures, key-wrapping keys in backups, and any protocol where a public key is embedded in something you cannot easily reissue. NIST's National Cybersecurity Center of Excellence has a dedicated project on migration to post-quantum cryptography whose practice guide, SP 1800-38, Migration to Post-Quantum Cryptography, remains at preliminary draft stage as of the confirmation date; it is the closest thing to a published methodology for this discovery work.
Prioritize by how long the data must stay confidential, and by how long the trust anchor must last. The two priorities that AWS states on its migration page map cleanly to two different kinds of system. Data in transit over public networks that must remain confidential for a long time is addressed by hybrid key exchange, because that is the exposure the "harvest now, decrypt later" framing describes: traffic captured today, decrypted later. Long-lived devices that ship with a root of trust are addressed by post-quantum signatures, because a device that cannot be updated must be able to verify signatures for its entire service life. A stateless internal API call between two services in the same account sits at neither extreme.
Understand what the migration costs in engineering terms. The technical price of hybrid key exchange is paid in handshake size, compatibility, and operational surface, not in anything you can express as a single number:
- Handshake size. ML-KEM key exchange messages are substantially larger than elliptic-curve ones. AWS's guidance quantifies the additional data transferred and notes that the processing overhead is comparable to the ECDH exchange already in use, and that the total overhead has been immaterial in typical internet handshakes.
- Middlebox compatibility. This is the failure mode that actually bites. AWS's KMS documentation warns explicitly that legacy intermediate hosts, proxies, or firewalls performing deep packet inspection may block requests, either because of the new key exchange groups appearing in the ClientHello or because of the larger key exchange messages. Testing from multiple network paths is the recommended check, and this is worth doing before you enable anything broadly.
- Client and SDK versions. Support arrives through the client stack - specific SDK versions, specific HTTP clients, specific OpenSSL versions - and differs by language and platform. A server-side enablement with no client-side rollout changes nothing.
- Certificate chains, separately from key exchange. Key establishment and signatures migrate on completely different schedules, discussed in the next section.
Verify rather than assume. For AWS API calls, the negotiated key exchange is observable: the
keyExchange field in the tlsDetails section of the CloudTrail record shows a value such as X25519MLKEM768 when hybrid key agreement was used. For load balancers, ALB connection logs and NLB access logs record the key exchange. Making this observable is what turns "we enabled post-quantum TLS" from an assertion into a measurement, and AWS has also published guidance on automating readiness checks with AWS Config.For the surrounding AWS design context, my AWS Elastic Load Balancing Decision Guide covers listener and policy selection, Amazon CloudFront Origin Architecture Guide covers the edge-to-origin path, and AWS Secure Web Application Reference Architecture Guide covers where TLS termination sits in a typical stack.
Current Overview of Post-Quantum Cryptography
Key Establishment and Digital Signatures Are Two Separate Migrations
The single most useful mental model is that post-quantum cryptography is not one migration but two, with different urgency, different mechanics, and different timelines.Key establishment protects confidentiality. Its urgency comes from the fact that a session key negotiated today protects data that an adversary could record today and attack later - the framing that AWS, NIST, and the various national bodies all describe as "harvest now, decrypt later." Nothing has to be reissued to fix it: both endpoints upgrade their software, negotiate a new key exchange group, and every subsequent session is protected. This is why key establishment moved first everywhere, including on AWS.
Digital signatures protect authenticity. A signature verified today is verified against a key that is presented at the same moment, so recording traffic gains an adversary nothing. The urgency instead comes from longevity: a root certificate embedded in a device shipping today, a code-signing key whose signatures must verify for a decade, a document signature that must remain checkable. Signatures are also much harder to migrate, because a signature algorithm has to be encoded in certificates, understood by every relying party in the chain, and supported by every verifying implementation - which is why the X.509 algorithm identifier RFCs matter so much and why they arrived years after FIPS 204.
The standardized algorithms split along the same line. FIPS 203 specifies ML-KEM, the key-encapsulation mechanism. FIPS 204 and FIPS 205 specify ML-DSA and SLH-DSA, the signature schemes. HQC was selected in 2025 as a second key-encapsulation mechanism built on a different mathematical assumption than ML-KEM, and FIPS 206 - which will standardize FALCON as FN-DSA - is listed by NIST as in development; as of the confirmation date, no draft of FIPS 206 has been published on the NIST publication site.
Hybrid Key Exchange and Why It Is Used
Every production deployment of post-quantum key establishment described in this article is hybrid: a traditional key exchange and a post-quantum one are performed independently in the same handshake, and their outputs are combined into a single session secret. RFC 9954 specifies this construction for TLS 1.3, and RFC 9370 provides the equivalent capability for IKEv2.The argument for hybrid is conservative rather than enthusiastic. The traditional algorithms have decades of cryptanalysis behind them; the post-quantum ones are comparatively new, and the competition itself demonstrated that new schemes can fall. Combining them means the session remains confidential unless both components are broken. AWS describes the resulting property directly: an adversary would need to break both primitives to break the confidentiality of the hybrid key agreement, and the negotiated key is therefore at least as strong as the stronger of the two.
In practice the construction shows up as a named group in TLS configuration.
X25519MLKEM768 combines X25519 with ML-KEM-768; SecP256r1MLKEM768 and SecP384r1MLKEM1024 are the NIST-curve equivalents. These names appear in ALB security policies, in AWS-LC and s2n-tls command-line options, and in the CloudTrail tlsDetails field - which makes them the most practically useful strings in this entire article.Impact on Certificates and PKI
The certificate side is where the migration gets genuinely difficult, and it is worth being explicit about why the two halves have moved at such different speeds.A hybrid key exchange changes only what the two endpoints compute during the handshake. The server certificate is untouched: the same RSA or ECDSA certificate keeps working, which is exactly why AWS could enable post-quantum key exchange on CloudFront's existing security policies without customers reconfiguring anything, and why AWS's migration plan describes services terminating TLS on your behalf negotiating ML-KEM using the certificates you already have.
Migrating the signatures in a certificate chain is a different problem. Every relying party has to understand the new algorithm identifiers, which is what RFC 9881 provides for ML-DSA in X.509 and RFC 9935 provides for ML-KEM; the certificate authority has to be able to issue with the new algorithm; and the chain has to validate end to end. That is a coordination problem across an entire ecosystem rather than a software upgrade at two endpoints. It is also why the practical post-quantum signature deployments available today are in closed or semi-closed PKIs - AWS Private CA issuing ML-DSA certificates, IAM Roles Anywhere accepting ML-DSA trust anchors, KMS producing ML-DSA signatures for code signing - where the operator controls both the issuer and the verifiers.
Post-quantum signatures are also considerably larger than ECDSA signatures, which matters for protocols that carry several certificates per handshake. That is the practical reason the certificate migration is being approached deliberately rather than urgently, alongside the fact that its threat model does not include retroactive attack. If you want to inspect what a chain actually presents today, my SSL/TLS Certificate Decoder Tool decodes certificates entirely in the browser.
Work in Progress at the IETF
Several pieces of protocol work relevant to deployment were still in progress as of 2026-07-31. Internet-Drafts are working documents and can change or be abandoned; they are listed here because implementations - including AWS's - already follow some of them, which is exactly the situation where knowing the status matters.| Document | Subject | Status as of 2026-07-31 |
|---|---|---|
| draft-ietf-tls-ecdhe-mlkem | Post-quantum hybrid ECDHE-MLKEM key agreement for TLS 1.3, which defines the named groups including X25519MLKEM768 | Active Internet-Draft in the TLS working group; IESG state "Approved-announcement sent"; intended status Proposed Standard |
| draft-ietf-sshm-mlkem-hybrid-kex | PQ/T hybrid key exchange with ML-KEM in SSH | Active Internet-Draft in the SSHM working group; IESG state "RFC Ed Queue"; intended status Informational |
| draft-ietf-tls-mldsa | Use of ML-DSA in TLS 1.3 | Active Internet-Draft in the TLS working group; IESG state "Approved-announcement to be sent::AD Followup"; intended status Informational |
The SSH draft is the one to watch if you use AWS Transfer Family, because AWS documentation states that its SFTP and SSH post-quantum key exchange follows a draft proposal and that the key exchange method names might change as that draft evolves toward standardization.
Submission Names and Standardized Names
Algorithms were submitted to the competition under one name and standardized under another. Both remain in circulation, and configuration written before 2024 generally uses the submission name.| Submission name | Standardized name | Standard | Role |
|---|---|---|---|
| CRYSTALS-KYBER | ML-KEM | FIPS 203, published 2024-08-13 | Key encapsulation |
| CRYSTALS-Dilithium | ML-DSA | FIPS 204, published 2024-08-13 | Digital signature |
| SPHINCS+ | SLH-DSA | FIPS 205, published 2024-08-13 | Digital signature (stateless hash-based) |
| FALCON | FN-DSA | FIPS 206, in development; no draft published as of 2026-07-31 | Digital signature |
| HQC | (standard in preparation) | Selected 2025-03-11; NIST stated a draft would be released for comment | Key encapsulation |
The practical consequence shows up in AWS's own history: connections that negotiated "Kyber" against KMS endpoints in 2022 and connections that negotiate ML-KEM against the same endpoints today are the same lineage of algorithm, but they are not interoperable, and the pre-standard versions were removed. Documentation, runbooks, and cipher configuration written during the transition period will contain both names.
Crypto Agility
Crypto agility is the property that made the 2019-to-2025 sequence on AWS survivable, and it is the one design characteristic worth optimizing for, because there is no reason to assume ML-KEM and ML-DSA are the last algorithms anyone will deploy. NIST's own process is still running: a second key-encapsulation mechanism was selected in 2025 and a third round of additional signature candidates was announced in 2026.In practice, agility means a small number of unglamorous properties. Algorithm selection lives in configuration or policy rather than in code. Cipher and group preferences are expressed as named policies you can swap, which is precisely the model ALB, API Gateway, CloudFront, and Transfer Family use. Public keys and algorithm identifiers are not embedded anywhere they cannot be reissued. Dependencies stay current, because support arrives through library and SDK versions. And the negotiated algorithm is observable in logs, so you can tell what is actually happening rather than what you configured. AWS's guidance for custom applications reduces to the same list, with the additional observation that workloads which delegate cryptography to managed services inherit the provider's migrations rather than executing their own. For the lifecycle view of retiring old components generally, see my AWS End of Support and EOL Reference.
Frequently Asked Questions about Post-Quantum Cryptography Standardization History
When did NIST start the post-quantum cryptography standardization process?
NIST published NISTIR 8105, Report on Post-Quantum Cryptography, on 2016-04-28, after releasing a draft for comment on 2016-02-03. The formal call for proposals was published in the Federal Register on 2016-12-20, and the submission deadline was 2017-11-30. Of the 82 algorithms submitted, 69 were accepted as first-round candidates on 2017-12-20.When were the first post-quantum cryptography standards published?
NIST published FIPS 203, FIPS 204, and FIPS 205 on 2024-08-13. FIPS 203 specifies ML-KEM for key encapsulation, FIPS 204 specifies ML-DSA for digital signatures, and FIPS 205 specifies SLH-DSA for stateless hash-based signatures. These were derived from the CRYSTALS-KYBER, CRYSTALS-Dilithium, and SPHINCS+ submissions, which NIST had selected for standardization on 2022-07-05 - a gap of just over two years between selection and publication.What is the difference between ML-KEM and ML-DSA?
ML-KEM is a key-encapsulation mechanism specified in FIPS 203; it establishes a shared secret and therefore protects confidentiality. ML-DSA is a digital signature algorithm specified in FIPS 204; it protects authenticity and integrity. They migrate on different schedules: key establishment is the more urgent of the two because recorded traffic can be attacked later, whereas signatures are harder to migrate because new algorithm identifiers must be understood by every relying party in a certificate chain.Why is post-quantum key exchange deployed in hybrid form?
Hybrid key exchange performs a traditional key exchange and a post-quantum one independently in the same handshake and combines the results into one session secret, so the session stays confidential unless both are broken. RFC 9954, published on 2026-07-15, specifies this construction for TLS 1.3, and RFC 9370, published on 2023-05-22, provides the equivalent for IKEv2. AWS describes the same property for its own deployment: an adversary would need to break both primitives to break the confidentiality of the hybrid key agreement.Which AWS services support post-quantum cryptography?
As of 2026-07-31, AWS has announced hybrid ML-KEM key exchange for AWS KMS, AWS Certificate Manager, AWS Secrets Manager, AWS Payment Cryptography, and Amazon S3 endpoints, and as a selectable TLS policy for Elastic Load Balancing, Amazon API Gateway, Amazon CloudFront, and AWS Transfer Family. For post-quantum signatures, AWS KMS supports ML-DSA signing keys, AWS Private CA supports issuing ML-DSA certificate authorities and certificates, AWS IAM Roles Anywhere accepts ML-DSA trust anchors, and AWS CloudHSM support is in preview. AWS has stated it plans to deploy ML-KEM hybrid key agreement across its HTTPS endpoints over the coming years, so this list should be re-checked against the official AWS post-quantum cryptography pages.What did NIST say about when quantum-vulnerable algorithms will be phased out?
NIST released the initial public draft of NIST IR 8547 on 2024-11-12. Its transition tables state that ECDSA and RSA at 112 bits of security strength are to be deprecated after 2030 and disallowed after 2035, that EdDSA at 128 bits is to be disallowed after 2035, and that finite-field and elliptic-curve Diffie-Hellman at 112 bits follow the same dates. The document also cites National Security Memorandum 10, issued on 2022-05-04, which sets 2035 as the primary target for completing the migration across US federal systems. NIST IR 8547 remained an initial public draft as of 2026-07-31.Were any candidate algorithms broken during the process?
Yes, and this is a normal outcome of an open evaluation. A key-recovery result against Rainbow, then a third-round signature finalist, was received by the IACR Cryptology ePrint Archive on 2022-02-25, and an efficient key-recovery attack on SIDH - the basis of the fourth-round candidate SIKE - was received on 2022-07-30. NIST IR 8545, published on 2025-03-11, recorded that HQC was the only fourth-round key-establishment algorithm selected for standardization. Multi-year public competitions exist precisely so that results like these arrive before deployment rather than after.Is the standardization process finished?
No. NIST selected HQC as an additional key-encapsulation mechanism on 2025-03-11 and stated it would draft a standard for public comment. FIPS 206, which will standardize FALCON as FN-DSA, is listed as in development, with no draft published as of 2026-07-31. The separate track for additional digital signature schemes, opened in September 2022 and closed to submissions on 2023-06-01 with 40 algorithms, reached its third round on 2026-05-14 with nine candidates, documented in NIST IR 8610.Summary
Post-quantum cryptography standardization has taken a decade of public process, and the record of it is unusually complete: a call for proposals in December 2016, 69 first-round candidates in December 2017, three rounds of narrowing, the selection of four algorithms in July 2022, and the publication of FIPS 203, FIPS 204, and FIPS 205 in August 2024. The process has not stopped - HQC was selected in March 2025, FIPS 206 remains in development, and a third round of additional signature candidates was announced in May 2026 - which is itself the strongest argument for treating agility rather than any specific algorithm as the design goal.The protocol layer that makes those standards deployable arrived on its own schedule and largely after them: the X.509 algorithm identifiers for ML-DSA in October 2025 and for ML-KEM in March 2026, and hybrid key exchange for TLS 1.3 as RFC 9954 in July 2026. On AWS, deployment ran ahead of both, beginning with pre-standard algorithms on AWS KMS endpoints in November 2019 and converging on standardized ML-KEM in April 2025, then spreading through 2025 and 2026 to Elastic Load Balancing, Amazon CloudFront, Amazon API Gateway, Amazon S3, AWS Transfer Family, and the signature-side services built on ML-DSA.
For anyone planning this work, the practical shape is consistent regardless of which cloud or which protocol you start from. Key establishment first, because that is where recorded traffic creates retroactive exposure and because hybrid key exchange requires no reissuance. Signatures and certificate chains on a longer horizon, prioritized by how long a trust anchor has to survive. An inventory before a target date. And enough agility in configuration, dependencies, and observability that the next algorithm change is a policy update rather than a project. The one thing worth re-checking rather than remembering is the service support table - it was accurate on 2026-07-31, and it will not stay that way.
This timeline will be updated as post-quantum cryptography standardization and its deployment on AWS continue to evolve.
TLS Certificate Ecosystem History and Timeline - Certificate Authorities, Automation, and Shrinking Certificate Lifetimes
Major Security Vulnerabilities History and Timeline - Disclosure, Impact, and the Response Practices They Changed
Cryptography Glossary for Engineers
AWS KMS Envelope Encryption and Data Key Caching Patterns - Design Decisions for the AWS Encryption SDK and Multi-Region Keys
AWS History and Timeline regarding AWS KMS - Overview, Functions, Features, Summary of Updates, and Introduction to KMS
AWS Zero Trust Network Architecture Guide
References:
NIST Post-Quantum Cryptography project
NIST Post-Quantum Cryptography Standardization
NIST Post-Quantum Cryptography: Additional Digital Signature Schemes
FIPS 203, Module-Lattice-Based Key-Encapsulation Mechanism Standard
FIPS 204, Module-Lattice-Based Digital Signature Standard
FIPS 205, Stateless Hash-Based Digital Signature Standard
NIST SP 800-227, Recommendations for Key-Encapsulation Mechanisms
NIST IR 8547 (Initial Public Draft), Transition to Post-Quantum Cryptography Standards
NIST SP 1800-38, Migration to Post-Quantum Cryptography
RFC 9954: Hybrid Key Exchange in TLS 1.3
RFC 9794: Terminology for Post-Quantum Traditional Hybrid Schemes
RFC 9958: Post-Quantum Cryptography for Engineers
AWS Post-Quantum Cryptography
AWS Migration to Post-Quantum Cryptography
AWS post-quantum cryptography migration plan
Using hybrid post-quantum TLS with AWS KMS
References:
Tech Blog with curated related content
Written by Hidekazu Konishi