PQC migration checkpoints of shared services
PQC migration toolkit: 4 views
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: SSH administration of servers, partly by an outsourced operator
8 checkpoints: 7 proposed, 0 agreed, 1 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: 7
- 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 | Hybrid ML-KEM key exchange for SSH published as an RFC | Standards body or supervisor (outside the plan) | Nothing | Unknown: no date published or agreed | Completed | 2026: RFC 10042, Informational, 2026. | An RFC naming the key exchange methods. RFC 10042: Post-Quantum/Traditional Hybrid Key Exchange with ML-KEM for Use in SSH | Nothing | No review cycle agreed | 6 checkpoints |
| Stage 1 | Inventory of administrators' clients, the bastion and the managed servers | Own organisation | Nothing | Official guidance target: EU roadmap milestone 1: first steps and national roadmaps | Proposed | Not completed | SSH client and server products and releases recorded for each group of hosts. | Nothing | No review cycle agreed | 6 checkpoints |
| Stage 2 | Administrators' clients on a release with the hybrid method | Own organisation | Inventory of administrators' clients, the bastion and the managed servers; Hybrid ML-KEM key exchange for SSH published as an RFC | Unknown: no date published or agreed | Proposed | Not completed | Client releases recorded with their evidence. | Nothing | No review cycle agreed | 3 checkpoints |
| Stage 2 | Operator states the bastion release and the methods it offers | Supplier or vendor | Inventory of administrators' clients, the bastion and the managed servers; Hybrid ML-KEM key exchange for SSH published as an RFC | Unknown: no date published or agreed | Proposed | Not completed | A dated statement from the operator naming the release and key exchange methods. | Nothing | No review cycle agreed | 3 checkpoints |
| Stage 2 | Managed servers on a release with the hybrid method | Own organisation | Inventory of administrators' clients, the bastion and the managed servers; Hybrid ML-KEM key exchange for SSH published as an RFC | Unknown: no date published or agreed | Proposed | Not completed | Server releases recorded with their evidence. | Nothing | No review cycle agreed | 3 checkpoints |
| Stage 3 | Key exchange methods agreed with the operator | All parties of the service jointly | Administrators' clients on a release with the hybrid method; Operator states the bastion release and the methods it offers; Managed servers on a release with the hybrid method | Unknown: no date published or agreed | Proposed | Not completed | The ordered method list for clients, bastion and servers, recorded with who agreed and when. | Nothing | No review cycle agreed | 2 checkpoints |
| Stage 4 | Joint test through the bastion | All parties of the service jointly | Key exchange methods agreed with the operator | Unknown: no date published or agreed | Proposed | Not completed | Logs show the hybrid method negotiated on both legs. | Nothing | No review cycle agreed | 1 checkpoint |
| Stage 5 | Classical-only methods removed, when the operator and the organisation authorise it | All parties of the service jointly | Joint test through the bastion | Unknown: no date published or agreed | Proposed | Not completed | A recorded authorisation and a check that no classical-only session 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
None.
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.