KRIs for OT and ICS security

The KRIs in this domain account for these constraints. They measure OT security posture through indicators appropriate to environments where availability and safety frequently take precedence over traditional security controls, where "we can't patch that" is sometimes a correct operational answer, and where compensating controls, network segmentation, and anomaly detection become the primary defensive mechanisms.

If you are standing this up from scratch, start with how to build a KRI program and the consolidated KRI reference library, which maps every domain to one CIS-aligned catalog.

KRI inventory

1. IT/OT network segmentation integrity

What to measure. Whether network segmentation between corporate IT networks and OT/ICS networks is enforced, maintained, and regularly validated, specifically: the count of direct communication paths between IT and OT segments that bypass the defined demilitarized zone (DMZ) or data diode architecture.

Why it matters. IT/OT network convergence is the primary attack vector for ICS-targeted threats. Ransomware that reaches OT networks through inadequate IT/OT segmentation doesn't just encrypt files, it can halt manufacturing lines, disable safety systems, and cause physical damage. Every direct path from IT to OT that bypasses the DMZ is a potential ransomware pivot or attacker lateral movement path.

• OT network monitoring (Claroty, Dragos, Nozomi Networks, Armis): network topology visualization and communication flow analysis
• Firewall rule review: IT/OT firewall rules, count of rules permitting direct IT-to-OT communication; any/any rules on IT/OT boundary
• Network packet capture: traffic analysis at IT/OT boundary, actual communication flows vs. approved policy
• Data diode configuration: one-way communication enforcement for historian-to-IT data flows

How to calculate.

• Direct path count: count of communication paths from IT segments to OT segments not routed through approved DMZ, should be zero
• DMZ policy compliance: (Traffic flows through DMZ matching approved policy) ÷ (total IT/OT traffic flows) × 100

Status	Criteria
Green	Zero direct IT-OT paths; all data flows through monitored DMZ; historian data flows via data diode or one-way gateway; segmentation validated through testing
Amber	1–2 direct paths with documented compensating controls and remediation plans
Red	>2 direct IT-OT paths; or corporate workstations communicating directly with PLCs/DCS; or no IT/OT boundary enforcement

2. OT asset inventory completeness

What to measure. Percentage of OT/ICS assets (PLCs, RTUs, HMIs, engineering workstations, historians, DCS controllers, SCADA servers) identified in the OT asset inventory, with vendor, firmware version, communication protocols, and physical location documented.

Why it matters. You cannot monitor, patch, or defend OT assets you don't know exist. OT environments are particularly challenging for asset discovery because passive scanning is often required (active scanning can disrupt control systems), assets may predate network connectivity, and vendor documentation may be incomplete or unavailable. Despite these challenges, inventory is the prerequisite for every OT security control.

• OT asset discovery platforms (Claroty, Dragos Platform, Nozomi Networks Guardian, Armis Centrix): passive network-based discovery without disrupting industrial protocols
• Plant documentation: P&IDs (piping and instrumentation diagrams), network diagrams, vendor asset lists
• Vendor maintenance records: vendor-supplied asset lists from OEM service contracts
• Physical walk-down: manual inventory verification against physical assets in the field

How to calculate. (OT assets in inventory with vendor, firmware, protocol, and location documented) ÷ (OT assets identified through passive discovery and physical walk-down) × 100

Status	Criteria
Green	>90% of discovered assets in inventory with key fields; passive discovery running continuously; physical walk-down within 18 months
Amber	75–89%; or inventory present but missing firmware versions for critical assets; or discovery relying on vendor documentation only
Red	<75%; or no OT asset inventory; or inventory last updated >36 months ago

3. Remote access to OT security controls

What to measure. Percentage of remote access sessions to OT networks (vendor remote maintenance, engineering remote access, IT support) going through a defined, monitored, and authenticated remote access pathway, with no direct internet-to-OT connections.

Why it matters. Vendor remote access to OT systems is the single most exploited vector in ICS-targeted attacks. Direct RDP or VNC connections from vendor laptops to PLCs and HMIs are found in most industrial environments and are notoriously difficult to eliminate because vendors require them for maintenance contracts. Uncontrolled remote access is the attack path behind numerous high-profile OT incidents.

• OT remote access platform (Claroty SRA, Tosibox, Dispel, Zscaler for OT): session logs showing authenticated access through controlled gateway
• Firewall logs: inbound connections to OT network IP ranges from internet, direct connections outside approved gateway
• VPN logs: VPN sessions terminating in OT segments, should route through jump server/bastion, not directly
• Vendor access records: active vendor remote sessions with session recording confirmation

How to calculate. (Remote access sessions to OT through approved, monitored gateway) ÷ (total remote access sessions to OT detected) × 100 Critical gap: any direct internet-to-OT connection outside approved gateway, count should be zero

Status	Criteria
Green	100% of remote OT access through approved gateway with session recording; zero direct internet connections to OT; vendor access time-limited and revoked post-session
Amber	90–99% through approved gateway; or gateway monitoring without session recording
Red	Any direct internet-to-OT connections; or remote access not monitored; or vendor access with persistent VPN credentials never revoked

4. OT-Specific vulnerability and patch risk score

What to measure. A risk-adjusted measure of known vulnerabilities in OT assets, accounting for the fact that many OT systems cannot be patched on the same cadence as IT systems, combining CVE severity, active exploitation status, and availability of compensating controls.

Why it matters. Standard patch SLAs are often unachievable in OT environments where patching requires planned production downtime. A direct vulnerability management approach that treats OT systems like IT systems will produce unachievable compliance metrics. OT vulnerability risk measurement must account for operational constraints while still producing a meaningful risk signal.

• OT vulnerability management (Claroty, Dragos, Nozomi, Tenable OT Security): CVE matching against OT asset firmware inventory, OT-aware scanners that don't disrupt industrial protocols
• ICS-CERT advisories (CISA ICS-CERT): OT-specific vulnerability disclosures for asset types in your inventory
• Vendor advisories: OEM firmware advisories for PLCs, RTUs, and DCS systems in inventory
• CISA KEV: KEV entries that apply to OT/ICS systems, these require immediate compensating controls if patching is not feasible

How to calculate. Risk score per asset = (CVE severity × exploitation probability) × (1 − compensating control effectiveness) Aggregate across OT asset inventory, weighted by asset criticality to operations Track separately: OT assets with CISA KEV vulnerabilities and no available patch, these require documented compensating controls

Status	Criteria
Green	OT-specific vulnerability tracking active; all KEV-affected OT assets with documented compensating controls; patch plan in place for next maintenance window for critical CVEs
Amber	Vulnerability tracking active but compensating controls not documented for all unpatched high CVEs
Red	No OT-specific vulnerability tracking; KEV-affected OT assets with no compensating controls; vulnerability data from IT scanner (disrupts OT)

5. OT network monitoring and anomaly detection coverage

What to measure. Percentage of OT network segments with passive network monitoring deployed, detecting anomalous communication patterns, unauthorized protocol use, rogue connections, and lateral movement within the OT environment.

Why it matters. Active scanning is dangerous in OT environments. Passive monitoring is the primary compensating control that provides detection visibility without operational risk. Without it, lateral movement within an OT network after initial access is invisible. Passive OT monitoring platforms (Claroty, Dragos, Nozomi) are now mature enough to serve as the primary detection capability in OT environments where agent-based EDR cannot be deployed.

• OT monitoring platform: coverage report showing network segments with traffic span/tap coverage
• Network topology documentation: OT network segments identified vs. segments with monitoring
• Alert volume and type: anomaly alerts from OT monitoring platform, industrial protocol violations, new asset connections, unauthorized communication patterns
• Historian and SCADA: access logs as a data source for monitoring, supplementing network-layer visibility

How to calculate. (OT network segments with passive monitoring deployed) ÷ (total OT network segments) × 100

Status	Criteria
Green	>90% of OT segments with passive monitoring; alert triage process defined; monitoring alerts routed to SOC or OT security team
Amber	70–89%; or monitoring deployed but alerts not actively reviewed; or coverage gaps in critical production segments
Red	<70%; or no OT-specific monitoring; or IT security tools deployed in OT (potential disruption risk)

6. Safety system integrity monitoring

What to measure. Whether safety instrumented systems (SIS), emergency shutdown systems (ESD), and other safety-critical OT components are isolated from systems that could be used to manipulate them, and whether integrity monitoring of safety system configurations is active.

Why it matters. Safety system manipulation is the highest-consequence attack in OT security, it's what the TRITON/TRISIS malware was designed to do. Safety systems that are connected to networks reachable from IT or from OT engineering workstations can be manipulated to disable safety shutdowns. The Triton attack specifically targeted Triconex safety controllers to prevent emergency shutdown during a sabotage attempt.

• Safety system network architecture documentation: SIS isolation from process control networks and engineering workstations
• Configuration integrity monitoring: baseline configuration of SIS controllers with change detection
• Access logs: engineering access to SIS, should be restricted and logged; unauthorized access should alert
• Physical security: SIS hardware access controls, physical locks, key switches, tamper detection

KRI values.

• SIS network isolation: SIS on isolated network segment with no connections from process control or IT networks (yes/no/partial)
• Configuration baseline monitoring: SIS controller configurations with automated change detection (yes/no)
• SIS access logging: all access to SIS engineering interfaces logged with alerting on anomalous access (yes/no)

Status	Criteria
Green	All three controls active; SIS on isolated segment; configuration monitoring active with change alerting; physical access controls in place
Amber	SIS on separate segment but with engineering workstation access from shared workstations; or configuration monitoring without alerting
Red	SIS reachable from process control network or IT network; or no SIS configuration integrity monitoring; or SIS access unlogged

7. OT incident response capability

What to measure. Whether the organization has OT-specific incident response capability, including OT-aware playbooks, OT forensic capability, and relationships with OT IR specialists, and whether it has been tested through tabletop or functional exercise.

Why it matters. Standard IT incident response capability is insufficient for OT incidents. Isolating an infected OT system may halt production. Removing malware from a PLC requires different tools and expertise than removing it from a Windows server. Organizations that have only IT IR capability and expect it to suffice for OT incidents discover the gap at the worst possible moment.

• IR plan: OT-specific sections covering production impact assessment, OT isolation decisions, OT-aware forensic procedures
• Retainer agreements: OT IR specialty firm retainer (Dragos, Claroty, or specialized ICS security firms)
• Exercise records: OT incident tabletop including production impact scenario
• OT security team: designated OT security responders with relevant training (GICSP, ICS410)

KRI values.

• OT IR playbooks: documented OT-specific IR procedures including production impact assessment (yes/no)
• OT IR retainer: relationship with OT-specialist IR firm (yes/no)
• Exercise completion: OT incident scenario in tabletop within 18 months (yes/no)
• OT-qualified responders: at least one team member with OT security credentials or equivalent experience (yes/no)

Status	Criteria
Green	All four components present; OT IR playbooks reviewed within 12 months; exercise completed within 18 months
Amber	IT IR plan with OT section but no OT-specific playbooks; or OT IR retainer without exercise
Red	No OT-specific IR capability; IT IR approach only; or no OT retainer firm

Deriving these KRIs by source type

From OT Network Monitoring Platforms (Claroty, Dragos, Nozomi, Armis)

• Asset inventory export: All three platforms provide asset discovery APIs; export includes protocol, vendor, firmware where identifiable
• Network flow analysis: Communication flow baseline; new/anomalous flows alert, feeds segmentation integrity KRI
• Alert feed: OT-specific alerts (protocol violations, unauthorized commands, rogue device connections) → route to SIEM or dedicated OT SOC dashboard
• Vulnerability matching: Platforms cross-reference OT asset inventory against ICS-CERT and vendor advisories, OT-specific CVE matching without active scanning

From CISA ICS-CERT Advisories

• Advisory RSS feed: https://www.cisa.gov/uscert/ics/advisories, subscribe for new advisories; match by vendor and product against OT asset inventory
• CISA KEV for OT: Filter KEV catalog for ICS/SCADA-related CVEs: OT-specific KEV entries require immediate compensating controls
• ICS-CERT alerts: High-urgency advisories for active exploitation in OT environments, treat as KEV-equivalent for OT

From Vendor Maintenance Systems

• OEM advisories: Siemens ProductCERT, Rockwell Automation security advisories, Schneider Electric cybersecurity advisories, ABB PSIRT, firmware advisory matching against asset inventory
• Firmware version tracking: Compare installed firmware versions (from OT platform or manual inventory) against latest vendor-released version; track gap
• Patch window planning: Coordinate with operations for next planned maintenance window, patch plan tracking against known critical CVEs

From Remote Access Platforms (Claroty SRA, Dispel, Tosibox)

• Session logs: All remote access sessions with start/end time, user, target asset, session recording status
• Active session monitoring: Real-time alert on new remote session to critical OT assets outside maintenance windows
• Orphaned access accounts: Vendor accounts in remote access platform cross-referenced against active vendor relationships, revoke access for inactive vendors

From Plant Documentation and Operations

• P&ID cross-reference: Piping and instrumentation diagrams show physical process control points, cross-reference against OT asset inventory to identify assets not yet inventoried
• Change management logs: Plant change management records for new equipment installations, trigger OT asset inventory update and security assessment
• Historian data: Process data historian contains implicit asset inventory (assets reporting process data), cross-reference against OT security inventory