Skip to main content

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

Site-to-site IPsec VPN (IKEv2) between two organisations

Illustrative template Two organisations connect their networks with an IKEv2 tunnel between one gateway each, authenticated with certificates, over a transit network run by a provider. Neither organisation can migrate the tunnel alone.

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

Limitations: A generic template. The post-quantum key exchange for IKEv2 is a draft on the date read; the multiple-key-exchange and intermediate-exchange RFCs it builds on are published. Post-quantum authentication of the gateways is not assessed here.

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.

Components of the service, their readiness and dependencies
ComponentControlled byChosen releaseReadinessDepends onBlocked byEvidence and note
Own VPN gateway
VPN / IPsec key exchange
Own organisationNot chosen No product release chosenNothingNothingCan be upgraded in parallel with the partner's gateway.
Partner organisation's VPN gateway
VPN / IPsec key exchange
Counterparty (the other organisation or its users)Not chosen No product release chosenNothingNothingUpgraded on the partner's own timetable.
Transit network between the two sites
No cryptographic function of its own
Network, CDN or hosting providerNot chosen Not covered by the product navigatorNothingNothingCarries larger IKE messages; check that fragmented IKE exchanges pass.
Agreed IKEv2 proposal between the two gateways
VPN / IPsec key exchange
All parties of the service jointlyNot chosen No agreement recorded between the partiesOwn VPN gateway; Partner organisation's VPN gateway; Transit network between the two sitesOwn VPN gateway; Partner organisation's VPN gateway; Transit network between the two sitesBoth parties must agree the same additional key exchange and parameters.
Certificates authenticating the gateways
PKI / CA certificate issuance
Certificate authority or trust service providerNot chosen No product release chosenNothingNothingAuthentication can stay classical while key exchange migrates first.

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

  • Own VPN gateway: blocks 1 other components
  • Partner organisation's VPN gateway: blocks 1 other components
  • Transit network between the two sites: blocks 1 other components

Can start in parallel (no dependencies)

Own VPN gateway; Partner organisation's VPN gateway; Transit network between the two sites; Certificates authenticating the gateways

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 9370: Multiple Key Exchanges in the Internet Key Exchange Protocol Version 2 (IKEv2) (IETF (RFC Editor))
    Lets two IKEv2 peers run several key exchanges, so a post-quantum one can be added to a classical one; both gateways must support it.
    IETF RFC; Proposed Standard, published 2023; read 2026-10-23 at: RFC information page: title, status Proposed Standard. Applies to: Own VPN gateway; Partner organisation's VPN gateway; Agreed IKEv2 proposal between the two gateways.
  • RFC 9242: Intermediate Exchange in the Internet Key Exchange Protocol Version 2 (IKEv2) (IETF (RFC Editor))
    Adds exchanges between the first IKEv2 exchange and authentication so that large post-quantum keys can be sent with IKE fragmentation instead of IP fragmentation.
    IETF RFC; Proposed Standard, published 2022; read 2026-10-23 at: Section 1, Introduction, on IKE fragmentation and large key exchange payloads. Applies to: Own VPN gateway; Partner organisation's VPN gateway; Transit network between the two sites.
  • Post-quantum Hybrid Key Exchange with ML-KEM in IKEv2 (draft-ietf-ipsecme-ikev2-mlkem) (IETF Datatracker)
    Describes ML-KEM in IKEv2 alone or as an additional key exchange. Still a draft on the date read.
    IETF Internet-Draft (work in progress, not a standard); Internet-Draft, revision 09 of 5 July 2026, in the RFC Editor queue, intended Proposed Standard; not yet an RFC; read 2026-10-23 at: Document page: latest revision, intended status, IESG state RFC Ed Queue. Applies to: Own VPN gateway; Partner organisation's VPN gateway; Agreed IKEv2 proposal between the two gateways.
  • 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: Certificates authenticating the gateways.

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.

No interoperability evidence recorded for this service.

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.
  • : 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

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
CheckpointActionComponentStateWaits forDate
Inventory and scope confirmedIdentify the product and release used for Own VPN gateway and record it.Own VPN gatewayCan start nowNothingUnknown: no date published or agreed

Counterparty (the other organisation or its users)

Action plan of Counterparty (the other organisation or its users)
CheckpointActionComponentStateWaits forDate
Inventory and scope confirmedIdentify the product and release used for Partner organisation's VPN gateway and record it.Partner organisation's VPN gatewayCan start nowNothingUnknown: no date published or agreed

Certificate authority or trust service provider

Action plan of Certificate authority or trust service provider
CheckpointActionComponentStateWaits forDate
Inventory and scope confirmedIdentify the product and release used for Certificates authenticating the gateways and record it.Certificates authenticating the gatewaysCan start nowNothingUnknown: no date published or agreed

Network, CDN or hosting provider

Action plan of Network, CDN or hosting provider
CheckpointActionComponentStateWaits forDate
Compatible configuration agreedConfirm with the provider of Transit network between the two sites that the larger key exchange messages and their fragments pass.Transit network between the two sitesCan start nowNothingUnknown: no date published or agreed

All parties of the service jointly

Action plan of All parties of the service jointly
CheckpointActionComponentStateWaits forDate
Compatible configuration agreedAgree Agreed IKEv2 proposal between the two gateways between the parties concerned and record who agreed and when.Agreed IKEv2 proposal between the two gatewaysWaiting for the items listedOwn VPN gateway; Partner organisation's VPN gateway; Transit network between the two sitesUnknown: no date published or agreed
Interoperability testRun a joint interoperability test of the whole chain in a test environment and record its scope and result.Whole serviceWaiting for the items listedOwn VPN gateway; Partner organisation's VPN gateway; Transit network between the two sites; Agreed IKEv2 proposal between the two gateways; Certificates authenticating the gatewaysUnknown: no date published or agreed
PilotPilot the service with a limited group, keeping the classical fallback.Whole serviceWaiting for the items listedInteroperability testUnknown: no date published or agreed
Staged rolloutRoll out in stages agreed by every party.Whole serviceWaiting for the items listedPilotUnknown: no date published or agreed
ValidationValidate that the post-quantum mechanisms are actually negotiated or verified on every hop.Whole serviceWaiting for the items listedStaged rolloutUnknown: no date published or agreed
Retirement of the legacy fallback, when authorisedRetire the classical-only fallback only when every party has authorised it.Whole serviceWaiting for the items listedValidationUnknown: 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.