Table of Contents
Why IoT/OT security is different, and why it matters for MSPs
Step 1: conduct a passive asset discovery
Step 2: perform a risk assessment
Step 3: segment and isolate the OT/IoT environment
Step 4: harden devices and configurations
Step 5: deploy continuous monitoring and threat detection
Step 6: align to compliance frameworks
Building a repeatable IoT/OT security practice
FAQ
TL;DR
IoT/OT security follows a different methodology than IT security: visibility first, then isolation, then hardening. Rushing to controls without a full asset picture is how MSPs break production environments.
enhanced.io is a channel-only Open XDR SOCaaS built exclusively for MSPs, with 400+ integrations across endpoint, network, cloud, identity and IoT/OT.
Passive discovery is not optional. Active scanning risks crashing legacy industrial controllers, and NIST SP 800-82 Rev 3 warns against it directly.
Segmentation is the single highest-impact control in an IoT/OT environment. Most legacy devices cannot be patched, so compensating controls carry the weight instead.
OT monitoring has to be protocol-aware. A tool that cannot parse Modbus, DNP3, EtherNet/IP or BACnet will miss most OT-specific threats.
IoT and OT devices are now the most common entry point into industrial and enterprise client environments. Systems that run HVAC, manufacturing equipment, building access and critical infrastructure are often running outdated firmware, sitting on default credentials, and have never been through a security review. That is both a risk and an opening for MSPs positioned to do something about it.
IoT/OT security does not follow the same rules as IT security. You cannot push an agent to a PLC. You cannot patch a decade-old industrial sensor without OEM sign-off. Aggressive scanning risks crashing a system running a production line. The tools and playbooks your team uses for endpoints and servers need to be adapted before they touch an OT network.
enhanced.io is a channel-only Open XDR SOCaaS built exclusively for MSPs, with 400+ integrations across endpoint, network, cloud, identity and IoT/OT. This guide walks through the 6-step framework we use with partners to assess and secure client IoT/OT environments, from initial discovery through to ongoing monitoring and compliance alignment.
The core principle behind all six steps is the same: visibility first, then isolation, then hardening. Rushing to controls without a complete asset picture is how MSPs break production environments, and that is the mistake this guide is built to help you avoid.
Why IoT/OT security is different, and why it matters for MSPs
Before scoping an engagement, your team needs to understand the fundamental differences between IT and OT security. Getting this wrong does not only produce a bad client outcome. It disrupts physical operations, triggers a safety incident, or voids an OEM warranty.
The IT/OT convergence problem
Most clients do not have a clean separation between their IT and OT networks. Operational technology has grown steadily more connected to corporate networks and the internet over the past decade, which has expanded the attack surface most MSPs have not been asked to secure until now. A manufacturing plant's SCADA system might share network infrastructure with the corporate email environment. A hospital's building management system might sit on the same VLAN as clinical workstations.
That convergence means a compromise in the IT environment becomes a threat to OT systems, and the reverse is also true.
Key constraints that change your approach
| Constraint | IT environment | OT/IoT environment |
|---|---|---|
| Patching | Routine, automated | Often impossible; OEM certification required |
| Scanning | Standard practice | Crashes legacy devices; use passive methods only |
| Availability | High priority | Mission-critical; downtime has physical consequences |
| Agent deployment | Standard | Not supported on most OT devices |
| Encryption | Widely supported | Many legacy protocols (Modbus, DNP3) have no native encryption |
The practical implication is that your standard RMM-based approach will not work here. IoT/OT engagements need passive discovery, protocol-aware monitoring, and compensating controls for systems that cannot be patched or hardened directly.
Step 1: conduct a passive asset discovery
You cannot secure what you cannot see. The first step in any IoT/OT engagement is building a complete, verified asset inventory, and it has to be done passively.
Why passive matters
Active scanning tools that work fine in IT environments send unexpected commands to industrial controllers, and those controllers reboot, freeze, or behave unpredictably in response. NIST SP 800-82 Rev 3, the authoritative guide to OT security, warns against active scanning on OT networks for exactly this reason.
What to capture in the asset inventory
Deploy passive network monitoring sensors at strategic points across the environment. At minimum, the inventory should record:
Device identity: vendor, model, serial number, firmware version
Network identity: IP address, MAC address, communication protocols in use
Connectivity: what the device talks to, and on what ports
Operational role: what process or function the device supports
Patch status: last known firmware update date and current patch level
Location: physical location and network zone
For OT environments, map assets to the Purdue Model levels, Level 0 through Level 5. That gives you a structured view of where each device sits in the operational hierarchy, and it is the basis for prioritizing risk by proximity to critical processes.
What you'll typically find
Most clients are surprised by what passive discovery turns up. Shadow devices connected without IT's knowledge, end-of-life systems still running production workloads, and devices talking directly to the internet with no monitoring in place are common findings. Document everything before moving to the next step.
Step 2: perform a risk assessment
With a complete asset inventory in hand, the next step is understanding what is at risk. Not every device carries the same weight. A compromised smart thermostat is a different problem than a compromised PLC controlling a chemical dosing process. Structure the assessment around three questions drawn from the ISA/IEC 62443 framework: what are we working with, what might go wrong, and what are we going to do about it.
Prioritizing risk by consequence
For each device or system zone, assess:
Consequence of compromise: what happens if this device is taken offline or manipulated. Physical damage, safety risk, data loss, regulatory breach.
Known vulnerabilities: are there published CVEs for this firmware version, and has the vendor issued advisories.
Threat likelihood: is the device internet-facing, does it use default credentials, is it running an unsupported OS.
Compensating controls in place: is there any existing segmentation, monitoring, or access control protecting this device. Rank findings by consequence severity and likelihood together. A high-consequence, high-likelihood item, for example an internet-exposed HMI running Windows XP with default credentials, should drive immediate action regardless of what else is on the list.
Document the risk register
Produce a risk register that maps each finding to a remediation action, an owner, and a timeline. This becomes the foundation for the client conversation and the roadmap for the engagement. It is also the documentation trail that frameworks like NIST CSF 2.0 and IEC 62443 require for ongoing compliance.
Step 3: segment and isolate the OT/IoT environment
Network segmentation is the single highest-impact control in an IoT/OT environment. It limits lateral movement, contains a breach before it reaches critical systems, and sits at the foundation of every major OT security framework.
The goal is straightforward. IoT and OT devices should not be able to communicate freely with IT networks, the internet, or each other unless there is a documented operational reason for it.
Segmentation architecture for OT environments
The recommended architecture follows the Purdue Model with a dedicated IT/OT DMZ, sometimes called Level 3.5, sitting between the corporate IT network and the OT environment. All traffic between the two passes through services in the DMZ. No direct paths between IT and OT should exist.
For IoT devices, the approach is simpler but equally important:
Dedicated VLANs for IoT device categories: building management, cameras, sensors, and similar
Firewall rules that enforce default-deny, so IoT devices only reach the specific systems they need to function
No direct internet access for OT or IoT devices unless operationally required, and only through a monitored, proxied connection
Isolation of transient devices matters too. Vendor laptops, maintenance tablets and USB drives are among the most common attack vectors in OT environments. Honeywell's 2024 USB Threat Report found that 51% of malware now found on USB drives is built specifically to spread through removable media. Put strict controls in place before any transient device connects.
What to do when segmentation isn't immediately possible
Legacy environments often cannot be segmented overnight. OEM constraints, process dependencies and budget cycles are real barriers. In these cases, apply compensating controls:
Increase monitoring density around the unsegmented zone
Implement application allowlisting on any PC-based OT assets that support it
Restrict outbound communications at the perimeter firewall
Prioritize segmentation in the remediation roadmap with a defined timeline
Step 4: harden devices and configurations
Once segmentation is in place, the next step is reducing the attack surface of individual devices. This is where a lot of engagements stall, because hardening OT devices is constrained by OEM requirements, operational uptime, and the plain fact that many devices cannot be patched. Work through hardening in order of impact and feasibility.
Where hardening is possible
Replace default credentials on every device that supports it. Default usernames and passwords are the most exploited vulnerability in IoT environments, and they take minutes to fix
Disable unused services and close unused ports. If a device's management interface is only needed locally, disable remote access entirely
Enable logging on all network and computing devices: routers, switches, firewalls, HMIs, workstations. Devices that cannot log are a blind spot; document them as such
Apply firmware updates where OEM-certified updates exist. Do not patch without confirming OEM approval, since unauthorized updates void warranties and break OEM-certified configurations
Enforce MFA for all remote access to OT systems. This is a hard requirement under NIST SP 800-82 Rev 3 and increasingly expected by cyber insurance underwriters.
Where hardening isn't possible
Legacy OT devices, particularly older PLCs, RTUs and embedded industrial controllers, often cannot be patched, reconfigured or updated without breaking what they are there to do. The answer is not to ignore them. It is to compensate.
| Compensating control | Purpose |
|---|---|
| Application allowlisting | Prevents unauthorized code execution on PC-based OT assets |
| Network micro-segmentation | Limits what the device reaches even if compromised |
| Passive anomaly monitoring | Detects behavioral changes without touching the device |
| Physical access controls | Prevents unauthorized local access to the device |
| Immutable backups | Enables recovery without paying ransom or rebuilding from scratch |
Document every device where hardening was not possible, along with the compensating controls applied. That documentation is required for compliance frameworks, and it protects the MSP if an incident happens later.
Step 5: deploy continuous monitoring and threat detection
Hardening and segmentation reduce the attack surface. Continuous monitoring is what catches threats that get through anyway, and in OT environments threats often sit undetected for months before they cause damage.
OT monitoring has to be protocol-aware. Generic IT security tools do not understand industrial protocols like Modbus, DNP3, EtherNet/IP or BACnet. A monitoring platform that cannot parse these protocols will miss most OT-specific threats and generate noise instead of signal.
What effective OT/IoT monitoring looks like
Deploy passive network monitoring sensors at the most active points in the environment, with the deepest coverage at Purdue Model Levels 2 and 3, where most attacker activity occurs in OT networks. The monitoring platform should:
Baseline normal industrial process behavior for each asset, rather than applying generic anomaly thresholds
Perform protocol-level deep packet inspection for industrial protocols
Alert on behavioral deviations: unexpected communication paths, new devices appearing on the network, unusual command sequences sent to controllers
Correlate events across IT and OT boundaries to catch attacks that move between environments
Integrating OT visibility into your SOC workflow
A standalone OT monitoring tool that raises alerts with no downstream response capability creates more work without improving the outcome. The goal is to feed OT and IoT telemetry into the same detection and response workflow your SOC already uses for IT environments.
That takes a platform built for broad integration, one that ingests data from OT-specific sensors alongside endpoint, identity and cloud telemetry and correlates across all of it. An Open XDR platform is well suited to this. It profiles OT assets passively and continuously, applies native protocol parsers to catch anomalies like unauthorized write commands to a PLC or unexpected firmware download attempts, and correlates IT and OT telemetry to catch lateral movement between the two, without requiring you to replace an OT sensor a client already runs. I go through the threat patterns this catches in OT security threats for MSPs.
One caveat worth stating plainly. In high-consequence environments such as nuclear facilities, transmission-level power, or critical water infrastructure, a dedicated OT sensor stays the requirement, by regulation or by best practice. For the mid-market manufacturers, building operators, retail chains and education campuses most MSPs serve, native OT visibility inside the SOC platform is sufficient on its own.
For MSPs managing multiple clients, centralized visibility across every IoT/OT environment from a single platform is not only convenient operationally. It is the only model that scales. Our OT security use case has the detail on what that looks like at volume: telemetry from 10,000+ industrial devices monitored across current deployments, with 150+ unique OT-specific security events analyzed monthly.
Step 6: align to compliance frameworks
Compliance is increasingly what drives IoT/OT security spend. Clients in manufacturing, healthcare, utilities and critical infrastructure are now subject to regulations that explicitly require OT security controls. For MSPs, that is both a service opportunity and a scoping requirement.
The most relevant frameworks for IoT/OT environments:
| Compensating control | Purpose |
|---|---|
| Application allowlisting | Prevents unauthorized code execution on PC-based OT assets |
| Network micro-segmentation | Limits what the device reaches even if compromised |
| Passive anomaly monitoring | Detects behavioral changes without touching the device |
| Physical access controls | Prevents unauthorized local access to the device |
| Immutable backups | Enables recovery without paying ransom or rebuilding from scratch |
What this means for your engagement scope
When you onboard a client with IoT/OT infrastructure, identify which frameworks apply before you scope the engagement. A manufacturer supplying the US defense sector needs CMMC alignment. A European utility needs NIS2 coverage. A healthcare network needs to work out how OT devices, infusion pumps, building systems, interact with HIPAA-covered data.
Mapping your findings and controls to the relevant framework turns the engagement into a compliance-ready deliverable instead of only a security report. That reframes the conversation as a business necessity rather than a discretionary spend, which is the conversation that gets budget approved and renewed. Compliance reporting on this kind of engagement should run monthly and on demand, the same cadence we hold ourselves to; see our SLAs, in full for what that looks like end to end.
Building a repeatable IoT/OT security practice
The six steps above describe what to do in a single engagement. The bigger opportunity is making this repeatable across every client who has IoT or OT infrastructure.
Standardize the intake process. Build a discovery questionnaire that identifies IoT/OT exposure before the engagement starts. Ask about industrial protocols in use, OEM maintenance contracts, and existing segmentation. Surprises in OT environments are expensive.
Develop tiered service packages. Not every client needs the same depth of coverage. A small manufacturer with a handful of PLCs has different needs than a utility with distributed SCADA infrastructure. Offer tiered options, assessment only, assessment plus monitoring, full managed OT security, so clients buy what they need.
Build OT into incident response playbooks. OT incidents have different response requirements than IT incidents. Downtime decisions involve operational staff, safety officers, and sometimes regulators. Define escalation paths and decision authorities before an incident occurs.
Revisit the asset inventory quarterly. OT environments change. New devices are added, firmware versions change, network connections are modified. A stale inventory is a liability. Build recurring discovery into the service contract.
IoT and OT security is one of the fastest-growing service categories for MSPs. The attack surface is large, the clients are underserved, and the consequences of a breach are severe enough that the security case largely makes itself. Stability IT, an MSP focused on manufacturing clients, built exactly this kind of practice on top of enhanced.io. MSPs who build the expertise and the delivery model now will be well positioned as regulatory pressure and client awareness keep growing.
About enhanced.io
enhanced.io is a channel-only Open XDR SOCaaS built exclusively for MSPs, with 400+ integrations across endpoint, network, cloud, identity and IoT/OT. Every partner works with a named, CISSP-certified Fractional Security Director, backed by a 24x7 SOC. enhanced.io never sells direct to end clients. Book a partnership conversation with Hannah Lloyd.
What's the difference between securing IT and OT environments?
IT tools assume you patch, scan and push an agent whenever you need to. OT does not allow any of that by default. Patching often needs OEM certification, active scanning risks crashing legacy controllers, and most OT devices cannot run an agent at all. The sequence that works is visibility first, then isolation, then hardening.
What's the difference between securing IT and OT environments?
Active scanning sends unexpected commands to industrial controllers built for a narrow, predictable set of inputs. Those commands cause a controller to reboot, freeze or behave unpredictably. NIST SP 800-82 Rev 3 warns against active scanning on OT networks directly, which is why passive discovery is the standard first step.
What is the Purdue Model, and why does it matter for OT segmentation?
The Purdue Model is a reference architecture that maps OT and IT systems into levels, from field devices at Level 0 up to the corporate network at Level 5. It gives you a structured way to see where a device sits in the operational hierarchy, and where segmentation boundaries, including the Level 3.5 IT/OT DMZ, need to go.
Which compliance frameworks apply to IoT/OT environments?
The most common are NIST SP 800-82 Rev 3 for general OT and ICS environments, IEC 62443 for industrial automation and control systems, NIST CSF 2.0 extended to OT, NIS2 for EU critical infrastructure operators, and CMMC for the US defense industrial base. Which one applies depends on the client's sector and geography.
Which compliance frameworks apply to IoT/OT environments?
You compensate instead of ignoring it. Application allowlisting, network micro-segmentation, passive anomaly monitoring, physical access controls and immutable backups all reduce risk around a device you cannot touch directly. Document every device this applies to and the controls you put around it.
Does OT monitoring require replacing existing security tools?
No. An Open XDR platform ingests telemetry from OT-specific sensors alongside endpoint, identity and cloud data, and correlates across all of it, without requiring you to replace a sensor a client already runs. In high-consequence environments like transmission-level power or critical water infrastructure, a dedicated OT sensor stays the requirement regardless.
How often should an OT asset inventory be updated?
Quarterly, at minimum. OT environments change: new devices get added, firmware gets updated, network connections get modified. A stale inventory is a liability during an incident and a gap in an audit. Build recurring discovery into the service contract rather than treating the first assessment as a one-time deliverable.
