There is an easy version of this article. Search Shodan for a building-automation port, count the results, and publish a number with the word “exposed” next to it. It takes ten minutes and it is wrong, usually by a large factor, and anyone who checks the working will find that out.
This is the other version. We ran a passive survey of internet-facing building management controllers in Ireland, and the headline is deliberately unglamorous: the number of genuinely exposed BACnet controllers we could confirm is small. But the survey is worth publishing anyway, for two reasons. The small number has a very specific and troubling shape. And the gap between the raw result and the real result is a lesson in how this kind of research goes wrong – a lesson that matters every time someone waves a Shodan screenshot at you.
Safety classification: Green. This survey used only Shodan’s existing scan data – a public index of internet-wide scans. Nothing was scanned, probed or connected to as part of this work. Reading an index of what is already public is passive; actively confirming a live host is not, and we did not do it. No controller is identified in this article, and no address, site name or object name that could identify one appears anywhere in it.
What we searched for, and why it under-reports and over-reports at once
Building management systems in Ireland run on a handful of protocols. BACnet/IP on UDP port 47808 is the dominant one for HVAC and building services. Modbus/TCP on 502 carries power and plant monitoring. The Tridium Niagara Framework, which sits on top of everything as a front-end, speaks its Fox protocol on TCP 1911.
The naive approach is to search each port and count. The problem is that an open port is not a device. Searching a port catches three things at once: the real controllers you want, unrelated services that happen to use the same port number, and honeypots pretending to be controllers to attract exactly this kind of attention. Any survey that counts open ports counts all three and calls the total “exposed building systems.”
The correct unit is not an open port but a device the scanner actually fingerprinted. When Shodan speaks BACnet to a host and gets a valid property read back – vendor, model, firmware, object name – that is a building controller. When it gets an open port and an unparseable blob, that is a maybe, and a maybe is not a finding. Every number below counts fingerprinted devices, not open ports, and the difference turned out to be most of the raw result.
The BACnet result, and the noise around it
The raw search for BACnet’s port in Ireland returned ten hosts. The real answer was two.
Eight of the ten returned a single, identical response – the same bytes, on hosts across four different networks, none of them carrying the industrial-control tag that the scanner applies to devices it recognises. Decoding that response settles it: a genuine BACnet/IP message begins with a fixed header byte that marks it as BACnet, and these did not. They were something else entirely – most likely a single vendor’s customer-premises equipment answering on that port number across an address range, replicated across a provider’s customer base. Identical responses from unrelated networks are the fingerprint of one product, not eight buildings.
Strip the look-alikes and two genuine BACnet controllers remained, both fingerprinted cleanly, both flagged as industrial control systems by the scanner, both the same model from the same vendor. That five-to-one gap between the raw count and the real count is not a detail. It is the reason to distrust any exposure statistic that does not show its working.
Following the vendor rather than the port
Two devices is a thin result, so we searched by vendor name instead of by port, which matches the parsed banner rather than the open socket. That widened the picture without loosening the standard – every hit was still a fingerprinted device with a full identity.
It returned a small cluster of the same controller family: a programmable BACnet building controller widely used for HVAC plant. After collapsing one device that appeared on two different carrier addresses – the same controller seen twice, identifiable because its internal identity was identical on both – we were left with four distinct controllers of this family exposed in Ireland during the survey window.
Four. Not four hundred, not forty. In a country with the building stock Ireland has, four internet-exposed controllers of the dominant type is, on its face, reassuring. The instinct is to file it under “problem smaller than feared” and move on.
Do not move on, because of what those four have in common.
The shape of the four
Three of the four controllers still carried their factory-default identity – the name the device ships with, derived from its own hardware address, the string a commissioning engineer is supposed to replace with something like “Block C AHU” during setup. A default identity means nobody completed that step. The controller was taken out of the box, put on the network, made to work, and left. Everything downstream of that – default credentials, no hardening, no thought about what else the device could reach – tends to travel with an uncommissioned identity, because the same step that sets the name is the step where someone would have thought about the rest.
The fourth was different, and more interesting for it. It had been renamed to something descriptive – a plant room. Someone configured that one. It is a commissioned, in-use, deliberately set-up system, and it is on the public internet anyway. That is not neglect. That is a working building control system with a door left open on purpose, presumably so somebody could reach it remotely without the inconvenience of a VPN.
Every one of the four sat on a consumer or business ISP, or a mobile network – not in a data centre, not in cloud hosting. That distribution is the signature of the mechanism behind all of this. These are not cloud-hosted anything. They are controllers in real buildings, reached over whatever internet connection the building already had, with a port opened – or a cellular router added – so that an integrator or a facilities contractor could dial in for support. The remote access is a feature somebody wanted. The exposure is the same feature seen from the outside.
The firmware told one more part of the story. Most of the cluster ran an older software build; one ran something markedly newer. A fleet maintained to different levels is a fleet nobody is maintaining centrally – each device patched, or not, whenever someone last had a reason to touch it. We are deliberately not turning that into a vulnerability claim. Mapping specific build numbers to specific published flaws needs a check against the vendor’s advisories that this survey did not perform, and asserting a CVE from a version string you have not verified is exactly the kind of overreach this article is arguing against. “Inconsistently patched” is what the data supports. “Vulnerable to X” is not, until someone does that work properly.
The Niagara result, which is also a result
We searched for exposed Niagara Fox front-ends, the management layer that typically holds credentials for every controller beneath it. In Ireland, we found none directly exposed.
That is worth stating plainly rather than omitting because it is not a scary number. Niagara guidance has for years been explicit that the Fox port should never face the internet, and a clean result is consistent with that advice being followed – or with remote access to those front-ends being tunnelled through something else rather than port-forwarded, which is how it should be done. Either way, “we looked for the highest-value target and did not find it hanging open” is a genuine, reassuring finding, and a survey that only reported the uncomfortable numbers would be telling half the story.
What the survey actually establishes
Put the pieces together and the honest conclusions are narrow, specific and defensible.
Internet-exposed building controllers exist in Ireland, but in small numbers – single digits for the dominant BACnet controller type during the survey window, not an epidemic. The exposure that does exist is concentrated in one controller family, which points not at a general epidemic of careless buildings but at the installation habits of the one or two integrators who deploy that family and set up remote access the same way each time. Most of the exposed devices were never fully commissioned, and all of them are reached over ordinary building internet connections rather than anything cloud-hosted, which tells you the exposure is a remote-support convenience seen from the wrong side. And the crown-jewel target, the Niagara front-end, was not found exposed at all.
The uncomfortable extrapolation is the one the survey cannot make but you should hold in mind: this is only what faces the public internet, only what one scanner has caught, and only within the survey window. It is the tip, not the iceberg. A controller reachable only from inside a compromised corporate network, or through a contractor’s VPN, or on a cellular router the scanner has not yet indexed, is invisible to this method and represents the same risk. The four we can see are an argument for looking properly at the ones we cannot.
A note on method, because it is the point
The reason to trust these numbers is that every one of them is a device that answered as what it claims to be, de-duplicated so the same controller on two addresses counts once, with the look-alikes and honeypots removed by checking the actual protocol response rather than the port. The reason to distrust the easy version is that it does none of that.
If you take one thing from this survey, let it be the habit rather than the count. When someone shows you a number of “exposed systems,” ask how many were fingerprinted rather than found, how many were de-duplicated, and how many survived a look at the actual banner. The number almost always shrinks under those three questions – and what is left, as here, is usually smaller, stranger and more useful than the headline.
Is your building controller reachable from the internet?
You can check the same way we did, passively, in a few minutes – and if a controller in a building you run is answering on a public address, it is worth knowing before someone else does.
CyberLabs OT and building-systems security assessments examine industrial and building-automation exposure, remote-access pathways, network segmentation and monitoring controls, while accounting for the operational availability that building services depend on.