AS2 Protocol: How Secure B2B Document Exchange Works

AS2 (Applicability Statement 2) is a protocol for sending business documents securely over the internet. It packages a payload—often an EDI document, XML file, CSV, JSON or PDF—in a signed and optionally encrypted S/MIME message, sends it over HTTP or HTTPS, and can request a Message Disposition Notification (MDN) from the receiving system.

That combination is what distinguishes AS2 from a basic file upload. The sender can protect the document itself, identify the signing party and retain a protocol receipt linked to the exact message transmitted. Retailers, manufacturers, logistics operators and other trading partners use AS2 when they need a direct, automated and auditable B2B exchange.

How an AS2 exchange works

A successful outbound exchange normally follows seven stages:

1. The source application creates a business document, such as an X12 850 purchase order, EDIFACT INVOIC or XML order.
2. The AS2 sender assigns a unique Message-ID and adds protocol headers including AS2-From and AS2-To.
3. The sender signs the payload with its private key if signing is required.
4. It encrypts the signed package with the recipient’s public certificate if encryption is required.
5. The AS2 message is transmitted to the partner’s endpoint over HTTP or HTTPS.
6. The recipient validates the headers, decrypts the package, verifies the signature and processes the MIME structure.
7. The recipient returns an MDN synchronously in the same HTTP session or asynchronously through a separate connection.

The MDN disposition tells the sender whether the AS2 package was processed or whether an error occurred. When the MDN is signed and its Message Integrity Check (MIC) matches the original message, it provides strong evidence that the corresponding package arrived intact.

AS2 protects the message, not only the connection

HTTPS encrypts the network session between two endpoints. AS2 can also protect the message itself through S/MIME. These layers are related but not interchangeable.

Control	What it protects	Typical evidence
HTTPS/TLS	The network session	TLS handshake and server certificate logs
AS2 encryption	Confidentiality of the packaged payload	Successful decryption by the intended private key
AS2 digital signature	Integrity and origin of the message	Signature validation against the sender’s certificate
Signed MDN	Integrity of the protocol receipt	MDN signature and matching MIC

Some partners require HTTPS, AS2 signing, AS2 encryption and a signed MDN together. Others use a different combination. The correct configuration is the one agreed for that partner profile; enabling stronger algorithms on only one side will make the exchange fail.

The AS2 message format

An AS2 message is an HTTP request containing headers and a MIME body. The business document does not need an .as2 file extension. AS2 is the transport envelope around the payload, not the business format inside it.

Common elements include:

• AS2-From: the sender’s agreed AS2 identifier.
• AS2-To: the recipient’s agreed AS2 identifier.
• Message-ID: a unique identifier used for correlation and duplicate detection.
• Content-Type: describes the MIME entity, which may be signed, encrypted or compressed.
• Disposition-Notification-To: requests an MDN.
• Disposition-Notification-Options: states requirements such as a signed receipt and acceptable MIC algorithms.
• MIME content: the EDI or other business payload, plus signature or encryption structures when configured.

Header values can be case-sensitive in partner implementations and quoted AS2 IDs must be reproduced exactly. Seemingly minor differences—a space, an unexpected quote or a test ID used in production—can cause an otherwise healthy HTTPS request to be rejected.

For a field-by-field implementation reference, use the AS2 connection parameters guide.

Certificates, signing and encryption

Each organization normally holds a private key and shares the corresponding public certificate. The private key must remain under the owner’s control.

When Company A sends to Company B:

• Company A signs with A’s private key; Company B verifies with A’s public certificate.
• Company A encrypts for B using B’s public certificate; Company B decrypts with B’s private key.

The signing and encryption certificates may be the same certificate or separate certificates, depending on platform and partner policy. Certificate trust, format, fingerprint and expiry must be managed explicitly. A certificate can be cryptographically valid yet still fail because the receiving partner loaded a different copy or associated it with the wrong AS2 profile.

Read AS2 certificates explained for certificate exchange, formats and rotation practices.

Synchronous and asynchronous MDNs

A synchronous MDN is returned in the HTTP response to the original AS2 POST. It is simpler operationally because message and receipt share one session, but the sender must wait while the recipient processes the package.

An asynchronous MDN is delivered later to a return endpoint. It separates receipt processing from the initial POST and may suit slower workflows, but it adds a second inbound route, certificate and firewall considerations, and another correlation path.

Neither mode changes what an MDN means. An MDN confirms protocol-level handling; it does not prove that an ERP accepted the invoice or that an EDI translator accepted every segment. That later outcome may be communicated by an X12 997 or 999, an EDIFACT CONTRL, or an application-specific response. See AS2 MDN versus EDI acknowledgments for the complete evidence chain.

Which port does AS2 use?

AS2 has no mandatory universal port. Most modern deployments expose an HTTPS endpoint on port 443. A partner may publish another port, and HTTP deployments may use port 80 or a custom value. The endpoint URL—including scheme, host, path and any non-default port—must be exchanged exactly.

A successful TCP or TLS test proves only that the endpoint can be reached. It does not validate AS2 IDs, certificates, algorithms, MDN settings or payload handling. A complete go-live test must cover the whole protocol exchange.

AS2 compared with SFTP, APIs and VANs

Option	Exchange pattern	Native protocol receipt	Typical use
AS2	Direct message push to a partner endpoint	MDN	Governed EDI and partner-mandated B2B exchange
SFTP	Upload or download from folders	No AS2 MDN; confirmation is designed separately	Batch file movement and shared-folder workflows
API	Application request/response	API-specific response	Real-time application integration
VAN	Documents routed through a network provider	Provider-specific tracking	Multi-partner EDI services and managed routing

These options can coexist. An ERP may deliver a file to an AS2 gateway through an API or SFTP, while the gateway performs the external AS2 exchange. The protocol boundary should be chosen deliberately so that internal applications do not need to implement partner-specific certificates and MDN behavior.

Use the detailed AS2 vs SFTP comparison for secure file-transfer architecture and AS2 vs VAN when deciding between a direct protocol relationship and a network intermediary.

What two trading partners must exchange

Before testing, both parties should confirm:

• test and production endpoint URLs;
• test and production AS2 IDs;
• public certificates and independently verified fingerprints;
• signing, encryption and MIC algorithms;
• whether payload compression is used;
• synchronous or asynchronous MDN mode;
• whether the MDN must be signed;
• content type, filename convention and expected EDI document types;
• retry, duplicate-message and timeout behavior;
• technical contacts and go-live acceptance criteria.

Keep these values in a controlled partner profile rather than copying them from old email threads. The AS2 onboarding checklist provides a reusable collection process.

Common AS2 failures

Most failures fall into a small number of layers:

• Network: DNS, firewall, TLS or endpoint path failure.
• Identity: incorrect AS2-From or AS2-To value.
• Cryptography: unknown signing certificate, wrong decryption key, unsupported algorithm or expired certificate.
• Packaging: invalid MIME boundaries, content type, compression or signature structure.
• Receipt: missing, unsigned, invalid or unmatched MDN.
• Business processing: the AS2 exchange succeeds but the EDI or ERP workflow rejects the document.

Diagnose them in that order and retain raw HTTP headers, Message-ID, timestamps, certificate fingerprints, disposition text and MIC values. An HTTP 200 by itself is not enough to declare the document delivered.

When those records support a governed process, the AS2 EDI compliance guide maps protocol evidence to access, retention, change and audit controls.

AS2 implementation checklist

1. Create separate test and production partner profiles.
2. Exchange and verify parameters through trusted channels.
3. Send a small representative payload with signing, encryption and the required MDN mode.
4. Match the MDN to the original Message-ID and verify its signature and MIC.
5. Test negative cases, duplicates, retries and timeouts.
6. Confirm the downstream business acknowledgment where one is required.
7. Monitor certificates, missing receipts and repeated delivery failures after go-live.

Follow the detailed AS2 setup tutorial and pre-go-live AS2 test plan when you are ready to configure a partner.

Frequently asked questions

Is AS2 only for EDI files?

No. AS2 can carry many payload types, although EDI is its most established use. The sender and recipient must agree the content type, filename and business-processing rules.

Does AS2 require a VPN?

Usually not. AS2 was designed for secure exchange over the internet using HTTP or HTTPS plus message signing and encryption. A partner can still require private connectivity as an additional network control.

Does a successful MDN mean the invoice was accepted?

No. It means the AS2 package reached a protocol disposition. Business acceptance is a separate state and may require a 997, 999, CONTRL or application response.

Can one AS2 server connect to many partners?

Yes. Each partner should have its own profile, including identifiers, endpoint, certificates, algorithms, MDN settings and operational contacts.

AS2Connection provides a managed AS2 server and cloud AS2 gateway for teams that need partner-specific AS2 communication without operating the protocol infrastructure themselves.

Technical references

The normative starting point is RFC 4130: MIME-Based Secure Peer-to-Peer Business Data Interchange Using HTTP, AS2. It defines the HTTP exchange, MIME/S/MIME packaging, AS2-specific MDN fields, signed receipts and MIC processing. The general MDN format is maintained in RFC 8098. Partner implementation guides still determine the bilateral options used in a specific connection.