A Short History of FTP and Why It Refuses to Die

Sooner or later, every administrator finds it: an FTP server humming away in a corner of the network, moving files for a process nobody fully remembers setting up. The discovery usually triggers one of two reflexes — "rip it out immediately" or "don't touch it, it works" — and both reflexes, acted on without understanding, cause outages. The better first move is to understand what you found: why this protocol exists, why it is shaped the way it is, and why, despite every obituary written for it, it is still here.

This article is that understanding. It is not a list of dates — FTP's story is really a story about assumptions: the ones its designers reasonably made about their network, the ways the world broke those assumptions, and the surprising durability of a tool that simply refused to stop being useful. By the end, you will be able to look at the FTP in your own environment and judge it on its merits rather than its age — and know what to do about it either way.

This piece is part of our The FTP Protocol series; the other articles cover the machinery in detail, while this one explains where the machinery came from.

Born Before the Network Had Walls

FTP was created in the earliest days of computer networking, on the research network that preceded the internet — a small community of universities and laboratories whose machines could, for the first time, talk to each other at all. It is one of the oldest application protocols still in production use anywhere: older than the web, older than domain names, older than email as we know it. It is so old, in fact, that its first versions ran on the network plumbing that TCP/IP itself later replaced; when the modern internet protocols arrived, FTP was already a veteran that had to be ported over to them.

The problem it was built to solve sounds trivial today and was anything but: move a file from one computer to a completely different kind of computer, intact. The machines of that era disagreed about nearly everything — how many bits made a byte, how text was encoded, how lines ended, how files were even structured. A "file transfer protocol" had to be a diplomat between systems that shared almost no assumptions. That is why FTP has a concept most modern protocols lack: transfer types, the famous ASCII-versus-binary distinction, which let the protocol translate text conventions between unlike systems while leaving binary data untouched. What looks today like a bizarre trap (choose wrong and your file corrupts) was, in context, a genuinely thoughtful feature.

The environment explains the security posture too. The network was a professional community where every connected machine belonged to a known institution. Designing for hostile eavesdroppers would have seemed as strange as encrypting conversation inside your own office. So credentials traveled as readable text, and so did data — not through carelessness, but because the threat model of the day made that a reasonable choice. The same trusting spirit shaped the protocol's most distinctive structure, the separation of the command conversation from the data stream — a design covered in depth in our two-channel architecture article — including the assumption that a server could freely open a connection back toward a client, since every machine was reachable by every other.

Even the name is a small museum piece: the bland literalness of "File Transfer Protocol" dates from an era when protocols were named like laboratory equipment. Our blog post What does FTP stand for? unpacks the name for readers meeting it fresh.

The Ideas FTP Taught Everything After

It is easy to catalogue FTP's flaws from the present. It is more useful to notice how much of the modern internet learned its manners from FTP, because several of its inventions became permanent fixtures:

• The three-digit reply code. FTP established the pattern of numbered, machine-readable responses with a category system baked into the digits. The mail protocols adopted the convention, and the web's status codes carry the same family resemblance — if 550 and 404 feel like cousins, that is because they are.
• The client-server file service. The idea that a machine could offer its files as a service — with login, navigation, and structured requests, rather than raw disk access — was FTP's core contribution, and it is the ancestor of every download server and cloud storage endpoint you use today.
• Anonymous public distribution. The convention of a guest account, open to all comers for fetching published files, made FTP the world's first public download infrastructure. Long before web downloads existed, entire software cultures — freeware, shared academic datasets, operating system distributions — moved through anonymous FTP archives. The "download page" is that idea wearing modern clothes.
• Human-readable wire protocols. An FTP session can be read, and even conducted, by a person with a raw network connection. That transparency set a debugging culture — the expectation that an administrator could watch a protocol work — which shaped generations of text-based protocols after it.

A protocol this influential does not persist out of nostalgia. It persists because it was, for a very long time, the standard way computers exchanged files — which brings us to the age of ubiquity.

The Age of Ubiquity

For a long stretch of networking history, FTP was not a way to move files; it was the way. Operating systems shipped FTP clients as standard equipment. Web browsers spoke ftp:// URLs natively. Websites were published by uploading files over FTP to a hosting provider — for many people, "knowing FTP" was the practical definition of knowing how to put something on the internet. Hardware vendors distributed drivers from FTP servers; universities ran vast public archives; "the FTP site" entered ordinary office vocabulary the way "the shared drive" did later.

Ubiquity had a consequence that explains almost everything about FTP's present: it got embedded. When every platform speaks a protocol, product designers reach for it by default. FTP client code was compiled into printers, scanners, cameras, industrial controllers, medical instruments, network equipment, and business software. Batch scripts by the hundred thousand were written around it. Partner agreements specified it. Each of those decisions was individually sensible — FTP was the lingua franca — and each one planted the protocol somewhere it would prove very hard to remove.

The Assumptions That Aged Badly

Then the network changed underneath the protocol. The internet grew from a professional neighborhood into a hostile public space, and one by one, FTP's founding assumptions failed. The fair way to tell this part is as a table of assumptions, not a list of blunders — every one of these was reasonable when it was made:

The second row deserves special mention because it produced FTP's most famous operational headache: the active-versus-passive mode split, a workaround grafted onto the protocol so it could survive a world of firewalls and address translation. That story has its own series, beginning with active vs passive FTP explained and why firewalls block active FTP. The remaining rows — corruption, silent failure, and friends — are catalogued with fixes in FTP's failure modes.

The industry's answer to the trust problem was not one successor but two, and the distinction still confuses people daily: FTPS wraps the original FTP protocol in TLS encryption, keeping its structure while protecting its contents, and SFTP is a different protocol entirely, built on SSH, that happens to have a similar name. Each has its own series in this library — FTPS in depth and SFTP in depth — and choosing among the three is the subject of SFTP vs FTPS vs FTP.

Where FTP Survives, and Why

Mainstream web browsers eventually dropped support for ftp:// links, and public-facing FTP has largely given way to web downloads and encrypted transfer. So where is all the FTP that keeps showing up in audits? In a handful of durable niches, each surviving for its own logical reason:

• Embedded devices and appliances. The office copier that scans documents to a network folder very likely speaks FTP. So do security cameras exporting footage, lab instruments exporting results, industrial controllers on factory floors, and network equipment saving configuration backups. The FTP client in these devices is compiled into firmware; it cannot be upgraded to something newer, and the device may outlive three generations of the IT staff who manage it.
• Partner exchanges older than everyone in the room. Business-to-business file feeds — orders, invoices, inventory files — often standardized on FTP when the connection was first built, and changing a working exchange requires two organizations to schedule, test, and cut over together. Working agreements have enormous inertia; nobody wants to be the party that broke the feed.
• Internal batch pipelines. Somewhere in most established companies, a nightly job started by an administrator long since departed still moves files by FTP between internal systems. It works, it is invisible, and nobody currently employed wrote it — a situation so common we wrote a whole guide to reading the FTP automation you inherited.
• Mainframe and midrange ecosystems. The big iron that runs banking, insurance, and logistics grew up with FTP as a first-class citizen, and the batch cultures around those platforms still lean on it heavily.

Notice the common thread: in every niche, FTP persists where the cost of changing is high and the party that would change it is not the party inconvenienced by it. Protocols do not die when something better arrives. They die when the last device and the last contract that depend on them die.

Why It Refuses to Die

Beyond inertia, FTP holds genuine advantages that keep it in service, and honesty requires listing them:

• Universality. Every operating system, programming language, and scripting environment can speak FTP, usually with tools already installed. No other transfer protocol has coverage that complete.
• Simplicity and transparency. A junior administrator can read an entire FTP session in a log or capture and understand it — a property this series leans on constantly. Debugging opaque protocols is harder work.
• Interoperability across generations. A brand-new client can talk to a decades-old server and the reverse. Backward compatibility of that depth is rare and valuable in environments full of old equipment.
• It genuinely works. Within its limits, FTP moves files reliably and fast, with negligible overhead. A protocol that quietly does its job for decades earns a certain kind of trust, even from people who know its flaws.

An Honest Risk Framing

Now the part that gets shouted about, framed the way an engineer should frame it. FTP's real security problems are specific and finite: credentials cross the network readable by anyone positioned to capture traffic; file contents cross the same way; there is no built-in integrity verification; and an internet-exposed FTP service is a standing invitation to password-guessing. Those are the actual risks. Everything else you have heard is a variation on them.

Whether those risks matter depends entirely on exposure. The same protocol is a different proposition in different places:

• A scan-to-FTP copier delivering documents to a server on an isolated internal VLAN, using an account that can write to exactly one folder, carries modest risk that containment handles well.
• The same protocol carrying payroll files across the public internet, with a password that is also used elsewhere, is a genuine incident waiting for a capture point.

When you find an FTP flow — during an audit, a migration project, or a 2 a.m. incident — the following checklist turns "we still have FTP" into a decision. Work through it once per flow and write the answers down:

1. What does it carry? Public price lists and office scans are one conversation; credentials, personal data, and financial records are a different one entirely.
2. What networks does it cross? A single isolated VLAN, the corporate WAN, or the public internet — exposure, and therefore urgency, rises sharply at each step.
3. Who can reach the server? A handful of known devices, everything inside the firewall, or the whole world. Firewall rules answer this precisely.
4. What can the account do? Write to one inbound folder, or roam the entire filesystem? Least privilege turns a captured password into a small problem instead of a breach.
5. Is the password unique to this flow? A captured FTP password that is reused on other systems converts a minor compromise into a major one.
6. Can the far end speak anything better? If the device or partner supports FTPS or SFTP, schedule the upgrade. If it genuinely cannot, document why and contain it instead.

The pragmatic playbook, in order: inventory every FTP flow you actually have, including the embedded devices that never appear in documentation. Contain what cannot change — isolated network segments, dedicated accounts locked to single folders, no reused passwords. Encrypt what talks across trust boundaries, moving exposed flows to FTPS or SFTP. Migrate deliberately, one flow at a time, as devices retire and partner agreements come up for renewal. A practical detail that softens the whole journey: modern server software speaks the old and new protocols side by side — Sysax Multi Server, for example, serves FTP, FTPS, and SFTP from one Windows installation, so the legacy copier and the encrypted partner feed can coexist on one server while migration proceeds account by account, on your schedule rather than in one risky weekend.

Judging the Veteran Fairly

The story compresses to this: FTP was built for a trusting network by people solving real interoperability problems, it succeeded so completely that it embedded itself in the world's devices and business processes, the network then turned hostile around it, and the industry responded with encrypted successors while the original soldiered on in the niches where change is expensive. None of that makes FTP shameful, and none of it makes FTP safe by default. It makes FTP a tool with a context — and administrators are paid to know the context.

So respect the reader — perhaps you — who still runs it, and pair that respect with competence: learn how its two channels actually work, keep the failure modes field guide within reach, and if you want to explore the protocol hands-on before touching production, build the safe playground from our FTP lab guide. A protocol this old rewards being understood rather than merely feared.

Frequently Asked Questions