A new retail partner sends over their onboarding pack and it includes a line that gives your team pause: "AS2 endpoint required, MDN return receipts mandatory." Your existing partners all use SFTP and it has worked fine for years. Do you stand up an AS2 stack, push back, or run both?
This is one of the most common B2B file transfer questions, and the answer depends less on protocol preference than on who you are trading with and what they will accept. Below is a practical breakdown of how AS2 and SFTP actually differ, where each one is the only sensible choice, and how to avoid running two stacks if you do not have to.
What AS2 Actually Is
AS2 (Applicability Statement 2) is an HTTP-based protocol specifically designed for B2B document exchange, originally driven by retail and supply-chain EDI workflows in the early 2000s. It is defined in RFC 4130 and sits on top of standard HTTP or HTTPS.
The defining features of AS2 are not really about transport. They are about trust and proof:
- S/MIME envelopes sign and encrypt each payload using X.509 certificates, so the receiver can verify the sender's identity and the payload's integrity independent of the transport.
- MDN (Message Disposition Notification) receipts are returned by the receiver. A signed MDN is a cryptographic receipt that the message was received and verified intact, and is the closest thing the file transfer world has to certified mail.
- Non-repudiation falls out of the MDN. The receipt is signed by the receiver's key, so neither side can later claim the message was never delivered or was tampered with.
Underneath all of this, AS2 is just an HTTPS POST. The complexity lives in the certificate exchange, the S/MIME envelope, and the signed receipt flow, not in the wire protocol.
What SFTP Actually Is
SFTP (SSH File Transfer Protocol) is a file transfer protocol that runs over an SSH connection, almost always on port 22. We have a full breakdown in What is SFTP, but the relevant parts here are:
- A single encrypted channel for both authentication and file transfer.
- SSH key pairs (or passwords) for authentication.
- File operations are filesystem-like: list, get, put, rename, delete.
- No built-in concept of a receipt or a signed envelope. The protocol confirms a successful byte-level write, and nothing else.
SFTP cares about moving bytes safely between two endpoints. AS2 cares about producing a paper trail that holds up in a dispute.
Where They Actually Differ
Receipts and Non-Repudiation
This is the headline difference. AS2 returns a signed MDN that proves the receiver got the message and that the payload validated. SFTP returns a write confirmation that the bytes hit disk.
In practice that means:
- AS2 is the right answer when you need a receipt that holds up legally or contractually. A signed MDN with the MIC (message integrity check) is treated by most EDI-using trading partners as proof of delivery.
- SFTP can approximate this with application-layer acknowledgements (a partner posts a
.ackfile back to a return folder, or you both compare checksums in a log) but nothing about the protocol itself produces a cryptographic receipt.
If your contract or trading-partner agreement actually requires non-repudiation, AS2 is the only common protocol that gives it to you out of the box.
Partner Onboarding Cost
AS2 onboarding involves a certificate exchange, an AS2 ID assignment, an endpoint URL, and usually a written agreement covering MDN modes (sync vs async), signing and encryption algorithms, and compression settings. Most AS2 connections take days to weeks to stand up with a new partner, and that cost recurs with every new partner.
SFTP onboarding is closer to "send us your SSH public key and a source IP we can allowlist." Many of our customers do new-partner setup in under an hour. The tradeoff is exactly what you would expect: less ceremony, less proof.
If you are onboarding hundreds of small partners (a marketplace, a healthcare-data aggregator, a retail distributor with many small suppliers), the per-partner cost of AS2 adds up quickly. If you are onboarding a handful of large partners and they are already on AS2, the cost is a rounding error.
Cost and Operational Overhead
AS2 implementations tend to be heavier:
- Certificate lifecycle management for every partner. Certificates expire, and an expired partner certificate stops the flow until both sides rotate.
- MDN matching logic. Async MDNs may arrive minutes or hours after the original POST, and you need infrastructure to match them back to the original message.
- Retransmit handling. AS2 has a defined retry behavior for missing MDNs that you have to implement and monitor.
SFTP operational overhead is mostly about SSH key rotation, IP allowlist hygiene, and audit logs. Lighter, but with fewer guarantees if something goes wrong in transit.
Connectivity and Firewall
Both protocols are well-behaved through corporate firewalls. SFTP uses a single port (22). AS2 uses 80 or 443 (HTTPS in practice), which is friendlier in some locked-down environments that block SSH outbound but allow web traffic. We have seen partners specifically choose AS2 over SFTP for exactly this reason in highly restricted financial and government networks.
Authentication and Encryption
This one is closer to a tie than people expect:
- AS2 authenticates via X.509 certificate exchange and encrypts the payload at the S/MIME layer. The transport (HTTPS) is independently encrypted.
- SFTP authenticates via SSH keys (or passwords) and encrypts the entire SSH channel.
Both are strong when configured correctly. The practical difference is that AS2 encryption travels with the payload (the envelope is encrypted, so the file is still encrypted at rest after the POST completes), while SFTP encryption travels with the session (the file is plaintext on disk at both ends). For some compliance regimes that matters; for most it does not.
When AS2 Is Non-Negotiable
There are real situations where you do not get to choose:
- Major retail trading partners. Many Tier 1 retailers and their EDI VANs (value-added networks) mandate AS2 for inbound 850 (purchase orders), 856 (advance ship notices), and 810 (invoices). If you want to be a supplier, AS2 is the price of entry.
- EDI-driven supply chains. Automotive, big-box retail, and certain pharmaceutical distribution networks have standardized on AS2 over a decade ago and will not negotiate it away for one supplier.
- Contractual non-repudiation requirements. If your contract explicitly requires signed receipts of delivery, AS2 is the simplest path. Layering signed acknowledgements on top of SFTP is possible but more work and harder to defend in a dispute.
If you are in one of these categories, the question is not "AS2 or SFTP" but "do I build AS2 in-house, use a managed VAN, or use a platform that handles it for me."
When SFTP Is the Better Call
For most B2B flows outside of formal EDI, SFTP is the more sensible default:
- Internal B2B flows between subsidiaries, business units, or sister companies where contractual non-repudiation is not at stake.
- High-volume, many-partner onboarding where the AS2 setup cost would dominate.
- Data engineering and ELT pipelines where the file is consumed by a job, not by a procurement system that needs a receipt. Our post on the role of SFTP and MFT in ELT pipelines covers this pattern.
- Healthcare, finance, and legal use cases that are not EDI-flavored. HIPAA and PCI-DSS care about encryption and audit, not about MDNs specifically. See our HIPAA-focused SFTP post for a deeper take.
Hybrid Setups Are the Norm
Most established B2B operations run both, because their partner mix forces it. A typical pattern looks like this:
- AS2 inbound for the handful of retail or supply-chain partners who require it.
- SFTP inbound for everyone else (smaller suppliers, internal flows, data vendors).
- A normalized internal pipeline that does not care which protocol delivered the file. Everything lands in the same processing path once it is inside the perimeter.
The mistake we see most often is teams running two completely separate stacks: an AS2 appliance with its own logging, user management, and storage, and an SFTP server with another set. The maintenance and audit cost is twice what it should be.
Common Pitfalls
- Treating AS2 as "more secure" than SFTP. It is not, in any general sense. It is more provable. The cryptographic primitives are similar; what differs is what gets receipts.
- Letting partner certificates lapse silently. An expired AS2 certificate stops the flow with no graceful degradation. Calendar reminders are not enough; automated monitoring of partner cert expiry is.
- Choosing AS2 because one partner asked, then forcing it on everyone. Onboarding cost scales linearly with partner count. Most of your partners almost certainly do not need it.
- Skipping the signed MDN to "make it faster". Unsigned MDNs defeat the entire point of AS2. If you do not need the receipt, you do not need AS2.
How FilePulse Fits
FilePulse is primarily an SFTP-first managed platform, with FTPS support for partners who need it. We do not yet offer native AS2, but we are increasingly seeing customers consolidate their SFTP/FTPS partners onto FilePulse while keeping a separate AS2 endpoint for their handful of retail-EDI partners. That hybrid pattern works well: get the per-partner onboarding cost down for the long tail, and keep the AS2 stack focused on the partners that actually need it.
Next step: If most of your B2B partners are on SFTP or FTPS and the operational overhead is creeping up, sign up for FilePulse and consolidate them into one managed stack. Already running AS2 alongside? Talk to our team about how customers structure the hybrid.
