Using port check to inventory IoT and OT device exposure

What an inventory built on port check actually is

An asset inventory for IoT and OT exposure usually means knowing, for every site or network segment you’re responsible for, what’s reachable from the internet right now — not a single snapshot of one address. AdminKit’s port check tool tests nine specific TCP ports against the one public IP a request comes from, by design, and never a target you type in, which means building an inventory with it is a matter of repetition and record-keeping rather than one all-at-once scan: run it from each site, connection, or public IP you operate, and keep each result as a dated entry rather than treating a single check as a permanent fact. This fits environments like a chain of retail locations, a factory with more than one WAN connection, or an integrator managing several customer sites — anywhere “exposure” is really a question about several addresses, not one.

Turning an open port into a device fingerprint

Each of the nine ports this check covers maps to a recognizable device category, which is the basis of a usable fingerprint table rather than a flat list of yes/no results:

Port	Protocol	Typical device	Guide
502	Modbus TCP	PLC, RTU, or other industrial controller	Modbus TCP 502 remediation playbook
1883 / 8883	MQTT / MQTTS	IoT message broker	is port 1883 (MQTT) open?
554	RTSP	IP camera or video encoder	is port 554 (RTSP) exposed?
23	Telnet	Router, camera, or NAS admin shell	is port 23 (Telnet) exposed?
7547	TR-069/CWMP	ISP-managed router or ONT	TR-069 port 7547 exposure, explained
80 / 443 / 8080	HTTP(S) admin UI	Router, NVR, or other device with a web console	is port 8080 (admin panel) exposed?

IANA’s port number registry is the authoritative reference for which protocol a given port is registered to, which is useful when an open port doesn’t match the usual device in your environment — a non-standard service squatting on a well-known port is itself worth investigating. Two protocols common in building and sensor networks, BACnet/IP (47808) and CoAP (5683), are UDP-based and not covered by this check yet; both have their own guides — BACnet/IP exposure and is port 5683 (CoAP) exposed? — with a manual command to check them in the meantime.

Building the inventory record

A minimal, workable inventory entry needs only a handful of fields per site or address: the public IP checked, the date, which of the nine ports came back open, the device type inferred from the fingerprint table above, and what action was taken (closed, moved behind a VPN, or deliberately left open with a documented reason). CISA’s Known Exploited Vulnerabilities Catalog is worth cross-referencing for any device type you find exposed, since several of the ports this check covers correspond to device families with a documented history of active exploitation once reachable from the internet.

What this process can’t tell you

Port check reports whether a TCP connection succeeded, not which internal device answers it — that mapping lives in your own router or firewall’s port-forwarding configuration, which only you have access to. It also can’t discover devices that aren’t port-forwarded to the internet at all, which is most of a typical IoT/OT network by design; this inventory specifically tracks internet-facing exposure, not a full asset list of everything on the LAN. Treat a clean result on all nine ports as confirmation that this specific exposure surface is closed today, not as a statement about the network’s overall security posture.

Next step

Run AdminKit’s open ports on my IP check from each site or connection in your inventory, starting with what is my IP to confirm the exact address being tested, and log each result against the fingerprint table above before moving to the next location.

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.