PQC transition coordination for shared services
Post-quantum migration of a shared service needs every party in the chain: your own organisation, suppliers, counterparties, certificate authorities and network providers. Pick a reference service and, if you wish, the product release of each component to see what the reviewed evidence says, what blocks what, who must act and a shared action plan you can print or export.
A product that supports a post-quantum algorithm does not mean the service can migrate: every party must configure, test and agree it, and the fallback must be retired. The reference services are illustrative templates, not real estates, not an agreed plan and not a coordination body. Not compliance advice.
Choose a reference service
Code signing and firmware updates from a supplier to an operator's devices
Illustrative template A device supplier signs firmware and software updates with keys held in an HSM; devices in the operator's network verify the signature before installing. Devices must be able to verify new signatures before the signer can switch.
Parties involved: Own organisation, Supplier or vendor, Certificate authority or trust service provider
Limitations: A generic template. Device bootloaders and update agents are not in the product navigator. Stateful hash-based signatures need strict state management by the signer.
0 of 5 components have approved evidence that the chosen release is generally available.
The service is not shown as migrated or ready: even with every component available, the parties still have to agree the configuration, test the whole chain together, pilot, roll out, validate and retire the fallback.
Product releases, optional
Choose the release you run for each component, from the products of the PQC navigator. Readiness is read from the assertions an editor approved for that release; leave a component on Not chosen if you do not know.
Component chain and readiness
Components are listed with the ones they depend on first. A component is blocked while anything it depends on, directly or further up the chain, is not available. Components without dependencies can start in parallel.
| Component | Controlled by | Chosen release | Readiness | Depends on | Blocked by | Evidence and note |
|---|---|---|---|---|---|---|
| Supplier's signing HSM | Supplier or vendor | Not chosen | No product release chosen | Nothing | Nothing | Holds the signing keys and, for LMS or XMSS, the signing state. |
| Bootloaders and update agents verifying signatures on the devices | Supplier or vendor | Not chosen | Not covered by the product navigator | Nothing | Nothing | Installed devices may need a firmware update that adds the new verification first. |
| Code-signing certificate or trust anchor | Certificate authority or trust service provider | Not chosen | No product release chosen | Supplier's signing HSM | Supplier's signing HSM | Only where updates are signed under a certificate rather than a raw key. |
| Signing library in the supplier's build pipeline | Supplier or vendor | Not chosen | No product release chosen | Supplier's signing HSM; Bootloaders and update agents verifying signatures on the devices | Supplier's signing HSM; Bootloaders and update agents verifying signatures on the devices | An algorithm in the library is not yet a signature format the devices accept. |
| Operator's acceptance and rollout of updates with new signatures | Own organisation | Not chosen | No agreement recorded between the parties | Signing library in the supplier's build pipeline | Signing library in the supplier's build pipeline; Supplier's signing HSM; Bootloaders and update agents verifying signatures on the devices | The operator decides when devices stop accepting classical-only signatures. |
Bottlenecks (not available, and other components wait for them)
- Supplier's signing HSM: blocks 3 other components
- Bootloaders and update agents verifying signatures on the devices: blocks 2 other components
- Signing library in the supplier's build pipeline: blocks 1 other components
Can start in parallel (no dependencies)
Supplier's signing HSM; Bootloaders and update agents verifying signatures on the devices
Readiness, in words
- Available in the chosen release (approved evidence)
- Preview only in the chosen release
- Announced roadmap only, no release
- Explicitly unsupported for this function
- No verified information for the chosen release
- No product release chosen
- Not covered by the product navigator
- No agreement recorded between the parties
Protocol and standard requirements
The specifications each component has to follow, with their status on the day they were read. An Internet-Draft is work in progress, not a standard.
- NIST SP 800-208: Recommendation for Stateful Hash-Based Signature Schemes
Specifies LMS and XMSS with their multi-tree variants for use in US federal systems; a reference for stateful hash-based signing. - RFC 8554: Leighton-Micali Hash-Based Signatures
Specifies LMS, a stateful hash-based signature scheme used for firmware and software signing where the signer can manage state. - RFC 9882: Use of the ML-DSA Signature Algorithm in the Cryptographic Message Syntax (CMS)
Sets the conventions for ML-DSA signatures in CMS, the container used by many code, document and e-mail signatures. - RFC 9881: Algorithm Identifiers for the Module-Lattice-Based Digital Signature Algorithm (ML-DSA) in X.509
Sets the identifiers and formats for ML-DSA in X.509 certificates and revocation lists, the basis for post-quantum certificate chains.
Interoperability evidence
Published test results with their exact scope. A passed test applies only to what was tested; it is not a certification and does not show that a service or an organisation is ready.
- IETF PQC Hackathon: ML-DSA-65 X.509 certificate artifacts
- Result
- Passed within the stated scope
- Scope
- Parsing and verifying self-signed ML-DSA-65 certificate artifacts from 17 producers with 4 verifiers (Bouncy Castle, a composite reference implementation, OpenSSL and QUBIP Aurora): all 68 pairs passed.
- Algorithms and formats
- ML-DSA-65 (pure), X.509 certificates in the RFC 9881 format
- Navigator products whose projects took part
- Bouncy Castle for Java, Botan, OpenJDK (Java SE), OpenSSL, CryptoNext Quantum-Safe Library
- Limitations
- Artifact test, not a TLS handshake or a deployed service. The page names submitters, not product releases or builds, so it does not apply to a particular release listed here. Not a certification.
- Results dated, read on
- 2026-10-06, 2026-10-23
- Locator
- Automated verification results, table ML-DSA-65-cert (2.16.840.1.101.3.4.3.18-cert): rows are producers, columns are parsers
EU coordinated roadmap milestones
Target dates as the PQC migration timeline records them from their sources. They are authority guidance targets: not legal deadlines and not dates agreed between the parties of this service.
- : EU roadmap milestone 1: first steps and national roadmaps
By the end of 2026 all Member States should have implemented at least the roadmap's first steps, established initial national transition roadmaps and started planning and pilots for high- and medium-risk use cases. - : EU roadmap milestone 2: high-risk use cases migrated
By the end of 2030 the roadmap's next steps should be implemented, high-risk use cases moved to post-quantum cryptography, planning and pilots for medium-risk use cases completed and quantum-safe software and firmware upgrades enabled by default.
What the PQC guide lists for this kind of service
Shared action plan
One action per component for the party that controls it, then the steps all parties take together. Dates are unknown unless a supplier published one; no date here is agreed. To print, use your browser’s print command: the page prints without menus.
Own organisation
| Checkpoint | Action | Component | State | Waits for | Date |
|---|---|---|---|---|---|
| Compatible configuration agreed | Agree Operator's acceptance and rollout of updates with new signatures between the parties concerned and record who agreed and when. | Operator's acceptance and rollout of updates with new signatures | Waiting for the items listed | Signing library in the supplier's build pipeline | Unknown: no date published or agreed |
Supplier or vendor
| Checkpoint | Action | Component | State | Waits for | Date |
|---|---|---|---|---|---|
| Inventory and scope confirmed | Identify the product and release used for Supplier's signing HSM and record it. | Supplier's signing HSM | Can start now | Nothing | Unknown: no date published or agreed |
| Supplier and counterparty statements obtained | Obtain a dated statement on post-quantum support for Bootloaders and update agents verifying signatures on the devices; the product navigator has no record for it. | Bootloaders and update agents verifying signatures on the devices | Can start now | Nothing | Unknown: no date published or agreed |
| Inventory and scope confirmed | Identify the product and release used for Signing library in the supplier's build pipeline and record it. | Signing library in the supplier's build pipeline | Waiting for the items listed | Supplier's signing HSM; Bootloaders and update agents verifying signatures on the devices | Unknown: no date published or agreed |
Certificate authority or trust service provider
| Checkpoint | Action | Component | State | Waits for | Date |
|---|---|---|---|---|---|
| Inventory and scope confirmed | Identify the product and release used for Code-signing certificate or trust anchor and record it. | Code-signing certificate or trust anchor | Waiting for the items listed | Supplier's signing HSM | Unknown: no date published or agreed |
All parties of the service jointly
| Checkpoint | Action | Component | State | Waits for | Date |
|---|---|---|---|---|---|
| Interoperability test | Run a joint interoperability test of the whole chain in a test environment and record its scope and result. | Whole service | Waiting for the items listed | Supplier's signing HSM; Bootloaders and update agents verifying signatures on the devices; Code-signing certificate or trust anchor; Signing library in the supplier's build pipeline; Operator's acceptance and rollout of updates with new signatures | Unknown: no date published or agreed |
| Pilot | Pilot the service with a limited group, keeping the classical fallback. | Whole service | Waiting for the items listed | Interoperability test | Unknown: no date published or agreed |
| Staged rollout | Roll out in stages agreed by every party. | Whole service | Waiting for the items listed | Pilot | Unknown: no date published or agreed |
| Validation | Validate that the post-quantum mechanisms are actually negotiated or verified on every hop. | Whole service | Waiting for the items listed | Staged rollout | Unknown: no date published or agreed |
| Retirement of the legacy fallback, when authorised | Retire the classical-only fallback only when every party has authorised it. | Whole service | Waiting for the items listed | Validation | Unknown: no date published or agreed |
Download the action plan as CSV · Download the chain and the plan as JSON
PQC product navigator: readiness evidence by product release · PQC guide: what the rules say · PQC milestones and deadlines · EU legal acts on quantum · Document library
Illustrative reference services for coordinating a post-quantum migration across organisations (#471, first pilot). Each service is a generic chain of components with the role that controls each one; product readiness comes only from the editor-approved assertions of the PQC product navigator, never from this file. Requirement and interoperability sources were read on 23 October 2026 on the publishers' own pages; summaries are the portal's own words. Not a coordination body, not an agreed plan, not compliance advice. Reference services compiled 2026-10-23.