AS2 and SFTP can both transfer business files securely, but they use different operating models. SFTP provides an encrypted SSH session for uploading and downloading files. AS2 packages each message for a named trading partner, can sign and encrypt the payload, and can request an MDN protocol receipt.
If a customer mandates AS2, SFTP is not a drop-in substitute. If both parties simply need a controlled folder exchange, SFTP may be the simpler fit. Many architectures use SFTP internally and AS2 externally rather than choosing only one.
AS2 vs SFTP comparison
| Factor | AS2 | SFTP |
|---|---|---|
| Transfer model | Sender pushes a message to partner endpoint | Client uploads/downloads files from server folders |
| Standard network port | Usually HTTPS 443, but endpoint defines it | Usually SSH 22, but server defines it |
| Identity | AS2 IDs plus certificates and optional HTTP/TLS controls | User/key authentication and server host key |
| Payload protection | Message signature and optional S/MIME encryption | SSH protects the transport session |
| Native receipt | MDN, optionally signed with MIC | No AS2 MDN; confirmation must be designed separately |
| File availability | Delivered as a message event | File remains in folder until moved or deleted |
| Automation | Event/message oriented | Polling, schedules or filesystem events |
| Typical B2B fit | Governed EDI and partner-mandated exchanges | Batch transfers, internal integrations and shared-folder workflows |
| Setup | IDs, URL, certificates, algorithms, MDN | Host, port, account, key, folders and host-key verification |
Both can be implemented poorly or securely. The protocol choice does not replace key rotation, least privilege, monitoring, retention and incident response.
How SFTP works
SFTP runs over SSH. A client authenticates to a server and performs file operations inside permitted directories. Authentication commonly uses an SSH private key, password or both. The client should also validate the server’s host key to prevent connecting to an impostor.
A typical EDI SFTP workflow is:
- Sender writes a complete file to an outbound staging area.
- A scheduled integration uploads it to the partner’s inbound folder.
- The partner polls or watches the folder and moves the file for processing.
- Status is inferred from logs, file movement or a separate acknowledgment file.
SFTP does not define what the receiver’s application must return. Teams must design correlation, pickup confirmation, duplicates and business acknowledgments themselves.
How AS2 works
AS2 sends an HTTP message containing AS2 headers and a MIME/S/MIME package. The sender can sign with its private key and encrypt with the receiver’s public certificate. The receiving AS2 service processes the package and returns an MDN.
The MDN is why AS2 is common in B2B EDI. A signed MDN with a matching MIC can provide evidence tied to the exact protocol message. It still does not prove business acceptance; a later 997, 999, CONTRL or application response may be required.
Read the AS2 protocol guide for the full message flow.
Security: session versus message
SFTP encrypts the SSH connection. Files are protected while they travel through that session, but their protection before upload and after download depends on storage and application controls. An organization can add file-level encryption or signatures, but SFTP itself does not require an AS2-style signed message envelope.
AS2 can use HTTPS for session protection and S/MIME signing/encryption for the packaged message. The receiver validates the partner signature and decrypts specifically for its key. This creates message-level evidence even if payload storage and downstream handling still require separate controls.
The comparison is therefore not “encrypted versus unencrypted.” It is encrypted transport with a folder model versus a protocol that can add message-level signature, encryption and receipt semantics.
Authentication and key management
SFTP generally requires:
- server host-key verification;
- user account or service identity;
- SSH public/private key pair or password;
- folder permissions and sometimes source-IP allowlisting.
AS2 generally requires:
- local and remote AS2 IDs;
- signing private key and exchanged public certificates;
- partner encryption certificate;
- endpoint URL;
- agreed algorithms and MDN behavior;
- optional HTTP authentication, TLS controls or allowlisting.
Both require lifecycle management. An expired AS2 certificate can stop signing or decryption; a rotated SSH host key can stop SFTP clients; an expired account can block folder access.
Delivery evidence
With SFTP, a successful upload proves that the server accepted file bytes into a location. It does not inherently prove that the partner picked up, validated or processed the file. Teams often add acknowledgment files, status APIs, folder moves or application reports.
With AS2, the MDN reports a defined AS2 disposition. A signed receipt with matching MIC provides stronger protocol-level evidence, but downstream EDI acceptance remains separate.
If non-repudiation or formal transport evidence is a contract requirement, document exactly which artifacts and retention rules satisfy it rather than relying on a generic protocol label.
Automation and latency
SFTP is often polled on a schedule. Polling is simple but introduces latency and requires safe file-write conventions. Upload under a temporary name and rename atomically when complete so the receiver does not read a partial file.
AS2 is normally event-driven: the sender posts when the message is ready and receives an immediate or later MDN. This can reduce pickup latency, but the sender still needs queues, timeouts and retry controls.
Either protocol can support high automation. Operational design—idempotency, durable queues, monitoring and reconciliation—matters more than marketing claims.
Error handling
SFTP failures often include authentication errors, host-key changes, missing directories, permission denials, disk limits and interrupted transfers. After a successful upload, a separate mechanism must surface parser or business failures.
AS2 failures can occur at network, identity, signature, decryption, MIME or MDN layers. The disposition and Message-ID help classify protocol problems, while EDI acknowledgments report downstream issues.
AS2 has more negotiated fields, which can increase onboarding complexity but also makes the expected security and receipt behavior explicit.
Partner onboarding
SFTP onboarding usually exchanges host, port, account, SSH public key, host-key fingerprint, folders, filename patterns and pickup schedule.
AS2 onboarding exchanges endpoint, AS2 IDs, certificates, algorithms, MDN mode, content type, retries and test cases. Use the AS2 parameters guide to see the complete set.
In either case, separate test and production and verify fingerprints through a trusted channel.
Performance and file size
Performance depends on implementations, network conditions, concurrency and processing, not only protocol. SFTP can be efficient for large batches and repeated file operations in one SSH session. AS2 messages may add signing, encryption and MIME overhead, while HTTP connections can run concurrently.
Benchmark realistic sizes and peak patterns. Ask how the receiver limits individual messages, simultaneous connections, timeouts and queue capacity. Avoid deciding from a single small-file test.
Cost and operating effort
Compare the full service, not license names. For either protocol, costs can include:
- hosted platform or infrastructure;
- high availability and backups;
- credentials, certificates and key rotation;
- logs, monitoring and retention;
- partner onboarding and support;
- ERP/EDI integration;
- incident response and manual replay.
SFTP can be simpler when no formal receipt is required. AS2 can reduce the amount of custom acknowledgment engineering for partners that already use MDNs. A managed gateway can reduce AS2 operational work without changing the partner requirement.
When to choose AS2
AS2 is usually the stronger choice when:
- the trading partner mandates AS2;
- signed message-level receipts are required;
- each partner needs an explicit identity and security profile;
- messages should be pushed rather than collected from a mailbox;
- audited transport evidence is important;
- AS2 is already part of the partner’s EDI implementation guide.
When to choose SFTP
SFTP is often appropriate when:
- both parties agree on a folder-based exchange;
- scheduled batch transfer is acceptable;
- the workflow already has reliable acknowledgment and duplicate controls;
- formal AS2 MDNs are not required;
- internal or legacy systems integrate naturally through files;
- the team already operates SSH identities and secure file services.
Hybrid AS2 and SFTP architecture
A common pattern is:
- ERP writes an outbound EDI file to an internal SFTP folder.
- An AS2 gateway collects the file and maps it to the partner profile.
- Gateway signs, encrypts and sends it over AS2.
- Gateway validates the MDN.
- It exposes status through a file, API, webhook or dashboard.
- Inbound AS2 payloads are deposited into an internal SFTP folder for the ERP workflow.
This keeps the external protocol required by the partner while avoiding AS2 certificate logic inside a legacy application.
Decision checklist
- Which protocol does the partner require in writing?
- Is message-level signing or encryption required?
- What delivery evidence must be retained?
- How will business acknowledgments be correlated?
- Is push or folder pickup a better operating model?
- Who owns key and certificate rotation?
- What are volume, size and latency requirements?
- How will duplicates and uncertain delivery be handled?
- Can one gateway bridge the external and internal methods?
If a partner requires AS2, AS2Connection provides a managed AS2 server and cloud AS2 gateway while your internal applications can continue using API, folders or SFTP.
