Securing an exposed Telnet device: what to do beyond turning it off
Disabling Telnet closes the most dangerous gap immediately, but devices that genuinely need some form of remote command-line access still need an answer for what replaces it — and devices that can't be fully replaced or patched yet still need network-level controls in the meantime, which is the part most quick fixes skip entirely.
By AdminKit team, Netbase JSC · Updated October 23, 2026
Why “turn it off” is correct but incomplete
Disabling Telnet is the right first move, and for devices where it was enabled by accident or isn’t actually needed, it’s close to the whole fix. But a meaningful number of devices run Telnet because it’s the only remote command-line interface the firmware offers, and simply switching it off removes administrators’ ability to manage the device at all — which in practice means people often turn it back on the moment they need to troubleshoot something, undoing the fix. A durable answer needs to cover what replaces Telnet’s functionality, not just that it gets disabled.
Step 1: confirm the device is actually reachable, and from where
Before changing anything, confirm your starting point with AdminKit’s port check tool against your own public IP (use what is my IP first to confirm that address), and separately check whether Telnet is reachable from elsewhere on your own local network, which a port check against your public IP won’t reveal. Devices on a shared or guest network segment can be reachable to more than you’d expect even with no internet exposure at all.
Step 2: migrate to SSH wherever the device supports it
RFC 854 defines Telnet as a plaintext protocol with no encryption and, in most implementations, no strong authentication beyond a static password. SSH, specified across RFC 4251 and its companion RFCs, was built specifically to replace this kind of remote shell access with an encrypted channel and support for key-based authentication, which removes the single-password-guess risk that makes Telnet dangerous at scale. If a device’s firmware offers SSH alongside Telnet, migrate fully and disable Telnet rather than running both — a disabled-but-present Telnet service is still an attack surface if it can be re-enabled.
Step 3: change every default credential, on whatever interface remains
Whether the device ends up using SSH, a web admin panel, or nothing beyond local console access, default or weak credentials undo every other control. Change the administrative credential on every interface the device exposes, not just the one you were originally worried about — a secured Telnet replacement with a default password on its web interface hasn’t actually closed the gap.
Step 4: for devices that can’t be upgraded, move the fix to the network
Some embedded devices genuinely can’t be updated to support SSH and won’t get a firmware update that adds it. For these, the fix has to happen around the device rather than on it:
- Keep any remote administration interface off the public internet entirely — no port forward, no UPnP-created mapping, under any circumstance.
- Restrict access to a dedicated management VLAN or a VPN, so reaching the device’s admin interface at all requires already being on a trusted, authenticated network path.
- Treat the device as having a defined replacement timeline rather than indefinite “compensating controls” — CISA’s BOD 23-02 frames exactly this kind of internet-exposed management interface as something to remove from direct exposure or place behind strong access control within a defined window, not something to leave indefinitely with partial mitigations.
Step 5: check for other exposed services on the same device
A device that shipped with Telnet enabled by default often shipped with other unnecessary services enabled too — an outdated web admin panel, an unauthenticated API, a diagnostic port never meant for production use. Review the device’s full set of listening services, not just the one you already knew about, since fixing Telnet alone can leave an equally serious gap sitting one port over.
Step 6: re-check after every change, and periodically afterward
Re-run port check after disabling Telnet and again after any firmware update or factory reset — some devices re-enable Telnet or restore a default port-forward rule automatically, which is exactly the kind of silent regression a one-time check won’t catch.
The same underlying pattern shows up elsewhere
RDP shares Telnet’s basic risk profile — a protocol built to grant administrative or interactive access, routinely found exposed directly to the internet — even though RDP’s own cryptography is far stronger than Telnet’s complete absence of it. See our guide on hardening RDP exposure for the equivalent checklist on that protocol, and is port 23 (Telnet) exposed for the quick exposure-check version of this page.
Defensive use only
Every check this guide links to is for devices and networks you own or are explicitly authorized to test. Never scan, probe, or attempt to connect to a device you don’t control — AdminKit’s active checks only ever run against the IP making the request or an asset you’ve verified ownership of. See our Disclaimer and Acceptable Use Policy for the full terms.
This guide is general information, not a security audit of your specific network — see our disclaimer for what AdminKit's guidance does and does not commit to.
Frequently asked questions
If I've already disabled Telnet, am I done?
You've closed the single most common path to a full administrative shell, which is the most important step. But if the device still has other exposed services, outdated firmware, or default credentials on whatever admin interface replaced Telnet, the underlying weaknesses that made Telnet dangerous in the first place are often still present elsewhere on the device.
What should replace Telnet for devices that genuinely need remote command-line access?
SSH, defined across RFC 4251 and related RFCs, provides the same kind of interactive remote shell access but with encryption and strong authentication built into the protocol itself, including support for key-based authentication instead of passwords alone — a meaningful upgrade over Telnet sending credentials in plaintext.
What if the device doesn't support SSH and can't be upgraded?
This is common on older or cheap embedded hardware, and the fix has to move to the network layer: keep any form of remote administration off the public internet entirely, restrict it to a dedicated management network or VPN, and treat the device as a candidate for replacement on a defined timeline rather than something to leave running indefinitely with compensating controls alone.
Does CISA have guidance specific to exposed management interfaces like this?
Yes — CISA's Binding Operational Directive 23-02 addresses internet-exposed management interfaces broadly, requiring federal agencies to either remove them from direct internet exposure or put strong access controls in front of them within a defined window. The same principle applies well beyond federal networks: a management interface, Telnet or otherwise, shouldn't be the first thing an internet scan finds.
How do I check whether a device I've already 'fixed' is still reachable?
Re-run a port check against your own public IP after making changes, rather than assuming a configuration change took effect — some devices re-enable Telnet or re-create a port forward automatically on reboot or firmware update, which is exactly the kind of regression a one-time fix won't catch.
Want AdminKit to watch this for you?
Free checks tell you the state today. Protective DNS and monitoring tell you when it changes.