Transferring a file from one machine to another sounds trivial. And it is —until that file is a payment batch, and the "machine next door" is at the other end of a network you don't control. That's when the question stops being "how do I move the file?" and becomes "who else can read it along the way?". The answer separates FTP from SFTP, and explains why in serious environments the former simply doesn't exist.
What each protocol moves
A file transfer protocol is just an agreement: how a client and a server talk to list folders, upload, download and delete files. FTP and SFTP solve the same problem —moving bytes— but from opposite technical worlds.
FTP (File Transfer Protocol) is a protocol from 1985 that moves files using two separate network connections and no encryption at all: everything —commands, credentials and content— travels in plain text.
SFTP (SSH File Transfer Protocol) is a modern protocol that moves files inside an already-encrypted SSH connection. Despite the name, it doesn't share a single line of code or design with FTP.
How FTP works (and why it's from another era)
What makes FTP peculiar is that it uses two channels: one to give commands and another to move the content.
- The client opens the control channel to the server on port 21. Commands (
USER,PASS,LIST,RETR…) and responses travel there. - The client authenticates by sending username and password —in plain text— over that same channel.
- To transfer a file, a second channel, the data channel, is opened. In active mode the server opens it toward the client; in passive mode the client opens it to a port the server points to (which is why passive is the one that survives behind firewalls).
- The file content travels over that data channel —also unencrypted—.
That two-channel design was reasonable in 1985. Today it's a double problem: it complicates firewalls (you have to manage port ranges for the data channel) and, above all, it protects nothing. An attacker with visibility of the network —a compromised Wi-Fi, a tampered router, a neighbor on the same segment— reads your password and your file as-is.
"I use FTP but only inside the internal network, so it's safe." The perimeter is not encryption. A compromised host or lateral movement inside that same internal network sees all FTP traffic in the clear. Internal doesn't mean confidential.
How SFTP works
SFTP doesn't reinvent security: it leans on SSH, the same protocol you use to administer servers remotely and securely. SFTP is, literally, an subsystem of SSH dedicated to files.
- The client opens a single SSH connection to the server, normally on port 22.
- Client and server negotiate encryption and verify identities before exchanging anything useful. From here on, everything through that connection is encrypted.
- The client authenticates by password or —recommended— with an SSH key pair: a private key that never leaves your machine and a public key that lives on the server.
- Commands and content travel over that single encrypted channel. One port, one tunnel, nothing readable from the outside.
The result: one port instead of several (happy firewall), end-to-end encryption of the transport, content integrity verification and the option to authenticate with keys instead of passwords. Everything FTP lacks, SFTP brings out of the box because it inherits it from SSH.
The key confusion: SFTP is not FTPS
This is where almost everyone stumbles. There's a third name —FTPS— and it's not a synonym for SFTP. They are different things:
- FTPS (FTP Secure) is plain old FTP with a TLS layer on top (the same encryption as HTTPS). It still has two channels and drags along FTP's firewall complexity. It typically uses port 21 (explicit mode) or 990 (implicit).
- SFTP has nothing to do with FTP: it's SSH, a single channel, port 22.
"SFTP is FTP with SSL." No. What you're describing is FTPS. The S in SFTP comes from SSH, not from "secure sockets". They're two different paths to the same goal —encrypting the transfer— but SFTP and FTP don't even speak the same language.
The three, side by side
| Feature | FTP | FTPS | SFTP |
|---|---|---|---|
| Technical base | Plain FTP | FTP + TLS | SSH |
| Encryption in transit | No | Yes | Yes |
| Channels / ports | 2 channels (21 + data) | 2 channels (21/990 + data) | 1 channel (22) |
| Firewall-friendly | Barely | Barely | Very |
| Key-based authentication | No | Via certificates | Yes (SSH keys) |
| Content integrity | Not guaranteed | Yes | Yes |
When to use each
- SFTP — the default choice today. One port, encryption, keys. It's what you want for any serious file exchange, internal or external.
- FTPS — when an old counterparty demands FTP but both agree to add TLS, or when there are certificates already under your management. It encrypts, but you inherit the two-channel pain.
- Plain FTP — practically never. At most, to serve public files where nothing is sensitive and there are no credentials to protect. When in doubt, don't.
Common mistakes
- Believing passive mode encrypts. Active vs passive only decides who opens the data channel. It has nothing to do with encryption: passive FTP is still plain text.
- Confusing SFTP with FTPS when configuring a client or firewall, and ending up opening the wrong port (21/990 instead of 22, or vice versa).
- Reusing the same password over SFTP instead of using keys. Encryption protects the transport, but a weak or leaked password is still the front door.
- Assuming "it's behind a VPN" is enough. The VPN protects one leg; the file can keep traveling in the clear inside if the protocol doesn't encrypt.
The banking angle: why SFTP and keys
In banking, file exchange is not an afterthought: it's infrastructure. Payment batches, reconciliations, clearing files, regulatory reports, vendor feeds. They move daily between institutions that don't share a network, and their content is exactly the most sensitive there is.
That's why there are three requirements FTP can't meet and SFTP can:
- Confidentiality in transit. Standards like PCI-DSS require encrypting card data when it crosses open networks. A file over FTP fails from the start.
- Strong, auditable identity. SSH keys let you give each counterparty its own credential, rotate and revoke it, and leave a trail of who connected. A shared password gives none of that.
- Integrity. The SSH channel detects whether the file was altered on the way. In a payment batch, that guarantee is not a luxury.
FTP and SFTP answer the same question —how to move a file— but only one answers the one that truly matters: who else can read it. In a bank, that second question rules. That's why the standard isn't up for debate: SFTP, with keys, and plain FTP outside the policy.
