How do you read an "open ports on my IP" scan result?
An open-ports-on-my-IP result reports, for each of nine specific TCP ports, whether something on your public IP accepted a connection within a timeout — nothing more — and reading it means matching each open port to the device and protocol it belongs to, since a Telnet port left open calls for a different, more urgent fix than an admin web UI on port 8080 that you deliberately exposed.
By AdminKit team, Netbase JSC · Updated October 29, 2026
What the result actually measures
AdminKit’s open ports on my IP check tests nine specific TCP ports against your own public IP — the address you’re connecting from, determined server-side, never one you type in — and reports each as open or not, only after you click to start it. “Open” here has one precise meaning, consistent with how NIST’s firewall guidelines describe basic port filtering: a TCP connection attempt to that port completed successfully within the timeout, which means some process on that address is actively listening on it. The check stops there — it never sends a login attempt, a protocol command, or anything resembling an exploit, so an open result tells you a door exists, not what’s behind it or whether it’s locked.
Reading “not open”: closed versus filtered
Two different outcomes both show as not-open, and the distinction is useful context even though the check doesn’t need you to act on it: a closed port means a host answered and explicitly refused the connection — there’s a live, reachable device at that address, it simply isn’t listening there. A filtered or timed-out result means nothing came back at all, which is the signature of a firewall silently dropping the attempt rather than replying to it. If you expect a port to be closed by firewall rather than by the service simply not running, a filtered/timeout result is the one that confirms the firewall is actually doing its job; a closed result from a host that answers everything else could mean the firewall isn’t filtering that specific port at all, just that nothing happens to be running there today.
The nine ports, grouped by what an open result actually hands over
- Telnet (23) — an unauthenticated or weakly authenticated plaintext admin shell on many consumer routers and cameras. CISA’s Known Exploited Vulnerabilities Catalog lists numerous device vulnerabilities reachable precisely through exposed management ports like this one. Treat an open result here as urgent; see Telnet and RTSP: why camera and router admin ports end up exposed and is port 23 (Telnet) exposed? for the fix.
- RTSP (554) — a live video stream, often viewable with no credential check at all depending on the device’s configuration. See is port 554 (RTSP) exposed?.
- MQTT (1883) and MQTTS (8883) — a publish/subscribe broker; 1883 is unencrypted and, without an access-control list configured, frequently lets anyone publish or subscribe to any topic. See is port 1883 (MQTT) open?.
- Modbus (502) — an industrial control protocol with no authentication built in at all by design; any open result on this port in a residential or office context, rather than an isolated OT network, is worth investigating immediately. See the Modbus TCP 502 remediation playbook.
- TR-069/CWMP (7547) — a remote-management protocol ISPs use to configure routers; an open result not expected by your own ISP relationship is unusual and worth checking. See TR-069 port 7547 exposure, explained.
- Admin web UIs (80, 443, 8080) — at minimum these require a login page before anything happens, which is why they’re lower urgency than the protocols above, but an open result you didn’t intentionally configure (a router’s admin panel reachable from the internet, for instance) is still worth closing. See is port 8080 (admin panel) exposed?.
Why your own address can be misleading
A public IP isn’t always a one-to-one match with a single device you control. Carrier-Grade NAT, a mobile network, or a home router sitting in front of several devices can all mean the address this check scans is shared or represents more than one thing at once. If an open port doesn’t match anything you recognize on your network, confirm whether your address is actually dedicated to you before chasing the wrong device — see what is CGNAT? for how to tell.
What to do with the result
Work down the list in the priority order above rather than treating every open port as equally urgent: an unauthenticated protocol with no login step (Telnet, RTSP, MQTT, Modbus) is a more immediate risk than a web admin UI that at least requires credentials first. For each port that’s open and shouldn’t be, the fix is almost always one of three things — disable the service if you don’t need it reachable from the internet at all, change any default credentials if you do, or move remote access behind a VPN or firewall rule instead of a direct port forward. Re-run the check after making a change; a fix that doesn’t actually take effect (a firewall rule applied to the wrong interface, a port-forward rule still active elsewhere) is common enough that confirming the result changed is worth the thirty seconds it takes.
Next step: check your own IP
Run AdminKit’s open ports on my IP check — it only ever scans the address you’re connecting from, and only after you click to start it. If a port-forward or firewall change doesn’t seem to be taking effect, confirm your actual public-facing address first with what is my IP, since CGNAT or a changed dynamic IP can make a stale result look like a fix that didn’t work.
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
Does 'open' mean the port is actually vulnerable?
No — 'open' only means a TCP connection attempt succeeded within the check's timeout. It says nothing about whether the service behind it uses a default password, runs outdated software, or is otherwise exploitable; the check stops at the bare connection and never sends protocol commands or credentials. Open is the starting fact to investigate, not the conclusion.
What's the difference between a closed and a filtered result?
A closed port means something answered the connection attempt and actively refused it (a TCP RST) — there's a live host at that address, just nothing listening on that specific port. A filtered or timed-out result means no response came back at all within the timeout, which usually means a firewall is silently dropping the connection attempt rather than replying. Both outcomes mean the port isn't reachable the way an open one is; the check reports them as not-open either way.
I ran this from my own network and port 8080 shows open — is that really exposed to the internet?
The check connects to your public IP from outside your network, the same way an internet scanner would, so an open result here does reflect real internet-facing exposure, not just LAN reachability. If you separately test from inside your own network against your router's LAN address, you're testing something different and will see your internal devices regardless of what's exposed externally.
My IP shows open ports I don't recognize at all — what's going on?
Your public IP can be shared: Carrier-Grade NAT (CGNAT), a mobile carrier network, or a router in front of several of your own devices can all mean the address answering isn't the single device you expect. Confirm what's actually on your network before assuming a result belongs to a device you own — see AdminKit's guide on CGNAT and dynamic-IP monitoring for how to tell whether your address is shared in the first place.
Which open port should I fix first if I see more than one?
Prioritize by what the protocol exposes with no further step needed: Telnet (23) hands out a plaintext admin shell and has been the entry point for internet-scale botnets, so treat it as most urgent. RTSP (554), MQTT (1883) and Modbus (502) typically need no credentials to read data or publish messages by default, which is next. An admin web UI on 80/443/8080 at least requires a login screen before anything happens, making it comparatively lower urgency — though still worth closing if you didn't mean to expose it.
Does a clean result (no ports open) mean my network has no other exposure?
No — this check only tests nine specific TCP ports chosen because they're commonly misconfigured on home and small-office devices; it is not a full port scan of your IP, and it doesn't test UDP services like BACnet (47808) or CoAP (5683) at all yet. A clean result on these nine ports is good news for exactly those nine, not a clearance for everything else that might be reachable.
Want AdminKit to watch this for you?
Free checks tell you the state today. Protective DNS and monitoring tell you when it changes.
Talk to an expert
Huy Nguyen (David), Founder & CEO, Netbase JSC
Ask whether this fix applies to your setup, or get a second pair of eyes on your DNS and mail records.