SFTP (SSH File Transfer Protocol) is one of the most commonly used methods for exchanging EDI files between trading partners. Built on the SSH (Secure Shell) protocol, SFTP provides encrypted file transfer capabilities that satisfy the security requirements of most EDI implementations. While it lacks some of the advanced features of purpose-built protocols like AS2, SFTP's simplicity, universal support, and reliability make it an excellent choice for many EDI scenarios, particularly where batch-oriented file exchange is the norm.
SFTP should not be confused with FTPS (FTP over SSL/TLS), which is a different protocol that adds TLS encryption to the traditional FTP protocol. While both provide encrypted file transfer, SFTP is generally preferred for EDI because it uses a single port (typically port 22), simplifies firewall configuration, and benefits from the mature security model of SSH.
How SFTP Works for EDI
In a typical SFTP-based EDI setup, one trading partner operates an SFTP server while the other connects as a client. The server allocates a dedicated directory structure for each trading partner, typically with separate folders for inbound and outbound documents. The client connects on a scheduled basis (or triggered by events) to deposit outbound files and retrieve inbound files. All data transfer occurs over an encrypted SSH channel, protecting the EDI content from interception.
Authentication Methods
SFTP supports multiple authentication mechanisms. Password-based authentication is the simplest but least secure option. SSH key-based authentication, where the client presents a cryptographic key pair rather than a password, is strongly recommended for automated EDI processes. Key-based authentication eliminates the risk of password theft and enables fully automated, unattended file exchange. Some organizations combine both methods (key plus password) for additional security, though this is less common in EDI contexts.
Directory Structure Conventions
A well-organized SFTP directory structure is essential for managing EDI file exchange with multiple partners. A common convention assigns each trading partner a home directory containing /inbound and /outbound subdirectories (from the server's perspective). Some implementations add /archive directories to retain processed files and /error directories for files that fail validation. File naming conventions typically encode the document type, sender, date, and a sequence number to enable easy identification and prevent duplicate processing.
Automating SFTP-Based EDI
Manual SFTP file transfer defeats the purpose of EDI automation. Production EDI environments use scheduled scripts or managed file transfer (MFT) platforms to automate the entire cycle: connect to the partner's SFTP server, upload outbound EDI files, download inbound files, confirm successful transfer, and trigger downstream processing. Scheduling frequency depends on business requirements, ranging from hourly polling for routine transactions to near-real-time monitoring for time-sensitive documents.
Managed file transfer platforms such as GoAnywhere MFT, IBM Sterling File Gateway, and Axway SecureTransport add enterprise capabilities including transfer scheduling, retry logic, audit logging, alerting on failures, and integration with EDI translation engines. These platforms are particularly valuable when managing SFTP connections with dozens or hundreds of trading partners.
Security Best Practices
- Use SSH key authentication instead of passwords for all automated EDI connections.
- Restrict directory access using chroot jails to prevent partners from seeing each other's files or accessing the broader filesystem.
- Rotate SSH keys on a regular schedule and revoke keys immediately when a trading relationship ends.
- Monitor connection logs for unusual activity such as failed authentication attempts, connections from unexpected IP addresses, or abnormal file transfer volumes.
- Implement IP whitelisting to restrict SFTP access to known trading partner IP addresses where feasible.
Limitations of SFTP for EDI
SFTP lacks built-in non-repudiation. Unlike AS2, which provides signed message disposition notifications as proof of delivery, SFTP only confirms that a file was successfully transferred. It does not prove that the recipient processed the file or that the content was valid. Organizations requiring non-repudiation must implement additional mechanisms, such as functional acknowledgement messages (like the X12 997 or EDIFACT CONTRL) at the application layer.
SFTP is also inherently a pull-based protocol; the client must initiate connections to check for new files. This introduces latency compared to push-based protocols like AS2 or API webhooks. For most EDI use cases, polling intervals of 15 to 60 minutes provide acceptable timeliness.
Related Resources
Compare SFTP with AS2 for point-to-point connectivity or VANs for managed network services. For testing your SFTP-based EDI setup, see our Testing & Validation guide. Industries that commonly use SFTP for EDI include Energy & Utilities and Banking & Finance.