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

Qualified electronic signatures and seals with a qualified trust service provider

Illustrative template An organisation signs documents with qualified certificates from a qualified trust service provider, whose keys sit in a qualified signature creation device; recipients validate the signatures with their own software against the EU trusted lists.

Parties involved: Own organisation, Counterparty (the other organisation or its users), Certificate authority or trust service provider, Standards body or supervisor (outside the plan)

Limitations: A generic template. ETSI TS 119 312 lists post-quantum signature suites, but leaves migration dates to a document still being prepared; no date for qualified trust services is recorded 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
Qualified signature creation device or remote signing HSM
HSM key storage and operations
Certificate authority or trust service providerNot chosen No product release chosenNothingNothingDevice certification is a separate question that this page does not assess.
Profiles and migration rules for qualified services
Certificate signatures
Standards body or supervisor (outside the plan)Not chosen No agreement recorded between the partiesNothingNothingSet by standards bodies and supervisors, not by the parties of this plan.
Qualified trust service provider's certificate authority
PKI / CA certificate issuance
Certificate authority or trust service providerNot chosen No product release chosenQualified signature creation device or remote signing HSM; Profiles and migration rules for qualified servicesQualified signature creation device or remote signing HSM; Profiles and migration rules for qualified servicesIssues the qualified certificates.
Signing application of the organisation
Algorithms in the cryptographic API
Own organisationNot chosen No product release chosenQualified trust service provider's certificate authorityQualified trust service provider's certificate authority; Qualified signature creation device or remote signing HSM; Profiles and migration rules for qualified servicesCreates the signed documents.
Recipients' signature validation software
Algorithms in the cryptographic API
Counterparty (the other organisation or its users)Not chosen No product release chosenQualified trust service provider's certificate authorityQualified trust service provider's certificate authority; Qualified signature creation device or remote signing HSM; Profiles and migration rules for qualified servicesRecipients must validate the new signatures, or hybrid signatures keep a classical one they can check.

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

  • Qualified signature creation device or remote signing HSM: blocks 3 other components
  • Profiles and migration rules for qualified services: blocks 3 other components
  • Qualified trust service provider's certificate authority: blocks 2 other components

Can start in parallel (no dependencies)

Qualified signature creation device or remote signing HSM; Profiles and migration rules for qualified services

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.

  • ETSI TS 119 312 V2.1.1: Electronic Signatures and Trust Infrastructures (ESI); Cryptographic Suites (ETSI)
    Lists ML-DSA and SLH-DSA as recommended for signatures and seals, LMS and XMSS only where signing state can be strictly managed, and recommends hybrid use of ML-DSA; it leaves migration dates to a separate document still being prepared.
    Published standard or specification; Technical Specification, version 2.1.1 of June 2026; read 2026-10-23 at: Clause 6.2.2.5 (ML-DSA), 6.2.2.6 (SLH-DSA), 6.2.2.7 (LMS and XMSS), 6.4 (hybrid schemes) and 8.5 (migration). Applies to: Qualified signature creation device or remote signing HSM; Qualified trust service provider's certificate authority; Profiles and migration rules for qualified services; Signing application of the organisation; Recipients' signature validation software.
  • 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: Qualified trust service provider's certificate authority.
  • RFC 9882: Use of the ML-DSA Signature Algorithm in the Cryptographic Message Syntax (CMS) (IETF (RFC Editor))
    Sets the conventions for ML-DSA signatures in CMS, the container used by many code, document and e-mail signatures.
    IETF RFC; Proposed Standard, published 2025; read 2026-10-23 at: RFC information page: title, status Proposed Standard, authors. Applies to: Signing application of the organisation; Recipients' signature validation software.

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.

  • : 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.
  • : EU roadmap milestone 3: medium-risk use cases migrated
    By the end of 2035 the transition of medium-risk use cases should be completed, and that of low-risk use cases as far as feasible.

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 Signing application of the organisation and record it.Signing application of the organisationWaiting for the items listedQualified trust service provider's certificate authorityUnknown: 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 Recipients' signature validation software and record it.Recipients' signature validation softwareWaiting for the items listedQualified trust service provider's certificate authorityUnknown: 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 Qualified signature creation device or remote signing HSM and record it.Qualified signature creation device or remote signing HSMCan start nowNothingUnknown: no date published or agreed
Inventory and scope confirmedIdentify the product and release used for Qualified trust service provider's certificate authority and record it.Qualified trust service provider's certificate authorityWaiting for the items listedQualified signature creation device or remote signing HSM; Profiles and migration rules for qualified servicesUnknown: no date published or agreed

All parties of the service jointly

Action plan of All parties of the service jointly
CheckpointActionComponentStateWaits forDate
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 listedQualified signature creation device or remote signing HSM; Profiles and migration rules for qualified services; Qualified trust service provider's certificate authority; Signing application of the organisation; Recipients' signature validation softwareUnknown: 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

Standards body or supervisor (outside the plan)

Action plan of Standards body or supervisor (outside the plan)
CheckpointActionComponentStateWaits forDate
Compatible configuration agreedAgree Profiles and migration rules for qualified services between the parties concerned and record who agreed and when.Profiles and migration rules for qualified servicesCan start nowNothingUnknown: 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.