What Is TFTP and When Is It Still Used?

TFTP shows up in the least glamorous corners of network work: firmware uploads, configuration backups, phone provisioning, and the first stage of a network boot. It is old, it is minimal, and it has no security of its own, yet it is still installed on almost every switch and router because it solves a narrow problem extremely well.

TFTP, the Trivial File Transfer Protocol, was designed to be small enough to fit in boot firmware. That constraint explains everything about it: no login, no encryption, no directory listing, and a transfer that is simple enough to implement in a few kilobytes of code.

What TFTP Does and Does Not Do

TFTP moves a single file between a client and a server over UDP. It supports reading and writing, a block size that both sides agree on, and retransmission when a block is lost. That is the whole feature set.

What it leaves out is as important as what it includes. There is no user account, so any host that can reach the server can read or overwrite files. There is no encryption, so the contents cross the network in the clear. There is no integrity check beyond the block acknowledgments, so a transfer can complete with a corrupted file if the corruption survives the checksums.

Why It Survived

TFTP survives because the client side is trivial. A boot loader, a switch firmware image, or a voice phone can implement a TFTP client in a tiny footprint, and the server side is a single small service. That is why the protocol is still the path of least resistance for a handful of recurring jobs.

Each of these has a modern alternative, usually SFTP or an HTTP endpoint, but the device support and the simplicity of TFTP keep it in upgrade guides and backup scripts.

Operating TFTP Safely

Since the protocol has no authentication, the security has to come from the network. Bind the server to the segment it needs, restrict who can reach UDP port 69 with the firewall or an ACL, and serve from a directory that contains only the files you intend to share. Log every request, because an unexpected read of a configuration file is a useful signal.

Where the platform supports it, prefer SFTP or SCP for anything that includes credentials, keys, or customer data. Reserve TFTP for firmware and configs on a management network, and treat the server itself as an untrusted service that happens to sit inside the perimeter.

A Note on TFTP and File Servers

TFTP is not a file sharing protocol in the everyday sense. It cannot browse directories, it cannot serve many users efficiently, and it does not replace SMB or NFS. It is a delivery mechanism for single files at boot time, and thinking of it that way keeps expectations, and security decisions, in the right place.

If you run a TFTP server for device provisioning, the recordings that matter are the address of that server and which devices depend on it. Recording service addresses such as the TFTP server, syslog collector, and NTP source next to the subnets they serve, as IP address management in Obelinf lets you do, means the next engineer knows which infrastructure depends on a service before it is moved or retired.