Executive summary
OT/ICS vulnerability management is the discipline of discovering, inventorying, prioritizing, and remediating security weaknesses in industrial control systems without creating safety, availability, or process-integrity harm. It is operationally distinct from enterprise vulnerability management because the target is a real-time physical process, not a general-purpose computing fleet.
The highest-authority technical framing is NIST Special Publication 800-82r3, Guide to Operational Technology (OT) Security, which shifts the language from “ICS security” to “OT security” and embeds vulnerability management inside the larger OT risk-management lifecycle. NIST SP 800-82r3 explicitly treats operational requirements, safety, and availability as constraints that ordinary IT vulnerability scanners often violate when they actively probe controllers, RTUs, and engineering workstations.
Peer-reviewed work supports the same conclusion. Asghar, Hu, and Zeadally documented that ICS environments face a patch-management dilemma: many control systems cannot be patched on IT timelines because of vendor validation constraints, continuous-process uptime, and safety recertification. Knowles et al. similarly found that cyber-security management in ICS is often less mature than enterprise IT and is constrained by legacy protocols, untested update paths, and organizational separation between OT and IT.
Commercially, the market is dominated by passive network-monitoring and asset-fingerprinting platforms sold on a subscription or per-asset basis. Public vendors with direct exposure include Microsoft, Tenable, Palo Alto Networks, Cisco, Fortinet, Rockwell Automation, Emerson, and Honeywell. The value chain also includes regulated asset owners such as utilities, oil and gas producers, water systems, and manufacturers.
The central contradiction in this market is evident in the sources: vendors market deterministic “full asset discovery” and vulnerability mapping, while their own SEC risk-factor language typically says that security products may not detect all threats and that security measures involve inherent limitations. That asymmetry is important for an investor or technical evaluator to track.
Source map
This note uses the following source classes:
| Tier | Source class | Examples used |
|---|---|---|
| Tier 1 | Standards-body document | NIST SP 800-82r3, NIST SP 800-30r1 |
| Tier 1 | Peer-reviewed journal article | Asghar et al. 2019, Knowles et al. 2015 |
| Tier 1 | Regulator technical assessment / directive | CISA BOD 22-01, CISA Known Exploited Vulnerabilities catalog |
| Tier 2 | Named framework / SIG model | MITRE ATT&CK for ICS, FIRST EPSS |
| Tier 2 | Company technical docs and product pages | Microsoft Learn, Tenable, Cisco, Palo Alto Networks, Fortinet, Rockwell, Emerson, Honeywell |
| Tier 2 | SEC/IR primary-source portals | SEC EDGAR searches, investor-relations filings pages |
For load-bearing technical claims, I tried to use at least two independent institutional lineages. Example: the claim that active scanning can disrupt OT devices is supported by NIST SP 800-82r3 and independently by Asghar et al. 2019. Those are different institutions and different document types.
Scope and definitions
OT/ICS vulnerability management covers:
- Asset discovery: identifying PLCs, RTUs, HMIs, engineering workstations, historians, network switches, drives, and field devices.
- Fingerprinting: determining make, model, firmware version, protocol stack, and installed module versions.
- Vulnerability mapping: correlating fingerprints to CVE records, vendor advisories, and malware/campaign intelligence.
- Risk-prioritized remediation: patching, segmenting, allowlisting, configuration hardening, or isolating devices.
NIST SP 800-82r3 defines OT broadly as programmable systems or devices that interact with or manage the physical environment. That document, published September 2023, is the current U.S. federal standards anchor for OT security. Its technical content covers network segmentation, patching constraints, risk assessment, incident response, and supply-chain assurance.
Source: NIST SP 800-82r3, Guide to Operational Technology (OT) Security, September 2023, DOI:10.6028/NIST.SP.800-82r3, doi.org , accessed 2026-04-30.
The peer-reviewed literature uses “ICS security” and “SCADA security” interchangeably in many cases. Asghar et al. define ICS as including SCADA, distributed control systems, programmable logic controllers, and industrial networks, and they categorize security requirements across availability, integrity, authenticity, and confidentiality. In ICS, availability is usually the first security objective because lost control can be physically dangerous.
Source: Asghar, M. R., Hu, Q., and Zeadally, S., Cybersecurity in industrial control systems: Issues, technologies, and challenges, Computer Networks, vol. 151, pp. 254–269, 2019, DOI:10.1016/j.comnet.2019.02.008, doi.org , accessed 2026-04-30.
Regulatory and standards stack
4.1 NIST SP 800-82r3
NIST SP 800-82r3 is the most authoritative general guidance for U.S. OT operators. It replaces the older “ICS security” framing with “OT security” and adds emphasis on:
- risk-based controls rather than checklist compliance;
- integration with the NIST Cybersecurity Framework;
- engineering and safety risk considerations;
- supply-chain and remote-access risks;
- incident response and recovery for OT.
The document repeatedly warns that traditional IT vulnerability assessment tools and methods can damage OT environments. It therefore supports passive discovery and risk-based patching rather than automated scanning alone.
Source: NIST SP 800-82r3, doi.org , accessed 2026-04-30.
4.2 IEC/ISA 62443
The ISA/IEC 62443 series is the leading consensus standard for industrial automation and control system security. The relevant part for vulnerability management is ISA/IEC 62443-3-2, which defines a process for security risk assessment during system design. It organizes the problem into zones and conduits, so that vulnerabilities are assessed against a defined OT zone, not just in the abstract. This matters for vulnerability prioritization: a CVE with high CVSS but unreachable from an attacker beyond a conduit may be lower risk than a lower-CVSS CVE reachable from a corporate-to-OT junction.
Source: ISA/IEC 62443-3-2, Security for industrial automation and control systems — Part 3-2: Security risk assessment for system design, isa.org , accessed 2026-04-30.
4.3 CISA KEV and BOD 22-01
The U.S. Cybersecurity and Infrastructure Security Agency maintains the Known Exploited Vulnerabilities (KEV) catalog. CISA Binding Operational Directive 22-01 requires federal civilian executive branch agencies to remediate catalogued KEVs on specified deadlines.
Important scope limitation: BOD 22-01 applies directly to federal agencies, not to all private OT owners. However, CISA KEV is still a useful input for OT vulnerability managers because it identifies vulnerabilities with evidence of active exploitation. For OT systems where patching may be unsafe or impossible, CISA advisories typically allow compensating controls such as segmentation, disablement of vulnerable services, or physical isolation.
Source: CISA BOD 22-01, November 3, 2021, cisa.gov , accessed 2026-04-30.
Source: CISA Known Exploited Vulnerabilities catalog, cisa.gov , accessed 2026-04-30.
4.4 MITRE ATT&CK for ICS
MITRE ATT&CK for ICS is a named knowledge base of adversary tactics, techniques, and procedures against industrial systems. It includes techniques such as Modify Parameter, Program Download, Point & Tag Identification, and Loss of Control. Vulnerability management teams use it to map a CVE or weakness to the specific attacker behavior it enables, rather than only to a CVSS score.
Source: MITRE ATT&CK for ICS, attack.mitre.org , accessed 2026-04-30.
4.5 FIRST EPSS
The Exploit Prediction Scoring System, maintained by FIRST, estimates the probability that a software vulnerability will be exploited in the wild in the next 30 days. EPSS is explicitly designed to complement CVSS, not replace it. Because CVSS measures inherent technical severity and EPSS measures exploitation likelihood, the two inputs create a better prioritization matrix.
Source: FIRST EPSS, first.org , accessed 2026-04-30.
Peer-reviewed evidence
5.1 Asghar et al. 2019
Asghar et al. provide a peer-reviewed survey of ICS security issues and technologies. The paper identifies several constraints that make OT vulnerability management hard:
- legacy protocols such as Modbus, DNP3, and EtherNet/IP often lack authentication and encryption;
- patch availability and validation lag enterprise software;
- production uptime and safety requirements restrict reboots;
- test environments are costly and may not faithfully replicate live plant behavior;
- networking and security teams often have limited visibility into control networks.
These findings support the NIST position that OT vulnerability management is not simply “run the scanner and patch.”
Source: Asghar, Hu, and Zeadally, Computer Networks, vol. 151, pp. 254–269, 2019, DOI:10.1016/j.comnet.2019.02.008, accessed 2026-04-30.
5.2 Knowles et al. 2015
Knowles et al. surveyed cyber-security management in industrial control systems and found that management practice is often less mature than technical controls. They specifically noted the absence of reliable asset inventories and the use of separate IT and OT governance processes. For vulnerability management, this is relevant because an asset can only be patched if it is known to exist, attributed to an owner, and understood well enough to accept risk.
Source: Knowles, W., Prince, D., Hutchison, D., Disso, J. F. P., and Jones, K., A survey of cyber security management in industrial control systems, International Journal of Critical Infrastructure Protection, vol. 9, pp. 52–80, 2015, DOI:10.1016/j.ijcip.2015.03.004, doi.org , accessed 2026-04-30.
Technical architecture of OT vulnerability management
Most commercial OT/ICS vulnerability-management platforms use a passive monitoring architecture. The general sequence is:
- Tap or mirror OT switch traffic: deploy a network TAP, SPAN, or packet broker on the Ethernet segments between control room and PLCs/RTUs.
- Deep packet inspection: parse industrial protocols, identify devices by vendor string, MAC address, IP, protocol attributes, and engineering-software fields.
- Baseline: learn normal communication patterns and alert on abnormal connections or commands.
- Vulnerability mapping: match device fingerprints against CVE databases, vendor security advisories, and the platform vendor’s own research.
- Risk scoring: combine CVSS base score, EPSS exploitation probability, network exposure, MITRE ATT&CK for ICS technique mapping, and ICS-zone criticality.
- Remediation workflow: recommend patch, compensate with segmentation/allowlisting, remove default credentials, disable unused ports/services, or isolate.
Microsoft’s Defender for IoT documentation, for example, describes passive, agentless monitoring of OT networks and integration with Microsoft Sentinel. It also warns that active scanning is invasive and can disrupt OT devices. This matches NIST SP 800-82r3.
Source: Microsoft Learn, Microsoft Defender for IoT documentation, learn.microsoft.com , accessed 2026-04-30.
Source: NIST SP 800-82r3, doi.org , accessed 2026-04-30.
Cross-verification status: The passive-vs-active-scanning claim is load-bearing. It has two independent institutional sources: NIST SP 800-82r3 and Asghar et al. 2019. It is therefore cross-verified, not single-source.
Patent landscape and moat assessment
No verified granted patent is cited in this note. The prompt requires at least one granted patent to support technical/performance/IP claims. I could not verify a specific granted patent number to the required standard—i.e., resolve the number, assignee, title, and grant date—during this session. Rather than fabricate a patent identifier, I leave this requirement unmet and flag it clearly.
This does not mean there are no relevant patents. The major OT/ICS security vendors—Microsoft/CyberX, Tenable/Indegy, Claroty, Nozomi Networks, Dragos, Palo Alto/Zingbox, Cisco/Sentryo—publish patent-related claims in marketing and legal materials. A proper patent search should query USPTO, EPO, and WIPO by assignee and by cooperative patent classification codes such as:
H04L63/14— network security, including intrusion detection;G06F21/57— software vulnerability assessment;H04L63/02— packet filtering;G06F21/55— detecting local intrusion or misuse;H04L67/12— involving IoT or machine-to-machine networks.
Implication: A patent is evidence of recorded claims, not proof of commercial performance. Even a verified patent would not by itself establish that a vendor’s product works at scale or that a defensive moat exists. The moat depends on the claims’ breadth, enforcement history, and whether competitors can design around them. None of those can be established here.
Quantitative worked calculation
8.1 Formula
Use the standard annualized loss expectancy formula from NIST SP 800-30:
\[
ALE = SLE \times ARO
\]
Where:
- SLE: single loss expectancy, the expected loss from one successful compromise event.
- ARO: annual rate of occurrence, the expected number of successful events per year.
For OT vulnerability management, a more decision-oriented form is the patch/test breakeven:
\[
Patch\ if\ p \times I > C_p
\]
Where:
- \(p\) = probability of exploitation before next maintenance window;
- \(I\) = expected impact of successful exploitation;
- \(C_p\) = cost of testing and deploying the patch in an OT window.
8.2 Worked example
Assume an OT asset owner faces a remotely reachable vulnerability on an HMI.
| Parameter | Value | Source / basis | Tier | Measured/derived/assumed/inferred | Cross-verified |
|---|---|---|---|---|---|
| Expected impact per successful HMI compromise, \(I\) | $1,500,000 | Assumed from production downtime, safety investigation, and recovery cost; no source-specific figure available | Assumed | Assumed | No |
| Cost to test and patch in a planned OT window, \(C_p\) | $40,000 | Assumed engineering labor, validation, controlled shutdown/restart | Assumed | Assumed | No |
| Breakeven exploitation probability | $40,000 / $1,500,000 = 2.67% | Derived from formula | Derived | Derived | No |
| Exploitation probability source | FIRST EPSS percentile or calibrated internal estimate | FIRST EPSS model | Tier 2 | Inferred | No |
| Risk assessment methodology | ALE = SLE × ARO; qualitative/quantitative risk framing | NIST SP 800-30 Rev. 1 | Tier 1 | Standard formula | Yes, widely cited |
Source: NIST SP 800-30 Rev. 1, Guide for Conducting Risk Assessments, September 2012, nvlpubs.nist.gov , accessed 2026-04-30.
Source: FIRST EPSS, first.org , accessed 2026-04-30.
8.3 Sensitivity
Sensitivity of the patching decision to impact and patch cost:
| Impact \(I\) | Patch cost \(C_p\) | Breakeven exploitation probability |
|---|---|---|
| $1,500,000 | $40,000 | 2.67% |
| $3,000,000 | $40,000 | 1.33% |
| $1,500,000 | $80,000 | 5.33% |
| $750,000 | $40,000 | 5.33% |
Interpretation: the higher the safety or production impact, the lower the exploitation probability threshold at which patching becomes economically rational. If the owner’s calibrated exploit probability is below the breakeven, the economic rationality shifts toward compensating controls such as network isolation, disabling the vulnerable service, or additional monitoring.
This is a simplified economic-utilities calculation. It does not capture regulatory mandates, safety-integrity-level requirements, or reputational externalities. NIST SP 800-82r3 would treat those as risk factors that may override a pure breakeven analysis.
Contradictions and source-bound claims
9.1 CVSS severity vs exploitation likelihood
CVSS base score is often treated as a priority ranking, but CVSS itself does not measure exploitation probability. FIRST EPSS exists specifically because a high-CVSS vuln may have low exploitation likelihood. For OT, the contradiction is sharper because control-plane reachability and process criticality may dominate the value of a CVE.
Sources: NVD/CVSS base score concept via NIST SP 800-82r3; FIRST EPSS via first.org , accessed 2026-04-30.
9.2 Patching mandate vs OT safety
CISA BOD 22-01 creates timed remediation for KEVs in federal enterprises. NIST SP 800-82r3 says OT patching should be risk-based and may require a maintenance window, vendor recertification, or compensating controls. These are not identical policies; they are in tension. The resolution is context-specific: a federal OT asset that is internet-reachable is a stronger candidate for rapid patching than a physically isolated, safety-instrumented PLC.
Sources: BOD 22-01, cisa.gov ; NIST SP 800-82r3, doi.org , accessed 2026-04-30.
9.3 Vendor marketing vs SEC risk factors
Vendor product pages describe asset discovery and vulnerability detection in strong terms. For example, Tenable’s OT product page describes asset discovery, vulnerability management, and threat detection for OT environments. However, public cybersecurity companies’ SEC risk factors typically say that security products may not detect all threats and are subject to limitations. Microsoft’s risk factors similarly describe cybersecurity as a significant business risk.
I did not find a public break-out of Defender for IoT or OT-specific revenue in Microsoft’s SEC filings. That is a reporting gap between the OT product narrative and the consolidated financial disclosure. The exact 10-K language and any separate operational-technology revenue line should be pulled from the relevant 10-K before making an investment claim. The absence of a separate line is evidence of immateriality at Microsoft’s scale but not evidence that the product is unsuccessful.
Sources: Tenable product page, tenable.com , accessed 2026-04-30; Microsoft acquisition disclosure, blogs.microsoft.com , accessed 2026-04-30; SEC EDGAR Microsoft 10-K search, sec.gov , accessed 2026-04-30.
9.4 Passive discovery vs zero-trust asset inventory
Vendors claim passive discovery is “complete,” but passive monitoring only sees devices that transmit on the monitored segment. Air-gapped systems, encrypted tunnels, direct serial links, and unswitched legacy segments may be invisible. NIST SP 800-82r3 and Asghar et al. both imply that asset inventory must be continuously verified, not assumed complete.
Sources: NIST SP 800-82r3, doi.org ; Asghar et al., doi.org , accessed 2026-04-30.
Unit economics / business model
Who monetizes it
OT/ICS vulnerability management is monetized by:
- OT security software vendors: Microsoft, Tenable, Palo Alto Networks, Cisco, Fortinet, Claroty, Nozomi Networks, Dragos, etc.
- Industrial automation incumbents: Rockwell Automation, Emerson, Honeywell, Schneider Electric, Siemens.
- Managed security service providers and systems integrators: industrial cybersecurity consulting, 24/7 SOC, risk assessments.
- Hardware appliance vendors: network TAPs, packet brokers, industrial firewalls, secure gateways.
How they monetize it
The dominant models are:
- Software subscription: per-site or per-asset licensing for the OT monitoring platform.
- Appliance + subscription: a physical or virtual sensor collecting network data, with a cloud or on-premise analytics subscription.
- Professional services: risk assessment, architecture design, incident response, and remediation consulting.
- Integration with enterprise SOC tools: some vendors monetize by routing OT findings into existing SIEM/SOAR products.
Exact price lists are commercial-in-confidence and not cited here. The unit economics are generally software-subscription economics: high gross margin once the sensor and analytics platform are deployed. Public cybersecurity software vendors often report non-GAAP gross margins in the high-70s to low-80s percent range, but the specific 2024 OT-segment margin is not disclosed and is therefore needs primary source validation.
Source for model inference: Tenable OT product architecture, tenable.com , accessed 2026-04-30; Tenable SEC filings portal, investors.tenable.com , accessed 2026-04-30.
Who captures value
Value is split between:
- Technology vendor: recurring subscription revenue.
- Asset owner/operator: reduced unplanned downtime, safety risk, regulatory non-compliance risk.
- Integrator: deployment and managed services fees.
- Insurer: better risk quantification may reduce cyber-insurance pricing, but this is a developing linkage and
needs primary source validation.
The core economic logic is that OT downtime is typically far more expensive than IT downtime because it halts physical production or service delivery. Therefore OT vulnerability management can support premium pricing per monitored asset relative to commodity IT asset management.
Disconfirming Evidence
The thesis that OT/ICS vulnerability management is a durable, differentiated technology market would be weakened or disproved by the following observable evidence:
- Active scanning becomes safe for all major OT protocols. If controllers and legacy field devices no longer fail or degrade under active probing, the need for passive-only OT platforms shrinks and enterprise scanners could commoditize the asset-discovery layer.
- Vendor-neutral SBOM and software-inventory standards become widely adopted. If asset owners can automatically obtain accurate firmware and software SBOMs from every PLC, RTU, and HMI, then passive fingerprinting becomes less valuable.
- Regulators force rapid patching and eliminate legacy protocols. If safety recertification and patch validation become so fast that vulnerabilities are transient, the remediation backlog that currently supports OT vulnerability-management platforms shrinks.
- NIST SP 800-82r3 or CISA guidance adopts a pure enterprise-style scanning model. The entire OT-specific category assumes that ordinary scanner behavior is not appropriate. A formal standards reversal would undermine the category’s technical rationale.
- EPSS/CVSS and MITRE ATT&CK mapping become integrated into free, vendor-neutral asset-inventory tools. If the value-added analytics are commoditized, differentiation shifts to services and integration, compressing software-subscription margins.
None of these are currently established by the cited sources; they are the falsification conditions to watch.