Port 23 (Telnet)

Why Port 23 (Telnet) Is Considered Unsafe

Port 23 is associated with Telnet, which was designed for remote administration before modern transport encryption was standard. Its core weakness is that usernames, passwords and interactive session content can be exposed to anyone who can observe traffic on the network path.

That makes the port dangerous even when the service is intended for legitimate administration, because the protocol itself provides no native confidentiality or integrity protection. An attacker does not need to defeat a password if the login can be copied in transit and reused elsewhere.

How Port 23 Exposure Happens

Organisations usually encounter Telnet exposure in legacy network gear, lab systems, embedded devices or forgotten management interfaces. The risk is highest when the service is reachable from shared internal networks, remote-access segments or, worse, the internet.

The most practical exposure checks are simple: verify the port is actually in use, confirm whether the device or host still requires Telnet, and compare the observed service against approved configuration and vendor guidance. Because port numbers are assigned and documented centrally, the IANA registry is a useful reference point for understanding why port 23 is conventionally tied to Telnet.

For network-wide hardening, NHIMG’s Network Ports and Protocols Security Guide places Telnet in the wider class of risky management protocols that should be replaced with encrypted alternatives.

What Secure Replacement Looks Like

Secure replacement means moving administrative access to protocols that provide encryption and stronger authentication, such as SSH or vendor-supported secure management channels. The goal is not just to “close a port”, but to remove a plaintext management path that can leak credentials and operational commands.

Where legacy systems cannot be changed immediately, defenders should restrict reachability, segment management traffic, and limit who can initiate remote sessions. That buys time, but it does not make Telnet safe, it only reduces who can observe or abuse it.

In broader control terms, the issue maps to secure configuration, access control and remote administration hygiene. NIST guidance on strong security controls is relevant here, especially for limiting unmanaged exposure and protecting administrative access paths through NIST SP 800-53 Rev 5 Security and Privacy Controls.

Detection, Monitoring and Compromise Review

Because Telnet traffic is readable in transit, defenders should treat unexpected use of port 23 as both a configuration problem and a potential compromise signal. An exposed Telnet listener can indicate legacy drift, but a newly opened session on an environment that should not use Telnet may also point to malicious pivoting or an unsafe workaround.

Monitoring should therefore focus on service inventory, remote-login logs, firewall allow-lists and unusual administrative access patterns. If Telnet has been used, review the session for possible credential capture, unauthorized login, lateral movement and persistence through reused passwords or compromised device accounts.

Where remote access patterns matter operationally, NCSC guidance on remote access security is a useful complement, and the NCSC UK Advice and Guidance page is a practical entry point for that work.

Risk and Threat Considerations

Port 23 is risky because it exposes a high-value administrative channel in plaintext. If Telnet is reachable by an attacker on the network, the attacker may be able to capture credentials, hijack a live session, or reuse stolen access to reach other systems.

Failure mechanism: Telnet transmits authentication and session data without encryption, so any intermediary that can observe the traffic can potentially read or reuse it.

Impact: A single exposed Telnet path can lead to account compromise, device takeover, privileged remote access and downstream lateral movement.

Practitioner Guidance

Why practitioners should care: Port 23 should be treated as a legacy exception, not a routine management option. If it appears in an estate, someone must own the decision to remove it, contain it, or formally justify the residual risk.

What to watch for: Any device that still accepts Telnet, any firewall rule that exposes it beyond a tightly controlled management segment, and any operational process that still depends on plaintext remote login are signals that the environment needs attention.

Practitioner takeaway: The safest default is to disable Telnet wherever possible and move administrative access to encrypted protocols before the exposure becomes an incident.

Related resources from NHI Mgmt Group

• How should security teams harden SSH without relying on port changes alone?
• What is the difference between changing port 22 and real SSH hardening?
• How do security teams know whether a telnet exploit is actually working in the environment?
• What breaks when DTLS session state is tied to IP address and port?