You Cannot Defend What You Cannot Measure

Most CISOs can answer basic questions about their IT security posture: mean time to detect, patch cadence, phishing click rates, endpoint coverage percentage. But ask those same CISOs to quantify the security posture of their OT connectivity – the actual connections between IT and OT environments – and the conversation stalls.

This is not a knowledge gap. It is a measurement gap. And it matters because OT connectivity is where the attacks are concentrated. Dragos reported that ransomware groups targeting industrial organizations increased 64% year-over-year in 2025, with attacks affecting 3,300 organizations globally. Manufacturing accounted for more than two-thirds of victims, with an average dwell time of 42 days for ransomware in OT environments. Claroty found that 82% of verified OT intrusions used internet-facing remote access tools as the initial entry point. The SANS Institute’s 2025 ICS/OT survey found that 22% of organizations reported a cybersecurity incident affecting OT systems in the past year, with 40% of those incidents causing operational disruption.

The attacks are not targeting PLCs directly. They are targeting the connectivity layer – the VPNs, jump servers, remote access tools, and file transfer mechanisms that bridge IT and OT. And most organizations have no structured way to measure whether that layer is getting more secure or less secure over time.

This article defines five CISO KPIs OT connectivity security teams should track, with specific formulas, benchmarks, data sources, and board-ready reporting formats. These are not generic cybersecurity metrics adapted for OT. They are purpose-built for the IT/OT boundary – where the risk concentrates, the visibility gaps persist, and the regulatory pressure is accelerating.

KPI 1: Inbound Port Exposure Index

What It Measures

The number of inbound firewall ports open to OT zones from any external or IT network, weighted by protocol risk.

Why It Matters

Every inbound port on an OT firewall is a discoverable, scannable, exploitable entry point. The 2026 Dragos report documented that ransomware affiliates consistently authenticated into VPN portals and firewall interfaces before pivoting into OT networks. In August 2025, GreyNoise observed approximately 2,000 malicious IPs simultaneously probing RDP Web Client endpoints. The fewer inbound ports open to OT, the smaller the attack surface – and zero is the target.

How to Calculate

Inbound Port Exposure Index = Σ (open inbound ports × protocol risk weight)

 

Protocol	Risk Weight	Rationale
RDP (3389)	5	Most exploited OT remote access vector; CVE-2025-48817 demonstrated client-side RCE
VPN (443/1194)	4	Primary initial access path for ransomware in OT; Ivanti, Fortinet, Palo Alto VPN CVEs exploited at scale in 2025
SSH (22)	3	Common for engineering access; hardcoded credentials widespread in OT
HTTP/HTTPS (80/443)	2	Web interfaces for HMI and SCADA management consoles
Custom TCP	2	Vendor-specific protocols; often undocumented and unmonitored
SFTP (22)	1	File transfer; lower risk when properly scoped

Benchmark

Score	Rating	What It Means
0	Excellent	Zero inbound ports – full reverse-access architecture
1–5	Good	Minimal exposure, likely one VPN or SFTP port
6–15	Elevated	Multiple protocols exposed; supplementary products creating gaps
16+	Critical	Significant attack surface; immediate architectural review needed

Board Reporting

Present as a single number that trends over time. The board does not need to know what RDP port 3389 is. They need to see: “Our OT inbound exposure was 22 in Q1. It is 4 in Q3. Our target is 0 by Q1 next year.” That narrative is actionable and understandable.

Data Source

Firewall rule export (automated weekly), validated by external scan (Shodan, Censys) monthly. Any discrepancy between the firewall rule count and the external scan result is itself a finding – it means a port is open that someone forgot about.

KPI 2: Connectivity Consolidation Ratio

What It Measures

The number of separate products managing IT/OT connectivity, relative to the number of connectivity types they handle.

Why It Matters

Every additional product in the IT/OT connectivity stack adds a vendor, a console, a log format, an update cycle, and an attack surface. Dragos reported that ransomware groups exploited VPN portals and remote access tools – the supplementary products that organizations deploy around their data diodes because the diode cannot handle interactive sessions. The more fragmented the stack, the harder it is to maintain consistent security policy and the longer it takes to investigate incidents.

How to Calculate

Connectivity Consolidation Ratio = Number of connectivity products / Number of connectivity types

 

Connectivity types (count those that exist in your environment):

• Interactive application access (RDP, SSH, HTTP to OT)
• Bidirectional file sharing (SMB, SFTP between IT and OT)
• Unidirectional data transfer (historian replication, syslog)
• Vendor remote access (third-party maintenance sessions)
• Machine-to-machine API connectivity (real-time integration)

Example calculation:

Scenario	Products	Types	Ratio
Patchwork: Data Diode + VPN + Jump Server + SMB Proxy + TCP connector	5	5	1.0
Partial consolidation: Platform + Data Diode	2	5	0.4
Full consolidation: Single platform (diode retained for regulated flows)	1–2	5	0.2–0.4

Benchmark

Ratio	Rating	What It Means
≤ 0.4	Excellent	Consolidated platform covering multiple connectivity types
0.5–0.7	Good	Partial consolidation; some supplementary products remain
0.8–1.0	Elevated	One product per connectivity type; fragmented management
> 1.0	Critical	Multiple overlapping products for the same connectivity type

Board Reporting

“We currently use 5 products from 4 vendors to manage IT/OT connectivity. Our consolidation plan brings this to 2 products from 1–2 vendors by Q2, reducing our vendor management complexity and incident response coordination from 4 escalation paths to 1.”

Why This KPI Drives Decisions

A ratio above 0.8 signals that the organization is spending more on managing the connectivity stack than on securing it. Each product has its own patch cycle, its own CVE exposure, and its own integration requirements. The 2025 Mandiant M-Trends report found that exploits were the top initial access vector at 33% of investigations – and those exploits increasingly target the VPN concentrators, firewalls, and edge appliances that make up the supplementary stack.

KPI 3: Session Attribution Coverage

What It Measures

The percentage of OT connectivity sessions (RDP, SSH, HTTP, file transfers) that have complete identity attribution – meaning the organization can answer: who connected, from which device, at what time, to which specific OT resource, with what authorization, and what they did during the session.

Why It Matters

IBM reported a 2025 mean of 181 days to identify a breach and 60 days to contain it – a total lifecycle of 241 days. In OT environments, Dragos found an average ransomware dwell time of 42 days, partly because OT assets like engineering workstations running Windows are misclassified as IT systems and incidents are treated as IT-only. When the IR team cannot attribute a session to a specific user and a specific OT resource, investigation time multiplies.

The difference between “someone accessed the SCADA zone via VPN sometime last month” and “Jane Smith authenticated via MFA at 14:32 on March 7 from her company laptop, accessed SCADA-HMI-01 via RDP, and here is the full session recording” is the difference between weeks of forensic work and five minutes of log review.

How to Calculate

Session Attribution Coverage = (Fully attributed sessions / Total OT connectivity sessions) × 100

 

A session is “fully attributed” only if ALL of the following are recorded:

• Named user identity (not shared account, not generic “vendor” account)
• Authentication method and MFA status
• Device identifier and posture at time of access
• Target OT resource (specific workstation, server, or application)
• Session start/end time and duration
• Policy that authorized the session
• Session recording (for interactive sessions: video + keystroke)

Benchmark

Coverage	Rating	What It Means
95–100%	Excellent	Full attribution; IR team can investigate any session in minutes
80–94%	Good	Most sessions attributed; gaps typically in vendor or legacy access
50–79%	Elevated	Significant blind spots; shared accounts and unrecorded sessions common
< 50%	Critical	Majority of OT access is unattributed; incident investigation relies on correlation across fragmented logs

Board Reporting

“87% of our OT connectivity sessions are fully attributed with named identity, MFA, device posture, and session recording. The remaining 13% are legacy vendor sessions using shared credentials – we are migrating these to named accounts with per-session MFA and recording by Q3.”

The Vendor Access Problem

Vendor access is where attribution coverage typically collapses. Four technicians sharing two VPN credentials, connecting through the same jump server, with no session recording, no time limits, and no approval workflow. When something goes wrong – and the Dragos 2026 report documented that supply chain and vendor access remain primary attack vectors – the IR team cannot determine which technician connected, what they did, or whether the session was authorized.

KPI 4: Mean Time to Investigate OT Session (MTTI-OT)

What It Measures

The average time required for the IR team to fully reconstruct an OT connectivity session – from initial alert to complete understanding of who did what, when, and to which OT resource.

Why It Matters

Standard MTTD and MTTR metrics measure detection and response speed for IT security events. But OT connectivity incidents have a unique investigation challenge: the data needed to reconstruct the session is typically scattered across 4–6 different systems (VPN logs, jump server Windows Event Logs, firewall logs, application logs, SIEM correlation rules, and possibly a separate session recording system). The Mandiant M-Trends 2025 report found that median dwell time dropped to 10–11 days for targeted attacks, but OT environments lag significantly – Dragos reported 42 days average for ransomware in OT, partly due to misclassification and investigation complexity.

MTTI-OT captures this investigation overhead directly. It is not a detection metric – it assumes the alert already fired. It measures how long it takes to answer the five questions every IR team needs answered: Who? What device? Which OT resource? What actions? Under what authorization?

How to Calculate

MTTI-OT = Σ (time from alert to full session reconstruction) / Number of investigated OT sessions

 

Benchmark

Time	Rating	Architecture Signal
< 15 minutes	Excellent	Unified platform with per-session audit trail and recording
15–60 minutes	Good	Partially consolidated; some manual correlation required
1–4 hours	Elevated	Fragmented stack; IR team correlating 3+ log sources
> 4 hours	Critical	Multiple systems, multiple vendors, no unified timeline; investigation is forensic reconstruction, not log review

Board Reporting

“Our current MTTI-OT is 3.2 hours because the IR team must correlate logs from 4 separate systems. After platform consolidation, the target is under 15 minutes – a single audit trail with session recording for every OT connection.”

What Drives MTTI-OT Down

Three architectural factors determine MTTI-OT more than any process improvement:

Single audit trail vs. fragmented logs. If all OT connectivity flows through one platform, every session produces one log entry with complete context. If connectivity is split across 4–5 products, the IR team must join timestamps across different time formats, different identifiers, and different levels of detail.

Session recording vs. log inference. A recorded session (video + keystroke) answers “what happened” definitively. Without recording, the IR team infers actions from log entries that may or may not capture the relevant activity. In SCADA environments where actions can affect physical processes, inference is not acceptable.

Named identity vs. shared credentials. If four vendors share two accounts, the IR team cannot determine which individual connected. The investigation forks into parallel hypotheses that require manual verification – often by calling the vendor and asking who was on shift.

KPI 5: Zero Trust Coverage for OT Connectivity

What It Measures

The percentage of OT connectivity sessions that enforce the full Zero Trust decision chain: identity verification, device posture assessment, policy evaluation, least-privilege access, and continuous session monitoring.

Why It Matters

Every major regulatory framework is converging on Zero Trust for OT. The DoD issued DTM 25-003 in July 2025 directing all components to achieve target-level Zero Trust across all systems including OT. The January 2026 Five Eyes guidance from CISA, NCSC-UK, BSI, FBI, and partner agencies established secure connectivity principles for OT that emphasize identity-based access, continuous authentication, and granular policy enforcement. NIST SP 800-207 requires per-request access decisions based on identity, device health, and context.

A data diode satisfies the segmentation requirement but provides zero identity, zero authentication, zero authorization, and zero session monitoring. A VPN provides authentication but grants network-level access, not application-level. A jump server provides RDP access but typically without per-session MFA, device posture checks, or session recording. Only a connectivity platform that combines all five elements delivers full Zero Trust coverage for OT sessions.

How to Calculate

For each OT connectivity session, score against five Zero Trust criteria:

Criterion	Score 1 (Yes)	Score 0 (No)
Identity verified (named account + MFA)	Session uses named user account with multi-factor authentication	Shared account, no MFA, or password-only
Device posture assessed	Connecting device evaluated for OS patch level, EDR status, encryption, compliance	No device check; any device can connect
Policy evaluated per-request	Access decision based on user/group + target resource + time window + approval status	Blanket access once VPN connected
Least-privilege enforced	User can access only the specific OT resource authorized by policy	User can reach any device on the OT network
Session monitored and recorded	Session recorded (video + keystroke for interactive), activity logged, auto-terminated at policy limit	No recording, no time limit, no activity logging

Zero Trust Coverage = (Sessions scoring 5/5) / (Total OT connectivity sessions) × 100

 

Benchmark

Coverage	Rating	What It Means
90–100%	Excellent	Full Zero Trust enforcement; regulatory trajectory aligned
70–89%	Good	Most sessions enforced; gaps in vendor or legacy access
40–69%	Elevated	Significant sessions bypass Zero Trust chain; compliance gaps
< 40%	Critical	Majority of OT connectivity uses pre-Zero-Trust architecture (VPN, jump server, shared credentials)

Board Reporting

“42% of our OT connectivity sessions currently meet full Zero Trust criteria. The gap is concentrated in vendor remote access (0% coverage – shared VPN credentials, no MFA, no recording) and legacy file transfers (0% coverage – standalone SMB proxy with no identity integration). Our 12-month plan brings coverage to 90%+ by migrating vendor access and file sharing to the consolidated platform.”

The Compliance Trajectory

This KPI is not just a security metric – it is a compliance readiness metric. Organizations that cannot demonstrate Zero Trust coverage for OT connectivity will face increasing regulatory friction. The DoD Zero Trust mandate has specific deadlines. NIS2 in Europe requires risk-based access controls for essential entities. IEC 62443 SL3+ requires continuous authentication. Tracking this KPI now positions the CISO to demonstrate compliance progress rather than scrambling when the audit arrives.

The CISO Dashboard: All Five KPIs Together

KPI	Current State (Example)	Target	Timeline
1. Inbound Port Exposure Index	18 (VPN + RDP + 3 custom ports)	0	6 months
2. Connectivity Consolidation Ratio	1.0 (5 products / 5 types)	0.4 (2 products / 5 types)	9 months
3. Session Attribution Coverage	62% (vendor and legacy gaps)	95%+	12 months
4. MTTI-OT	3.2 hours	< 15 minutes	9 months
5. Zero Trust Coverage	42%	90%+	12 months

The five KPIs are interdependent. Reducing the Inbound Port Exposure Index to zero (KPI 1) requires architectural change – typically migration to reverse-access. That same migration consolidates the connectivity stack (KPI 2), which unifies the audit trail (KPI 3), which accelerates investigation time (KPI 4), which enables full Zero Trust enforcement (KPI 5). The KPIs are not five separate projects. They are five measurements of a single architectural transformation.

How to Start: The 30-Day Baseline

CISOs do not need to deploy anything to start tracking these KPIs. The 30-day baseline exercise uses existing data:

Week 1 – Firewall Rule Audit. Export all firewall rules governing traffic to OT zones. Count inbound ports. Calculate the Inbound Port Exposure Index. Run an external scan (Shodan/Censys) and compare. Document discrepancies.

Week 2 – Product Inventory. List every product involved in IT/OT connectivity: VPN, jump server, data diode, SMB proxy, file gateway, TCP connectors, remote access tools. Calculate the Consolidation Ratio. Document which vendor owns each product and when each was last updated.

Week 3 – Session Attribution Audit. For 20 recent OT connectivity sessions (mix of employee RDP, vendor access, file transfers), attempt to fully attribute each one. How many have named identity? MFA? Device posture? Session recording? Calculate Session Attribution Coverage. Measure how long each attribution took – that is your MTTI-OT baseline.

Week 4 – Zero Trust Scoring. For the same 20 sessions, score each against the five Zero Trust criteria. Calculate Zero Trust Coverage. Identify which criteria fail most frequently – that tells you where architectural change has the highest impact.

At the end of 30 days, the CISO has a quantified baseline for all five KPIs, a clear picture of where the gaps concentrate, and a data-driven foundation for the architectural business case.

Conclusion

Generic cybersecurity metrics do not capture the security posture of OT connectivity. MTTD and MTTR measure detection and response speed, but they do not tell the CISO whether OT access is properly attributed, whether the connectivity stack is consolidated or fragmented, or whether the organization is progressing toward Zero Trust compliance for the IT/OT boundary.

The five CISO KPIs OT connectivity security teams should track – Inbound Port Exposure Index, Connectivity Consolidation Ratio, Session Attribution Coverage, Mean Time to Investigate OT Session, and Zero Trust Coverage – provide that visibility. They are specific, measurable, and directly tied to the architectural decisions that determine whether OT connectivity is a controlled, auditable, policy-enforced surface or an expanding patchwork of point products with fragmented logs and shared credentials.

Start with the 30-day baseline. Measure where you are. Set targets for where you need to be. Track quarterly. Present to the board in language they understand: fewer ports, fewer vendors, faster investigations, higher compliance coverage. The numbers do the talking.