Protocols: SFTP vs FTPS

Protocols: SFTP vs FTPS

How do you transfer sensitive files? Business requirements and security standards have increased in recent years across industries and continents, but many organizations have struggled to keep up. Manual scripts, legacy tools, and single-use software are still utilized by IT and security teams despite their risks, causing more problems than they solve. SFTP vs FTPS, these two protocols each have advantages and disadvantages, so it is important to know these differences to determine which option is most advantageous.

by Eloïse Gruber

What is SFTP?

SFTP (FTP over SSH) is a secure FTP protocol that sends files over secure shell (SSH), providing a high level of protection for file transfers. SFTP implements AES, Triple DES, and other algorithms to encrypt data that flows between systems. It also offers several ways to authenticate a connection—with a user ID and password, SSH key, or a combination of a password and SSH key—for organizations that require stronger authentication.

What is FTPS?

FTPS (FTP over SSL) is a secure FTP protocol that allows you to protect and exchange files with trading partners, employees, and clients. Like SFTP, FTPS also implements strong algorithms like AES and Triple DES to encrypt critical file transfers. For connection authentication, FTPS uses a combination of user IDs, passwords, and/or certificates to verify a system’s authenticity.

When to Choose SFTP vs FTPS?

If SFTP and FTPS are both secure protocols with similar protection, when is it best to use one over the other? The answer is: it depends. Your choice comes down to your organization’s IT infrastructure, trading partner requirements, how you want to authenticate file transfers, and which ports you want to use.

When to Use SFTP?

SFTP has the upperhand over FTPS when it comes to authentication and firewalls. For example, when authenticating a connection, you can:

  • Use a user ID and password to connect to an SFTP server; OR
  • Use SSH keys with or instead of passwords for extra authentication

Key-based authentication does require you to generate an SSH key pair beforehand, so keep that in mind if you’re planning to use SFTP. You may want to look into Key and Certificate Management along with your SFTP Client/Server if you plan to use SSH keys to authenticate connections.

SFTP wins when considering ease of implementation. A very firewall friendly protocol, SFTP needs a single port opened (port 22) to transmit initial authentication, issued commands, and file transfers between itself and another server.

When to Use FTPS:

If you’re required to use FTPS by a trading partner or you want to use certificates to authenticate connections, FTPS will be your best option for secure file transfer. FTPS uses TLS (and SSL, though SSL is now considered insecure by PCI DSS and most industry standards) to encrypt server connections. X.509 certificates are used to authenticate these connections. They contain identifiable information like issuer name, subject name, subject public key details, and signature. When using certificates, they’re considered trustworthy if either signed by a known certificate authority (CA) or self-signed by a trading partner. Certificates signed by a CA are easy to validate using the chain of trust that is built into the standard. To validate self-signed certificates, you must have a copy of the trading partner’s public certificate in your trusted key store.

There is a downside. If you choose FTPS for your organization, be aware that FTPS can be difficult to connect through firewalls with high levels of security. FTPS uses multiple port numbers for implicit and explicit connection types, so every time a file transfer or directory listing request is made, another port will open. This can put your network at risk and open you up to vulnerabilities if you aren’t careful and alert.


If you would like to learn more about how BlueFinch can help your organisation protect its sensitive data and about our Data Security Suite? Please contact and take a look at our solutions.