Why Plain FTP Has to Go (and How to Say It)

Somewhere on your network, plain FTP is probably still running. Maybe it is a server a predecessor set up, a nightly script that has worked flawlessly for years, or a partner exchange nobody wants to reopen. You already suspect it should go. The hard part is rarely the technology — modern servers and clients speak SFTP and FTPS fluently. The hard part is getting your organization to decide, fund, and finish the retirement.

That decision needs a case, and the case has to be written in language the people approving it actually use: risk, obligation, cost, and proof. This article gives you that case. First the technical facts, stated plainly enough to repeat in a meeting without notes. Then the compliance and insurance pressure that has quietly turned FTP from "old but fine" into "flagged on every questionnaire." Then a one-page business case template you can copy, adapt, and send. This is the opening article of our Retiring Plain FTP series, which covers the whole program from discovery to final proof.

What Plain FTP Actually Sends Across the Wire

Plain FTP — FTP without any encryption layered on it — moves everything in cleartext, meaning the bytes travel across the network exactly as typed, readable by any equipment or software that can observe them in transit. That covers three things worth naming separately, because each one matters to a different person in your organization:

• Credentials. The username and password travel as readable text at the start of every session. In a packet capture — a recording of network traffic — the line literally reads PASS secret123. Anyone or anything positioned on the network path sees the password itself, not a scrambled version of it.
• File contents. Every file transferred — invoices, payroll extracts, medical results, configuration backups — crosses the network as readable bytes. If the file is sensitive on disk, it is equally sensitive in flight, and plain FTP does nothing to protect it there.
• Everything else. Directory names, file names, and the commands themselves are visible too. Even metadata tells a story: an observer learns which systems exchange files, when, and how often.

Two quieter gaps ride along with the cleartext problem. Plain FTP gives the client no way to verify it is talking to the real server — no certificate, no host key — so a machine that can redirect traffic can impersonate your server and quietly collect uploads and passwords. And nothing in the protocol detects whether a file was altered in transit. Encrypted protocols fix all three problems at once, which is why the fix is a protocol change rather than a patch; the mechanics are covered in our encryption in transit series.

Now the honest framing, because the case collapses if it sounds like fear-mongering. The risk is not that attackers lurk on every cable. It is that you cannot enumerate who can see the path. Traffic between two machines may cross switches, wireless links, VPN concentrators, carrier equipment, and — the case that actually bites — any compromised device that has found a way to observe traffic on your own network. A password sent in cleartext needs to be observed exactly once. After that, the observer does not need to attack anything; they log in with valid credentials, indistinguishable from the real user. That single property — one silent observation converts into durable, legitimate-looking access — is the whole technical case in one sentence.

How It Survived This Long

If plain FTP is that exposed, why is it still everywhere? Understanding this helps you tell the story internally without blaming anyone — which matters, because the person who set up the FTP server may be in the room, and may be you. FTP survives because it is reliable and invisible: a working flow can run for a decade without a ticket, so nobody looks at it. It is compatible with nearly every device, language, and legacy application, so it became the default glue between systems. And it predates the expectation of encryption — when these flows were built, cleartext on a private network was simply how things were done. Nobody chose insecurity; they chose the tool that worked, and the world changed around it.

That history also explains why retirement is a project rather than a setting. The protocol is entangled with scheduled jobs nobody owns, devices with FTP burned into firmware, and partners who configured their side years ago. Untangling those is what the rest of this series does — finding every flow, sequencing the retirement, and handling the special cases. This article's job is only to win the decision to start.

The Risk, Translated Into Business Language

Technical people tend to present the FTP problem as "cleartext credentials," and leadership tends to hear "IT wants to change something that works." The translation layer is where most business cases fail. Here is each technical fact restated as the business consequence it creates:

Notice what this table does not say: it does not claim an incident is likely this quarter, and it does not attach an invented dollar figure. Leadership has sat through inflated risk math before. The stronger move is to present exposure honestly — low-probability on any given day, silent when it happens, expensive when it surfaces — and pair it with the genuinely modest cost of closing it. For a structured way to reason about which flows carry how much risk, our transfer threat modeling series supplies the vocabulary.

The Compliance and Insurance Pressure

Even organizations unmoved by risk arguments are moved by obligations, and this is where the ground has genuinely shifted. Plain FTP now trips three separate external tripwires.

Regulatory and contractual frameworks

Most data-protection regimes require encryption in transit — the general obligation to protect data while it moves — for the data they govern. Card-payment standards require it for cardholder data crossing open or untrusted networks. Health-data rules treat transmission security as a required safeguard. Privacy regulations phrase it as "appropriate technical measures," and regulators and assessors consistently read encryption in transit into that phrase. Customer contracts increasingly say it outright in their security schedules. The common shape: nobody wrote "FTP is forbidden," but plain FTP fails the requirement each framework does write. An auditor who finds port 21 open with production data flowing through it has an easy finding, and easy findings get written up every single audit cycle until fixed — which means an unretired FTP server is a recurring cost in audit time and remediation-plan paperwork even if nothing ever goes wrong.

Security questionnaires

If your organization sells to other businesses, you fill in their security questionnaires, and nearly all of them ask some version of "Is data encrypted in transit?" Answering yes while plain FTP carries customer files is a misstatement to a counterparty; answering no loses deals. Sales teams discover this mid-deal, which is why a quiet retirement finished before the question arrives protects revenue. This argument often lands faster than any risk argument, because it attaches to income rather than hypotheticals.

Cyber insurance

Cyber-insurance applications ask about encryption in transit too, and the answers are not casual: they become part of the application record the policy is issued on. Misstating a control can complicate or jeopardize a claim precisely when you need the policy to perform. Insurers also increasingly scan applicants externally — an FTP banner on an internet-facing address is visible to them the same way it is visible to anyone. The defensible position is simple: retire plain FTP, document the handful of contained exceptions honestly, and let every questionnaire answer be true without a footnote.

What Retirement Actually Costs — and What Keeping It Costs

A credible business case prices both sides honestly. Start with the good news: the destination usually costs little. The secure successors — SFTP (file transfer over the SSH protocol) and FTPS (FTP wrapped in TLS encryption, the same layer that protects web traffic) — are served by the same class of software you already run. A Windows file transfer server such as Sysax Multi Server speaks FTPS, SFTP, and HTTPS alongside FTP from one installation, so the encrypted endpoint typically stands up beside the old one on hardware you already own. Client-side, every mainstream tool and library speaks the secure protocols; scheduled jobs can be repointed rather than rewritten, and a scheduling tool like Sysax FTP Automation runs the same transfer over SFTP or FTPS by changing the connection profile, not the job logic.

The real cost is coordination time, and it is honest to say so: discovering every flow, converting scripts, notifying partners and giving them test windows, and containing the rare device that cannot upgrade. For a mid-size estate this is weeks of part-time effort spread over a few months — bounded, schedulable, and mostly done in ordinary working hours. The technical playbook for the conversion itself is already written in our FTP-to-SFTP/FTPS migration guide; your case is only asking leadership to fund the organizational wrapper around it.

Against that, the cost of keeping FTP: a standing exposure that converts one network observation into valid credentials; a recurring audit finding; a questionnaire answer that is either damaging or untrue; an insurance application with a soft spot; and — the underrated one — the growing scarcity of people who want to maintain it. None of these carries a precise price tag. All of them are recognizable to anyone who has watched an incident, an audit, or a renewal go sideways.

Writing the Business Case

With the facts assembled, the writing itself follows a few rules that experienced administrators learn the hard way:

• One page. A business case that requires scrolling gets skimmed. Everything above is background for you; the page itself carries only conclusions.
• Risk language, not protocol language. "Passwords and file contents cross our network readable" survives the meeting; "FTP lacks TLS" does not. Never assume the reader knows what FTP is.
• No fear, no drama. One measured sentence about exposure outperforms a paragraph of breach headlines. You are asking for a routine risk decision, not sounding an alarm.
• A concrete ask. Name the decision you want: approve the program, name an owner, endorse a target completion window. A case without an ask produces agreement and no action.
• Pre-answer the objections. The likely pushbacks are predictable (next section). Answering them in advance signals you have done the thinking.

Here is the one-pager. Copy it, replace the bracketed parts with your numbers from the discovery work, and delete anything that does not apply. It deliberately avoids naming technologies until the "proposal" line, because the decision-maker is approving a risk fix, not a protocol.

BUSINESS CASE: RETIRING UNENCRYPTED FILE TRANSFER (PLAIN FTP)

THE ISSUE
Several of our file transfer flows use plain FTP, a protocol that sends
passwords and file contents across the network in readable form. Anyone
able to observe the network path — including a compromised machine on
our own network — can read credentials and data directly. A password
observed once grants working access that looks legitimate in our logs.

CURRENT EXPOSURE (from our inventory)
- [N] FTP flows identified: [N] internal, [N] with external partners
- Data crossing these flows includes: [e.g. customer invoices,
  payroll extracts, system backups]
- [N] flows carry data covered by [regulation / customer contract]

EXTERNAL PRESSURE
- [Auditor / assessor] has flagged unencrypted transfer [or: would
  flag it under (framework) at our next assessment]
- Customer security questionnaires ask whether data is encrypted in
  transit; today the accurate answer is "not always"
- Our cyber-insurance application asks the same question

PROPOSAL
Retire plain FTP in phases: move each flow to an encrypted equivalent
(SFTP or FTPS — same workflows, encrypted connection), coordinate
partner cutovers with notice and test windows, and isolate the [N]
devices that cannot upgrade behind documented controls. Existing
server infrastructure supports the encrypted protocols; no new
platform purchase is required.

COST
- Estimated effort: [N] hours over [N] months, [role names]
- Software/hardware: [none / minor — specify]
- Partner impact: notice plus a test window per partner; no workflow
  changes beyond new connection settings

RISK OF NOT ACTING
- Standing credential and data exposure on [N] flows
- Recurring audit finding; questionnaire and insurance answers that
  are either inaccurate or damaging

DECISION REQUESTED
Approve the retirement program, name [name] as owner, and endorse a
target completion window of [quarter]. Progress reported [monthly].

Two notes on using it. First, the exposure numbers should come from a real inventory — even a rough first pass — because "several flows, we think" ends the meeting with "come back when you know." The discovery article gets you real numbers in days. Second, resist padding the risk section; its restraint is what makes it credible.

Objections You Will Hear, and Honest Answers

Every FTP retirement case meets the same handful of objections. None of them is foolish, and each has an honest answer — which is worth preparing, because a defensive or dismissive response costs you the room.

"It's internal only — nobody outside can see it." Internal networks carry contractor laptops, guest devices, and occasionally compromised machines, and most incidents involve an attacker moving around inside after a foothold. Encryption in transit exists precisely so you need not vouch for every device on every path — and "internal" quietly becomes "reachable through the VPN, the wireless network, and the site-to-site link to the acquired company."

"We've had FTP for twenty years and never had an incident." Possibly true — and unverifiable, which is the actual problem. Reading cleartext traffic leaves no trace, and captured credentials walk in through the front door as a normal login. "No incident" here means "no incident we could have detected."

"Our partner requires FTP." Sometimes said, rarely still true. Most partners added SFTP or FTPS support long ago, and many are relieved when the other side proposes moving — someone has to go first. For the genuine holdouts, the partner communication article covers notices, test windows, and handling laggards without burning the relationship.

"This device only speaks FTP and the vendor is gone." Real, and the program has a lane for it: the device keeps its FTP, but confined to an isolated network segment where the cleartext hop is short and observed, with a secure relay carrying files onward — plus a signed risk acceptance so the exception is a decision, not an accident. That pattern is the subject of the containment article.

"It's too disruptive — these flows are business-critical." Criticality is the argument for the program: the flows most worth protecting are the ones least acceptable to leave readable. Disruption is managed like any migration — run old and new side by side, verify, then cut over — and that sequencing is exactly what the retirement plan article lays out.

"Is plain FTP ever acceptable?" A fair question with a narrow answer — genuinely public downloads and a few contained corners. We treat it honestly in when plain FTP is acceptable; citing it shows you have weighed the counterargument, which strengthens the case.

From Yes to a Program

When the case lands, what you have won is permission to run a program, and programs succeed on structure. The path from here: build the complete inventory of every FTP flow you own, sequence the retirement with easy wins first and parallel runs before each cutover, give partners notices and test windows, contain the unupgradeable devices behind signed exceptions — and finish by proving cleartext FTP is gone, not merely assuming it.

Each step has its own article: start with finding every plain-FTP flow you own, then build the retirement plan. Keep the business case document alive as you go — inventory numbers update it, and the final verification closes it with evidence. The strongest sentence you will ever add to it comes at the end: "this exposure no longer exists, and here is the proof."

Frequently Asked Questions