Is port 21 (FTP) exposed to the internet, and is that a credential risk?

Why FTP’s own design is the risk

FTP predates modern transport encryption by decades, and it shows in the protocol’s own specification. RFC 959, the document that defines FTP, describes the USER command as identifying “the user required by the server for access to its file system” and the PASS command as carrying “the user’s password” immediately after it — both sent as plain text over the control connection. The RFC is explicit that it has no technical fix for this: it says only that “it is therefore the responsibility of the user-FTP process to hide the sensitive password information” from being displayed on screen, which is about hiding a password from someone looking over a shoulder, not about encrypting it on the wire. Four decades later, that’s still exactly how an unmodified FTP server authenticates a login.

Why general server-security guidance treats this as a known risk

This isn’t a niche reading of an old document — it’s the standard framing in modern server-hardening guidance. NIST SP 800-123, the Guide to General Server Security, covers exactly this category of risk under its system and communications protection guidance: authentication protocols that transmit reusable credentials like passwords in the clear over a network you don’t fully control are a well-established weak point, because anyone positioned to observe that traffic — on a shared network, a compromised intermediate hop, or through basic packet capture — reads the username and password as plainly as the legitimate client does. A password that would be reasonably safe behind TLS or an SSH tunnel is not safe at all carried by FTP’s original control channel.

How to check your own exposure

AdminKit’s open ports check tests whether port 21 on your own public IP responds from outside your network, with your consent and only against the IP making the request — confirm your current public IP first with what is my IP. If port 21 answers and the server behind it accepts plain FTP logins rather than FTPS, every credential used against it is traveling exactly as RFC 959 describes: in the clear.

How to fix it

• Migrate transfers to SFTP, which runs over SSH and gets that protocol’s existing encryption and key-based authentication, or to FTPS, which wraps the original FTP commands in TLS — either removes the cleartext-credential problem RFC 959 never solved.
• Remove anonymous or shared FTP accounts entirely; a shared login multiplies how many places a plaintext password can leak from.
• Firewall port 21 to only the specific source IP ranges that still need it while you migrate, rather than leaving it open to the whole internet in the meantime.
• Audit for forgotten FTP services on older appliances, NAS devices and legacy backup tools — plain FTP often survives longest on infrastructure nobody thinks to revisit.
• If a third party still requires plain FTP for a legacy integration, treat the credentials as already compromised: use a dedicated account with the minimum access that one integration needs, not a shared login that also reaches anything else.

None of this requires giving up file transfer over the internet entirely — it requires giving up the one part of FTP, RFC 959’s unencrypted USER/PASS exchange, that the protocol’s own authors never solved.

This same logic — a protocol with no encryption of its own, still found running on more devices than expected — is also why this site covers exposed Telnet devices: different protocol, same root cause.

Defensive use only

Every check this page links to is for assets you own or are explicitly authorized to test. Never scan, probe, or attempt to connect to a network or device you don’t control — AdminKit’s active checks only ever run against the IP making the request or an asset you’ve verified ownership of. See our Disclaimer and Acceptable Use Policy for the full terms.

This guide is general information, not a security audit of your specific network — see our disclaimer for what AdminKit's guidance does and does not commit to.