Security Insights · Secure file transfer · 9 min read
SFTP vs FTPS: Differences, Ports and Security Explained
SFTP vs FTPS compared: what SFTP is, how FTPS adds TLS to FTP, which ports each uses, how they authenticate, and what neither protects after the transfer.
SFTP and FTPS both encrypt file transfers, and their names differ by one letter, but they're built on different protocols. That difference decides which ports you open, how servers and users prove who they are, and how much work your firewall team does.
This guide explains each protocol, compares both with plain FTP, and covers what neither one does once a file has arrived.
What is the difference between SFTP and FTPS?
SFTP (SSH File Transfer Protocol) moves files over a single Secure Shell (SSH) connection, usually on port 22. FTPS is the older File Transfer Protocol with Transport Layer Security (TLS) added, so it keeps FTP's separate control and data connections and uses X.509 certificates. Both encrypt files in transit, but they aren't compatible with each other.
What is SFTP?
SFTP is the SSH File Transfer Protocol. Despite the name, SFTP isn't FTP run through SSH. SFTP is a separate protocol that runs as a subsystem named "sftp" inside an SSH session, so commands, directory listings and file data all travel over one encrypted connection. SSH servers normally listen on TCP port 22.
SSH itself is standardized in RFC 4251 to RFC 4254, published by the IETF in January 2006, which cover the architecture, user authentication, transport layer and connection protocol. SFTP never became an RFC. The IETF working group's SFTP draft stopped at revision 13 in July 2006 and expired, and a 2025 individual draft to revive it also expired. SFTP clients and servers implement versions of that draft rather than a finished standard.
What is FTPS?
FTPS is FTP secured with TLS, defined in RFC 4217 (October 2005). It comes in two forms:
- Explicit FTPS starts as a normal FTP session on port 21, then the client sends the AUTH TLS command to switch the connection to TLS. This is the method RFC 4217 describes.
- Implicit FTPS starts TLS as soon as the client connects, on port 990, which IANA registers for FTP control over TLS/SSL. Implicit FTPS isn't part of RFC 4217.
Like FTP, FTPS uses one connection for commands and separate connections for file data and directory listings. Firewalls and NAT devices often read FTP commands to work out which data ports to open, and they can't do that once TLS encrypts the command channel. A common fix is to give the server a fixed range of passive data ports and open that range in the firewall.
SFTP vs FTPS vs FTP
Plain FTP, defined in RFC 959 (October 1985), has no encryption at all. FTP sends usernames, passwords and file contents across the network in cleartext, using port 21 for commands and, by default, port 20 for data.
| SFTP | FTPS | FTP | |
|---|---|---|---|
| Underlying protocol | SSH (RFC 4251 to 4254); SFTP itself is an IETF draft | FTP (RFC 959) with TLS (RFC 4217) | FTP (RFC 959) |
| Ports | 22, one connection | 21 (explicit) or 990 (implicit), plus separate data ports | 21 for commands, 20 or a negotiated port for data |
| Encryption | The whole SSH session | TLS on the command channel, and on data channels when the client requests it (PROT P) | None |
| Authentication | SSH host key for the server; password or SSH key pair for users | X.509 certificate for the server; username and password for users, optionally with a client certificate | Username and password, sent in cleartext |
| Firewall friendliness | Simple: one port | Harder: data ports must be opened, and encrypted commands can't be inspected | Harder: data ports must be opened, though firewalls can read the commands |
| Typical use | Automated and system-to-system transfers, and access to servers already running SSH | FTP-based systems and partners that need encryption added | Public, non-sensitive downloads |
SSH keys vs certificates
SFTP inherits SSH's authentication. The server proves its identity with a host key, which the client checks against a key it has stored locally or one certified by a trusted authority. Users can sign in with a password or with public key authentication, where the client proves it holds the private key matching a public key the server already has. RFC 4252 makes public key authentication mandatory: every SSH implementation must support it.
FTPS relies on TLS, so the server presents an X.509 certificate, normally issued by a certificate authority the client trusts. Users still log in with FTP's USER and PASS commands, now inside TLS, and servers can also ask for client certificates. RFC 4217 notes that without server certificates there's little protection against man-in-the-middle attacks.
What SFTP and FTPS don't do
Both protocols protect a file while it travels between client and server. Neither protects the file itself:
- The encryption ends at the server. Once a transfer completes, the file is stored in readable form unless the server encrypts its storage separately.
- People with administrative access to the server can usually open stored files, and so can an attacker who gains that access.
- Neither protocol controls what happens after a download. There's no built-in expiry, view-only mode or way to withdraw access to a copy someone already has.
- Logging depends on the server software and its settings. Neither specification defines an audit trail of who opened or downloaded each file.
The SFTP draft itself leaves security to the underlying transport, which only covers the connection. For a longer look at these limits, see Beyond SFTP.
Is SFTP more secure than FTPS?
Neither protocol is inherently more secure. Both use current encryption when configured well: SFTP through SSH and FTPS through TLS. The practical differences lie elsewhere. SFTP needs one open port and supports key-based logins, which makes it simpler to run through firewalls and to automate. FTPS suits organizations whose systems and partners already use FTP, or that manage identity through certificates.
Either one is a sound replacement for plain FTP, which shouldn't carry passwords or sensitive files. What matters more is configuration: current TLS versions or SSH algorithms, verified server keys or certificates, and strong user authentication.
Where DekkoCORE fits
SFTP and FTPS are built for moving files between systems. For sharing files with people, DekkoCORE is a browser-based alternative: files are encrypted with AES-256 keys on the user's device before they're uploaded, and each person you share with gets the permission level you choose. Access can end on a date you set, and every view and download is recorded in the audit log.
Common questions
Frequently Asked Questions
Is SFTP the same as FTP over SSH?
No. SFTP is its own protocol, the SSH File Transfer Protocol, which runs as a subsystem inside an SSH session. FTP tunneled through an SSH connection is a different setup that still uses FTP commands, and it isn't SFTP.
What port does SFTP use?
SFTP uses the SSH port, which is TCP port 22 by default. SFTP sends commands and file data over that one connection, so only one port needs to be open. Administrators can run SSH on a different port if they choose.
Does FTPS use port 21 or 990?
FTPS uses port 21 in its explicit form, where the client upgrades the session with the AUTH TLS command. Implicit FTPS starts TLS immediately and uses port 990. Both forms of FTPS also need separate ports for data connections.
Is plain FTP secure?
No. FTP, defined in RFC 959, sends usernames, passwords and file contents in cleartext, so anyone who can watch the network traffic can read them. The IETF's own FTP security documents, RFC 2228 and RFC 2577, both point out that FTP passwords cross the network unprotected.
Does SFTP encrypt files at rest?
No. SFTP encrypts files only while they move over the SSH connection. Once a file reaches the server, SFTP plays no part in how it's stored, so encryption at rest depends on the server's own storage settings. FTPS works the same way.
Is SFTP an official internet standard?
No. The SSH File Transfer Protocol was never published as an RFC. The IETF's SFTP draft stopped at revision 13 in 2006 and expired, although the SSH protocol underneath SFTP is standardized in RFC 4251 to RFC 4254.