File Transfer Protocol (FTP)

Applies to. FTP matters wherever a file that contains account data moves between systems: settlement files to an acquirer, batch uploads from a back-office system, log shipping from a CDE host. Because plain FTP sends both the login and the file contents unprotected, it is a textbook case of an insecure protocol under 1.2.6, which requires security features to be defined and implemented for any insecure service, protocol or port still in use; the guidance to 1.2.5 names telnet and FTP as its examples. 1.2.5 requires each allowed service, protocol and port, FTP included, to be identified, approved and tied to a business need, and 2.2.4's guidance gives an unused FTP server as an example of the unnecessary functionality that has to be removed or disabled.

Example. A merchant's nightly job sends a reconciliation file containing full card numbers to a processor by FTP over the internet. The FTP password and the card numbers both cross the wire in cleartext. Moving the job to SFTP, or to FTP inside a TLS session, closes that gap. Leaving it on plain FTP means listing it as an insecure protocol under 1.2.6 and adding a security feature that actually protects the credentials and the file, which in practice means encrypting the connection anyway.

Limits. FTP, FTPS and SFTP are three different things. FTPS is FTP inside a TLS session; SFTP is a file transfer service running over SSH and shares nothing with FTP beyond the letters. Both address the cleartext problem; plain FTP does not, whatever firewall sits around it. Using FTP only on an internal network does not make it secure, since anyone on that segment can read the traffic. And a secure transfer protocol does not make the file safe at rest: a file of card numbers left on an FTP server is stored cardholder data and needs Requirement 3 protection.