Why FTP Persists: The Honest Reasons

"Why do we still have FTP?" The new security lead asked it in the tone of someone who had already written the finding. I have given the lazy answer, "legacy," more often than I would like. The honest answer is longer. FTP has been declared obsolete for longer than many administrators have been working. And yet in almost any organization older than a few years it is still running somewhere. There is a scanner uploading to a share, or a partner feed that arrives at four in the morning. There is a batch file with a password in it that nobody has opened since its author left. The usual explanation, that the people running it are careless, is wrong. Worse, it is useless, because it suggests the fix is a lecture.

This article gives the real reasons and treats them with respect. FTP persists for reasons that are mostly economic. Changing it costs something. The cost lands on specific people today, and the benefit is spread thinly across an uncertain future. Each reason below is stated as fairly as its defenders would state it. Then it is given its honest counterweight, because a reason can be real and still not be sufficient. By the end you will be able to classify every FTP flow you own by why it persists. That is the first step toward doing something sensible about it. This is part of our Why FTP Won't Die series. The short history of FTP explains how the protocol got here.

Persistence Is a Cost Comparison, Not a Character Flaw

Every "should we replace this?" decision is a comparison between two costs. The cost of changing is visible, immediate, and yours. It includes hours, a change window, a partner to coordinate, and the chance the new thing fails on its first night. The cost of not changing is probabilistic, diffuse, and mostly somebody else's. It includes a breach that may never happen, an audit finding next year, and the odd support ticket. When one side of the ledger is concrete and the other is abstract, people choose the abstract cost. That is not ignorance. Under a short enough planning horizon it is rational. And most administrators live under short horizons because the ticket queue never empties. The same asymmetry is why the budget rarely arrives before the outage does. The companion piece is why nobody funds file transfer.

Keep that frame in mind. The point is not to defend FTP; the next article adds up what it costs. The point is to explain it accurately, because you cannot retire a protocol you have misdiagnosed. The people who kept FTP running are usually the people who kept the business running. Start from there.

Reason One: The Installed Base

The first reason is sheer accumulation. FTP was the only widely available transfer protocol for a long time. So every organization that automated anything during that time automated it with FTP. Nightly exports from the accounting system. A mainframe job step that pushes a report. Backup scripts. Partner feeds set up by someone who has since retired. Each was written once, tested once, and has run thousands of times since. Nobody counts them, because counting them is itself a project. That project is covered in finding all your FTP. (The count is always higher than the guess. I have never seen it come in lower.)

The installed base is real, and every job in it is work somebody would have to redo. That is a genuine cost, honestly stated.

The counterweight: an installed base is not an asset. It is a liability register. Every FTP job is a migration you have not done yet. The register only grows while the protocol remains the default. The same history also means every FTP operation has an exact analog in SFTP and FTPS (get, put, list, delete, rename). So the migration is mechanical rather than inventive. For many old scripts the work is a client swap. Sysax FTP Automation includes a command-line client, sysaxftp.exe. It is built to stand in for the console ftp client in old batch files while adding FTPS and SFTP. That is the difference between rewriting a job and re-pointing it. Inherited FTP automation has more on such jobs.

Reason Two: Devices That Only Speak FTP

The second reason is the strongest, and the one security guides tend to skip. A great deal of FTP traffic comes not from scripts or people but from embedded devices. This is equipment with a small, fixed operating system baked into firmware. A remarkable number of these devices speak FTP and nothing else:

• Multifunction printers and scanners with a "scan to folder" feature that is really "scan to FTP."
• Security cameras and recorders that upload clips or snapshots.
• Industrial controllers, machine tools, and building-management systems that export logs or accept recipes.
• Laboratory and clinical instruments that write results to a network location.
• Phone systems that fetch their configuration or push call records.
• Network equipment that backs up configuration files and fetches firmware.
• Point-of-sale terminals and kiosks that pull price files overnight.

These devices share three properties. Their firmware is rarely updated and often cannot be. Their manufacturer may have moved on or vanished. And their replacement cycle is measured in a decade or more. They are expensive, physically installed, and sometimes legally validated. In regulated environments, changing how a clinical instrument communicates can trigger a formal re-validation. That re-validation can cost more than the instrument. An administrator who "just keeps FTP for the scanners" is not being lazy. They are respecting a constraint outside their control. I have kept FTP alive for a scanner myself, and would again.

The counterweight: device FTP is the strongest reason but also the narrowest. Device traffic is almost always one-directional, low-volume, internal, and predictable. The scanner uploads to one server, from one address, on one schedule. That makes it the easiest FTP to contain. It can stay on its own network segment, reaching only the server that ingests its files. It can use a unique account that can do nothing else. The devices justify an FTP listener. They do not justify FTP on the internet, or FTP for anything that is not a device. Legacy devices that only speak FTP addresses them directly. The containment pattern is in living with FTP responsibly.

Reason Three: Universal Client Support

Ask any system, any platform, any partner "can you do FTP?" and the answer is yes. Every operating system ships a client. Every programming language has a library. Every mainframe has an FTP subsystem that predates its current operators. When two organizations that have never worked together need to move a file, FTP is the lowest common denominator. It is the one protocol neither side has to install, license, or explain. That is why it became the default for partner exchange, and defaults are sticky.

The counterweight: universal is not the same as good. The clients that make FTP universal are the worst ones in daily use. The built-in console client speaks only active mode and cannot use TLS. See an honest look at the built-in FTP clients for the explanation. That is why so many "universal" setups fail at the first firewall they meet. And SFTP has caught up. It ships with every major operating system. Every mainframe has it, and every language has a library. Every partner who says "FTP only" almost certainly has an SFTP client on the same machine. Universal support is the reason you can migrate, not the reason you cannot.

Reason Four: Simplicity

FTP fits in a person's head. Commands are words. Replies are numbers with text. An account is a username and a password. No keys to generate, no certificates to renew, no trust stores, no host-key prompts that confuse users. When something breaks at two in the morning, FTP is the protocol you can debug by reading the conversation. A session log shows exactly what was said and what the server answered. See FTP commands and reply codes for examples. Anyone who has been burned by a certificate that expired on a public holiday values that simplicity. And they are right to.

The counterweight: the simplicity is the vulnerability. The reason you can read the conversation is the reason an attacker on the path can read it too, password included. And the simplicity is only skin deep. At the firewall, FTP's two-connection design is the most complicated thing on the network. That is why why firewalls block active FTP exists as an article at all. The "complexity" of SFTP, meanwhile, is mostly a one-time setup cost (generate a key, record a host key, done). It replaces a recurring cost in passwords and firewall tickets. Simple to learn and simple to operate are different things. Ask your firewall.

Reason Five: Vendor and Partner Requirements

Sometimes the decision is not yours. A software vendor's product only exports via FTP. A partner's onboarding form has a box for "FTP host" and no other box. A contract signed long ago names the protocol. A larger partner's change control means any alteration on their side takes a quarter and a project code. In every case your side could be ready for SFTP tomorrow and it would not matter. File transfer is bilateral: it happens at the speed of the slower party. An administrator who keeps FTP for one partner because that partner cannot move is not making a technical choice. They are absorbing someone else's constraint.

The counterweight: "FTP only" on a partner's sheet usually means "nobody has asked," not "nothing else is possible." Most partners can offer SFTP or FTPS if the request is made through the right person, with lead time, and in writing. The levers are the moments when the relationship is already being touched: contract renewals, system upgrades, a new integration, an audit on their side. Partner communications covers the conversation. And the partner protocol decision helps you choose what to ask for. The vendor case is harder. But a product that exports only by FTP can often be pointed at a local server that forwards over something better. That turns a vendor constraint into a device-style containment problem.

Reason Six: The It-Works Inertia

The last reason is the most human. Somewhere in your estate there is a job that runs every night, has run for years, and that nobody wants to touch. Its author left. The documentation is the script itself. The business depends on it and does not know it exists. The person who would have to change it knows one thing for certain. If they change it and it breaks, that is their fault. If they leave it alone and something goes wrong, that is "legacy." The risk of changing is concrete and personal; the risk of not changing is abstract and shared. Under that asymmetry, leaving it alone is the sane choice for any individual. That is exactly why it is the wrong choice for the organization.

Kestrel Payroll had such a job. PAYEXPORT.BAT had run every night for longer than anyone on the team had worked there. Its author had retired. The standing instruction was "do not touch it." When a new administrator finally copied it to a test server and ran it in daylight, it did three things. It uploaded the payroll file to the bank. It uploaded the same file to a server decommissioned years earlier (failing silently, nightly). And it emailed a status report to a mailbox that no longer existed. Moving the one live upload to SFTP took an afternoon. The fear had taken four years.

The counterweight: inertia compounds. The job you are afraid to touch this year will be scarier next year. One more person will be gone, and one more undocumented dependency will have grown around it. The cure is not courage; it is a rehearsal. A copy of the job, pointed at a test server, run in daylight, teaches you in an afternoon what the job actually does. And a job you understand is a job you can move. Automation inventory and debt describes the method. And the hit-by-a-bus test is the question to ask about every job only one person understands.

The Reasons and Their Counterweights at a Glance

A Persistence Census for Your Own Estate

The practical use of all this is classification. Once you know why each FTP flow persists, you know what will end it. You also know how urgent it is and how to contain it in the meantime. The census below is a plain-text record for a spreadsheet or a wiki page. It has one entry per flow (one direction of traffic between one source and one destination). If you already keep a transfer inventory, these are extra columns on it. Finding the flows in the first place (port scans, firewall logs, scheduled-task searches) is covered in cleartext discovery. This worksheet starts where discovery ends:

FLOW ID   : ftp-014
SOURCE    : scanner, 3rd floor (10.20.4.31)
TARGET    : ftpsrv01 (10.20.1.8), account scan3f
DIRECTION : upload only
WHAT      : scanned PDFs, ~40/day, internal only
SPEAKS FTP BECAUSE : DEV   (IB=installed base, DEV=device only,
                            UNI=universal client, SIM=simplicity,
                            VEN=vendor/partner, INR=inertia)
COST TO CHANGE     : replace device; no firmware option
EVENT THAT ENDS IT : device refresh, budgeted next cycle
OWNER              : facilities (M. Okafor)
CONTAINED?         : yes - device VLAN, unique account, upload-only,
                     no internet exposure, logging on
NEXT REVIEW        : at device refresh

Two fields do most of the work. Speaks FTP because forces an honest reason rather than "always been that way." A flow that gets two codes (a device and inertia, say) is telling you which one is the excuse. Event that ends it turns persistence into a schedule: a device refresh, a contract renewal, a rewrite already planned for other reasons. Flows with no plausible ending event need a project of their own. Those are the input to the FTP retirement plan.

If the receiving server already speaks the secure protocols too, the census gets a shortcut. A server such as Sysax Multi Server runs FTP alongside FTPS and SFTP on one Windows machine. Its activity logging to a file or a database gives you a record of which accounts still connect over plain FTP. That turns "who still needs it?" from a survey into a log query. The query has a habit of revealing that a flow everyone assumed was still FTP quietly moved years ago. Nobody updated the diagram.

What Persistence Does Not Justify

The reasons above explain why an FTP listener still exists. They do not license everything that tends to accumulate around one. Nothing in the list justifies:

• FTP exposed to the internet. No device needs it, no partner needs cleartext specifically, and a public FTP port is the first thing any scanner finds.
• Shared or reused credentials. A scanner's FTP password should be the scanner's and nobody else's. Never use a domain account or the same password as anything reachable over a better protocol. Device accounts also outlive devices. The article on finding stale and orphaned accounts catches the ones whose scanner went to the recycler years ago.
• Anonymous upload. An open drop is an invitation, whatever the original reason for it, as locking down guest access explains.
• "It's internal, so it's fine." Internal networks carry compromised laptops and curious contractors. Internal is a reason for containment to be possible, not a reason to skip it. Our comparison series draws the line carefully in when plain FTP is acceptable.

The distinction separates two conversations. "Why do we still have FTP?" has honest answers, and this article gave them. "Why is it configured like that?" usually does not, and the fix is cheap.

The Version to Tell Your Manager

Here is the one-paragraph version for a manager or an auditor. FTP persists because changing it costs specific people specific hours today. Leaving it costs the organization an uncertain amount later. And some of it lives in devices and partners we do not control. That is a rational response to the incentives, not a failure of the people involved. The answer is to make the future cost visible and schedule each remaining flow. Contain what cannot move yet, and stop adding to the pile. It beats "legacy," and unlike "legacy" it comes with a to-do list.

The next article, what FTP's persistence costs, makes that future cost visible with a worksheet you can fill in for your own estate. Living with FTP responsibly covers the containment. And why retire FTP opens the retirement program itself.

Frequently Asked Questions