FTPS Explained: Implicit vs Explicit FTPS, Ports 990 and 21, and What the Certificate Does
FTPS is FTP secured with TLS. That one sentence clears up most of the confusion: it is not SFTP, and it is not a new protocol. Here is how the two modes work, which ports they use, what the certificate does, and when FTPS remains the sensible choice in 2026.
FTPS is FTP secured with TLS.
That simple definition clears up most of the confusion around it. FTPS is not SFTP, and it is not an entirely new file transfer protocol. It is the familiar FTP protocol, with commands such as USER, PASS, LIST, RETR, and STOR, running over encrypted connections.
That also means FTPS inherits FTP's biggest complication: it uses separate connections for commands and data. TLS protects those connections, but it does not simplify them. Certificates, passive port ranges, NAT, and firewall rules all become part of the setup.
Here is how FTPS works, why it comes in two modes, and when it remains a sensible choice in 2026.
What FTPS is
FTP has existed since 1971. In its original form, it sends usernames, passwords, commands, directory listings, and file contents without encryption.
FTPS, short for FTP over SSL/TLS and sometimes called FTP Secure, adds TLS protection to FTP. The relevant security extensions first appeared in RFC 2228 in 1997 and were later defined specifically for TLS in RFC 4217.
The underlying FTP workflow does not change. A client still authenticates, requests directory listings, downloads files, and uploads files using standard FTP commands. TLS encrypts those exchanges so that someone monitoring the network cannot read the credentials or the transferred data.
In practical terms, an FTPS server is usually an FTP server with TLS enabled, and an FTPS client is an FTP client that can negotiate TLS. That is why tools such as FileZilla and WinSCP offer FTPS as a connection option rather than as a separate protocol.
Explicit vs implicit FTPS
FTPS comes in two forms: explicit and implicit. They start TLS differently and normally use different ports. Choosing the wrong mode is one of the most common reasons an FTPS connection fails immediately.
| Mode | Default port | When TLS starts | Use |
|---|---|---|---|
| Explicit FTPS, or FTPES | 21 | After the client sends AUTH TLS | The standard choice for modern FTPS |
| Implicit FTPS | 990 | Immediately on connection | Compatibility with legacy systems |
Explicit FTPS
Explicit FTPS connects to the standard FTP control port, TCP 21. The connection begins as ordinary FTP, and the client sends the command AUTH TLS. The client and server then perform a TLS handshake before credentials or any protected FTP commands are exchanged. A properly configured server can require this upgrade and reject clients that try to continue without TLS.
Explicit FTPS is the standardized approach described in RFC 4217. When a modern service says it supports "FTPS," explicit mode is usually what it means.
Implicit FTPS
Implicit FTPS usually listens on TCP port 990. TLS begins as soon as the client connects, before either side sends an FTP command. There is no AUTH TLS upgrade because the connection is encrypted from the first byte.
Implicit FTPS predates RFC 4217 and was never standardized in the same way. It nevertheless shipped in enough commercial products to remain common in long-running financial, healthcare, and government integrations.
A useful rule of thumb: port 21 usually means explicit FTPS, port 990 usually means implicit FTPS, and if a partner says only "FTPS," start with explicit mode and confirm the setting with them. The FTP port post covers the whole port picture across FTP, FTPS, and SFTP.
FTPS needs more than one port
FTP uses two kinds of connection: a control connection for authentication and commands, and a data connection for each directory listing, upload, or download. FTPS keeps this design. Securing the control connection does not remove the need for separate data connections.
After negotiating TLS in explicit mode, an FTPS client normally sends PBSZ 0 and then PROT P. PROT P requests private, TLS-protected data connections. The alternative, PROT C, leaves data connections unencrypted. The protocol allows it, and a secure deployment never wants it.
Each protected data connection performs its own TLS handshake.
Passive mode and port ranges
Most FTPS connections now use passive mode. The server selects a port from a configured range and tells the client where to connect. An administrator might configure TCP ports 50000 to 50100 for passive data connections, and that range has to be allowed through the server-side firewall, forwarded correctly if the server sits behind NAT, advertised with an address the client can reach, and permitted by any restrictive client-side network policy.
When any of those is wrong, login works while directory listings or file transfers hang. This is the classic "FTPS connects, but transfers fail" problem, and the active versus passive FTP post explains the mechanics underneath it.
TCP 989 was historically associated with implicit FTPS data, but modern passive deployments use an administrator-defined high-port range instead.
What the certificate does
During the TLS handshake, an FTPS server presents an X.509 certificate, the same kind of certificate an HTTPS website uses. The client verifies that the certificate is valid for the server's hostname, that a trusted certificate authority issued it, that it has not expired, and that the chain is complete.
These checks do more than enable encryption. They confirm that the client reached the intended server rather than an impostor intercepting the connection.
Public, private, and self-signed certificates
A certificate from a public certificate authority is the easiest option for connections with external partners, because common clients already trust it. A private certificate authority also works when every participant is configured to trust it.
Self-signed certificates are common in older FTPS environments. They are safe when the certificate or its fingerprint reaches the client through a trusted channel and is explicitly pinned. The risky pattern is accepting an unknown certificate at the first connection without verifying it: the session is encrypted, but that first connection is open to impersonation.
Expired certificates are the other frequent cause of sudden failures. An integration runs for months and stops overnight because nobody renewed the server certificate.
Client certificates and mutual TLS
FTPS can also use client certificates. The server requests a certificate from the client during the TLS handshake, and both sides authenticate each other, a model known as mutual TLS. Depending on the server, the client certificate supplements the FTP credentials or maps to a user identity. Banking, healthcare, and other regulated exchanges sometimes require this layer.
Why firewalls struggle with FTPS
Traditional FTP-aware firewalls inspect the control channel, read the server's passive-mode response, and open the required data port just in time. That works only while the firewall can read the FTP commands.
With FTPS, the control channel is encrypted. The firewall cannot see which passive port the server selected, so it cannot open that port dynamically. Administrators solve this with a fixed passive port range allowed through the firewall, and on restrictive client networks, outbound access to that range has to be approved too.
This is one reason SFTP became the easier operational choice. SFTP carries commands and file data over a single SSH connection, normally on TCP port 22, so there is no passive range to configure or troubleshoot. FTPS is secure. It asks for more network coordination.
FTPS vs SFTP
FTPS and SFTP both encrypt file transfers, and their similar names are about where the resemblance ends.
| FTPS | SFTP | |
|---|---|---|
| Underlying protocol | FTP over TLS | SSH File Transfer Protocol |
| Typical control port | 21 or 990 | 22 |
| Connections | Separate control and data connections | One SSH connection |
| Server authentication | X.509 certificate | SSH host key |
| Common client authentication | Password or client certificate | Password or SSH key |
| Firewall setup | Control port plus a passive data range | Usually one port |
An SFTP client cannot connect to an FTPS server, and an FTPS client cannot connect to an SFTP server.
For a new integration, SFTP is the simpler default. FTPS still makes sense when a trading partner already requires it, when a legacy FTP integration needs encryption without a full protocol migration, when an industry or contract names it, or when replacing a working partner integration would create risk for no gain. In business-to-business transfers, compatibility often matters more than elegance. The SFTP versus FTPS post weighs the two for a new deployment, and the FTP versus FTPS versus SFTP comparison covers all three.
Common FTPS problems
Most FTPS failures fall into a handful of categories.
The client is using the wrong mode. A client configured for implicit FTPS cannot connect to an explicit endpoint, even though both use TLS. Confirm the port and the mode together: 21 is usually explicit, 990 usually implicit.
Login works, but listings and transfers fail. That points to the data channel, not authentication. Check that the passive range is open, that NAT forwards the whole range, that the server advertises its public address, and that the client network allows outbound connections to those ports.
The certificate is expired or does not match. Verify the expiration date, the hostname, the trust chain, and the intermediates. Automated renewal only helps if the FTPS service reloads the renewed certificate.
The control channel is encrypted, but the data is not. Make sure the client requests PROT P and the server requires protected data connections. A secure control channel with cleartext transfers defeats the point.
Old TLS versions no longer work. Legacy FTPS systems often depend on retired TLS versions or cipher suites, and connections fail when the other side disables them. The fix is to update the older system, not to re-enable outdated cryptography.
Running an FTPS server yourself
A production FTPS server needs more than a certificate and an open port. Someone maintains certificate issuance and renewal, TLS versions and cipher policies, the passive port range, firewall and NAT rules, the advertised public address, user accounts and permissions, transfer and authentication logs, monitoring, and compatibility with every partner's client. Each item is manageable, and each is a recurring responsibility. Certificate expiration is the one that gets forgotten until a scheduled transfer fails outside business hours.
A managed platform takes over that work. Files.com accepts FTPS, FTP, SFTP, and WebDAV on one hostname, runs the FTPS endpoint and the passive networking on its side, and records every transfer in an audit log you can query. A partner who can only speak implicit FTPS on port 990 connects the way they always have, and your side of the exchange is the same users, folders, and automations you use for every other protocol. The hosted FTP and SFTP service is the starting point.
For a server inside your own network, ExaVault's free appliance runs FTPS, FTP, and SFTP on the same one-hostname model, free for deployments up to 50 users.
Is FTPS still worth using in 2026?
Yes, mainly for compatibility. FTPS provides strong encryption when TLS is configured correctly, certificates are verified, and data connections use PROT P. It remains widely supported and carries many established business integrations.
Its drawbacks are operational rather than cryptographic. Separate data connections, passive port ranges, certificate management, and the two-mode split make FTPS more cumbersome than SFTP. For a new integration, SFTP is easier to deploy and maintain. When a partner or an existing system already depends on FTPS, there is no reason to treat it as insecure or obsolete. Configure it carefully, automate certificate renewal, restrict the passive port range, and monitor the service like any other internet-facing endpoint.
Frequently asked questions
Is FTPS the same as SFTP?
No. FTPS is FTP secured with TLS. SFTP is a file transfer protocol that runs over SSH. They use different authentication systems, connection models, and ports, and they are not interoperable.
What port does FTPS use?
Explicit FTPS normally uses TCP port 21 and upgrades the connection with AUTH TLS. Implicit FTPS normally uses TCP port 990 and begins TLS immediately. File transfers and directory listings also need data connections, usually through a passive port range configured on the server.
Is FTPS secure?
Yes, when it is configured correctly: the client verifies the server certificate, modern TLS versions are required, and data connections use PROT P. A self-signed certificate is secure when it is verified or pinned through a trusted process. Blindly accepting an unknown certificate weakens server authentication.
Should I use explicit or implicit FTPS?
Explicit, unless an existing system needs implicit mode for compatibility. Explicit FTPS is the standardized approach and every current client and server supports it.
Can FileZilla or WinSCP connect to an FTPS server?
Yes. In FileZilla, select FTP as the protocol and choose "Require explicit FTP over TLS" or "Require implicit FTP over TLS." In WinSCP, select FTP as the file protocol and choose explicit or implicit TLS/SSL encryption to match the server. If you would rather have the server appear as a drive than in a transfer window, ExpanDrive mounts FTPS servers in Finder and Explorer in either mode.
Why can I log in but not transfer files?
The control connection is working and the data connection is not. The most likely causes are a blocked passive port range, incorrect NAT forwarding, or a private IP address being advertised to an external client.
Keep reading
- FTP vs FTPS vs SFTP: The Differences That Actually MatterFTP is the original cleartext protocol. FTPS is FTP wrapped in TLS. SFTP is not actually FTP — it's a subsystem of SSH. Here's the real difference, which one to pick for a new deployment in 2026, and why most teams are retiring all three in favor of a managed platform.
- SFTP vs FTPS: How to Pick the Right Secure File Transfer ProtocolSFTP and FTPS both encrypt file transfers but they're very different protocols underneath. SFTP runs over SSH on a single port; FTPS is FTP wrapped in TLS with all of FTP's dual-channel quirks. Here's how each works, the five differences that actually matter, and when each is the right choice.
- FTP Port: What Port Does FTP Run On?FTP uses port 21 for control and port 20 (active) or an ephemeral high port (passive) for data. SFTP uses port 22. FTPS uses port 990 for implicit TLS. Here's the breakdown, the firewall implications, and how modern cloud platforms make the port question obsolete.
- Active vs Passive FTP: How Each Mode Actually WorksActive FTP and passive FTP are two ways the protocol handles its separate data connection — and the choice between them determines whether your transfers work through a firewall. Passive mode is the modern default. Here's why, how each one works, and what to do when the data channel won't open.
- curl FTP, FTPS, and SFTP: Upload, Download, and Script Transfers From the Command Linecurl speaks FTP, FTPS, and, depending on the build, SFTP. The commands for uploading and downloading over each, the flags that matter, why the macOS and Windows curls lack SFTP, how to keep credentials out of the command, and how to run any of it from a scheduled job.