What does FTP mean, and is the File Transfer Protocol still safe?

FTP stands for File Transfer Protocol, the standard from RFC 959 for moving files between computers over TCP. Plain FTP sends commands and, by default, credentials without encryption, so for anything sensitive use FTP over TLS or SSH based transfer instead.

What was FTP designed to do?

RFC 959, dated October 1985, lists four objectives: to promote sharing of files, to encourage indirect or implicit use of remote computers through programs, to shield a user from variations in file storage systems among hosts, and to transfer data reliably and efficiently. It is designed mainly for use by programs, though a person can use it directly.

Nothing in those objectives mentions confidentiality. The protocol is from an era of small trusted networks.

How does an FTP session work?

FTP uses two kinds of connection. The control connection carries commands and replies. The RFC says it is established over TCP to the server's service port 21. Data moves over a separate data connection, opened for each transfer.

The login sequence uses a USER command and a PASS command, with the password carried as a text string. The specification also describes active and passive handling: the server's data port may "listen" for the client to connect, and the PASV command asks the server to identify a data port. Those separate, changing data ports are why FTP has long been awkward to place behind firewalls.

What is wrong with plain FTP?

Because the base protocol has no encryption, anyone who can observe the network path can read the commands, the credentials, and the file contents. That is the basic reason it is discouraged for sensitive transfers. It is a property of the design, not a bug in a given server.

Anonymous access, weak or shared accounts, and leftover test servers add practical risk. Old FTP services also tend to sit untouched, which makes them easy targets in an inventory review.

What are the safer options?

RFC 4217, Securing FTP with TLS, specifies how FTP uses TLS, with an AUTH command to negotiate it and protection for the data connection. Secure Shell is a different protocol: RFC 4251 describes it as a protocol for secure remote login and other secure network services over an insecure network, and SFTP is the file transfer service built on top of it. Despite the name, SFTP is not FTP inside SSH. It is a separate protocol with its own design.

There is also a firewall angle. Because FTP opens separate data connections, firewalls that do not understand the protocol can block transfers or be configured too loosely to make them work. Opening a wide range of ports to fix a failing upload is a common shortcut, and it leaves that range open long after the original problem is forgotten.

A constructed example

A small manufacturer lets a supplier upload parts drawings to an old server on port 21. During a review, the team finds the supplier's account shares a password with two employees, the server allows anonymous listing, and the logs show it has not been patched in years. They move the supplier to SFTP with a per-user key, disable the old service, and keep a note of the date. The upload tool needed one setting changed.

How to check or apply this

1. Scan your own address ranges for anything listening on port 21 and note the owner of each.
2. For each service, find out what data it carries and who uses it.
3. Disable anonymous access unless there is a documented, public reason.
4. Move sensitive transfers to FTP over TLS or to SFTP, and use individual accounts, with keys where possible.
5. Retire servers that nobody can explain.
6. If you must keep plain FTP on a closed network, restrict it by address and log all access.
7. Remember third parties. Ask vendors how they send you files.

Quick check

Sources

• RFC 959: File Transfer Protocol (FTP)
• RFC 4217: Securing FTP with TLS
• RFC 4251: The Secure Shell (SSH) Protocol Architecture

Last reviewed: 18 October 2026.