SFTP vs FTPS: How to Pick the Right Secure File Transfer Protocol

If you've already ruled out plain FTP (good — it's cleartext, no encryption) and you're picking between SFTP and FTPS for a new secure file-transfer deployment, the answer is almost always SFTP: single port, native SSH key authentication, no certificate management, and trivial to firewall. The exception is when a partner or a piece of legacy software can speak FTP but not SSH — in that case FTPS keeps the existing FTP tooling and adds TLS encryption. This post covers how each protocol works, the five differences that actually matter in production, and how to decide between them when both are options.

For the broader three-protocol comparison (including plain FTP), see our FTP vs FTPS vs SFTP explainer. This post is the narrower two-protocol guide for teams that have already committed to encryption.

The two protocols at a glance

Feature	SFTP	FTPS
Underlying protocol	SSH	FTP + TLS
Ports	22 (single)	21 + ephemeral (explicit), 990 + 989 (implicit)
Encryption	Native, mandatory	TLS, negotiated
Authentication	Password OR SSH key	Password + server certificate
Channels	Single	Dual (control + data)
Firewall complexity	Low	High (passive port ranges, NAT issues)
Modern recommendation	Default for new deployments	Compatibility-driven choice

SFTP and FTPS share four letters in different orders and the broad job of "secure file transfer," but their wire protocols are unrelated. An SFTP client cannot connect to an FTPS server, and vice versa.

How FTPS works

FTPS is plain FTP with a TLS encryption layer added. The protocol semantics are identical to FTP — same USER / PASS / LIST / RETR commands, same dual-channel design, same active vs passive modes — but the connections are encrypted with TLS, and the server presents an X.509 certificate the client validates.

Two flavors exist:

• Implicit FTPS — TLS handshake happens immediately, before any FTP commands. Control on port 990, data on port 989. Specified by Microsoft in the late 1990s; considered deprecated in modern deployments but still in use on legacy systems.
• Explicit FTPS — client connects to plain port 21, then issues AUTH TLS to upgrade the connection. The data channel also gets its own TLS handshake. This is the modern FTPS standard, specified in RFC 4217.

An explicit-FTPS session begins with the cleartext upgrade handshake before any credentials transit:

220 ProFTPD Server
AUTH TLS
234 AUTH TLS successful
[TLS handshake — server cert presented, validated by client]
USER alice
331 Password required
PASS ********
230 User alice logged in
...

After the AUTH TLS upgrade, everything that follows — credentials, commands, file bytes — is encrypted with TLS.

How SFTP works

SFTP is not FTP. It's a file-transfer subsystem of SSH that runs entirely inside an SSH session over port 22. The mechanics:

1. Client opens an SSH connection to the server on port 22.
2. SSH handshake: ciphers negotiated, server's host key presented, client validates it against ~/.ssh/known_hosts.
3. Client authenticates with a password or an SSH key.
4. Client requests the sftp subsystem; server spawns an SFTP server inside the existing encrypted SSH channel.
5. File operations (ls, get, put, mkdir, permission changes) flow over the same single channel.

The SSH layer handles encryption, authentication, and identity verification; SFTP rides inside it. A session looks like this:

$ sftp alice@sftp.example.com
The authenticity of host 'sftp.example.com (...)' can't be established.
ED25519 key fingerprint is SHA256:abc123…
Are you sure you want to continue connecting? yes
alice@sftp.example.com's password: ********
Connected to sftp.example.com.
sftp> ls
report-2026-05.csv
sftp> get report-2026-05.csv
100%  142KB  142.0KB/s  00:00
sftp> bye

Everything SFTP gets — encryption, key auth, host-key verification, modern cipher suites — it gets from SSH.

The five differences that actually matter

1. Number of ports

SFTP uses one port (22). FTPS uses two or more — port 21 for the control channel plus a configurable range of ephemeral high ports (often 50000–50100 in production) for passive-mode data connections. Implicit FTPS adds another two (989 + 990).

This is the single largest operational difference. SFTP firewall configuration is one outbound rule. FTPS firewall configuration is multiple rules, has to match between server and firewall exactly, and tends to silently fail when ranges drift out of sync.

2. Authentication model

SFTP supports SSH key authentication natively. Generate a keypair, install the public key on the server, and connections from that client authenticate without a password. SSH keys are how nearly every server in the world is administered; the tooling and operational discipline already exist.

FTPS only supports passwords in the standard protocol. The server presents an X.509 certificate that the client validates (so the client knows it's talking to the right server) but the client always sends a password to authenticate itself. For automated workflows, password-only auth is a meaningfully weaker design.

3. Encryption posture

SFTP encrypts everything from the first byte. The SSH handshake comes before any credentials transit; there's no cleartext phase to misconfigure.

FTPS has a cleartext opening phase. The client connects to port 21 in the clear and sends AUTH TLS before any sensitive bytes. A misconfigured client that skips the TLS upgrade sends credentials in the clear over an FTPS port. This is a real production failure mode, not a theoretical one — FileZilla and several other clients have historically had "fall back to plain FTP" toggles that defeat the encryption story when enabled.

Implicit FTPS solves this by mandating TLS before any data, but is otherwise the deprecated flavor.

4. Certificate management

SFTP doesn't have certificates. SSH uses key fingerprints (known_hosts); the client trusts the server's host key on first connection and verifies it matches on every subsequent connection.

FTPS uses X.509 certificates — the same kind HTTPS uses. The server needs a valid cert from a CA the client trusts (Let's Encrypt has made this much easier than a decade ago, but it's still a thing you manage). Certificate expiration breaks connections. Cert rotation is a deployment step.

5. Firewall traversal in the wild

SFTP traverses every modern firewall and NAT cleanly because there's nothing unusual happening on the wire — outbound TCP to port 22, just like every SSH session.

FTPS struggles in two specific environments. Deep packet inspection firewalls can't see inside the encrypted control channel to track the passive-mode PASV response, so they sometimes drop the data connection. NAT routers can't rewrite the IP address advertised in PASV responses because that response is now encrypted, so behind-NAT FTPS servers often need explicit external-IP configuration.

These differences add up to: SFTP works reliably in environments where FTPS has subtle, hard-to-debug failures.

When FTPS is actually the right choice

The narrow set of cases where FTPS beats SFTP:

• A partner can speak FTP but not SSH. FTPS keeps their existing FTP tooling and credentials; SFTP would require them to install new client software and generate keys. For a partner you can't move, FTPS is the encrypted compromise.
• A regulated workflow contractually requires FTPS. Some industry standards (notably parts of the banking sector and some government file-exchange requirements) name FTPS specifically. When the contract says FTPS, the contract wins.
• Existing automation calls the ftp command directly. Rewriting scripted FTP automation to use sftp instead is real work; if you have a large surface area of FTP-shaped automation, FTPS is the path that doesn't require rewriting any of it.
• Cross-platform compatibility with .NET legacy stacks. Older .NET Framework versions had robust built-in FTPS support and weaker SFTP support. Modern .NET 8+ has good SFTP libraries (notably SSH.NET) so this is a smaller factor than it used to be.

For any other case, SFTP is the cleaner answer.

Migration: from FTPS to SFTP, or vice versa

If you've inherited an FTPS integration and are weighing whether to migrate to SFTP:

Migrate when:

• The partner is flexible. Most modern partners have SFTP options; if they're offering, take it.
• You're touching the integration anyway. A new partner onboarding, a system refresh, or an infrastructure migration is a good time to combine the protocol switch with work you'd be doing regardless.
• The integration is the primary path for sensitive data and the security review is coming up.

Stay on FTPS when:

• The partner cannot speak SSH and won't move.
• The data has zero sensitivity. (Rare for any modern workflow, but it happens.)

The migration itself is usually low-friction on a managed-file-transfer platform that exposes both protocols on the same backend storage — the partner changes their connection string from ftps://server:21/ to sftp://server:22/ and the rest of the workflow continues unchanged.

The modern way: a platform that handles both

Files.com is the File Orchestration Platform we'd recommend for any team running secure file-transfer workflows in 2026. The platform exposes SFTP and FTPS (plus plain FTP and WebDAV) on their standard ports on a subdomain Files.com provisions, with the operational surface fully managed:

• SFTP on port 22 with native SSH key auth. Per-user keys, rotation, revocation through the admin UI or REST API.
• FTPS with auto-managed TLS certificates. Provisioned and renewed via Let's Encrypt; modern cipher suites by default.
• Same backend storage, same users, all four protocols. Partners pick whichever protocol they prefer; the file layer is unified.
• Audit logging on every operation across all protocols. Per-file, per-user, immutable trail.
• SOC 2 Type II and HIPAA-BAA out of the box. Compliance posture pre-built.
• REST API, automation workflows, AS2 partner messaging, share links — features the protocols never had.

Start a free Files.com trial — no credit card, provisioned in about 10 minutes. The SFTP-vs-FTPS question shrinks to "which dropdown does the partner choose."

For the narrow set of teams that must run file-transfer infrastructure inside their own datacenter — air-gapped environments, strict data-residency mandates, regulated workloads that prohibit multi-tenant cloud — the free ExaVault on-premise appliance handles SFTP / FTPS / FTP / WebDAV from a self-hosted VM image.

FAQ

Is SFTP more secure than FTPS?

Both are secure when configured correctly. SFTP is harder to misconfigure into an insecure state — encryption is mandatory, key auth is native, and there's no cleartext fallback. FTPS has equivalent cipher strength but more places where a misconfiguration (skipped AUTH TLS, expired cert, weak cipher allowed) can leave traffic exposed.

Which is faster, SFTP or FTPS?

In practice, throughput is close enough that the protocol choice rarely decides it. FTPS can have slightly lower CPU overhead per byte because TLS adds less framing than SSH. SFTP can be faster on many small files because there's only one connection to set up. For typical workloads, network latency and disk I/O dominate either way.

Can I use the same client for both SFTP and FTPS?

Yes. FileZilla, WinSCP, Cyberduck, and Transmit all support both protocols — the choice is a dropdown in the connection dialog. The protocol setting determines which port the client connects on and which handshake it speaks.

What's the difference between FTPS and "FTP over SSL"?

They're the same thing. FTPS is short for "FTP over SSL/TLS" — the protocol is named after the security layer it adds. Some older documentation distinguishes "FTPS" (implicit) from "FTPES" (explicit), but in modern usage "FTPS" usually means explicit FTPS unless specified otherwise.

Does SFTP need a certificate?

No. SFTP uses SSH host keys instead of X.509 certificates. The server has a host key pair; the client trusts it on first connection (via the known_hosts mechanism) and verifies it on every subsequent connection. No CA, no certificate expiration, no cert renewal cron job.

Is SFTP the same as "secure FTP"?

Sometimes the term "secure FTP" is used as a generic label that could refer to either SFTP or FTPS. In strict usage, SFTP specifically means SSH File Transfer Protocol; FTPS specifically means FTP over SSL/TLS. If a vendor uses "secure FTP" without specifying, ask which protocol they actually mean — the implementation differences matter for firewall config and client compatibility.

Can I run SFTP and FTPS on the same server?

Yes — most managed-file-transfer platforms (including Files.com and the ExaVault on-prem appliance) expose both protocols simultaneously on the same backend storage. Self-hosting both is also possible but requires running OpenSSH (for SFTP) plus a separate FTP daemon with TLS support (for FTPS), with shared user accounts and a shared filesystem.