Migrate Enterprise FTP Workflows to SFTP or FTPS (2026)

Migrating enterprise FTP workflows to SFTP or FTPS is less about security upgrades and more about embracing a more robust, auditable, and future-proof communication protocol.

Let’s watch a simple file transfer happen. Imagine sender.example.com needs to send a daily sales report to receiver.example.com.

First, the client (sender.example.com) initiates a connection.

sftp -v user@receiver.example.com

The -v flag shows us the verbose handshake. We see the client and server negotiate algorithms for key exchange, encryption, and integrity. This is the core of SFTP: a secure, encrypted tunnel established before any data is transmitted.

Once authenticated (usually via SSH keys, sometimes password), the client can issue commands.

put sales_report_20231027.csv

The put command isn’t just dumping bytes. It’s a structured command sent over the encrypted SSH channel. The server receives it, verifies permissions, and writes the file. The transfer itself is protected end-to-end.

Now, let’s contrast this with traditional FTP.

ftp receiver.example.com
user
password
put sales_report_20231027.csv

Notice how the username and password are sent in plain text. The entire data channel is also unencrypted. Anyone sniffing the network can see credentials and the file content. This is the fundamental problem SFTP/FTPS solves.

The Problem SFTP/FTPS Solves: Insecure Data Transmission

Traditional FTP (File Transfer Protocol) transmits credentials and data in plain text. This exposes sensitive information like financial reports, customer data, and proprietary code to interception by attackers on the network. SFTP (SSH File Transfer Protocol) and FTPS (FTP over SSL/TLS) encrypt this traffic, making it unreadable to eavesdroppers.

How SFTP Works: A Secure Shell Wrapper

SFTP isn’t FTP with encryption. It’s a completely different protocol that runs over SSH (Secure Shell). When you connect via SFTP, you’re actually establishing an SSH connection. The SSH protocol handles the authentication and encryption of the entire communication channel. File transfer commands and data are then sent as messages within this secure tunnel.

• Authentication: Typically uses SSH public-key cryptography (e.g., id_rsa and id_rsa.pub) for passwordless, highly secure authentication.
• Encryption: Uses strong ciphers negotiated during the SSH handshake (e.g., AES-256-GCM) to encrypt all data in transit.
• Integrity: SSH ensures that data hasn’t been tampered with during transmission.

How FTPS Works: FTP with SSL/TLS

FTPS is FTP but with an SSL/TLS (Secure Sockets Layer/Transport Layer Security) layer added. This is the same technology that secures HTTPS websites. FTPS has two main modes:

• Implicit FTPS: The client connects to a dedicated FTPS port (usually 990) and immediately initiates the SSL/TLS handshake. All subsequent FTP commands and data are encrypted.
• Explicit FTPS (FTPES): The client connects to the standard FTP control port (usually 21) and then issues an AUTH TLS command to the server to upgrade the connection to an encrypted SSL/TLS channel. Data transfers then occur over this secured channel (often on separate ports for data, which can complicate firewall rules).

Key Differences and Migration Considerations

Migration Steps:

1. Assess Your Needs:

   • Security Requirements: How sensitive is the data?
   • Compliance: Do you need specific audit trails (e.g., HIPAA, PCI-DSS)?
   • Existing Infrastructure: What firewalls, NAT devices, and client software are in place?

2. Choose Your Protocol (SFTP vs. FTPS):

   • SFTP: Generally preferred due to its simplicity (single port 22), robust SSH security, and easier firewall traversal. It’s also often easier to configure for automated, key-based authentication.
   • FTPS: A good option if you have existing infrastructure heavily invested in FTP and want to layer security on top without a full protocol change, or if your clients only support FTPS. Be mindful of the potential for complex firewall configurations, especially with active mode FTPS.

3. Server-Side Setup:

   • For SFTP: Ensure your SSH server (e.g., sshd) is running and configured to allow SFTP subsystem. Most Linux distributions include this by default.
     • Diagnosis: Check sshd_config for Subsystem sftp /usr/lib/openssh/sftp-server.
     • Fix: If missing, add or uncomment the line. Restart sshd with sudo systemctl restart sshd.
   • For FTPS: Configure your FTP server (e.g., vsftpd, ProFTPD) to support SSL/TLS. This involves generating SSL certificates and configuring the server to use them.
     • Diagnosis: In vsftpd.conf, check for ssl_enable=YES, rsa_cert_file=/etc/ssl/certs/ssl-cert-snakeoil.pem, rsa_private_key_file=/etc/ssl/private/ssl-cert-snakeoil.key.
     • Fix: If ssl_enable is NO, set it to YES. Ensure certificate paths are correct. Restart vsftpd with sudo systemctl restart vsftpd.

4. Client-Side Configuration:

   • Update Client Software: Ensure your file transfer clients (e.g., FileZilla, WinSCP, custom scripts) support SFTP or FTPS.
   • Configure Connections:
     • SFTP: Use sftp://hostname or ssh://hostname and port 22. Use SSH keys for authentication where possible.
     • FTPS: Use ftps://hostname for implicit or ftp://hostname with AUTH TLS enabled for explicit. Specify the correct port (990 for implicit, 21 for explicit).
   • Scripting: If you use command-line tools like lftp or custom scripts, update them to use sftp commands or lftp -e "set ftp:ssl-force true;" for FTPS.

5. Firewall Rules:

   • SFTP: Open outbound port 22 on your firewall for the clients and inbound port 22 on the server. This is usually the simplest firewall change.
   • FTPS:
     • Implicit: Open outbound port 990 and inbound port 990.
     • Explicit: Open outbound port 21 and inbound port 21. Additionally, you’ll need to configure the FTP server to use a passive port range (e.g., pasv_min_port=40000, pasv_max_port=40100 in vsftpd.conf) and open this range inbound on the server. This is where FTPS can become complex.

6. Testing:

   • Perform test transfers with sample files.
   • Verify that authentication works correctly (especially key-based for SFTP).
   • Confirm that data is being encrypted (use packet capture tools like Wireshark if necessary to confirm unreadable traffic).
   • Check server logs for successful and failed connection attempts.

The most common pitfall is the firewall configuration for FTPS, particularly the passive mode port range. If you’re moving from FTP and using explicit FTPS, you’ll need to ensure that the server’s passive port range is opened inbound on the server-side firewall, in addition to the standard port 21. Many organizations find SFTP’s single-port nature far simpler for network administration.

After successfully migrating your workflows to SFTP, your next challenge will likely be integrating these secure transfers with modern orchestration tools or cloud-based file sharing services.