Most Managed Detection and Response (MDR) services were built for IT environments: endpoints, cloud workloads, email servers, and identity systems. They work well in those contexts. But the moment an MDR provider tries to extend coverage into operational technology (OT), the model breaks down. Industrial protocols look nothing like standard network traffic. PLCs and HMIs do not run endpoint agents. Legacy devices that have been operational for 15 years were never designed with security monitoring in mind.
That gap between IT-focused MDR and the reality of OT networks is where organisations face their biggest exposure. And it is exactly where the concept of OT MDR comes in, along with a set of challenges that make OT MDR fundamentally different from anything the IT security world has built before.
What Is OT MDR?
OT MDR applies the core principles of Managed Detection and Response (continuous monitoring, threat hunting, anomaly detection, and incident response) to industrial and operational technology environments. It extends security coverage beyond the corporate network into the production floor, the water treatment plant, the building management system, or the logistics hub.
Where traditional MDR monitors endpoints and cloud workloads, OT MDR focuses on the protocols, devices, and behaviours unique to industrial systems. That means decoding traffic on protocols like Modbus, Profinet, OPC UA, and BACnet. These are communication languages used by industrial machines that have no equivalent in standard IT networks. A firmware update pushed to a PLC at 3am may be a critical security event; the same update during a scheduled maintenance window is completely routine. Understanding that difference requires context that goes far beyond standard alerting logic.
Key components of a mature OT MDR approach include:
- Passive network monitoring that maps assets and traffic without installing agents or causing downtime
- Protocol-aware deep packet inspection (DPI) to detect threats hiding inside industrial traffic
- Behavioural baselines that define what normal looks like for each device and network segment
- Risk scoring tied to operational impact, so a compromised HMI on a critical production line gets flagged differently than a misconfigured sensor in a test environment
- Structured integration paths that feed OT security events into the centralised security monitoring platform used by the team handling detection and response
Why OT Needs MDR Now
1. The threat volume keeps climbing
ENISA’s 2025 Threat Landscape report identified OT threats as 18.2% of all threat categories tracked across Europe, with attack volumes jumping 22% year-on-year. Manufacturing remains the most targeted sector, with 68% of industrial ransomware incidents hitting production environments. These are not theoretical risks. They translate directly into halted production lines, missed delivery windows, and P&L impact that boards can no longer ignore.
2. NIS2 demands detection and reporting capabilities
Under NIS2 incident reporting obligations, organisations classified as essential or important entities must report significant incidents to their national CSIRT within 24 hours, provide a detailed assessment within 72 hours, and submit a final report within one month. That reporting timeline is nearly impossible to meet without continuous monitoring and structured incident detection in place. You cannot report what you cannot see, and most OT environments still lack the visibility to detect incidents in the first place.
Fines for non-compliance reach up to EUR 10 million or 2% of global annual turnover. Senior management is personally accountable under NIS2.
3. IT-only MDR leaves OT exposed
Standard MDR providers typically monitor endpoints, cloud platforms, and identity systems. They rarely have the capability to decode industrial protocols, map OT assets, or understand the operational context of an alert on a SCADA system. The result: a security monitoring service that covers the office but leaves the factory, the warehouse, or the utility network completely unwatched.
MDR, MSSP, SIEM, SOC: Cutting Through the Acronym Confusion
Before diving into how OT MDR works in practice, it helps to clarify what each security service model actually delivers. These terms are often used interchangeably, but they serve very different purposes:
| Service Model | What It Does | OT Relevance |
|---|---|---|
| SIEM (Security Information and Event Management) | Collects and correlates log and event data from across the environment to identify patterns and generate alerts | Provides a centralised data store for security events, but needs OT-specific data sources and skilled analysts to be effective in industrial environments |
| MSSP (Managed Security Service Provider) | Manages and monitors security tools such as firewalls, intrusion detection, and patching on behalf of a client | Handles security infrastructure, but typically does not take ownership of outcomes or provide OT-specific detection and response capabilities |
| SOC-as-a-Service (Security Operations Centre) | Provides 24/7 analyst monitoring, alert triage, and escalation to the relevant teams | Adds human analyst oversight, but response authority varies widely and OT expertise within SOC teams is rare |
| MDR (Managed Detection and Response) | Combines detection technology, analyst expertise, and active response into a single managed service outcome | Takes ownership of threat detection and coordinated containment. When properly equipped for OT, this is the model that closes the gap between alerting and action |
The distinction that matters most: SIEM, MSSP, and SOC providers primarily detect and alert. MDR providers are expected to act, to move from detection to coordinated response. That difference matters enormously in OT environments, where the consequences of an uncontained threat can extend far beyond a data breach.
The R in MDR: Why Response Is Different in OT
“Applying IT-centric incident response actions in OT, such as aggressive containment, indiscriminate isolation, or automated shutdowns, can halt production, damage equipment, or create unsafe operating conditions.”
Dean Parsons, SANS Certified Instructor and CEO of ICS Defense Force (SANS Institute, February 2026)
In IT environments, MDR Response means the provider acts immediately and autonomously: isolating an infected endpoint, killing malicious processes, suspending compromised accounts. This is fast, effective, and appropriate for IT assets. In OT, the same actions can cause catastrophic outcomes.
Taking a PLC offline mid-cycle, isolating a network segment that controls an active production process, or severing a connection to a safety system can trigger exactly the kind of physical disruption, equipment damage, or safety event that the attacker intended to cause. The SANS Institute made this point explicitly in their February 2026 analysis of ICS/OT incident response: traditional IT response controls can sometimes cause more harm than good when applied directly to industrial environments.
In OT environments, the priority order is fundamentally different from IT:
- Safety first – above everything else
- Availability – keeping critical processes running
- Integrity – ensuring data and commands are trustworthy
- Confidentiality – protecting sensitive information (last priority in OT, first in IT)
This means OT Response cannot be automated or remotely triggered without direct coordination with plant engineers, process owners, and operations leadership. As SANS notes: containment in OT does not always mean shutdown. If a threat is understood, constrained, and not actively affecting the physical process, maintaining controlled operations while containing the threat may be safer than aggressive isolation.
So how does OT MDR deliver Response?
OT MDR Response is not a button the provider presses remotely. It is a structured, coordinated process that requires the right information in the right hands at the right moment. The MDR provider’s role is to:
- Detect: Confirm the threat is real, not a false positive or a scheduled maintenance action
- Enrich: Add OT context to the alert. Which asset, which protocol, what changed, what the operational impact could be
- Escalate: Route the alert to the right people (the security team, the plant engineer, the operations manager) with a clear, actionable picture of the situation
- Guide: Provide OT-aware containment options and recommendations, while the organisation decides how and when to act based on operational risk
- Document: Record the incident for NIS2 reporting, post-incident review, and regulatory compliance
The key difference from IT MDR is that the human decision-maker in OT is always an engineering or operations lead, not just a security analyst. Response in OT is engineering-led and safety-first. MDR enables that response by providing the situational awareness and structured escalation that makes fast, confident decisions possible.
OT MDR does not replace the plant engineer’s judgement. It arms that engineer, and the security team, with the enriched, real-time intelligence to make the right call quickly and safely.
The Missing Piece: OT Visibility as the MDR Foundation
Even the best MDR provider cannot protect what it cannot see. And in OT environments, visibility is the piece that is almost always missing.
Consider what an MDR analyst, or an OT engineer responding to an escalation, needs to do their job effectively in an industrial environment:
- A complete, real-time inventory of every connected OT and IoT device
- Continuous network traffic analysis using protocol-aware deep packet inspection
- Behavioural baselines that distinguish normal operations from anomalous activity
- Risk context that links technical findings to business impact and operational consequences
- Structured data feeds that route OT security events into the security monitoring platform used by the team handling detection and response
Without these inputs, an MDR provider is operating blind in the OT segment. They might monitor the IT perimeter flawlessly, but attackers who pivot from IT into OT (a well-documented attack path) will move through an unmonitored zone. According to industry research, 90% of OT networks contain outdated assets that IT-focused tools simply do not recognise.
This is where the foundation matters. OT MDR does not start with a 24/7 SOC. It starts with the ability to see what is on the network, understand what it is doing, and detect when something changes.
Nautilus: The OT Intelligence Layer That Makes MDR Work
Nautilus provides the foundational visibility, detection, and reporting capabilities that OT MDR depends on. Whether an organisation works with an external MDR provider, an MSSP building out OT capabilities, or an in-house security team, Nautilus delivers the OT-specific data and intelligence that these teams need to detect threats and guide effective response.
What Nautilus brings to the OT MDR stack
| Capability | What It Does for OT MDR | Compliance Alignment |
|---|---|---|
| Continuous Asset Discovery | Maps every PLC, HMI, IoT device, and vendor laptop in real time, eliminating the blind spots that undermine detection and response | NIS2 asset inventory, IEC 62443 |
| Protocol-Aware DPI | Decodes industrial traffic (Modbus, Profinet, OPC UA, BACnet) to detect threats that generic tools miss | Deep anomaly detection |
| Behavioural Anomaly Detection | Establishes baselines for normal OT operations and flags deviations, from unexpected firmware updates to unusual command sequences, providing the context needed for engineering-led response | Continuous monitoring requirement |
| Risk Reporting in Business Terms | Translates technical findings into executive-ready reports that quantify risk in financial terms, not just vulnerability scores | NIS2 board-level reporting |
| Security Platform Integration | Feeds OT telemetry into Microsoft Sentinel, Splunk, ServiceNow, and other platforms, so MDR analysts and security teams get a unified IT/OT view | SOC workflow integration |
How this works in practice
Nautilus deploys passively using virtual sensor appliances connected to network span ports. There is no software installed on OT devices, no agents, no disruption to running processes. The platform is operational within hours, which means an organisation can go from zero OT visibility to full network monitoring in a single working session.
Once deployed, Nautilus continuously maps the OT environment, analyses traffic at the protocol level, and generates alerts based on behavioural anomalies. These alerts, enriched with risk context, asset metadata, and operational impact assessment, feed directly into the organisation’s centralised security platform through open API integrations.
The MDR provider or in-house team then handles investigation, escalation, and coordinated response with the confidence that their OT coverage is complete, their data is accurate, and their response guidance is grounded in operational reality.
For MSSPs building OT MDR services
MSSPs that want to serve industrial clients face a specific problem: they lack OT-native telemetry. Nautilus solves this by acting as the OT data layer within the MSSP’s existing service stack. The platform supports white-label deployment, integrates with standard security platforms, and provides the structured OT data that MSSPs need to extend their MDR offering into industrial environments, without building proprietary OT capabilities from scratch.
Building Your OT MDR Capability: A Practical Approach
Establish OT visibility first. Deploy passive sensors at span ports to gain a complete view of your OT network. You cannot detect, or respond to, threats in an environment you cannot see.
Baseline normal behaviour. Let the platform learn what standard operations look like across your OT devices and protocols. This baseline is what makes anomaly detection meaningful rather than noisy, and it is what allows your response team to distinguish a real threat from a routine maintenance action.
Integrate with your security platform and MDR provider. Connect OT telemetry to your centralised security monitoring platform (such as Microsoft Sentinel or Splunk) and your asset management system. This gives your security team or MDR partner a unified IT/OT view and ensures OT events are handled within your existing security workflows.
Define OT response playbooks and escalation procedures. Develop OT-specific incident response playbooks that define exactly what happens when a threat is detected. These playbooks should specify: who gets notified (security team, plant engineer, operations manager, legal), what information is needed before any action is taken, which response options are available for each threat scenario, and what the approval process is for any containment action that could affect running processes. This is what separates a reactive scramble from a structured, defensible response. Frameworks such as SANS PICERL, IEC 62443, and NIST SP 800-82 provide a solid basis for OT-specific playbook development.
Use risk reporting for board communication and NIS2 compliance. Translate your OT security posture into financial terms that executives and boards can act on. This also provides the audit-ready evidence that NIS2 requires for incident reporting and compliance demonstration.
The Bottom Line
OT MDR is not a product you buy off the shelf. It is a capability you build by combining the right visibility platform with the right detection and response services, and by understanding what Response actually means in an industrial environment.
In OT, Response is not an automated action that a remote provider triggers on your behalf. It is a structured, engineering-led process that requires real-time situational awareness, clear escalation paths, and pre-defined playbooks that account for operational risk. The MDR provider or security team enables that process. Nautilus provides the intelligence layer that makes it possible.
The organisations that get OT MDR right start with the foundation: comprehensive OT asset discovery, protocol-aware monitoring, behavioural anomaly detection, and risk reporting that connects technical findings to business outcomes. That foundation is what turns an MDR service from an IT overlay into genuine industrial protection.
Whether you are an industrial organisation looking to bring your OT environment under your existing MDR coverage, or an MSSP ready to extend your services into the industrial mid-market, the starting point is the same: you need to see what is on the network, understand what it is doing, and have the right playbooks in place before an incident forces your hand.
