Two Protocols, One Question

If you have been running AS2 for years and someone on your team (or a European trading partner) mentions AS4, you probably have the same question everyone asks: should we switch?

The short answer is: probably not yet, if you are in the US doing retail or pharmaceutical EDI. But AS4 is not vaporware, and it is not irrelevant. It is a real protocol solving real problems that AS2 handles poorly. Whether those problems are your problems depends on your trading partners, your geography, and your use case.

This is a technical comparison. No hand-waving. We will look at what each protocol actually does, where each one wins, and what switching would cost you.

What AS2 Actually Is

AS2 (Applicability Statement 2) was published as RFC 4130 in 2005, building on work that started in the late 1990s. It defines a method for transporting structured data (typically EDI documents) over HTTP/HTTPS using S/MIME for encryption and digital signatures.

The core architecture is simple:

Sender wraps the payload in an S/MIME envelope (encrypted, signed, or both)
Sender POSTs the envelope to the receiver's HTTP endpoint
Receiver processes the message and returns a Message Disposition Notification (MDN) confirming receipt
The MDN can be synchronous (returned in the HTTP response) or asynchronous (sent to a separate URL)

That is it. No message broker. No intermediary. Point-to-point. The sender knows the receiver's URL, has the receiver's public certificate, and pushes data directly.

AS2 strengths:

Simplicity: one HTTP POST, one MDN response. Easy to debug, easy to monitor.
Non-repudiation: signed MDNs provide legal-grade proof of delivery
Encryption at the message level: even if TLS is somehow compromised, the payload remains encrypted with S/MIME
Massive installed base: Walmart mandated AS2 for all suppliers in 2002. That single decision created the largest AS2 network in the world and drove adoption across US retail and manufacturing.

What AS4 Actually Is

AS4 is a profile of the ebMS 3.0 (ebXML Messaging Service) specification, published by OASIS. It was designed to address limitations in AS2 that became apparent as B2B messaging requirements evolved.

The architecture is fundamentally different from AS2:

Messages are SOAP/XML envelopes transmitted over HTTP/HTTPS
Payloads are attached as MIME parts to the SOAP message
Security uses WS-Security (XML Signature and XML Encryption) instead of S/MIME
Message exchange patterns include both push and pull modes
Multi-hop routing is supported through intermediary nodes (MSH: Message Service Handlers)

AS4 was designed as a web services protocol from the ground up. If AS2 is "send a secure package via courier," AS4 is "route a secure package through a postal network with tracking, forwarding, and multiple delivery options."

Key Technical Differences

Message Format

AS2 uses S/MIME (Secure/Multipurpose Internet Mail Extensions). The payload is wrapped in a MIME structure, encrypted with the recipient's public key (typically using AES), and signed with the sender's private key (typically using RSA with SHA-256). The result is a binary blob that gets POSTed over HTTP.

AS4 uses SOAP with WS-Security. The payload is attached to a SOAP XML envelope. Encryption uses XML Encryption (xenc), and signatures use XML Digital Signature (xmldsig). The message metadata (routing, reliability, security parameters) is expressed in SOAP headers.

Practical implication: AS2 messages are smaller and faster to process. S/MIME is a mature, well-optimized format. SOAP/XML adds overhead, both in message size and in parsing complexity. For high-volume EDI (thousands of documents per hour), this difference is measurable.

Push vs. Pull

AS2 is push-only. The sender initiates the connection and delivers the message. The receiver must have a publicly accessible HTTP endpoint. This works well when both parties have static infrastructure, but it creates challenges for organizations behind strict firewalls or without the ability to expose an inbound endpoint.

AS4 supports both push and pull. In pull mode, the receiver initiates the connection and checks for waiting messages, similar to how email clients check a mailbox. This is significant for smaller organizations that cannot or will not open inbound firewall ports. They can poll for messages on their own schedule.

Practical implication: if your trading partner cannot expose an HTTP endpoint (common in highly regulated environments or small organizations with minimal IT infrastructure), AS4 pull mode solves a real problem that AS2 cannot solve without workarounds like VAN intermediaries.

Multi-Hop Routing

AS2 is strictly point-to-point. Sender to receiver. If you need an intermediary (for protocol translation, compliance logging, or network segmentation), you build it outside the AS2 protocol. Value-Added Networks (VANs) serve this role, but they are not part of the AS2 specification.

AS4 has native support for intermediary MSH nodes. A message can traverse multiple hops: sender to intermediary to intermediary to receiver. Each hop maintains the security context. This is built into the protocol, not bolted on.

Practical implication: multi-hop is valuable in complex supply chains where a central hub routes messages between many parties. The Peppol network in Europe uses AS4 for exactly this reason: a four-corner model where access points route messages between buyers and suppliers through a central directory.

Reliability and Error Handling

AS2 reliability is binary: you get an MDN or you do not. If the connection fails mid-transfer, you retry the entire message. There is no partial delivery, no message fragmentation, no built-in retry policy. Error information in the MDN is minimal: processed/failed with a short disposition string.

AS4 includes WS-ReliableMessaging concepts. Messages can be acknowledged at a more granular level. Error reporting is richer, with structured SOAP faults that include error codes, severity levels, and descriptive text. Duplicate detection is built into the protocol via message IDs and sequence numbers.

Practical implication: for large file transfers or unreliable network connections, AS4's reliability features reduce the likelihood of silent failures. For typical EDI document sizes (a few KB to a few MB), AS2's simpler retry model works fine.

Security Model

AS2 uses S/MIME, which encrypts and signs the entire payload as a single unit. Certificate management is straightforward: each partner has a key pair, you exchange public certificates, done.

AS4 uses WS-Security, which allows selective encryption and signing of individual XML elements. You can encrypt the payload but leave routing headers readable by intermediaries. You can sign specific parts of the message independently.

Practical implication: AS4's granular security model is more flexible but more complex to configure correctly. Misconfigured WS-Security policies are a common source of interoperability failures in AS4 deployments. AS2's "encrypt everything, sign everything" approach is simpler and harder to get wrong.

Where AS2 Dominates

AS2 is the standard protocol for B2B data exchange in several major sectors:

US Retail. Walmart's 2002 AS2 mandate set the template. Target, Amazon, Kroger, Home Depot, and hundreds of other retailers followed. If you are a supplier to US retail, you run AS2. This is not a technology choice; it is a trading partner requirement.

US Pharmaceutical. DSCSA compliance requires secure, auditable data exchange. The pharmaceutical supply chain standardized on AS2 for transaction data, EPCIS events, and verification communications. Thousands of manufacturer-to-wholesaler and wholesaler-to-dispenser connections run on AS2.

US Manufacturing and Distribution. Purchase orders, invoices, advance ship notices, and other EDI documents flow over AS2 between manufacturers, distributors, and logistics providers. The infrastructure is built, tested, and operational.

The installed base is AS2's greatest asset. Switching protocols requires both sides to agree, invest, test, and cut over. When your largest customer runs AS2 and has no plans to change, your protocol decision is made for you.

Where AS4 Is Growing

European e-Procurement (Peppol). The Pan-European Public Procurement Online (Peppol) network uses AS4 as its transport protocol. Peppol connects government agencies and businesses across Europe for electronic invoicing and procurement. If you do business with European government entities, you will encounter AS4 through Peppol access points.

European Energy (ENTSOG/ENTSO-E). European energy market operators use AS4 for data exchange between transmission system operators, distribution system operators, and market participants. The AS4 usage profile for energy is well-defined and widely implemented.

Australian Government (Digital Business Council). Australia adopted AS4 for government-to-business data exchange, following the Peppol model.

Cross-Border Trade. AS4's multi-hop routing makes it suitable for trade networks that span multiple countries and regulatory jurisdictions. The intermediary model maps well to customs brokers, trade facilitation platforms, and multi-party logistics networks.

The pattern is clear: AS4 adoption is strongest in environments where a central authority (government, regulatory body, industry consortium) can mandate a new protocol and where multi-hop routing provides clear value.

Migration: What Switching Would Actually Cost

If you are considering a move from AS2 to AS4, here is what is involved:

Software

Your current AS2 software (OpenAS2, mendelson, IBM Sterling, Cleo) may or may not support AS4. Some platforms support both protocols. Others require a separate AS4 gateway. Budget for software licensing, installation, and configuration.

Notable AS4-capable platforms: Holodeck B2B (open source), IBM Sterling B2B Integrator, Cleo Integration Cloud, Axway Gateway, and various Peppol-certified access points.

Certificate and Security Infrastructure

AS2 uses X.509 certificates with S/MIME. AS4 uses X.509 certificates with WS-Security. The certificates themselves may be reusable, but the security configuration is entirely different. Your team needs to understand WS-Security policies, SOAP header security, and XML encryption/signature. This is a different skill set than S/MIME configuration.

Trading Partner Coordination

This is the real cost. Every trading partner running AS2 would need to either switch to AS4 or you would need to maintain both protocols in parallel. For a company with 200 AS2 trading partners, migrating all of them to AS4 is a multi-year project. Running dual protocols doubles your operational complexity.

Testing

Every connection must be tested end-to-end after migration. Message encryption, signing, delivery, acknowledgment, error handling. Multiply your current test effort by 1.5x to 2x because AS4's richer feature set means more configuration parameters to validate.

Staff Training

Your operations team knows AS2. They know how to read S/MIME headers, troubleshoot MDN failures, and manage certificate rotations. AS4 introduces SOAP, WS-Security, ebMS concepts, and (potentially) multi-hop routing. Training takes time, and production incidents during the learning curve are expensive.

Should You Switch?

Here is a decision framework:

Stay with AS2 if:

Your trading partners require AS2 (US retail, US pharma)
Your connections are point-to-point with no need for intermediary routing
Your current infrastructure works and meets security standards
You have no European or government trading partners requiring AS4

Add AS4 if:

You need to connect to the Peppol network for European e-invoicing
Trading partners in Europe or Australia require AS4
You need pull-mode messaging for partners who cannot expose inbound endpoints
You are building a hub-and-spoke network where multi-hop routing simplifies architecture

Run both if:

You have trading partners on both protocols (this is increasingly common for companies with both US and EU operations)
You are migrating gradually and need to maintain AS2 connections during the transition

For most US-based companies doing domestic B2B, AS2 remains the correct choice. The protocol is mature, well-supported, and required by the trading partners that matter most. AS4 is the better protocol on paper (richer features, better error handling, more flexible routing), but protocol decisions are not made on paper. They are made by the trading partner who sends you a connectivity requirements document that says "AS2, port 443, here is our certificate."

Keep Your AS2 Infrastructure Solid

Whether you stay on AS2 indefinitely or plan to add AS4 in the future, your AS2 connections need to be healthy today. Expired certificates, outdated encryption, and broken MDN configurations do not fix themselves.

AS2 Certify validates your AS2 connections against current standards. It tests TLS configuration, certificate validity, encryption algorithms, signing algorithms, and MDN exchange, then produces a graded report showing what passes and what needs attention. If you are maintaining AS2 connections (and you are, if you are reading this), regular validation catches problems before your trading partners or your customers find them.

AS4 may be the future for some use cases. AS2 is the present for most. Make sure your present is working correctly.