OT Security: The Gap Most GRC Programs Haven’t Closed

Most GRC programs are built around IT assets — endpoints, servers, cloud environments, SaaS platforms. The risk register covers data breaches, ransomware, and regulatory compliance. That scope is appropriate for most of what the program governs.

The problem is that a significant and growing category of risk sits outside that scope entirely: operational technology. And the threat actors targeting it stopped being theoretical a long time ago.

In 2025, adversaries targeting operational technology crossed a line that had previously been limited to a small number of well-known attacks. They are no longer simply gaining access and waiting. Multiple threat groups, independently and across different geopolitical alignments, moved into actively mapping control loops — identifying engineering workstations, exfiltrating configuration files and alarm data, and learning how physical processes operate well enough to disrupt them. This is the removal of the last practical barrier between having access and being able to cause physical consequences. Asimily

That’s Dragos’s assessment from their 2026 OT Cybersecurity Report. It’s worth reading twice.

What OT Actually Means for GRC

Operational technology is the hardware and software that monitors and controls physical processes — industrial control systems (ICS), SCADA platforms, programmable logic controllers (PLCs), and the distributed control systems that run manufacturing lines, power grids, water treatment facilities, pipelines, and building automation systems.

The GRC gap is straightforward: these systems were designed for reliability and uptime, not cybersecurity. They run on legacy protocols. They often can’t be patched without taking a production process offline. They were built to last decades, and many of them are running on software and hardware that outlived the engineers who installed it.

For organizations in manufacturing, energy, healthcare, utilities, and critical infrastructure, OT assets represent some of the highest-consequence risk in the environment. A ransomware attack on IT is bad. A wiper attack on OT that takes a production line or a water treatment system offline is a different category of problem — one with physical consequences and potential regulatory liability that extends well beyond a data breach.

Wipers have overtaken ransomware as the weapon of choice for state-sponsored actors targeting OT environments. A single pattern connects nearly every major incident: a malicious file crossed a trust boundary that no one was inspecting. Nexus

The Threat Actors Currently Active

The geopolitical context matters here because OT threats are primarily nation-state driven, and the actors are already inside critical infrastructure — not theoretically, but documentably.

VOLTZITE, assessed as Chinese state-aligned and overlapping with Volt Typhoon operations, has been documented pre-positioning in US water, power, and communications infrastructure using living-off-the-land techniques designed for long-term persistent access — not immediate impact. The intent is to maintain the capability to cause disruption when directed, not to act now.

The Stryker attack in March — covered in the April 14 post — is the clearest recent example of what happens when pre-positioning becomes execution. Nation-state-backed attackers wiped and disrupted more than 200,000 systems, servers, and mobile devices across the organization. Stryker is a medical device manufacturer, not a power grid. The targeting logic has expanded well beyond traditional critical infrastructure definitions. Bitsight

In March 2026, an Iran-attributed attack on Jordan’s national wheat silo management system attempted to manipulate silo temperature controls to spoil the country’s strategic grain reserve. Manipulating temperature controls to destroy a food supply is a different use of cyber capability than stealing credentials or encrypting files. It’s the physical consequence scenario that OT security practitioners have been warning about for years. OPSWAT

Where Most GRC Programs Fall Short

The gap isn’t awareness — most security professionals know OT is a risk category. The gap is governance.

OT environments are typically owned by operations, engineering, or facilities teams — not IT and not security. The people who manage these systems are experts in the physical process they control, not in cybersecurity. When a PLC needs a patch, the decision is made by someone whose primary concern is uptime, not security hygiene. That’s not a criticism — it’s an organizational reality that GRC programs need to account for.

Most risk registers don’t include OT assets at all. Most control frameworks that GRC programs operate against were designed for IT environments. NIST CSF, ISO 27001, SOC 2 — these frameworks are adaptable to OT but require intentional mapping. Without that mapping, the GRC program has a documented blind spot in its highest-consequence asset class.

The IT/OT convergence trend has made this worse in some ways. As OT environments connect to corporate IT networks for monitoring, remote access, and data integration, they inherit IT-side vulnerabilities without inheriting IT-side security controls. Remote access tools exposed to the internet and default credentials on industrial systems are the two entry points that appear in OT breach reports with remarkable consistency.

Where to Start

You don’t need to rebuild your entire GRC program around OT overnight. You need to understand your OT exposure and start closing the most critical gaps.

Conduct an OT asset discovery exercise. You cannot govern what you haven’t inventoried. Work with operations and engineering teams to document OT assets, their network connectivity, their remote access exposure, and their patch status. This exercise will surface the gaps and inform prioritization.

Map your IT/OT network boundaries. How are your OT environments connected to corporate IT? Are those connections documented and segmented, or were they established informally for operational convenience? The attack path in most OT incidents runs through IT first. Understanding that boundary is foundational.

Address remote access exposure. Attacks against industrial control systems regularly succeed through weak or default passwords and remote access tools exposed to the internet. These aren’t sophisticated entry points. They’re fixable with basic access hygiene. Audit remote access to OT systems and apply the same controls you’d apply to any privileged IT access — MFA, just-in-time provisioning, session logging. Bitsight

Extend your risk register to OT assets. OT systems with physical consequence potential belong in your risk register with appropriate risk ratings. The absence of OT from your documented risk profile isn’t a sign that the risk doesn’t exist — it’s a sign that your governance framework has a gap.

Reference NIST SP 800-82. The Guide to Operational Technology Security is the foundational framework for OT security governance. If your GRC program hasn’t mapped OT controls against 800-82, that’s the starting reference.

The GRC conversation around OT is overdue in most organizations. The threat actors targeting these environments are not waiting for the governance programs to catch up.

Discussion Questions

Are OT assets included in your organization’s risk register? If not, what’s the process for adding them, and who owns that conversation with operations and engineering?
Have you mapped the IT/OT network boundaries in your environment? Do you have documented visibility into how OT systems connect to corporate IT — including informal or undocumented connections?
When did your organization last audit remote access to OT systems? Are default credentials and internet-exposed remote access tools part of your vulnerability management scope?