— May 16, 2026 · 11 min read

PQC EDI roadmap 2026-2030: migrating AS2/AS4 without breaks

NIST finalised its three post-quantum cryptography standards in August 2024 (FIPS 203, 204, 205). For EDI leads, the question is no longer whether to migrate, but how to orchestrate the AS2/AS4 transition over 2026-2030 without breaking interoperability with a heterogeneous partner ecosystem. This article provides an operational phased plan.

Global PQC context 2024-2026

Since the NIST standards publication in August 2024, several national authorities have published their own guidance. The NSA Cybersecurity Advisory Quantum-Resistant Cryptography Requirements (CNSA 2.0), September 2022, imposes specific timelines for US national security systems. ANSSI published in April 2024 its Position Paper on Post-Quantum Cryptography, recommending a PQC roadmap for 2030 and favouring the hybrid approach during transition. Germany's BSI and the Netherlands' NLNCSA have published similar recommendations.

On the IETF side, the LAMPS Working Group (Limited Additional Mechanisms for PKIX and S/MIME) is advancing drafts for ML-DSA and ML-KEM integration into X.509 and S/MIME. Several RFCs prepare this integration: RFC 9692 (ML-KEM Hybrid Public Key Encryption, 2024) and the ongoing drafts on hybrid certificates.

Phase 1 — 2026: inventory and sandbox

The first step is the cryptographic inventory. For each EDI component:

• Map signature algorithms used on X.509 certificates (RSA-2048, RSA-3072, ECDSA P-256, ECDSA P-384).
• Map key exchange algorithms (RSA encryption, ECDH P-256, ECDH P-384).
• Identify underlying libraries (OpenSSL, BoringSSL, BouncyCastle, Conscrypt, JSSE) and their versions.
• List partner contracts that mandate a specific algorithm in the EDI/Trading Partner Agreement (TPA).

In parallel, stand up a sandbox environment with a PQ-enabled library: liboqs (Open Quantum Safe project) provides OpenSSL and BoringSSL wrappers integrating ML-KEM and ML-DSA. AWS and Google Cloud are starting to offer PQC-supporting KMS in preview in 2026. The sandbox enables measurement of: added latency, handshake size, application library compatibility.

Phase 2 — 2026-2027: hybrid certificates

The hybrid approach issues certificates containing both a classical public key (RSA/ECDSA) and a PQC public key (ML-DSA), with two signatures on the certificate: one classical, one PQC. IETF drafts specify the necessary X.509 extensions.

Public CAs have been experimenting since 2024: Let's Encrypt announces PQC programmes from 2026, DigiCert and GlobalSign offer pilot hybrid certificates, Entrust and Sectigo start to deliver PQ root certificates for 2027. For PEPPOL CAs, OpenPEPPOL has indicated a PQC roadmap aligned with eDelivery library evolution.

For AS2, deploying a subset of non-critical partners on hybrid certificates in 2027 lets the end-to-end chain be validated. For AS4, the PEPPOL eDelivery profile will have to publish explicitly the supported PQ ciphersuites.

Phase 3 — 2027-2028: production extension

From end-2027, assuming libraries have consolidated support:

• Extend hybrid to all AS2 / AS4 partners with a dual-track onboarding workflow (classical OR hybrid accepted).
• Industrialise shorter-duration renewals (1 year instead of 2-3) during the ecosystem stabilisation phase.
• Test PQ XAdES signature for electronic invoices (UBL, PEPPOL BIS Billing), in collaboration with national tax authorities.

Phase 4 — 2028-2030: gradual PQ-only

This phase assumes that root CAs have all published their PQ-pure certificates and that the main EDI software (IBM Sterling B2B Integrator, OpenText BizManager, Cleo Harmony, Axway, Mendelson, Drummond-certified products) has consolidated native support. The PQ-only switch happens partner by partner according to:

• Business criticality (volume, transactional value).
• Library maturity on the other side.
• Contractual constraints (TPA mentioning an algo).

The 2030 schedule remains indicative: the main uncertainty stems from the evolution of national positions (ANSSI, NSA CNSA 2.0, BSI) and the emergence of a CRQC (Cryptographically Relevant Quantum Computer). Serious estimates place CRQC emergence at 10-20 years, but the "harvest now, decrypt later" principle makes the transition prudent, not wait-and-see.

Cryptographic agility: the key investment

More important than choosing the right algorithm at moment T is structuring the code to allow algorithm change without heavy rewrite. The crypto-agility principle includes:

• Interface/implementation separation: never a direct call to RSA-2048 in application code, always a SignaturePolicy interface.
• External configuration: the active algorithm is driven by configuration, not by deployment.
• Multi-algorithm tests: the CI test suite covers RSA, ECDSA, ML-DSA, SLH-DSA in parallel.
• Per-algorithm metrics: dashboard of algorithm usage by partner, to monitor the transition.

Vendor-side impact

Major EDI vendors have started to publish their PQC roadmaps:

• IBM Sterling B2B Integrator: PQC support announced for 2027+ versions.
• OpenText BizManager: PQC roadmap aligned OpenSSL 4.x.
• Axway B2B Integration: hybrid support under evaluation for 2027.
• Cleo Harmony: planned with OpenSSL 4.0.
• Drummond Group operates the Drummond Certified AS2 certification programme and is working on a PQ test profile for 2027.

Conclusion: a decade-long transition

The PQC EDI transition will span the decade 2026-2030 (or even 2035 for the slowest partners). The stake is not purely technical — NIST standards exist, libraries mature — but infrastructural and coordinative: a large-scale transition must be steered in a distributed ecosystem of thousands of enterprises and dozens of CAs. Vendors and integrators that lay their crypto-agility foundations in 2026 will pay the lowest transition cost.

For further reading, see the detailed PQC EDI 2026 roadmap, the EDI security 2026 foundation and the article Modern AS2, AS4, OFTP2.