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

Public website over TLS behind a CDN and a load balancer, with an HSM-backed certificate authority

Illustrative template Visitors connect to a CDN edge, which forwards requests through the organisation's load balancer to its origin servers. Certificates come from a certificate authority whose signing keys sit in a hardware security module. Key establishment and certificate signatures migrate separately.

Parties involved: Own organisation, Counterparty (the other organisation or its users), Certificate authority or trust service provider, Network, CDN or hosting provider

Limitations: A generic template, not a real estate. Each TLS hop is negotiated separately: a protected visitor connection says nothing about the edge-to-origin hop. Publicly trusted certificates cannot use post-quantum signatures under the current CA/Browser Forum rules.

0 of 7 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.

Visitors' browsers and devices

CDN edge: TLS towards visitors and towards the origin

Origin web servers and their TLS library

HSM holding the certificate authority's signing keys

Certificate authority issuing the server certificates

Certificates the CDN edge presents to visitors

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.

Components of the service, their readiness and dependencies
Component	Controlled by	Chosen release	Readiness	Depends on	Blocked by	Evidence and note
Visitors' browsers and devices TLS key establishment	Counterparty (the other organisation or its users)	Not chosen	No product release chosen	Nothing	Nothing	Chosen by each visitor, not by the organisation; the edge can only offer hybrid key agreement.
CDN edge: TLS towards visitors and towards the origin TLS key establishment	Network, CDN or hosting provider	Not chosen	No product release chosen	Visitors' browsers and devices	Visitors' browsers and devices	Hybrid key agreement is used on a hop only when both ends support the same group.
Load balancer terminating TLS in front of the origin TLS key establishment	Own organisation	Not chosen	Not covered by the product navigator	CDN edge: TLS towards visitors and towards the origin	CDN edge: TLS towards visitors and towards the origin; Visitors' browsers and devices	Load balancers are not in the product navigator; ask the supplier for a dated statement.
Origin web servers and their TLS library TLS key establishment	Own organisation	Not chosen	No product release chosen	Load balancer terminating TLS in front of the origin	Load balancer terminating TLS in front of the origin; CDN edge: TLS towards visitors and towards the origin; Visitors' browsers and devices	Library support is not enough: the web server must be configured to offer the hybrid group.
HSM holding the certificate authority's signing keys HSM key storage and operations	Certificate authority or trust service provider	Not chosen	No product release chosen	Nothing	Nothing	Shared by every certificate the authority issues, so several services may wait on it.
Certificate authority issuing the server certificates PKI / CA certificate issuance	Certificate authority or trust service provider	Not chosen	No product release chosen	HSM holding the certificate authority's signing keys	HSM holding the certificate authority's signing keys	A private authority can issue ML-DSA certificates for internal hops; a publicly trusted one cannot yet.
Certificates the CDN edge presents to visitors Certificate signatures	Network, CDN or hosting provider	Not chosen	No product release chosen	Certificate authority issuing the server certificates; Visitors' browsers and devices	Certificate authority issuing the server certificates; Visitors' browsers and devices; HSM holding the certificate authority's signing keys	Visitors' software must also verify the new signatures, so the browsers are a shared dependency.

Bottlenecks (not available, and other components wait for them)

Visitors' browsers and devices: blocks 4 other components
CDN edge: TLS towards visitors and towards the origin: blocks 2 other components
HSM holding the certificate authority's signing keys: blocks 2 other components
Load balancer terminating TLS in front of the origin: blocks 1 other components
Certificate authority issuing the server certificates: blocks 1 other components

Can start in parallel (no dependencies)

Visitors' browsers and devices; HSM holding the certificate authority's signing keys

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.

RFC 10024: Post-Quantum Traditional (PQ/T) Hybrid Key Agreement Mechanisms for TLS 1.3 (IETF (RFC Editor))
Defines hybrid key agreement for TLS 1.3 that combines ML-KEM with an elliptic-curve exchange; both ends of a connection must support the same group for it to be negotiated.
IETF RFC; Proposed Standard, published 2026; read 2026-10-23 at: RFC information page: status Proposed Standard; Section 7.4 on the pre-standard Kyber code points. Applies to: Visitors' browsers and devices; CDN edge: TLS towards visitors and towards the origin; Load balancer terminating TLS in front of the origin; Origin web servers and their TLS library.
Record in the standards directory
RFC 9881: Algorithm Identifiers for the Module-Lattice-Based Digital Signature Algorithm (ML-DSA) in X.509 (IETF (RFC Editor))
Sets the identifiers and formats for ML-DSA in X.509 certificates and revocation lists, the basis for post-quantum certificate chains.
IETF RFC; Proposed Standard, published 2025; read 2026-10-23 at: RFC information page: title, status Proposed Standard, authors. Applies to: HSM holding the certificate authority's signing keys; Certificate authority issuing the server certificates; Certificates the CDN edge presents to visitors.
Use of ML-DSA in TLS 1.3 (draft-ietf-tls-mldsa) (IETF Datatracker)
Specifies ML-DSA signatures for TLS 1.3 authentication. Still a draft on the date read, so its details may change before publication.
IETF Internet-Draft (work in progress, not a standard); Internet-Draft, revision 06 of 11 September 2026, in the RFC Editor queue, intended Informational; not yet an RFC; read 2026-10-23 at: Document page: type, latest revision, intended status, IESG state RFC Ed Queue. Applies to: Certificate authority issuing the server certificates; Certificates the CDN edge presents to visitors.
CA/Browser Forum Baseline Requirements for TLS server certificates, version 2.3.1 (CA/Browser Forum)
Publicly trusted TLS server certificates may use RSA or ECDSA keys only; no post-quantum algorithm is permitted in this version.
Industry rules; Version 2.3.1, effective 4 October 2026; read 2026-10-23 at: Section 6.1.5 Key sizes. Applies to: Certificate authority issuing the server certificates; Certificates the CDN edge presents to visitors.

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 (IETF Hackathon pqc-certificates project)
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
IETF PQC Hackathon: ML-DSA-65 private key formats (IETF Hackathon pqc-certificates project)
Result
Failed within the stated scope
Scope
Reading ML-DSA-65 private key files with the OpenSSL parser: seed-format keys from 10 producers were accepted and those from 2 producers, Botan and one other submitter, were rejected; the same 2 failed the seed and expanded-key consistency check.
Algorithms and formats
ML-DSA-65 private keys (seed and expanded-key encodings)
Navigator products whose projects took part
OpenSSL, Botan
Limitations
The results page does not state why the files were rejected; the run logs are linked from the project index. Applies to the submitted artifacts only, not to a product release, and says nothing about certificates or signatures.
Results dated, read on
2026-10-06, 2026-10-23
Locator
Automated verification results, tables ML-DSA-65-seed and ML-DSA-65-consistent: column openssl

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.

By 31 December 2026: 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.
By 31 December 2030: 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.
2024-11-27: Joint statement of national agencies: protect the most sensitive use cases by 2030
Agencies of 18 Member States urged organisations to start the transition now and recommended protecting the most sensitive use cases against store-now-decrypt-later attacks by the end of 2030 at the latest; partners from 21 European states reissued it in June 2025.

What the PQC guide lists for this kind of service

First steps and an initial national PQC roadmap (By 31 December 2026)
High-risk use cases moved to post-quantum cryptography (By 31 December 2030)
Quantum-safe upgrades enabled by default (By 31 December 2030)

National PQC guidance by Member State

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

Action plan of Own organisation
Checkpoint	Action	Component	State	Waits for	Date
Supplier and counterparty statements obtained	Obtain a dated statement on post-quantum support for Load balancer terminating TLS in front of the origin; the product navigator has no record for it.	Load balancer terminating TLS in front of the origin	Waiting for the items listed	CDN edge: TLS towards visitors and towards the origin	Unknown: no date published or agreed
Inventory and scope confirmed	Identify the product and release used for Origin web servers and their TLS library and record it.	Origin web servers and their TLS library	Waiting for the items listed	Load balancer terminating TLS in front of the origin	Unknown: no date published or agreed

Counterparty (the other organisation or its users)

Action plan of Counterparty (the other organisation or its users)
Checkpoint	Action	Component	State	Waits for	Date
Inventory and scope confirmed	Identify the product and release used for Visitors' browsers and devices and record it.	Visitors' browsers and devices	Can start now	Nothing	Unknown: no date published or agreed

Certificate authority or trust service provider

Action plan of Certificate authority or trust service provider
Checkpoint	Action	Component	State	Waits for	Date
Inventory and scope confirmed	Identify the product and release used for HSM holding the certificate authority's signing keys and record it.	HSM holding the certificate authority's signing keys	Can start now	Nothing	Unknown: no date published or agreed
Inventory and scope confirmed	Identify the product and release used for Certificate authority issuing the server certificates and record it.	Certificate authority issuing the server certificates	Waiting for the items listed	HSM holding the certificate authority's signing keys	Unknown: no date published or agreed

Network, CDN or hosting provider

Action plan of Network, CDN or hosting provider
Checkpoint	Action	Component	State	Waits for	Date
Inventory and scope confirmed	Identify the product and release used for CDN edge: TLS towards visitors and towards the origin and record it.	CDN edge: TLS towards visitors and towards the origin	Waiting for the items listed	Visitors' browsers and devices	Unknown: no date published or agreed
Inventory and scope confirmed	Identify the product and release used for Certificates the CDN edge presents to visitors and record it.	Certificates the CDN edge presents to visitors	Waiting for the items listed	Certificate authority issuing the server certificates; Visitors' browsers and devices	Unknown: no date published or agreed

All parties of the service jointly

Action plan of 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	Visitors' browsers and devices; CDN edge: TLS towards visitors and towards the origin; Load balancer terminating TLS in front of the origin; Origin web servers and their TLS library; HSM holding the certificate authority's signing keys; Certificate authority issuing the server certificates; Certificates the CDN edge presents to visitors	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

The exports contain only the service, the releases chosen above and the public evidence. Nothing is stored.

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.