FTP vs FTPS vs SFTP: Choosing the right File Transfer Protocol

What’s Plain FTP? 

File Transfer Protocol (FTP) in it’s basic form is one of the internet's oldest networking standards. Its design, dating back to 1971, was developed decades before network security became a common concern, and was built for closed academic machines – think the ARPANET terminals linking early research universities – as opposed to the adversarial networks most businesses depend on today.  

As such, it was standardised without any native security or encryption capabilities, yet still features in many legacy systems and business processes to this day. 

How FTP handles connections and security 

The way FTP operates today is still dictated by its original architecture, particularly in the number of connections it demands and the way data is exposed in transit. 

Dual-channel architecture. FTP separates control commands from data transfer entirely: TCP port 21 handles the control channel, negotiating connections and transmitting credentials, while a separate data channel opens on port 20 in active mode (rarely used due to firewalling), or a dynamic high port in passive mode. 

Plain-text risk. The most notable challenge with FTP in it’s basic form is not its age so much as its lack of encryption: credentials, commands and file payloads all move across the wire in plain, unencrypted text, which leaves it exposed to packet sniffing, credential harvesting and more targeted exploits such as FTP bounce attacks and port stealing. 

What’s FTPS? 

FTPS takes the existing FTP protocol and adds TLS encryption around it, protecting credentials, commands and file transfers without changing the underlying FTP architecture. 

It comes in two forms, explicit and implicit, distinguished by when encryption begins and which ports the connection uses. 

How Explicit FTPS and Implicit FTPS work 

Explicit FTPS. The modern standard, set out in RFC 4217, ensures that it’s flexible – say, the client opens a standard connection over port 21, then explicitly requests encryption via the AUTH TLS command. The server can therefore support both legacy unsecured FTP and secure FTPS, depending on its configuration and what the client can handle. 

Implicit FTPS. Implicit FTPS takes the opposite approach: encryption begins from the first byte, with no negotiation involved, and the client connects directly to a dedicated secure port, usually port 990. It was never standardised under RFC 4217 and is now largely confined to legacy environments. 

Multi-port complexity. Both forms protect the transfer, but retain FTP’s separate control and data channels. That still means multiple ports, more firewall configuration and more opportunities for a connection to fail. 

What is SFTP? 

Despite the similarity in name, SFTP is a completely separate protocol. Rather than being an extension of FTP, it’s instead built on Secure Shell (SSH), with security incorporated into the connection from the outset. 

Commands, file information and the files themselves all pass through the same encrypted channel, usually over port 22. This makes SFTP simpler to configure and less prone to the network issues associated with FTP’s multi-channel architecture. 

How SFTP handles connections and security 

SFTP takes a more consolidated approach to file transfer, combining encryption, authentication and data transfer within a single connection. 

Single-channel architecture. Where FTP and FTPS use separate channels for commands and file transfers, SFTP carries everything through one encrypted connection. This removes the need to open additional or dynamic ports, making it easier to manage through firewalls. 

SSH-based security. SFTP uses SSH to encrypt credentials, commands, metadata and file payloads throughout the session. It also supports password authentication, SSH key pairs and multi-factor authentication, depending on the server configuration. 

Reliable automation. SFTP handles file operations in a consistent, structured way across different operating systems. This makes it well suited to automated transfers and system integrations, where unpredictable directory listings or failed data connections can otherwise disrupt a workflow. 

Which protocol should you choose? 

Plain FTP has a narrow, specific home, and is typically only used in isolated legacy systems on closed, private networks that cannot be updated. 

FTPS is often still used by trading partners, financial clearing houses and mainframe environments – those that explicitly mandate it, at least. While it’s not obsolete, FTPS is increasingly confined to the corners of infrastructure that specifically require it for legacy reasons or compatability with other external parties. 

For everything else, SFTP is the modern default. Organisations building secure automation, system integrations and cloud workflows favour it because it offers a more seamless and dependable means of transferring files securely. 

Why most modern requirements point to SFTP 

Simpler firewall configuration. One inbound rule, usually port 22, significantly reduces the attack surface as well as the timeouts that are caused by blocked dynamic ports. 

Strong encryption and integrity. SSH protects both commands and data throughout the transfer, while integrity checks help detect any tampering in transit. 

Easier automation. Consistent file operations, atomic renaming and file-locking capabilities – these all help to prevent automated processes from tripping over incomplete files or competing transfers. 

Compatibility. For file transfer SFTP is widely considered the most compatible protocol with connecting services between different businesses and software. 

Conclusion 

Legacy protocols persist for a reason: infrastructure has a long memory, not every system gets modernised as soon as a newer standard is established, and there is often a chain of dependencies between systems and businesses 

But for secure enterprise transfer, SFTP is fast becoming the default. Through one encrypted channel, it carries commands, metadata and file payloads, supports reliable automation and avoids the multi-port complexity behind many FTP and FTPS connection failures.  

Moving to SFTP does not need to mean replacing every workflow at once. A managed service can often be introduced alongside existing processes, allowing organisations to migrate connections in stages with minimal disruption. 

If legacy FTP or FTPS is still holding critical workflows together, get in touch to find out what moving to managed SFTP could look like for your business.