Port 990: FTPS (Implicit) — The encrypted FTP that predates the RFC

Port 990 is where implicit FTPS lives. When an FTP client connects to port 990, the SSL/TLS handshake happens immediately—before any FTP commands are sent, before any credentials are exchanged. The connection is encrypted from the first byte.

This is different from explicit FTPS, which starts as plain FTP on port 21 and upgrades to encryption via the AUTH TLS command. With implicit FTPS, there is no upgrade. You connect to port 990, and encryption is simply assumed.

How Implicit FTPS Works

The workflow is straightforward:

1. Client connects to port 990 (control channel)
2. SSL/TLS handshake happens immediately
3. Once encrypted, FTP commands flow over the secure connection
4. File transfers use port 989 (data channel), also encrypted from the start

No negotiation. No choice. You connect, you encrypt, you proceed. This is why it's called "implicit"—the encryption is implied by the port number itself.

The RFC That Never Was

Here's the strange part: implicit FTPS was never formally defined in an RFC.

RFC 4217 ("Securing FTP with TLS") only describes explicit FTPS—the method where a client connects to port 21 and negotiates encryption. Implicit FTPS simply existed before RFC 4217 was written. It worked. People used it. IANA assigned it port 990 and port 989. And it became a de facto standard without ever being blessed by the formal standards process.¹

This is how the Internet actually evolves sometimes. The thing that works becomes the thing people use, and eventually it gets a port number, whether or not it ever gets an RFC.

Why It's Deprecated

Implicit FTPS is considered legacy now, and explicit FTPS has generally overtaken it in new implementations.²

Why?

• Less flexible — You can't serve both encrypted and unencrypted clients from the same port
• Dual ports required — You need both 990 (control) and 989 (data) open and properly configured
• Not in the RFC — RFC 4217 doesn't even mention implicit FTPS, making it harder to justify in modern implementations³
• Firewall complexity — FTP's active/passive modes already make firewall rules complicated; implicit FTPS doubles the problem

Explicit FTPS (port 21 with AUTH TLS) became the preferred standard because it allows a single port to serve both secure and insecure clients, and it's actually documented in the RFC.

Why It Still Exists

Despite being deprecated, port 990 remains in use due to its simplicity and compatibility with older systems that were built before explicit FTPS became the standard.²

Some organizations never migrated. Some vendors still default to implicit FTPS. Some legacy systems can't be updated. And so port 990 keeps carrying encrypted file transfers, decade after decade, even though the protocol was never formally blessed.

It works. That's enough.

Security Considerations

Implicit FTPS is more secure than plain FTP (which sends passwords in cleartext), but it has problems:

• Outdated TLS versions — Older implementations may use deprecated TLS versions that are now considered weak⁴
• Certificate validation issues — Many clients don't properly validate certificates, opening the door to man-in-the-middle attacks
• FTP protocol vulnerabilities — Encrypting FTP doesn't fix FTP's inherent design problems (active/passive mode complexity, credential transmission)

If you're starting fresh, don't use FTPS at all—implicit or explicit. Use SFTP (SSH File Transfer Protocol) on port 22 instead. SFTP has overtaken FTPS in popularity due to its simplicity and efficiency.⁵

Related Ports

• Port 989 — FTPS data channel for implicit mode (port 990's partner)
• Port 21 — Standard FTP control channel, also used for explicit FTPS via AUTH TLS
• Port 22 — SSH/SFTP, the modern replacement for both FTP and FTPS
• Port 20 — FTP data channel in active mode

Checking What's Listening

On Linux/macOS:

sudo lsof -i :990
sudo netstat -an | grep 990

On Windows:

netstat -an | findstr 990

If you see something listening on port 990, it's almost certainly an FTP server configured for implicit FTPS.