PQC migration checkpoints of shared services
The checkpoints a post-quantum migration of a shared service goes through, who owns each one by role, what it waits for, the kind of each date and what a slip would delay. External prerequisites such as standards and industry rules carry their real status from recorded sources.
Reference model, not an agreed plan. No participant has agreed this plan and no coordination governance exists, so no checkpoint is agreed, no date is participant-agreed and no operational board is active. Participant checkpoints are proposed and undated. Owners are roles, never people. Not compliance advice.
Choose a reference service
Proposed, agreed and completed: Public website over TLS behind a CDN and a load balancer, with an HSM-backed certificate authority
13 checkpoints: 11 proposed, 0 agreed, 2 completed.
Nothing is agreed: no governance between participants exists. Completed checkpoints are external prerequisites whose completion a recorded source shows.
Planned dates by kind
- Unknown: no date published or agreed: 10
- Vendor roadmap date: 1
- Official guidance target: 2
- Verified legal obligation: 0
- Participant-agreed date: 0
Readiness of the components and the action plan of this service
Checkpoint board
Stages give an order, not a schedule: a checkpoint is in a later stage than everything it waits for. Checkpoints in one stage can run in parallel; checkpoints that wait for each other share a stage and are agreed together.
| Stage | Checkpoint | Owner (role) | Depends on | Planned date and its kind | State | Completed | Acceptance evidence | Blocker | Next review | A slip affects |
|---|---|---|---|---|---|---|---|---|---|---|
| Stage 1 | ML-KEM and ML-DSA published as standards (FIPS 203 and FIPS 204) | Standards body or supervisor (outside the plan) | Nothing | Unknown: no date published or agreed | Completed | 2024-08-13: Published on 13 August 2024, as the PQC timeline records. | Final standards published by NIST. NIST publishes its first post-quantum standards | Nothing | No review cycle agreed | 11 checkpoints |
| Stage 1 | Inventory of TLS endpoints, certificates and the parties of each hop | Own organisation | Nothing | Official guidance target: EU roadmap milestone 1: first steps and national roadmaps | Proposed | Not completed | A dated list of endpoints, products and releases per hop, confirmed by each party for its own part. | Nothing | No review cycle agreed | 6 checkpoints |
| Stage 2 | Hybrid ML-KEM key agreement for TLS 1.3 published as an RFC | Standards body or supervisor (outside the plan) | ML-KEM and ML-DSA published as standards (FIPS 203 and FIPS 204) | Unknown: no date published or agreed | Completed | 2026-08: RFC 10024, Proposed Standard, August 2026, as the PQC timeline records. | A Standards Track RFC with assigned code points. IETF standardises hybrid ML-KEM key agreement for TLS 1.3 | Nothing | No review cycle agreed | 6 checkpoints |
| Stage 2 | ML-DSA authentication in TLS 1.3 published as an RFC | Standards body or supervisor (outside the plan) | ML-KEM and ML-DSA published as standards (FIPS 203 and FIPS 204) | Unknown: no date published or agreed | Proposed | Not completed | An RFC with assigned signature scheme code points. Use of ML-DSA in TLS 1.3 (draft-ietf-tls-mldsa) | Still an Internet-Draft in the RFC Editor queue (revision 06, read again on 30 October 2026). | 2027-01-28 | 2 checkpoints |
| Stage 2 | CA key storage supports ML-DSA keys | Certificate authority or trust service provider | ML-KEM and ML-DSA published as standards (FIPS 203 and FIPS 204) | Unknown: no date published or agreed | Proposed | Not completed | The HSM release and its evidence recorded by the certificate authority. | Nothing | No review cycle agreed | 1 checkpoint |
| Stage 3 | Industry rules allow post-quantum keys in publicly trusted TLS certificates | Standards body or supervisor (outside the plan) | ML-DSA authentication in TLS 1.3 published as an RFC | Unknown: no date published or agreed | Proposed | Not completed | A version of the CA/Browser Forum Baseline Requirements that permits a post-quantum key type. CA/Browser Forum Baseline Requirements for TLS server certificates, version 2.3.1 | Version 2.3.1 (effective 4 October 2026) allows only RSA and ECDSA keys in section 6.1.5. | 2027-01-28 | 1 checkpoint |
| Stage 3 | CDN provider states hybrid key agreement towards visitors and towards the origin | Network, CDN or hosting provider | Inventory of TLS endpoints, certificates and the parties of each hop; Hybrid ML-KEM key agreement for TLS 1.3 published as an RFC | Unknown: no date published or agreed | Proposed | Not completed | A dated statement naming the key agreement groups on both connections and whether they are on by default. | Nothing | No review cycle agreed | 4 checkpoints |
| Stage 3 | Load balancer and origin server releases with hybrid key agreement selected | Own organisation | Inventory of TLS endpoints, certificates and the parties of each hop; Hybrid ML-KEM key agreement for TLS 1.3 published as an RFC | Unknown: no date published or agreed | Proposed | Not completed | Releases recorded, with the vendor evidence for each (for example an approved assertion in the product navigator). | Nothing | No review cycle agreed | 4 checkpoints |
| Stage 4 | Key agreement groups and fallback agreed for every hop | All parties of the service jointly | CDN provider states hybrid key agreement towards visitors and towards the origin; Load balancer and origin server releases with hybrid key agreement selected | Unknown: no date published or agreed | Proposed | Not completed | A written configuration per hop, recorded with who agreed it and when. | Nothing | No review cycle agreed | 3 checkpoints |
| Stage 4 | Post-quantum certificates issued for the edge and the origin | Certificate authority or trust service provider | Industry rules allow post-quantum keys in publicly trusted TLS certificates; CA key storage supports ML-DSA keys | Vendor roadmap date: Vendor evidence in the product navigator | Proposed | Not completed | Certificates with a post-quantum signature accepted by the visitors' browsers in a test. | Nothing | No review cycle agreed | 0 checkpoints |
| Stage 5 | Joint test of hybrid key agreement on every hop | All parties of the service jointly | Key agreement groups and fallback agreed for every hop | Unknown: no date published or agreed | Proposed | Not completed | A test record with the releases, the group negotiated on each hop and the behaviour with classical-only clients. | Nothing | No review cycle agreed | 2 checkpoints |
| Stage 6 | Staged rollout of hybrid key agreement | All parties of the service jointly | Joint test of hybrid key agreement on every hop | Official guidance target: EU roadmap milestone 2: high-risk use cases migrated | Proposed | Not completed | Monitoring shows the hybrid group negotiated on every hop for the agreed share of connections. | Nothing | No review cycle agreed | 1 checkpoint |
| Stage 7 | Classical-only key agreement retired on every hop, when every party authorises it | All parties of the service jointly | Staged rollout of hybrid key agreement | Unknown: no date published or agreed | Proposed | Not completed | A recorded authorisation of every party and a check that no classical-only connection remains. | Nothing | No review cycle agreed | 0 checkpoints |
Mutual dependencies and parallel work
Checkpoints that wait for each other
None.
Checkpoints that can start now, in parallel
- Stage 2: ML-DSA authentication in TLS 1.3 published as an RFC; CA key storage supports ML-DSA keys
If a checkpoint slips
Choose a checkpoint to see every checkpoint that waits for it, directly or further down. The portal does not compute new dates: where an affected checkpoint has a dated target, that target may no longer hold.
Kinds of date, kept apart
- Unknown: no date published or agreed
- Nothing published or agreed. Unknown dates stay unknown; the portal never fills them in.
- Vendor roadmap date
- A target a supplier announced for a release. A roadmap is not a release; shown only once an editor approved the vendor evidence in the product navigator.
- Official guidance target
- A date an authority sets as guidance, as the PQC migration timeline records it. Not a legal deadline and not agreed between the parties.
- Verified legal obligation
- A date a recorded legal act sets. None of the reference services has one.
- Participant-agreed date
- A date the parties of a service agreed. None exists: this is a reference model.