Port 23 (Telnet) is targeted by credential-stuffing, password-spraying, brute-force login attempts, and malware scanning for exposed remote-access services. Because Telnet sends traffic in clear text, credentials can also be intercepted on path. Defenders should disable it where possible, restrict exposure, and monitor for repeated login failures and internet-facing devices.
What attackers do once Port 23 is exposed
Port 23 is attractive because Telnet is an old remote-access service that many devices still expose unnecessarily. The most common abuse is low-cost account attack, where bots cycle through known usernames and common passwords until one works. Once a login succeeds, the attacker often gets a shell on a device that may have weak monitoring, poor segmentation, or default credentials.
Because Telnet carries usernames and passwords in clear text, interception is also part of the threat model. That means a simple exposed session can become a credential theft event, not just a login attempt. On unmanaged embedded devices, the same exposure can lead to rapid scanning, repeated authentication abuse, and follow-on compromise of neighboring systems if the device is trusted inside the network.
Why Telnet exposure is more dangerous than a noisy login service
The problem is not only that Telnet is old, it is that it removes confidentiality from the authentication exchange. If a password can be captured on the wire, the attacker does not need to guess it later. That turns a single exposed service into a reusable access path, especially where the same credentials are shared across appliances or reused for administrative access.
This is why defenders should treat Port 23 as a high-risk remote-management surface rather than just another open port. A device reachable from the internet can be targeted automatically, and even a partially successful attack may reveal whether the environment uses weak, reused, or default credentials. The first real control decision is therefore whether the service should exist at all, then whether any remaining exposure is constrained to tightly controlled administrative networks.
How to confirm exposure and reduce the attack surface
Start by identifying every host that listens on Port 23, then verify whether the service is still required for business or operational reasons. In many environments, the right answer is removal or replacement with an encrypted management protocol. If the service must remain temporarily, limit it to specific source addresses, isolate the device from general user traffic, and ensure authentication is unique per system.
The Network Ports and Protocols Security Guide is useful here because Telnet is not an isolated problem, it sits in a broader class of risky management ports that should be inventoried, segmented, and retired where possible. For a quick protocol reference, IANA remains the canonical source for port and service registry context.
Risk and Threat Considerations
Telnet exposure combines three distinct risks: public-facing brute-force attempts, password interception in transit, and lateral movement from a device that may have excessive trust inside the network. If attackers can reuse captured credentials, a single weakly protected management service can become a broader foothold.
Failure mechanism: The service transmits credentials in clear text, which enables passive capture, while internet-reachable endpoints invite automated password attacks at scale.
Impact: A successful login can expose device administration, enable persistence, and create a path to adjacent systems if the compromised host is trusted elsewhere.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while CIS Controls v8, NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-5 — Account Management | Telnet abuse hinges on weak, reused, or exposed accounts on internet-facing devices. |
| Recommendation — Inventory exposed accounts and remove or restrict any credentials that can authenticate to Telnet services. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Telnet attacks succeed when reusable credentials are weak, shared, or poorly managed. |
| Recommendation — Rotate and retire authenticators that can be used against exposed Telnet management services. | ||
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | Telnet sends secrets in clear text, creating direct credential exposure risk. |
| Recommendation — Eliminate clear-text secret exposure by replacing Telnet with encrypted management channels. | ||
| MITRE ATT&CK | T1110 — Brute Force | Credential-stuffing, password-spraying, and brute-force login attempts are core attack patterns here. |
| Recommendation — Detect and block repeated login attempts against exposed remote-access services. | ||
| NIST CSF 2.0 | PR.AA-05 — Managed access control mechanisms | Restricting who can reach Telnet and what they can do is central to reducing exposure. |
| Recommendation — Limit remote management access to approved sources and tightly controlled administrative paths. | ||
Practitioner Guidance
What to verify: Confirm whether any Port 23 listener is truly needed, whether it is reachable beyond a management subnet, and whether the same credentials are shared across multiple devices. If any of those answers is yes, treat the exposure as more than a nuisance scan.
Decision rule: If Telnet is still required for a legacy device, compensate with segmentation, source allowlisting, and monitoring for repeated failures, but plan replacement rather than long-term acceptance. If the service is not required, disable it and remove the route to attack rather than trying to harden an inherently weak protocol.
Practitioner takeaway: Port 23 is risky because it turns routine remote administration into a credential-reuse and credential-capture problem, so the safest fix is usually elimination of Telnet, not just stronger passwords.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 18, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org