ZoomEye finds roughly 900,000 reachable hosts on Niagara framework ports 1911 and 4911

The measurement

Two queries run against ZoomEye's global index on 27 September 2026, differing only in the port number, returned 902,191 hosts on port 1911 and 816,986 on port 4911, according to a dev.to analysis. Both ports are conventionally associated with the Niagara framework, the supervisory software layer found in a large share of the world's managed buildings, data centres, campuses and light industrial sites.

What sits behind the ports

Niagara operates above the equipment layer. Where BACnet controllers attach directly to individual pieces of building equipment, a Niagara supervisor runs above them, translating between protocols and presenting operators with one consolidated view of data points and histories. The framework communicates over BACnet, Modbus, LonWorks and a range of proprietary protocols through driver modules, and it also serves a web interface, which is why supervisors are frequently reachable over standard web ports in addition to 1911 and 4911.

Why the supervisor is the prize

The dev.to post argues that the security stakes are structural. Compromising a controller affects only the equipment that controller governs; compromising a supervisor affects everything the supervisor can reach, and reaching everything is essentially the supervisor's job description. Because supervisors read from and write to all downstream systems, they also store the credentials for those systems, so an attacker who takes one over inherits authenticated access instead of having to earn it.

Niagara also carries a substantial vulnerability history, the post notes, including flaws in its web interface and in file handling that have been exploited in the field. Version state matters as a result, yet it is frequently unmanaged: supervisors are typically maintained under facilities contracts rather than by an IT patch process.

Exposure is often deliberate

Supervisors are also the device class most likely to be exposed on purpose. Remote access to building management systems is a routine operational requirement, and the dev.to piece lists the common patterns used to satisfy it: a port forwarded from a public address, a management interface reachable through a VPN that is itself unconstrained, and vendor remote-support connections that remain active long after the commissioning project ends.

What the numbers do and don't show

The two counts, being in the same order of magnitude, are consistent with a single class of devices answering on multiple interfaces — which is what the framework does — rather than two separate populations. The measurement establishes scale of reachability, not identity or condition: it cannot distinguish production supervisors from development instances, vendor test systems or unrelated software, and neither port is assigned exclusively to Niagara. The post explicitly does not claim that any counted host is a Niagara supervisor, nor that any host is vulnerable. The figures also come from a single index on a single day and depend on what was routable and how services responded.

What operators should check

The recommendations in the post start with a question rather than a port scan: does the supervisor need to be reachable from outside its own network at all, and if so, by whom. The suggested answer to that need is a VPN with per-user authentication and a defined set of permitted destinations, not a forwarded port.

The second check is version state — which release each supervisor runs, whether it is still supported, and whether any update process covers it. A supervisor that has run continuously since commissioning is described as the common case and the one needing the most attention.

The third is the downstream credential set: reviewing which systems the drivers are configured to connect to, and whether the supervisor's credentials for those systems are broader than the integration actually requires.

For detection, supervisors log point changes and operator activity as part of normal operation. Reading those logs for configuration modifications, new driver connections and changes to user accounts is described as more productive than inspecting network traffic, and it produces evidence that survives an incident.

Why it matters

Building automation sits at an awkward junction between IT and facilities management, and an internet-reachable supervisor is a single point from which heating, cooling and even industrial controllers can be manipulated using credentials that are already trusted. Close to a million hosts answering on the framework's conventional ports — whatever their exact composition — indicates that this layer is broadly visible, often deliberately exposed, and rarely on a conventional patch cycle. The fixes are not exotic: restrict reachability, establish version state, and scope downstream credentials to what the integration genuinely needs.