Do You Need AS4 if AS2 Already Works?

No, not universally. AS2 remains perfectly valid for most point-to-point trading partner connections, and nothing forces you to replace a working setup. But AS4 becomes unavoidable the moment a partner, network, or regulator requires it specifically, and two of those triggers are already live: Peppol's access point network and the EU's ICS2 customs system. If neither applies to you yet, keep your AS2 stack. If either does, you're not choosing anymore.

What does AS4 actually do differently from AS2?

AS4 replaces AS2's email-style MIME packaging with a SOAP/web-services envelope and adds a pull option so receivers don't need a permanently open listener. The two protocols solve the same problem (secure, non-repudiated B2B document exchange) but come from different standards families and handle connection management differently.

AS2 belongs to the older IETF EDIINT lineage, while AS4 grew out of the OASIS ebXML/ebMS web services stack, which is why AS4 messages carry SOAP headers and metadata that AS2 never had. That architecture difference has a practical consequence for how each side of the connection behaves. With AS2, AS2 requires security procedures on both sides to isolate AS2 access: authentication, firewall, DMZ, etc., and unlike AS4, which operates on a push/pull basis, it requires a permanent connection from the EDI message recipient. That push/pull option is the detail most comparison articles bury: it means a receiver can poll for messages on its own schedule instead of running an always-on endpoint, which matters a lot once you're dealing with hundreds of partners instead of a dozen. This is also exactly the kind of protocol-layer complexity that connectivity platforms exist to absorb. Carrier and freight integration tools like Cargoson, alongside platforms such as MercuryGate, Descartes, and Transporeon, are increasingly built to manage AS2 and AS4 endpoints behind the scenes so an EDI team isn't maintaining separate certificate stores and connection logic per carrier.

Is AS4 actually mandatory anywhere today?

Yes, in two places that matter to almost any company trading in Europe: Peppol and EU customs filing under ICS2. Both have already passed their mandate dates, not just announced them.

Since 2020-02-01 AS4 is the mandatory transport protocol in the Peppol eDelivery network, which means any Access Point handling e-invoicing or procurement documents through Peppol has had to support AS4 for years now, regardless of what it ran before. On the customs side, the EU's ICS2 system for pre-arrival cargo filings doesn't give you a REST option at all: the EU ICS2 system does not use REST for direct integration, and ICS2 uses the AS4 messaging standard, which is based on the ebMS 3.0 protocol. And the legacy path is gone now too. ICS2 version 3 became mandatory across all transport modes on the 3rd of February 2026, and any operator still using version 2 messaging formats after the 3rd of February, or the 1st of June in applicable countries, will have their filings rejected by the ICS2 Common Repository. If you file Entry Summary Declarations for goods moving into the EU by sea, road, rail, or air, you're on AS4 whether you planned for it or not.

Does moving to AS4 mean retiring AS2?

No. AS4 was built to coexist with AS2, not replace it overnight, and most EDI teams end up running both stacks in parallel rather than migrating every partner at once.

Tenor's own description of the protocol makes this explicit: it is a superset of AS2, i.e. it can address both AS2 and AS4 partners. In practice that means you add an AS4 endpoint where a partner or network requires it, and leave your existing AS2 connections untouched everywhere else. Industry coverage of the healthcare and medical device space describes the same pattern: AS2 remains the required protocol for major retail programs and FDA ESG submissions, while AS4 is mandated in EU frameworks like EUDAMED, Peppol and eDelivery, and most organizations will run both for years, which is why hybrid gateways matter more than a wholesale switch. That's the realistic target state for most mid-size shippers: dual-protocol capability, not a cutover project.

What does an AS2-to-AS4 migration actually involve?

It's a certificate and partner-testing exercise, not a configuration flag. Expect PKI setup for WS-Security, partner-by-partner conformance testing, and, if you're joining Peppol or filing ICS2, formal registration or self-conformance testing before anything goes live.

• Set up WS-Security certificates and key management for message-level signing and encryption, separate from whatever S/MIME certs you already run for AS2.
• Test each trading partner connection individually rather than flipping a global switch, since upgrading an EDI environment to the AS4 protocol requires careful planning around security, compliance, partner onboarding, and message reliability.
• Register for SMP/SML discovery if you're onboarding onto Peppol, since AS4 access points there need to be locatable through the network's own directory layer.
• Complete conformance testing before any regulatory filing is recognized. For ICS2, that means working through an IT Service Provider model, where an ITSP is any party that delivers IT Services to a declarant or representative by operating an AS4 access point as a Sender, identified by EORI and digital certificate before it's authorized to exchange messages.

Which trading partners or regions will push you toward AS4 first?

EU-based partners on Peppol, anyone filing EU customs declarations, and large enterprises consolidating high-volume document exchange onto fewer, bigger connections. The common thread is volume and regulation, not a general preference for newer technology.

Peppol's e-invoicing reach and ICS2's customs scope already cover a lot of ground, but there's also a throughput argument pulling large shippers toward AS4 on its own merits. As one comparison of the two protocols puts it, AS4 is ideal for bulk loading of high-volume integration scenarios, where throughput and elasticity are paramount to the success of these implementations, and it simplifies the configuration, security, and routing of messages by providing a single, standards-compliant way to manage a large number of trading partners in one location. If you're managing a long tail of EU suppliers or filing customs declarations across multiple member states, this is less a technology upgrade than a compliance deadline with a protocol attached.

Should you start testing AS4 now or wait for a mandate?

Start now if you have any EU trading partners, any Peppol exposure, or any customs filing obligation. Certificate issuance and conformance testing take lead time, and ICS2's version 2 shutdown already proved how little warning a hard cutover gives you in practice.

A practical checklist before you build anything: identify which specific partners, networks, or regulations actually require AS4 for you (not the industry in general), confirm whether your existing EDI platform or VAN already supports it out of the box, and run AS2 and AS4 in parallel for a defined test period with a handful of partners before you commit wider resources. Most teams don't need to rebuild their entire B2B stack. They need one well-tested AS4 endpoint for the partners and networks that actually demand it, sitting alongside the AS2 setup that's still doing its job everywhere else.