TFTP: Why a Protocol With No Security Is Still on Your Network

Trivial File Transfer Protocol is deliberately minimal: no authentication, no encryption, no directory listing, no way to delete or rename. It runs on UDP port 69 and does two things — read a file, write a file. That minimalism is why it is still deployed decades after it should have disappeared, and also why it is a liability wherever it is reachable.

How it works

A client sends a read or write request to UDP 69. The server responds from a different, ephemeral port, and the rest of the transfer continues between the client's port and that one. This surprises people configuring firewalls: opening UDP 69 alone is not enough, and stateful inspection or a protocol helper is needed for the transfer to complete.

Data moves in fixed-size blocks, traditionally 512 bytes, each acknowledged before the next is sent. That lockstep behavior makes it simple to implement and slow over links with any latency. A block smaller than the full size signals the end of the file.

Because UDP provides no reliability, TFTP implements its own with acknowledgements and timeouts. The original design could not transfer files larger than about 32 MB due to a 16-bit block counter; extensions negotiate larger block sizes and allow the counter to wrap, which is why modern implementations handle bigger files.

What it has no concept of

There is no authentication. Anyone who can reach the server can request any file the server is configured to serve, and where writes are enabled, upload. Access control exists only as filesystem permissions and server configuration.

There is no encryption. Everything, including the file contents, crosses the network in plaintext.

There is no integrity checking beyond UDP's weak checksum, so a corrupted or substituted file arrives looking normal.

Combine those and the implications are direct: a network device configuration pulled over TFTP exposes community strings, shared keys, and password hashes to anyone on the path. A firmware image fetched over TFTP can be replaced in transit by an attacker in a position to do so. Neither requires breaking anything.

Where it survives

TFTP persists because it fits in firmware. Network device bootstrapping, firmware upgrades, and configuration backup have used it forever, and the client is a few hundred bytes of code in a boot ROM.

PXE network boot is the other durable use. A client with no operating system obtains an address and boot parameters by DHCP, then fetches the boot loader over TFTP — the DHCP options carry the server address and filename. Anything richer would not fit in a network card's boot ROM. IP phones and thin clients pull their configuration the same way.

In each case the protocol is chosen because the client is too constrained for anything better, not because anyone thinks it is a good idea.

Containing it

Treat a TFTP server as an unauthenticated file share, because that is what it is.

Keep it on an isolated provisioning or management VLAN with no route from user networks or the internet, and restrict by source address to the devices that need it. Run it only while it is needed — starting the server for a firmware push and stopping it afterward eliminates the standing exposure entirely, and is the practice in well-run environments.

Disable write access unless a specific workflow requires it, and serve only the directory holding the intended files, never a path that reaches configuration or system files. Verify checksums out of band after any firmware transfer, since the protocol will not tell you the image was altered.

Where the device supports it, use SFTP or SCP instead — both authenticate and encrypt, and modern network equipment generally offers them. Reserve TFTP for the cases where the client genuinely cannot do better, and make sure that path runs over the isolated network described under out-of-band management rather than alongside production traffic.

Monitor for it as well. TFTP traffic outside the provisioning network is worth an alert; it is a known exfiltration and staging channel precisely because it is simple, unauthenticated, and often unexamined.

Exam angles

Know TFTP as UDP port 69 with no authentication and no encryption, and contrast it with FTP on TCP 20 and 21, FTPS, and SFTP on TCP 22. Recognize PXE boot, network device firmware and configuration transfer, and IP phone provisioning as its legitimate uses. When a scenario asks for secure file transfer, TFTP is never the answer; when a scenario describes a device that can only speak TFTP, the answer is network isolation and running the service only when needed.