Cyber Defense Matrix 2.0 · Asset Row · OT/IoT
OT/IoTSS Extension
Operational technology and Internet-of-Things assets. A SecurityStack extension reflecting that availability-first, patch-averse environments need their own column of coverage questions.
OT/IoT is a SecurityStack extension to the original Cyber Defense Matrix, covering operational technology (industrial control systems, SCADA, process networks) and Internet-of-Things devices. These assets run on a fundamentally different operating model — availability-first, patch-averse, long device lifecycles — that makes the standard Devices controls either inapplicable or dangerous. CDM 2.0 gives them their own row so coverage gaps are visible rather than hidden.
Provenance note: This row/column is a SecurityStack extension and is not part of NIST CSF 2.0. Practitioners citing it externally should label it as such.
Why OT/IoT is not just Devices
Traditional IT security is confidentiality-first: protect the data, contain the breach, accept operational friction as the price. Operational technology is availability-first: the process must not stop, because stopping the process breaks the business (or in industrial contexts, endangers people). A control that reboots an unresponsive endpoint is standard IT hygiene. The same control applied to a PLC running a chemical process can cause an incident — not a cybersecurity incident, a process-safety one.
IoT brings a related but different set of constraints: long-lived devices with firmware you cannot easily update, opaque vendor supply chains, and scale (thousands or millions of devices per deployment). Standard Devices controls like EDR, patching, and configuration baselines either do not fit or require specialized tooling. CDM 2.0 separates OT/IoT from Devices to keep these differences legible.
Tools built for OT/IoT specifically
OT security tooling: Claroty, Nozomi Networks, Dragos, Armis, Tenable OT Security, Microsoft Defender for IoT. These platforms discover OT assets (often passively, because active scanning is unsafe), monitor network traffic for OT-specific protocols (Modbus, DNP3, IEC 61850, PROFINET), detect anomalous process behavior, and track vulnerabilities against OT-specific intelligence.
IoT security tooling overlaps with OT and extends to consumer/enterprise IoT contexts: Armis, Ordr, Medigate (acquired by Claroty, healthcare-focused), Forescout. Medical-device security is typically a Medigate/Claroty domain; industrial OT is Dragos/Nozomi/Claroty; general-enterprise IoT (cameras, printers, HVAC, VoIP) is Armis/Ordr/Forescout.
Coverage patterns and what practitioners commonly miss
The most common finding in organizations that believe they have OT/IoT coverage: the tooling is deployed on the IT side of the DMZ and has no visibility into the process networks. An OT platform that reads north-bound traffic (OT data heading to the enterprise) misses east-west traffic within the process network entirely. Meaningful coverage requires sensor placement inside the OT network segments.
The second pattern: OT and IT teams treating each other's findings as out-of-scope. OT teams see their EDR stack as 'the IT problem' and IT teams see the SCADA network as 'the OT problem.' The boundary is the real attack path — most OT-targeted attacks start on IT assets (phishing, corporate compromise) and pivot across the boundary. The matrix cell RESPOND × OT/IoT depends on IT and OT teams having joint runbooks, not separate ones.
Per CDM 2.0 rules, organizations with no OT presence mark the row Not Applicable and it is excluded from coverage. Organizations with any OT — manufacturing, utilities, healthcare with connected medical devices, logistics with industrial automation — should not mark the row N/A simply because they have not invested in the tooling. That is exactly the gap the row is designed to surface.
Standards and references for OT/IoT coverage
The authoritative references for OT security are the IEC 62443 family (industrial communication networks), the Purdue Reference Model (network segmentation), and NIST SP 800-82 (Industrial Control Systems security). CDM 2.0 OT/IoT coverage should cross-reference these; most mature OT security programs use Purdue as the architectural backbone and IEC 62443 as the control framework. For IoT specifically, NISTIR 8259 and the IoT device-security baselines are the equivalent references.
Frequently asked
Do we need OT tooling if we only have building-automation systems?
Usually yes, at some level. Building automation (HVAC, access control, elevator systems) runs on OT-adjacent protocols and is a documented attack vector. A general-enterprise IoT platform (Armis, Ordr) often covers this adequately without needing a full OT-security platform.
Why is patching so much harder in OT?
OT devices are typically on maintenance windows measured in months or years, not weeks. Patching them requires process shutdown or failover infrastructure that may not exist. Vendor support for older devices often lags, and some vendors invalidate support if non-vendor patches are applied. The operational risk of a bad patch can exceed the security risk of not patching — a calculus that does not apply in most IT contexts.
Is medical-device security the same as OT?
It shares the constraints (availability-first, long lifecycles, regulated) but has its own tooling ecosystem and its own regulatory framework (FDA pre-market and post-market cybersecurity guidance, IEC 80001 for medical-device networks). Medical-device security programs are typically owned by biomedical engineering with security support, not the other way around.
What does 'passive discovery' mean for OT?
OT discovery tools read network traffic to identify devices and their behavior without sending any probes to the devices themselves. Active scanning (standard IT vulnerability scanning) is unsafe in OT environments — scanner traffic has caused PLC failures and process outages. Passive-first is the default; active scanning is reserved for maintenance windows and approved vendor tooling.