The Register ran a story that should make every IT manager uncomfortable: cybercriminals are moving past stealing data and are now going after physical building systems — the HVAC controllers, the door access systems, the building management platforms that keep offices habitable and open for business. The article's subtitle says it all: "Hold my beer, have fun getting into your offices."
Here's the uncomfortable question that follows from it: if someone tampered with a building controller on your network tonight, when would you find out?
Not whether you'd detect it. When. For most IT teams, the honest answer is: tomorrow morning, when a user walks to the helpdesk and says the badge reader on floor two doesn't work. Not from your RMM. Not from your monitoring. Because those devices were never in the system. They don't run agents. They aren't in the asset list. They ride your switches, they depend on your VLANs, and when they break — or get abused — the ticket lands on your desk anyway.
That's the gap this article exposes, and it's the same gap that turns a ten-minute fix into a two-hour fire drill.
The Problem: Your RMM Sees Your Servers. It Doesn't See Your Building.
Modern office buildings are data centers nobody built on purpose. Building management system (BMS) controllers, HVAC gateways, door access controllers, IP cameras, NVRs, digital signage players, elevator monitoring panels — all IP-connected, most of them headless, most of them running firmware that hasn't been touched since installation. They live on your network infrastructure, frequently on flat VLANs, sometimes with default credentials, and almost never with a patch cadence.
And when something goes wrong with them, it becomes an IT problem — without IT ever having had visibility.
What the existing tool stack does with these devices:
- Agent-based RMM platforms — ConnectWise, NinjaOne, Datto RMM, Kaseya — are excellent on Windows endpoints and servers. But if a device can't run an agent, it doesn't exist to the RMM. The door controller, the HVAC gateway, the camera: invisible.
- Standalone monitoring tools might ping a controller if someone manually added it three years ago. Nobody maintains that list. Devices get moved, get re-IPed, and the check silently points at nothing.
- Facilities runs its own vendor portal with its own logins and its own alerts — a system IT has no access to, no alerting from, and no way to correlate with network events.
- The helpdesk is a separate product entirely. So when a "badge readers down" ticket arrives, it arrives naked: no device context, no history, no indication whether this relates to last night's switch reboot or something stranger.
Why the gap exists: siloed architecture and legacy assumptions. RMM was designed for managed endpoints. Monitoring was designed for servers and network gear. Building systems fell into the crack between IT and facilities, and both sides assumed the other owned them. Then everything got plugged into the same Layer 2 domain, and the crack became a canyon.
What it costs in practice. Picture a Monday you've probably already lived:
- 8:40 — Three users can't badge into the second floor. Ticket hits the helpdesk.
- 8:45 — The tech checks the RMM: nothing. The controller never had an agent. No checks, no history, no map position.
- 8:55 — Tech SSHes into the access switch and starts walking MAC address tables, guessing which port the controller is on.
- 9:30 — Second ticket arrives: the server room is at 27°C. Nobody has connected the two yet.
- 10:20 — Root cause: a weekend power blip rebooted the door controller and the HVAC gateway. One came back onto the wrong VLAN; the other didn't come back cleanly at all.
Two "unrelated" tickets. One root cause on a network segment nobody monitors. Two hours of senior tech time, an SLA miss, a facilities vendor called out for a device restart — and, the part that should actually worry you, no telemetry history to say whether the odd controller behavior last week was a fault or somebody probing the device.
For an MSP, this multiplies: 40 clients, and at half of them an unmonitored subnet with building gear you've never inventoried, from vendors you can't script against, behind doors only the client's facilities manager can open. Every incident on those devices starts with a phone call instead of an alert.
And that's the benign scenario. The Register article describes the other one: these devices are now targets in their own right — attackers who disrupt building access or physical operations rather than exfiltrate data. Whether it's a fault, a misconfiguration, or an intrusion, the response bottleneck is identical: you can't respond quickly to devices you can't see, reach, or verify remotely.
How AlertMonitor Closes the Gap
The fix isn't another portal. It's making sure these devices live in the same system where your alerts, sessions, scripts, and tickets already live — so when something physical breaks, the response is a workflow instead of an archaeology dig.
One inventory, one map. AlertMonitor discovers everything that touches the network — including agentless, headless devices — via ping, SNMP, and service/port checks. That door controller shows up on the network topology map next to the switch it hangs off, not in a spreadsheet that was outdated before it was finished. When a "readers down" ticket comes in, the tech sees exactly where the device sits, what it's connected to, and what else shares that path.
RMM where it counts. For the endpoints you do manage — workstations, servers, network gear — technicians open remote sessions, push software, and execute scripts across device groups from the same console they monitor from. No tab-switching to a separate ConnectWise ScreenConnect or Ninja session, no re-authenticating into a third tool at 2 AM. When the fix touches a managed endpoint or switch, the tech never leaves the platform.
One timeline, not five. Monitoring events, script execution results, remote sessions, and helpdesk tickets all land on the same timeline. The badge-reader ticket arrives with context attached: controller stopped responding at 02:17, same window as the recorded power event, upstream switch port stayed up, last automated check results visible. The tech starts with an answer instead of a blank screen.
Scripted response at fleet scale. Run one script across a device group — restart services, pull diagnostics, verify state — and the results feed back into the monitoring data. Automated remediations and manual technician actions are visible to the whole team in the same record. Nobody has to ask "did anyone already try restarting it?"
For MSPs: client-scoped views and a single NOC dashboard across every site. Building-system reachability checks get templated once and deployed to every client that has a badge controller — instead of being hand-built per site, or not built at all.
The old way vs. the AlertMonitor way:
Fragmented: facilities ticket → empty RMM → SSH into a switch → hunt MAC tables → call the vendor → possibly drive to the site. Two-plus hours, three people, one SLA breach.
AlertMonitor: automated reachability check flags the controller → topology map shows its position → script run confirms state → remote session to the upstream managed switch or nearest endpoint → VLAN/config corrected → resolution logged against the same ticket facilities opened. Minutes, one person, full audit trail.
Practical Steps: What to Do Today
You don't need a BMS project to start shrinking this blind spot. Start with inventory and reachability — the two things every fast response depends on.
1. Find out what's actually on those subnets. Before you can monitor a device, you have to know it exists:
# Inventory sweep: what is alive on this subnet right now?
$subnet = "192.168.40"
1..254 | ForEach-Object -Parallel {
$ip = "$using:subnet.$_"
if (Test-Connection -ComputerName $ip -Count 1 -Quiet) { $ip }
} -ThrottleLimit 64 | ForEach-Object {
$null = arp -a $_ # populate the ARP cache
$entry = (arp -a | Select-String $_).ToString()
[PSCustomObject]@{
IP = $_
MAC = ($entry -split '\s+')[-1]
}
} | Sort-Object IP | Format-Table -AutoSize
Run it against every VLAN where facilities, security, or AV gear might live. MAC prefixes will surface vendor families — controllers, cameras, printers — that nobody ever told you about.
2. Put reachability checks on the devices you can't agent. Headless controllers won't run software, but they will answer ping and expose a management port. "Is it alive and is its service port open" is 90% of the early-warning signal:
# Uptime check for headless building controllers (Modbus TCP / management web UI)
$controllers = "10.10.5.20", "10.20.5.11", "10.20.5.12"
$controllers | ForEach-Object {
[PSCustomObject]@{
IP = $_
Alive = (Test-Connection -ComputerName $_ -Count 2 -Quiet)
Modbus = (Test-NetConnection -ComputerName $_ -Port 502 -WarningAction SilentlyContinue).TcpTestSucceeded
WebUI = (Test-NetConnection -ComputerName $_ -Port 443 -WarningAction SilentlyContinue).TcpTestSucceeded
}
} | Format-Table -AutoSize
Schedule this in AlertMonitor against a device group per site. When the door controller stops answering, you get the alert — not the phone call from the receptionist. (For BACnet gear, the same pattern applies on UDP/47808.)
3. Verify the fleet you do manage is actually managed. The unmanaged subnet hurts most when your managed endpoints are also drifting. Prove your coverage:
# Patch posture: last installed hotfix per server, oldest first — stragglers float to the top
Invoke-Command -ComputerName (Get-Content .\managed-servers.txt) -ScriptBlock {
[PSCustomObject]@{
Server = $env:COMPUTERNAME
LastHotfix = (Get-HotFix | Sort-Object InstalledOn -Descending |
Select-Object -First 1).InstalledOn
OS = (Get-CimInstance Win32_OperatingSystem).Caption
}
} | Sort-Object LastHotfix | Format-Table -AutoSize
In AlertMonitor, this runs as a scheduled script against a device group, with results landing in the same timeline as alerts and tickets — so "which machines are behind on patches" is a filtered view, not a Friday-afternoon firefight.
4. Check your Linux-side appliances in the same pass. NVRs, signage players, and random embedded boxes often expose SSH or at least answer the network:
# Liveness + service-port check across headless appliances
for ip in 10.20.5.11 10.20.5.12 10.20.5.20; do
if ping -c1 -W1 "$ip" >/dev/null 2>&1; then
echo "$ip: reachable"
else
echo "$ip: NOT RESPONDING"
fi
timeout 2 bash -c "cat < /dev/null > /dev/tcp/$ip/502" 2>/dev/null \
&& echo "$ip: modbus/502 open" || echo "$ip: modbus/502 closed or filtered"
done
5. Make it continuous, not a one-time audit. The sweep you run once is a snapshot; the sweep scheduled in AlertMonitor is a control. Inventory drift, a controller that drops off, a device that reappears on the wrong segment — all of it lands on the same timeline as your alerts and tickets, which means the next "physical" incident starts with evidence instead of guesswork.
The attack surface your monitoring doesn't cover is exactly the surface someone else will eventually use — whether they're after your data or, as The Register's reporting shows, just want to watch your building stop working. Close the blind spot before the ticket proves it to you.
Related Resources
AlertMonitor RMM & Remote Management
Is your security operations ready?
Get a free SOC assessment or see how AlertMonitor cuts through alert noise with automated triage.