OT security platforms promise visibility, vulnerability context and threat detection for industrial networks, but a poorly chosen or poorly deployed one can crash a controller, flood the SOC with noise or open a new remote path into the plant. The category, also sold as OT network detection and response or cyber-physical systems (CPS) protection, usually combines passive network sensors, optional active queries, an asset inventory, vulnerability matching, threat detection and often a secure remote access module. This vendor-neutral guide is for OT security leads, control engineers, CISOs and procurement teams writing requirements, running an RFP or planning a proof of concept. For OT fundamentals, see the OT Security Guide.
Key takeaways
- Safety first, then features. Insist on passive discovery by default and make any active query opt-in, protocol-native, rate-limited and approved by engineering per device class.
- Protocol depth decides value. A platform that cannot decode your Modbus function codes, S7 or EtherNet/IP program transfers, or DNP3 control commands cannot build a useful inventory or detect logic changes.
- Vulnerability context must respect OT reality. Look for exploitation status, reachability and compensating controls, not a CVSS list that assumes you can patch next week.
- Remote access modules are identity products. Vendor and engineer access needs named accounts, phishing-resistant MFA, approval windows and recording, not a shared vendor login.
- The platform joins your attack surface. Its sensors, console, cloud tenant and stored credentials need the same scrutiny as the controllers it watches.
Define requirements
Agree these with operations and engineering first. A platform bought without the plant's support rarely gets the network access, change windows or trust it needs.
- Sites and connectivity: number of sites, links (WAN, cellular, satellite), bandwidth at remote sites, and whether any site, or its data, must stay disconnected from the cloud or the corporate network.
- Protocols in use: controller families, DCS and SCADA products and protocols per network, for example Modbus TCP (502), DNP3 (20000), IEC 60870-5-104 (2404), S7comm (102), EtherNet/IP (44818 and 2222), OPC UA (4840), BACnet/IP (47808), PROFINET and IEC 61850, plus serial and fieldbus segments.
- Use cases ranked: asset inventory, vulnerability management, threat detection, controller logic change detection, compliance evidence, secure remote access. Few buyers need all on day one.
- Operating model: who triages alerts (IT SOC, OT team or MDR provider) and how they reach the plant. See the SOC Guide.
- Drivers: ISA/IEC 62443 (2-1 asset owner programme, 3-2 zones and conduits, 3-3 system requirements), NIST SP 800-82 Rev. 3, NIS2, NERC CIP or TSA Security Directives, and the evidence each needs.
Size changes the answer. A water utility with a few PLCs may get most value from an exposure check, an inventory, logic backups and one brokered remote access path, perhaps as a managed service. A multi-site manufacturer or energy operator needs central management of many sensors, role-based access by site, and enterprise SIEM and ticketing integration.
| Deployment choice | How it works | Trade-offs to test |
|---|---|---|
| Sensor on a SPAN port | Switch mirrors traffic to the sensor; nothing is sent to the process network | SPAN can drop packets under load and sees only traffic crossing that switch; needs a switch change window |
| Sensor on a network TAP | Passive tap copies every frame; NIST SP 1800-23 used TAPs that fail open | Most complete capture; needs physical installation and a brief link outage |
| Virtual or software sensor | Runs on an existing server or industrial switch | Lower hardware cost; competes for host resources and may need OT vendor approval |
| Console on premises or in the cloud | Sensors report to a server in the OT DMZ, or send metadata outbound to a vendor tenant | On premises keeps data local but you run it; cloud adds an outbound OT path and a third party holding your asset map |
| Active query module | Sends protocol-native read requests to fill passive gaps | Better firmware and module detail; must be scoped, scheduled and approved per device class |
Evaluation criteria
Weight criteria against your ranked use cases. An illustrative first-deployment split is 25% discovery and protocols, 20% vulnerability context, 20% detection and SOC integration, 15% remote access, 20% deployment, platform security and cost; adjust rather than copy it.
| Criterion | What good looks like | Weak signs |
|---|---|---|
| Passive discovery and safety | Passive by default; active queries opt-in, read-only, protocol-native, rate-limited, scoped per subnet and device type, with a documented list of what each sends | Generic IT port scans against Level 1 devices; no exclusions for fragile devices |
| Protocol coverage | Decodes your protocols to function codes, program uploads and downloads, mode changes and firmware sessions; handles serial and fieldbus via gateways | Protocol list counts names, not decoded commands; your main DCS protocol shown as unknown |
| Asset inventory depth | Fills the 14 high-priority fields in CISA's 2025 inventory guidance (including protocols, criticality, logging and user accounts), plus firmware, rack modules and serial numbers | Stops at IP, MAC and vendor; no criticality or zone; no export or API |
| Vulnerability context | Firmware matched to advisories; CISA KEV flags; SSVC-style prioritisation; CSAF ingestion; reachability through conduits; compensating controls and accepted risk recorded | Thousands of CVSS-sorted findings with "patch" as the only action |
| Threat and change detection | Baselines; alerts on new devices, writes from hosts that never write, mode changes, logic and firmware transfers; mapped to ATT&CK for ICS; approved changes taggable | IT signatures only; alert floods during maintenance |
| IT SOC integration | Syslog or API to the SIEM, ticketing, asset criticality and plant contact in every alert, STIX and TAXII, no automatic isolation of OT hosts | A separate console nobody watches; automated blocking without engineering approval |
| Secure remote access | Sessions brokered through the DMZ, IdP accounts, phishing-resistant MFA, approval windows, recording, credential injection, per-asset and per-protocol limits | Shared vendor accounts; always-on agents; no recording |
| Deployment footprint | Sizing per throughput, low-bandwidth mode, offline updates for isolated sites, central sensor management | Full appliance and constant cloud link required at every site |
| Platform security and cost | Console SSO and MFA, site-scoped roles, tenant audit log, signed updates, SBOM, disclosure process; clear unit of charge (sites, sensors, assets or bandwidth) and full data export at exit | Shared local admin accounts; unsigned updates; paid add-ons for logging, API or export |
Discovery safety and protocol depth
NIST's energy sector project used sensors that "passively monitor devices via a SPAN port" and treated active scanning as optional, noting it "requires scripts to interrogate devices by using a method supported by the device" (NIST SP 1800-23). The trade-off is real. In a 2022 academic testbed study of ICS asset discovery tools, certain Nmap flags put a PLC into a failure state that needed a power cycle, while passive tools found only devices that were communicating. Ask which device families each active query has been tested against, and repeat the test on spare hardware. Secure by Demand makes the same point to OT product makers: "Buyers should look for products that are designed to operate through security scans."
Vulnerability context when you cannot patch
Controller and HMI patches need vendor qualification and an outage, which is why ISA/IEC TR 62443-2-3 treats IACS patch management separately. CISA's OT asset inventory guidance says to "Use the KEV catalog as authoritative input" to prioritisation. A good platform produces a short list: exploited vulnerabilities on devices reachable from the DMZ or internet first, each with a patch date or a compensating control (tighter conduit rule, disabled service, read-only mode, targeted monitoring), an owner and a review date. See the Vulnerability Management Guide.
Remote access is an identity decision
CISA, the FBI, EPA and DOE recommend that OT remote access uses "a strong password and phishing-resistant multifactor authentication (MFA)", least privilege "for the specific asset and user role or scope of work", and that owners "disable dormant accounts" (CISA primary mitigations). The Colonial Pipeline ransomware attack began with an unused VPN account. Judge a remote access module as a privileged access product: IdP federation, no shared vendor accounts, per-asset authorisation, recording, and credential injection so vendors never learn controller or HMI passwords. It should also surface shared HMI and engineering logins inside the plant. See the OT and ICS Identity and Access Guide, the Remote Access Identity Guide and the Third-Party Access Guide.
Questions to ask vendors
- Which protocols do you decode to command level, and which only by port? Show program downloads, mode changes and writes from our own traffic.
- Exactly what does each active query send, to which device families, at what rate, and what testing shows it is safe? Can we disable active features per subnet?
- Which of CISA's 14 high-priority inventory attributes do you populate passively, which actively, and which need manual input?
- How do you show KEV status, reachability and compensating controls for a vulnerability we cannot patch until the next turnaround?
- How do you suppress alerts for approved engineering work without blinding the platform?
- What leaves the site (packets, metadata or alerts), over which ports, to where, and can the platform run with no cloud connection?
- For remote access: IdP login with phishing-resistant MFA, per-asset and per-protocol limits, searchable recordings?
- Following Secure by Demand for OT: is logging in the base licence, do you supply an SBOM "in a commonly used and machine-readable format", have you removed shared role-based passwords from your own sensors and console, and how are updates signed for air-gapped sites?
- What vulnerabilities and incidents in your own product have you disclosed, and how fast were they fixed?
Red flags
- Active scanning on by default, or a vendor who cannot list what its queries send.
- Protocol claims that count names rather than decoded commands.
- Vulnerability output that ignores exploitation, reachability and compensating controls.
- Automated response that isolates OT hosts without engineering approval.
- Remote access built on shared vendor accounts, always-on connections or no recording.
- Sensors that must reach the internet directly from the control network, against the principle that "a more critical environment should never be administered from a less critical environment" in the Principles of operational technology cyber security.
Proof of concept
- Scope with operations: one representative site with your main controller families, a DMZ and a remote access use case. Agree pass criteria, weights, change windows and a named engineer.
- Install passively: SPAN or TAP points at Level 2, Level 3 and the DMZ boundary, active features off. Record every switch change so it can be reversed.
- Measure discovery: after a full production cycle, compare the inventory with a known asset list; count missed devices, wrong models and missing firmware.
- Test active queries offline: on spare or lab controllers first, then only for approved device classes in a maintenance window with operators watching alarms.
- Stage detections: with engineering, perform a planned logic download, a mode change and a write from a non-engineering host. Measure detection, speed and whether the SOC receives asset context.
- Test remote access: run a vendor session with IdP login, MFA, approval, a time window and recording; confirm it ends on schedule and cannot reach other assets.
- Roll back: remove sensors, revert SPAN configuration, revoke every trial account and certificate, and get written confirmation that trial data is deleted.
Keep tracking after go-live: percentage of known assets discovered with firmware version, assets with owner and criticality, exploited vulnerabilities with a patch or documented compensating control, remote sessions brokered with MFA and recording, and median time for an OT alert to reach a named plant contact.
How NHI Mgmt Group can help
We provide independent requirements, RFP and evaluation support. Browse vendors in our products directory or contact us.
Related NHI Mgmt Group resources: OT Security Guide · OT and ICS Identity and Access Guide · PAM Buyer's Guide · Device and IoT Identity Guide · SIEM Guide