A retail chain runs an external discovery pass across its registered netblocks and finds seventeen hosts answering on 23/TCP. None of them is in the asset register. All seventeen turn out to be ISP-supplied routers at branch sites, shipped with remote management enabled, sitting on address space the head-office team had never thought to look at. Nobody made a decision to expose them. That is the point.
Exposed telnet servers are almost never the result of a deployment choice. They are a side effect: of firmware defaults, of a port forward opened for a supplier call in 2019, of a device that was factory-reset during a maintenance visit. Which is why the useful question is not “is telnet bad”(it is, and you know that) but “how do I establish whether any of this is mine”.
Why an open telnet port is not the same kind of problem as a missing patch
Telnet carries everything in clear text. Usernames, passwords, commands, output. Anyone positioned on the path, and on the public internet that includes more parties than you would like, can read the session and replay the credentials. There is no transport encryption to misconfigure because there is no transport encryption.
The second property matters more operationally. A successful telnet login looks exactly like legitimate administration. No exploit, no crash, no anomalous payload, just a correct credential pair arriving at a service that was designed to accept it. Your logs, if the device keeps any, record an admin session. The detection problem is not noise; it is that the event is indistinguishable from the thing it is imitating.
Who still runs it in 2026? Rarely a server anyone chose. Embedded and IoT firmware, legacy switches and console servers, out-of-band management cards on older hardware, industrial and building controllers, ISP-supplied customer premises equipment, digital signage and NVRs. The common thread is that the device is old, unowned, or both.
Automated credential stuffing against port 23 and its common sibling 2323 has run continuously since the Mirai era, using default password lists that are published and maintained. Exposure is so measured in hours, not months. A device that comes back online with telnet enabled on a Tuesday afternoon will have been probed before the end of the day.
And the banner is usually a marker for something wider. A host answering on 23 is typically a device with no patch route, no named owner, no logging and no configuration baseline. The telnet finding is the symptom you can see from outside; the unmanaged device is the condition.
How telnet ends up on an estate nobody chose to expose
Four routes account for most of what external discovery turns up.
- Firmware defaults that were never hardened. The device shipped with management services on, went live under time pressure, and nobody ran the hardening guide because nobody owned the hardening guide.
- Port forwards opened for a one-off support call. A vendor needed access for an afternoon. The rule outlived the engineer, the ticket and sometimes the contract.
- Acquisitions, branch sites and supplier-managed kit. The estate exists, the addresses are routable, and none of it sits in the central register because nobody inherited responsibility for it at the point of transfer.
- Permissive cloud security groups and IPv6. The IPv4 policy is strict and well reviewed. The same device is dual-stacked, reachable on its IPv6 address, and still answering on 23, because the policy was written once for v4 and never duplicated.
That last one deserves emphasis. IPv6 blind spots are not exotic failures of understanding; they are an ordinary consequence of a firewall review that only ever looked at one address family. If your discovery process enumerates v4 ranges only, your findings are structurally incomplete.
Finding your own exposed telnet servers, starting from a seed domain
External discovery works outwards, the way an attacker does: from the outside, with no privileged knowledge of what you believe you own.
Start with seeds. Your primary domains, brand and acquisition domains, and known organisation names. From there, pull certificate transparency log entries for hostnames, DNS records for the addresses those hostnames resolve to, and WHOIS or RIPE registration data to establish which netblocks are registered to the organisation and its subsidiaries. RIPE records are particularly useful in the UK because branch and acquired estate frequently sits in address space registered under a legacy company name that the security team has never heard of. The general mechanics of that walk are covered in more depth in our piece on how EASM moves from seed to inventory.
Then move from names to addresses and check the ports. Port 23/TCP first, 2323/TCP second, and be prepared for telnet answering on arbitrary high ports where someone has remapped it through a NAT rule. Banner responses are informative: many embedded devices identify their vendor and firmware line before authentication, which is both a gift to you and to everyone else.
Three external sources are worth pulling alongside your own scanning. The Shadowserver Foundation runs an Accessible Telnet Report that notifies national CSIRTs and network owners about hosts answering on 23/TCP in their address space; in January 2026 the project reported roughly 800,000 telnet-fingerprinted IP addresses globally, against a backdrop of active exploitation (figures move, so check the current daily report rather than treating that number as fixed). Internet-wide scan datasets give you a second opinion on what is visible. Your own firewall and egress logs tell you which of your edges are forwarding 23 outbound or inbound, which is often the fastest route to the port forward nobody remembers.
What you have at the end of that is a candidate list. Not an inventory.
Likely versus definitely: confirming before you raise a change
A banner on port 23 is evidence that a host is probably running telnet. It is an inference, not a confirmed fact. The address may be a honeypot deliberately answering on 23 to collect attacker behaviour. It may be a shared-hosting neighbour on an address your provider also serves. It may be an address that was reassigned away from you eighteen months ago and still appears in a stale RIPE object. It may be a device that answers but rejects every credential.
Ownership verification comes before the ticket, and certainly before any active testing. On ISP-managed CPE and supplier-administered kit this is not a formality: probing a device you do not administer, on address space you do not control, is somebody else’s incident. Confirm the assignment, confirm the contract, then act.
Passive observation and active testing answer different questions, and neither substitutes for the other. External discovery tells you a service is reachable from the internet and that it appears to be a particular firmware family. Authenticated vulnerability scanning and internal configuration data tell you which version is actually running and whether telnet is enabled by policy or by accident. Pairing the two is the whole discipline; we have written separately on why EASM gives you likely and vulnerability scanning gives you definitely.
Record the finding properly or you will rediscover it next quarter: IP address, port, hostname if any, hosting or access provider, named owner, first seen date, banner evidence and the date ownership was confirmed. Our note on the fields worth recording for an internet-facing asset covers the minimum set.
Triage, and what to do when you cannot simply switch it off
Work in this order:
- Internet-reachable hosts that accept logins, especially with vendor-default or shared credentials.
- Hosts reachable but with unknown credential state.
- Devices where telnet sits alongside other unauthenticated management interfaces, which usually means the whole management plane is exposed.
The clean fixes are the obvious ones. Disable the service in firmware. Delete the port forward. Bind management to a dedicated VLAN. Replace telnet with SSH where the device supports it and the key management is in place. Change the credentials regardless, because you have no idea how long the port has been answering.
Then there are the awkward cases. A building management controller on a leased line, end of life, no SSH in the firmware, no further releases coming. Disabling telnet removes the only management channel the facilities contractor has. The realistic path is not heroic: move the controller behind VPN-only access, segment it so it cannot reach the corporate network or the internet directly, allow-list the source addresses that need it, rotate credentials, and monitor attempts on 23. Then fund the replacement and put a date on it.
Where a vendor support contract explicitly requires telnet, say so in writing and treat it as a compensating-control case with a documented replacement date. The failure mode here is familiar: a risk acceptance that quietly never expires, renewed by inertia each year until the device is twelve years old and still answering. If the mitigation work plus the ongoing exception review costs more over three years than new hardware, that is the argument to take to the budget holder. Finance understands a dated plan better than a residual risk score.
Keeping port 23 closed: change detection rather than an annual sweep
Here is the part people underestimate. Your fix does not persist. A controller factory-reset during a maintenance visit comes back with telnet enabled, default credentials restored and your firewall exception, if the reset touched the edge device, gone with it. A quarterly scan gives that device up to thirteen weeks of exposure before anyone notices.
So the control that matters is detection of change, not periodic measurement of state. Alert on a new listener appearing on 23 or 2323, on a banner that changes on a host you already know about, and on a new address becoming reachable inside a netblock you own. The argument for that cadence is the same one we make about point-in-time scanning being a snapshot of a river.
Keep the noise down or the alerts will be ignored by March. Suppress known honeypot ranges and shared infrastructure where you cannot act anyway. Alert on transition rather than on standing state. Route findings into the ticket queue that already exists rather than a new console nobody opens.
The compliance hooks are straightforward in the UK. NCSC guidance is consistent that management interfaces should not be exposed to the internet, and Cyber Essentials expects default credentials to be changed and administrative access to be controlled rather than openly reachable (check the current requirements document, as the scheme is revised periodically). The Cyber Security and Resilience Bill points in the same direction for in-scope organisations and their suppliers, and we have looked at the practical fix list that implies. An open telnet port is one of the few findings that fails plainly against all three.
The Short Version
- Telnet exposure is not a deployment decision, so it will not be in your asset register. Discover it from outside, starting at seed domains and registered netblocks.
- A banner on 23 means likely telnet, not confirmed vulnerability. Verify ownership before you raise a ticket or run an active test.
- Check IPv6. A strict IPv4 policy and a dual-stacked device is the most common way a closed port stays open.
- Where telnet cannot be disabled, use VPN-only access, segmentation, allow-listing and credential rotation, with a funded replacement date written down.
- Resets undo fixes. Alert on a new listener appearing, not on an annual sweep.
Frequently Asked Questions
How do I check whether my organisation has exposed telnet servers?
Start from seed domains and organisation names, pull certificate transparency, DNS and RIPE or WHOIS data to establish your hostnames and netblocks, then test those ranges for 23/TCP and 2323/TCP across both IPv4 and IPv6. Cross-check against Shadowserver reports sent to your network owner or national CSIRT, and against your own firewall rules for inbound forwards on port 23. Treat the output as candidates until ownership is confirmed.
Is telnet always a serious risk, or only on certain devices?
Telnet is always clear text, so credentials sent over it are always exposed to anyone on the path. The severity depends on reachability and what the device controls: a telnet service bound to an isolated management VLAN is a different proposition to the same service answering from the public internet on a building controller. Internet-reachable telnet accepting logins is the case to treat as urgent. Finding that exposed telnet service in the first place often starts with the same free sources used to find forgotten internet-facing assets.
What should I do if a device only supports telnet and has no SSH option?
Remove internet reachability rather than the management channel. Put the device behind VPN-only access, segment it from the corporate network, allow-list the source addresses that genuinely need it, rotate the credentials and monitor connection attempts. Then set a replacement date and fund it, because compensating controls on end-of-life hardware are a holding position, not a fix.
Does scanning for telnet exposure make my organisation more of a target?
No. Port 23 is already being probed continuously by automated credential stuffing, and internet-wide scanning projects have been fingerprinting it for years. Your own discovery adds nothing material to that background. The genuine risk is running active tests against addresses you do not own, which is why ownership verification comes first.
How often should external assets be checked for open management ports?
Continuously, or as near to it as your tooling allows, with alerting on change rather than on state. Quarterly sweeps leave a firmware reset or a rebuilt device exposed for weeks. If continuous checking is not available yet, prioritise the ranges containing branch sites, acquired estate and supplier-managed equipment, because that is where open management ports tend to live. Further background on the discovery side sits across our wider coverage of external attack surface management.