When a Device Only Speaks FTP: Containment

Every FTP retirement eventually meets the device. A multifunction printer that scans to FTP and nothing newer. A lab instrument whose export module was written for a protocol landscape two decades gone. A machine controller, a badge system, a video recorder — equipment that does its real job perfectly and will never, under any firmware, learn SFTP. The retirement program built in this series converts scripts, moves users, and migrates partners, but none of those plays works here: the FTP client is burned into the device.

You have three honest options: replace the device (sometimes right, often absurdly expensive for a protocol problem), pretend not to see it (which quietly falsifies every "we retired FTP" claim you will ever make), or contain it — keep the device's FTP, but shrink the distance its cleartext travels to a short, isolated, watched hop, and carry the files onward encrypted. This article is the containment playbook from our Retiring Plain FTP series: the isolation segment, the local-drop-and-secure-relay pattern, the monitoring around it, and the risk-acceptance memo that turns an awkward leftover into a governed, documented exception.

Why Some Devices Never Upgrade

It helps to understand why this category exists, because the explanation shapes the fix. Embedded devices carry their network stack in firmware — software written into the device by its manufacturer, updated only when the manufacturer ships a new version. When FTP support was added to these products, it was the obvious choice: universally understood, trivial to implement on a small processor. Then the products shipped, the engineering teams moved on, and three durable situations emerged:

• The frozen product. The device still sells or still works, but its firmware line stopped receiving features long ago. Security protocols require real cryptographic machinery — key storage, algorithm updates — that old hardware may not even have room for.
• The absent vendor. The manufacturer was acquired, discontinued the line, or no longer exists. There is no one to ship an update even in principle.
• The validated system. In regulated environments — laboratory, medical, industrial — the instrument and its software were validated as a unit, and any change, including firmware, triggers a costly revalidation. The organization chooses not to update, rationally, because the change process costs more than the device.

Notice what these have in common: the device is not broken, and the people who bought it did nothing wrong. That framing matters when you write the risk memo later — containment is not a cleanup of someone's mistake; it is the engineering answer to equipment outliving the protocol assumptions of its era.

First, Verify It Truly Cannot

Before any device earns a containment exception, spend an hour confirming the constraint is real. "It only does FTP" is often folklore that predates the current firmware. Work the list:

• Check the installed firmware against the vendor's latest. Scan-to-SFTP and scan-to-SMB arrived in later firmware for many multifunction printers; an update may dissolve the problem outright.
• Read the device's own menus and manual. Export options are sometimes hiding under different names — network folder (SMB), email, WebDAV, or an HTTPS upload. Any of those beats containing plain FTP.
• Ask the vendor, if one exists. A support question costs nothing, and some vendors sell an add-on module or a newer export license for exactly this reason.
• Check the direction of the flow. Some devices can be pulled from instead of pushing: if the instrument writes to internal storage a nearby machine can fetch securely, the FTP client never needs to run at all.

Only when this check comes back empty does the device enter the containment lane of the retirement plan. Record the verification in the inventory — the memo you write later will cite it under "alternatives considered."

The Containment Principle: Shrink It, Don't Bless It

Be precise about what containment does and does not claim. It does not make the device's FTP secure — the credentials and file contents on that hop remain readable to anything that can observe them. What containment changes is who could possibly observe them. Uncontained, the device's cleartext crosses your general network, visible in principle to any compromised machine along the path, and often crosses the internet to a partner. Contained, the cleartext exists only on a short hop inside a segment that contains exactly two parties — the device and a relay — with everything beyond that hop encrypted, and the segment itself watched for anything unexpected.

Three properties define done: the cleartext hop is as short and as isolated as you can make it; every onward journey is encrypted; and the residual risk is written down, signed, and scheduled for review. The first two are network engineering. The third is what separates a managed exception from a shadow one, and it is the part auditors, insurers, and your own future self will thank you for.

The Isolation Segment

An isolation segment is a small network — usually a VLAN with its own subnet — whose traffic is separated from the rest of your network by a firewall, so nothing outside the segment can observe traffic inside it. The device moves into the segment, along with one other machine: the relay host. Then the firewall policy does the real work. The rules, in plain language:

• The device may reach the relay host on the FTP ports — and nothing else. Port 21 plus the data-connection ports the transfer needs. No internet, no file servers, no other subnets. Legacy devices frequently use active mode, where the receiving server connects back to the device for each transfer; inside a two-party segment that quirk is harmless, so permit it here rather than fighting decades-old firmware about passive mode.
• Nothing initiates connections into the segment except your management network, narrowly, for administering the device and relay.
• The relay host may send outbound on the secure protocol only — SFTP or FTPS to the flow's real destination — plus whatever management and time-sync your standards require.
• Everything else is denied and logged. The denies are not just protection; they are instrumentation. A logged attempt by the device to reach anywhere unexpected is your early warning that something on the segment is not what you think.

The isolation cuts both ways, which is why it earns its cost. Traffic inside the segment cannot be observed from outside it — a compromised laptop in the office cannot sniff the device's password. And the device itself, often running an old embedded operating system that will never see another patch, cannot reach anything but the relay if it is ever compromised. You have simultaneously protected the cleartext and quarantined the device's own attack surface. The same discipline, applied to another legacy protocol, is described in our TFTP security and containment guide.

The Local-Drop-and-Secure-Relay Pattern

Isolation alone would strand the files inside the segment, so the second half of the pattern carries them onward. The device delivers by plain FTP to a relay host in its own segment — a local drop, one short hop. The relay then forwards every arriving file outward over an encrypted protocol to wherever the flow actually needs to go: your main transfer server, a partner's SFTP endpoint, an archive. Downstream, nothing knows or cares that the first hop was FTP.

The diagram below shows the shape: cleartext confined to the short hop inside the dashed segment boundary, encryption everywhere beyond it, and every other path from the device denied.

Building the relay takes an afternoon with standard parts:

1. The receiving side is an ordinary FTP service on the relay host, bound to the segment's interface only, with one dedicated account for the device. A Windows file transfer server such as Sysax Multi Server fits naturally here: it accepts the device's plain FTP on the isolated interface, logs every session, and — because it also speaks SFTP, FTPS, and HTTPS — the same installation can serve as the encrypted endpoint the files move to next.
2. The forwarding side is a folder-watching job: when a file lands in the drop folder, send it onward over SFTP or FTPS, verify the send, then delete the local copy. A transfer scheduler like Sysax FTP Automation does this as configuration — folder monitoring, retry on failure, and error alerts — which matters, because a relay that fails silently turns "contained" into "files quietly piling up on an unwatched box."
3. The device's account is dedicated to that device, restricted to its own drop folder, write-only if the device tolerates it, and carries a password used nowhere else. Old firmware sometimes limits password length or characters; do the best the device allows, and let uniqueness carry the weight the complexity cannot. That password crosses the segment readable — uniqueness is what makes its capture worthless anywhere else.
4. Files should not dwell. Forward promptly and keep the drop folder empty; the relay is a corridor, not a store. Short retention also keeps the segment's data value near zero if anything ever does go wrong inside it.

Watching the Exception

A contained device is a standing exception, and standing exceptions rot unless something watches them. The watching is modest but non-negotiable: keep the relay's session logs, so every device upload is a dated record; alert on the firewall's deny log for the segment, because a device that suddenly tries to reach the internet is telling you something changed; and alert when the relay's forwarding job fails or the drop folder ages beyond its normal cycle. Include the segment in the periodic sweeps from the discovery article — the contained FTP should appear exactly there and nowhere else, and the sweep is how you prove the "nowhere else" half. If you want to reason more formally about what residual risk the watching actually covers, the transfer threat modeling series gives you the framework.

Documented Risk Acceptance

The technical containment is half the answer. The other half is governance: someone with authority over the risk — not the administrator who built the segment — formally accepts what remains, in writing, with a review date. This is a risk acceptance, and it changes the nature of the exception. An undocumented legacy device is a skeleton in the closet: discovered by an auditor, it reads as concealment. A documented one is a managed decision: disclosed on questionnaires, defensible in audits, and honest on insurance applications — "encrypted in transit, with one contained, documented exception under review" is a strong answer, while a discovered surprise is a terrible one.

The memo is one page. Copy this skeleton:

RISK ACCEPTANCE MEMO — LEGACY DEVICE ON PLAIN FTP

System:        [device make/model, location, asset tag]
Business use:  [what it does and for whom]
Owner:         [named business owner of the device/workflow]

RESIDUAL RISK ACCEPTED
The device transfers files by plain FTP, which sends credentials
and file contents unencrypted. This traffic is confined to an
isolated network segment containing only the device and a relay
host; all onward transfer is encrypted (SFTP/FTPS).
Remaining exposure: an attacker with a presence INSIDE the
isolation segment could read this device's transfers and its
dedicated credential.

COMPENSATING CONTROLS
- Isolated segment; firewall denies all other device traffic (logged)
- Dedicated, unique, folder-restricted account on the relay
- Relay forwards promptly; drop folder holds no standing data
- Session logging on relay; alerts on denies and forward failures
- Segment included in periodic discovery re-scans

ALTERNATIVES CONSIDERED
- Firmware upgrade: [checked — none available / details]
- Alternate protocol on device: [checked — none / details]
- Replacement: [cost/timeline; revisit at end-of-life]

ACCEPTANCE
[Name, role] accepts the residual risk described above.
Signature/date: ____________
Review date:  [+ one review cycle]   Expires: [date or event]
Exception ends early if: device retired, vendor ships a secure
protocol, or any incident involves this segment.

Route the memo to whoever owns risk in your organization — a security officer, an IT director, the device's business owner plus IT jointly. The signature line is the point: it moves the decision to the level where risk decisions belong. Where the broader question "when is plain FTP ever tolerable?" needs a principled treatment beyond one device, our when plain FTP is acceptable article is the companion — this memo is that article's reasoning, operationalized for a single stubborn machine.

The Exit Path

Containment is a holding pattern, not a destination, and the memo's review date is where the exit gets planned. Each review asks three questions: does the device still exist and still matter, has the vendor shipped anything that changes the answer, and is replacement now cheaper than the exception's ongoing cost? Two habits shorten the exception's life. First, put the device on the asset lifecycle list, so its eventual replacement is budgeted rather than perpetually deferred. Second — the cheapest security control in this entire series — add one line to your procurement checklist: new equipment that transfers files must support SFTP, FTPS, or HTTPS. Every device bought under that rule is a containment segment you will never have to build.

When the device finally retires, finish the job: remove its account, tear down the segment and firewall rules, run one sweep to confirm nothing else was using them, and close the memo with an end date. The final sweep matters more than it seems — contained segments have a way of quietly collecting a second device over the years, and the verification article treats every exception segment as a named item to re-check, not a blank spot on the map.

The Short Version

Verify the device truly cannot speak anything better. Give it a segment where its cleartext touches exactly one machine. Relay everything onward encrypted. Watch the denies, the logs, and the forwarding job. Sign the memo, review it on schedule, and buy nothing FTP-only ever again. That is the whole pattern — and it is the difference between "we retired FTP, except for some stuff" and "we retired FTP, with two documented exceptions, contained and reviewed, expiring with the hardware." The first sentence fails audits and undermines the program; the second one closes it with credibility intact.

Frequently Asked Questions