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: Qualified electronic signatures and seals with a qualified trust service provider
10 checkpoints: 8 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: 9
- Vendor roadmap date: 0
- Official guidance target: 1
- 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-DSA in CMS published as an RFC | Standards body or supervisor (outside the plan) | Nothing | Unknown: no date published or agreed | Completed | 2025: RFC 9882, Proposed Standard, 2025. | A Standards Track RFC. RFC 9882: Use of the ML-DSA Signature Algorithm in the Cryptographic Message Syntax (CMS) | Nothing | No review cycle agreed | 4 checkpoints |
| Stage 1 | ETSI cryptographic suites list post-quantum signatures | Standards body or supervisor (outside the plan) | Nothing | Unknown: no date published or agreed | Completed | 2026-06: ETSI TS 119 312 V2.1.1, June 2026. | A published ETSI specification listing the algorithms. ETSI TS 119 312 V2.1.1: Electronic Signatures and Trust Infrastructures (ESI); Cryptographic Suites | Nothing | No review cycle agreed | 4 checkpoints |
| Stage 1 | Inventory of signing uses, certificates and documents that must stay verifiable | Own organisation | Nothing | Official guidance target: EU roadmap milestone 1: first steps and national roadmaps | Proposed | Not completed | Signing uses, certificate profiles and retention periods recorded. | Nothing | No review cycle agreed | 3 checkpoints |
| Stage 2 | Migration dates for qualified trust services published | Standards body or supervisor (outside the plan) | ETSI cryptographic suites list post-quantum signatures | Unknown: no date published or agreed | Proposed | Not completed | A published document with migration dates that applies to qualified trust services. ETSI TS 119 312 V2.1.1: Electronic Signatures and Trust Infrastructures (ESI); Cryptographic Suites | Clause 8.5 of TS 119 312 leaves migration dates to a separate document still being prepared when read. | 2027-01-28 | 2 checkpoints |
| Stage 2 | Qualified signature creation device supports ML-DSA | Certificate authority or trust service provider | ETSI cryptographic suites list post-quantum signatures | Unknown: no date published or agreed | Proposed | Not completed | A device release with ML-DSA and its certification status, recorded by the provider. | Nothing | No review cycle agreed | 2 checkpoints |
| Stage 2 | Signing application creates ML-DSA signatures in the agreed formats | Own organisation | Inventory of signing uses, certificates and documents that must stay verifiable; ML-DSA in CMS published as an RFC | Unknown: no date published or agreed | Proposed | Not completed | Signed test documents in each format used. | Nothing | No review cycle agreed | 1 checkpoint |
| Stage 2 | Recipients' validation software verifies ML-DSA signatures | Counterparty (the other organisation or its users) | ML-DSA in CMS published as an RFC | Unknown: no date published or agreed | Proposed | Not completed | Recipients confirm validation of the signed test documents. | Nothing | No review cycle agreed | 1 checkpoint |
| Stage 2 | Plan for documents signed classically that must stay verifiable | Own organisation | Inventory of signing uses, certificates and documents that must stay verifiable | Unknown: no date published or agreed | Proposed | Not completed | A preservation approach per document class, for example re-sealing or archive timestamps. | Nothing | No review cycle agreed | 0 checkpoints |
| Stage 3 | Qualified certificates with ML-DSA keys offered | Certificate authority or trust service provider | Qualified signature creation device supports ML-DSA; Migration dates for qualified trust services published; ML-DSA in CMS published as an RFC | Unknown: no date published or agreed | Proposed | Not completed | A certificate profile published by the provider and accepted under its supervision. | Nothing | No review cycle agreed | 1 checkpoint |
| Stage 4 | End-to-end test: qualified certificate, signing and validation | All parties of the service jointly | Qualified certificates with ML-DSA keys offered; Signing application creates ML-DSA signatures in the agreed formats; Recipients' validation software verifies ML-DSA signatures | Unknown: no date published or agreed | Proposed | Not completed | A test record naming the provider, the formats and the validation results of each recipient. | 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: Migration dates for qualified trust services published; Qualified signature creation device supports ML-DSA; Recipients' validation software verifies ML-DSA signatures
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.