Is it safe to expose Port 23 (Telnet) to the internet?

Why Telnet Exposure Is Unsafe by Design

Telnet is not simply an older remote-access option, it is a protocol that assumes the network can be trusted. That assumption breaks down immediately on the public internet, where anyone on-path or able to observe traffic can read usernames, passwords, commands, and session output. The practical issue is not just encryption, but the complete absence of confidentiality for the management channel.

That is why the safer pattern is to treat Telnet as deprecated management exposure, not as a service to harden in place. A port open to the internet becomes part of the attack surface, and the risk is amplified when the service reaches administrative interfaces, embedded devices, or legacy systems that were never designed for hostile networks.

For a broader view of why risky exposed protocols are treated as a recurring operational pattern, see Network Ports and Protocols Security Guide.

What Attackers Do Once Port 23 Is Reachable

When Telnet is exposed, the common abuse pattern is straightforward: automated scanners find it, brute-force tooling tests weak credentials, and successful logins are reused for further access. Because Telnet transmits everything in clear text, passive interception can be enough to recover credentials even when the login itself is strong. That makes exposed Telnet a high-value target for opportunistic and targeted intrusions alike.

The issue is not limited to password guessing. Any administrative session over Telnet can expose commands, device states, and sometimes configuration secrets that were typed or echoed during the session. If the service is reachable from the internet, an attacker does not need a sophisticated exploit chain to gain value from it, only visibility and patience.

For the attacker perspective on why exposed credentials and weakly protected remote access are repeatedly harvested, the State of NHI & AI Agent Breach Report 2026 is a useful companion resource.

What Safe Replacement Looks Like in Practice

The right remediation is to disable Telnet wherever possible and move remote administration to an encrypted protocol such as SSH or a vendor-supported secure management plane. If Telnet cannot be removed immediately, it should be confined to tightly controlled administrative paths, never exposed broadly to the public internet, and limited by network allowlisting, strong authentication, and monitoring. The goal is to remove plaintext exposure, not merely reduce its frequency.

Management access should also be separated from general user traffic and from any production-facing service port. A secure replacement is only truly safer when access is logged, authentication is strong, and the protocol itself protects both credentials and session content. If the device or application cannot support that state, it belongs behind a controlled jump path until it can be retired or upgraded.

Risk and Threat Considerations

Exposed Telnet creates both confidentiality risk and direct compromise risk because it turns the management channel into readable text on an untrusted network. The most important threat is credential theft, but the broader exposure includes command capture, configuration discovery, and lateral movement once the attacker has a working administrative session.

Failure mechanism: Telnet sends authentication material and session traffic in clear text, so any observer on the path can collect usable credentials or sensitive management data, while automated scanners and brute-force tools can rapidly test exposed services.

Impact: A single exposed management port can lead to device takeover, unauthorized changes, credential reuse against other systems, and persistent administrative access if those credentials are valid elsewhere.

Practitioner Guidance

What to verify: Confirm whether Port 23 is reachable from the internet, whether any device still depends on it for administration, and whether the same credentials are reused on SSH, VPN, web admin, or other remote-access paths. If the service is legacy-only, document it as a retirement candidate rather than a permanent exception.

Decision rule: If remote administration must remain available, prefer encrypted remote management and restrict access to trusted admin networks or a controlled bastion path. If Telnet is externally reachable, treat it as an exposure that needs removal or isolation, not as a service to monitor indefinitely.

Practitioner takeaway: The key question is not whether Telnet can be made slightly safer, it is whether a plaintext management protocol should ever be exposed to hostile networks at all, and the answer is usually no.

Related resources from NHI Mgmt Group

• Is it safe to expose Port 53 for DNS to the internet?
• Is it safe to expose Port 135 (RPC) to the internet?
• Is it safe to expose port 27017 for MongoDB to the internet?
• Is it safe to expose Secure LDAP Port to the internet?