The EDR success story in IT security 

How did EDR change endpoint security? 

Endpoint detection and response changed the game for IT security. Instead of relying on signature-based antivirus that only catches known threats, EDR watches behavior: 

• Monitors when a process does something suspicious 

• Detects unusual file system activity 

• Identifies abnormal network connections 

• Can isolate a compromised machine in seconds 

If EDR works so well for endpoints, why not use it for building management systems? 

Because building management systems are not endpoints. And the fundamental assumptions that make EDR effective do not apply in operational technology environments. 

This is the critical misunderstanding that creates false security confidence in smart buildings. Organizations assume their EDR coverage extends to all networked devices, when in reality it cannot even install on building systems. 

The endpoint assumption that breaks in OT 

What core assumption does EDR rely on? 

EDR tools are built on a core assumption: they can install an agent on the device being protected. That agent monitors: 

• Processes and applications 

• File system activity 

• Network connections 

• User behavior 

When something looks wrong, it intervenes automatically. 

Why does this assumption work for traditional endpoints? 

This works brilliantly on Windows laptops, macOS workstations, and Linux servers because these are: 

• General-purpose computing devices with spare CPU cycles 

• Systems with memory overhead beyond their primary functions 

• Operating systems designed to run multiple applications simultaneously 

• Devices that can tolerate security software consuming resources 

Why does this assumption fail for building systems? 

Building management systems are none of those things. The architectural differences are fundamental, not incremental. 

What BMS controllers actually are 

What is a BMS controller and how does it differ from an endpoint? 

A BMS controller is a purpose-built device running a real-time operating system (RTOS). It has one job: controlling building systems with deterministic timing. 

How BMS controllers work: 

• Temperature sensor signals it is too hot 

• Controller opens the cooling valve 

• This must happen reliably, every time, within milliseconds 

• No delays, no exceptions, no competing processes 

Why cannot BMS controllers run security agents? 

Technical constraints: 

• No spare compute capacity: Devices were designed with exactly enough processing power to do their job, because every extra transistor costs money at scale 

• Real-time requirements: Adding a security agent would compromise their primary function and introduce timing delays 

• Embedded firmware: Many run on systems with no capability to install additional software 

• Resource limitations: Memory and storage are sized precisely for control functions 

What about updates and maintenance for BMS security? 

Even if you could install an agent, you would not want to: 

• BMS controllers run continuously, 24/7/365 

• They cannot be rebooted for updates without affecting building operations 

• Some controllers manage critical systems like fire suppression or emergency lighting 

• Taking them offline for security patches is not an option during business hours 

• Planned maintenance windows may not exist for life safety systems 

This is fundamentally different from IT endpoints where brief downtime is acceptable. 

The protocol problem 

What protocols do EDR tools understand? 

EDR tools understand Windows APIs and common application protocols: 

• What a normal HTTP request looks like 

• When PowerShell is doing something suspicious 

• Standard TCP/IP communication patterns 

• File system operations in Windows, macOS, or Linux 

What protocols do building systems use? 

Building systems speak entirely different languages: 

• BACnet: Building automation and control networks 

• Modbus: Industrial control and sensor communication 

• LonWorks: Lighting and HVAC system control 

• OPC-UA: Data exchange between building systems and enterprise applications 

• KNX: Building automation in European installations 

Why is this a problem for building automation cybersecurity? 

Your EDR has never heard of these protocols. Even if it could see the traffic, it would not know what normal looks like: 

• Is this BACnet command legitimate or malicious? 

• Should this Modbus controller be communicating with that IP address? 

• Is this OPC-UA data exchange expected or suspicious? 

The EDR has no idea. It lacks the protocol parsers, behavioral baselines, and industrial control logic to make these determinations. 

The response dilemma 

What happens when EDR detects a threat on an IT endpoint? 

When EDR detects a threat on a laptop, the automated response is straightforward: 

1. Isolate the device from the network 

2. User loses connectivity for a few minutes 

3. Security team investigates 

4. Device is cleaned or reimaged 

5. Annoying, but manageable 

What would happen if EDR took the same action on a BMS controller? 

Now imagine that response action on: 

• BMS controller managing HVAC for a data center: Cooling stops, servers overheat, potential equipment damage 

• Access control system for a hospital: Doors lock, emergency access compromised, patient care impacted 

• Elevator controller in a high-rise: Elevators stop, people trapped, emergency response needed 

• Fire suppression system: Life safety system offline during potential emergency 

Why are automated responses dangerous in OT environments? 

Automated response actions that make sense for IT endpoints can create safety hazards in OT environments. 

Security tools in building systems need to: 

• Detect and alert security teams 

• Provide context for investigation 

• Allow manual response decisions 

• Not automatically isolate or disrupt operations 

The risk calculation is inverted: in IT security, false negatives (missed threats) are the primary concern. In OT security, false positives that trigger automated responses can cause immediate physical harm. 

What works instead: passive network monitoring 

What is the right approach for BMS security? 

Securing building systems requires a different approach: network-based passive monitoring. 

How passive monitoring works: 

1. Monitor the network traffic that building devices generate 

2. Deploy sensors that understand OT protocols 

3. Build baselines of normal behavior for each device type 

4. Detect when a BMS controller starts communicating with unusual destinations or issuing unexpected commands 

5. Alert security teams without disrupting operations 

What are the advantages of passive monitoring over EDR? 

This approach has several advantages for building automation cybersecurity: 

• No agents to install or maintain on devices 

• No impact on device performance or reliability 

• Visibility into protocols that endpoint tools cannot understand (BACnet, Modbus, OPC-UA) 

• Detection without automated response actions that could cause harm 

• Continuous monitoring without requiring device downtime for updates 

Does passive monitoring provide the same visibility as EDR? 

In many ways, passive monitoring provides better visibility for building systems:

• Sees all communication between devices, not just activity on individual endpoints 

• Detects lateral movement across the building automation network 

• Identifies unauthorized devices joining the network 

• Monitors for protocol anomalies and malformed commands 

• Does not depend on agent installation or device cooperation 

The expertise gap in OT endpoint protection 

What expertise is required for building system security? 

Here is the challenge for MSPs: passive OT monitoring requires expertise that most IT-focused teams do not have. 

Critical questions that require OT expertise: 

• What does normal BACnet traffic look like? 

• How do you distinguish between a legitimate firmware update and a malicious modification? 

• When should unusual traffic trigger investigation versus business-as-usual activity? 

• Which communication patterns indicate reconnaissance versus routine maintenance? 

• What baseline behaviors are expected for different controller types? 

Why has OT security traditionally been limited to specialists? 

This is why OT security has traditionally been the domain of specialists. Vendors like Claroty, Dragos, and Nozomi built their businesses around this expertise: 

• Analysts trained in industrial protocols 

• Understanding of building automation architecture 

• Knowledge of operational constraints and safety requirements 

• Experience distinguishing threats from operational anomalies 

But they sell to enterprises, not MSPs. Their pricing and go-to-market models do not fit the mid-market buildings that MSPs serve. 

Bridging the gap: the enhanced.io approach 

How does enhanced.io make OT security accessible to MSPs? 

At enhanced.io, we combine passive OT monitoring with the expertise to make it useful for MSPs and their building operator clients. 

What we provide: 

• Platform integration: Network sensors that understand building protocols (BACnet, Modbus, OPC-UA) 

• SOC expertise: Analysts trained to investigate OT anomalies in building environments 

• Fractional security directors: Can explain findings to building operators in business terms they understand 

• Protocol-aware detection: Baselines for building automation behaviors and anomaly detection 

• Response guidance: Recommendations that account for operational constraints 

What does this mean for MSPs offering BMS security?

For MSPs, this means you can offer building security without building an OT security team: 

• You get the technology as part of the platform 

• You get the expertise as part of the SOC service 

• You get the strategic guidance through fractional security directors 

• Your clients get comprehensive coverage for both IT and OT environments 

How is this different from traditional EDR vendors? 

EDR vendors cannot pivot to this model because their architecture is fundamentally agent-based. They would need to: 

• Rebuild platforms around passive monitoring

• Retrain SOC analysts on industrial protocols 

• Develop new behavioral baselines for building systems 

• Change their entire product strategy 

This is why your endpoint-focused competitors cannot follow you into building automation cybersecurity. 

What should MSPs do next? 

EDR transformed endpoint security, but buildings do not run antivirus. MSPs - like Onsite Technologies - need a different approach entirely. 

If you serve clients with building management systems: 

1. Understand that your EDR coverage does not extend to building automation 

2. Assess what percentage of your clients' attack surface is currently unmonitored 

3. Explore passive monitoring approaches designed for OT environments 

4. Consider how fractional security director services can bridge expertise gaps 

Ready to explore OT security for your MSP clients? 

Talk to our team about how the fractional security director model works for building environments. Learn how enhanced.io enables MSPs to deliver building automation cybersecurity without becoming OT specialists. 

Or read our complete guide to OT security for MSPs to understand the full market opportunity and technical approach.