Modbus exposure check: is your industrial device reachable without authentication?
How does this check work, and what does the result tell you?
AdminKit checks whether the public IP you are connecting from has a Modbus/TCP industrial device reachable from the internet on port 502 by default, reading back only the device's own identity — vendor and product, via Modbus function 43 — never a coil or register, since Modbus/TCP has no built-in authentication at all.
Part of the Machine protocols cluster — more tools, guides and terms on machine protocols.
AI explanation Run a check below, then sign in to ask AI to explain the result in plain language.
This checks only the public IP address you are connecting from right now — never a host you type in, and never someone else's industrial device. It only ever reads the device's own identity (vendor/product, via Modbus function 43) when the device answers; it never reads or writes a coil or register.
Next step
Also see MQTT exposure, or check other commonly exposed ports on the same IP.
Keep this result
Copy a link to this check so you can share it or run it again later. Want a heads-up when this result changes? Talk to our team and we'll set it up for you.
How it works and limits
Modbus/TCP is the dominant protocol connecting factory-floor PLCs, sensors and controllers, defined by the Modbus Application Protocol specification. It predates the internet threat model entirely and has no authentication built in — anything that can reach port 502 can read or write registers controlling real physical equipment. NIST SP 800-82, the federal guide to operational technology security, covers internet-exposed industrial protocols like Modbus/TCP as a defense-in-depth problem precisely because the protocol itself cannot enforce any access control on its own.
What it checks
- Whether the public IP you are connecting from answers a Modbus/TCP connection on port 502 by default, or a port you specify.
- Whether the device also answers a Read Device Identification request (function 43) with a vendor name, product code or revision — a second, lower-severity signal that device metadata is exposed without authentication.
What it won’t do
- It never reads or writes a coil, discrete input, holding register or input register — the one request it sends beyond the TCP connection itself is the read-only device-identity request, nothing that touches process data.
- It never probes a device you did not request the check against — see “Why does it only check my own IP?” below.
Limits
- A completed TCP connection on port 502 is itself the finding: Modbus/TCP has no authentication, so reachability alone means anything on that network path could issue any request, whether or not this check’s one identity request happens to succeed.
- No query is logged; see /legal/privacy/.
Check manually today
nc -vz -w 3 <host> 502A successful connection means the port is reachable from wherever you ran this command — treat any factory or OT device that answers here as needing to be moved behind a firewall or VPN, not reachable directly from the internet. See CISA’s ICS advisories for currently known vulnerabilities in industrial control systems. Only test equipment you are authorized to test.
See is Modbus/TCP port 502 exposed? for the dedicated detection guide, the port 502 remediation playbook for how to fix what this finds, the glossary entry for Modbus/TCP, and AdminKit’s MQTT broker exposure check for a related machine-protocol self-check that works the same way.
Frequently asked questions
Is this check live?
Yes — it sends a real Modbus/TCP connection via AdminKit's Check API (POST /v1/check/modbus), the same endpoint anyone can call anonymously, rate-limited per visitor. Like AdminKit's open ports, RTSP and MQTT exposure checks, it only ever probes the public IP address the request comes from or an asset you've verified ownership of — there is no field to type in someone else's industrial device, so this works as a live, self-check tool for every visitor today.
Will it read or write any coil or register?
No. It only ever sends one request beyond the TCP connection itself: function 43 (Read Device Identification, MEI type 14, the 'basic' category), which asks the device to state its own vendor name, product code and revision. It never sends any function code that reads or writes a coil, discrete input, holding register or input register, and it cannot change anything on the device.
What does 'device identity readable' mean, versus just 'reachable'?
Modbus/TCP has no authentication at all, so a completed TCP connection on port 502 is already the main finding regardless of what happens next — anything that can reach the port can issue any request. Whether the device also answers the identity request with a vendor/product name is a second, lower-severity signal that device metadata is exposed too; a device that refuses or ignores that one follow-up request is still just as reachable.
Why does it only check my own IP, not a device I don't own?
Like every active AdminKit check, a Modbus probe only runs against your own IP or an asset you've verified ownership of — an unverified host gets no active connection attempt at all. That is also why the check always reads your current public IP automatically rather than offering a field to type a host into: no other address could be checked with your permission.
What if my device's Modbus port isn't 502?
Enter the external port your router or gateway actually forwards before running the check. Modbus/TCP has no encrypted variant in common use, so unlike the MQTT or RTSP checks there is no TLS-port caveat here — whatever port answers Modbus/TCP on your own IP is what this check reports on.