Managing Legacy Devices: Telnet and Serial Access in 2026

Telnet was declared dead decades ago and it is still running in nearly every data centre. Not because anyone chose it, but because the equipment that speaks it — rack PDUs, UPS management cards, KVM switches, environmental sensors, PLCs on a factory floor, baseboard management controllers — has a service life measured in decades and firmware updates measured in never.

The practical question is not "should I disable Telnet" (yes, if you can) but "how do I work with this device today without making things worse".

What you are actually dealing with

• Only Telnet. Management cards from the era when SSH was optional.
• Only serial. Console ports, industrial controllers, anything configured over a hand-held terminal.
• Serial behind a console server, which then offers Telnet or SSH on the front — check which, because it decides where your risk sits.
• SSH with obsolete algorithms, which is its own problem: old gear often wants SSHv1 or ciphers modern clients refuse. Expect to allow a legacy algorithm on one dedicated jump host rather than on your workstation.

The risk, stated plainly

Telnet sends everything in cleartext — usernames, passwords, and every command. Anyone with a tap on that network path sees all of it. Serial has the mirror-image problem: it is physically local, so it is not remotely sniffable, but it is usually completely unauthenticated.

Containment that actually works

1. Put legacy gear on its own segment or VLAN, reachable only from a jump host. This is the single highest-value control.
2. Access it from a dedicated machine or VM that holds the legacy client configuration and nothing else.
3. Use a console server that terminates SSH if you can — it converts the Telnet risk into a serial risk, which is much easier to contain.
4. Never reuse credentials from modern systems on legacy devices. Assume every Telnet password is public.
5. Log the session, and note in the log which segment the connection came from.

Day-to-day practice

• Group legacy sessions separately from modern ones, named by location and role. When something needs Telnet you should know which devices those are without looking it up.
• Save the parameters with the session. Serial settings for a fifteen-year-old PDU are not something you want to rediscover.
• Keep the command set on a button bar. Legacy CLI is often terse and easy to mistype; a stored, reviewed command beats a typed one.
• Turn on logging with timestamps and direction markers, and rotate it. Legacy devices fail in ways that are worth reconstructing later.
• Use ZMODEM or XMODEM to pull configuration off devices that have no file transfer of their own — see the ZMODEM guide.

Planning the way out

You will not replace all of it, and you do not need to. Prioritise by exposure:

1. Anything reachable from a general-purpose user VLAN. Fix first.
2. Anything with a default or shared password. Fix today, even if you cannot change the protocol.
3. Devices with known unpatched vulnerabilities and no vendor support. Either segment them hard or schedule replacement — "we will get to it" is how they end up on the incident report.
4. Devices that will outlive the project. Document the access path and parameters now, while someone still remembers them.

The realistic end state is not "no Telnet". It is "no Telnet reachable from anywhere that matters".

FAQ

Is it ever acceptable to still use Telnet?

For management on an isolated segment with no alternatives, it is a risk you can accept and document. On a general network, no.

My switch supports SSH but the client refuses to connect.

Old firmware often only offers deprecated ciphers or key exchange methods. Rather than weakening your main client, use a dedicated jump host with a legacy policy scoped to that device.

How do I get a config off a device with no file transfer?

Over a console session: ZMODEM if it has lrzsz, otherwise capture the output with session logging and clean it up afterwards. XMODEM is the fallback on very old gear.

Should I log Telnet sessions?

Yes — with timestamps. It is your best evidence of what happened, and it is also where credentials typed in cleartext end up, so treat those files as sensitive.