Blog
New Era of AI Cybersecurity Defense
Read More
Operational Technology (OT) and cyber-physical systems (CPS) are no longer niche concerns reserved for manufacturing engineers and plant managers. They now sit squarely in the blast radius of every CIO, CISO, and infrastructure leader—because the boundary between “information systems” and “systems that do things” is collapsing. In a recent training, Principal Cybersecurity Architect Gerry Wollam walked through why the OT world behaves differently, why threats are accelerating, and why the organizations that move first will be in the best position to reduce risk and fund modernization. This blog distills the most relevant insights for IT leaders who need to govern, secure, and invest across both IT and OT.
Many IT leaders intuitively understand networks, identity, endpoints, patching, and cloud controls. OT can look deceptively similar—Ethernet, IP addresses, remote access, and monitoring tools all show up. But the mission is fundamentally different. IT protects information and enables knowledge work; OT controls physical processes: energy generation, water treatment, cold storage, building automation, medical devices, robots, and industrial IoT. That shift from “data compromise” to “physics compromise” changes everything: acceptable downtime, safety requirements, lifecycle management, vendor constraints, and even who has decision rights.
One of the most important leadership reframes is lifecycle. IT systems often operate on three- to five-year refresh cycles; OT assets may run for 15–30 years—or “until they die.” When something keeps production running, the default behavior is to leave it alone. That creates a culture where change avoidance is rational, maintenance windows are rare, and security controls that assume frequent patching or constant agent updates simply don’t translate. As a result, OT security is often behind not because teams don’t care, but because incentives and constraints are different.
For IT leaders, the implication is straightforward: if your organization has plants, critical facilities, logistics operations, connected medical environments, or anything “smart” at the edge, then your risk profile is already shaped by OT—even if the OT team is not yet part of your security governance model.
Wollam’s central message was blunt: the examples that sound like science fiction are increasingly “completely possible, even right now.” The OT/CPS ecosystem is expanding (more sensors, more remote access, more vendor connectivity), while attackers are becoming more capable and more patient. In IT, a breach is often measured in records exposed or business interruption. In OT, consequences include safety incidents, environmental impact, equipment damage, and cascading outages—events that can trigger regulatory scrutiny, insurance disputes, and long-term reputational harm.
IT leaders often start with familiar playbooks: deploy endpoint agents, enforce MFA everywhere, patch aggressively, and implement a zero-trust architecture. The problem is not that these are “wrong”—it’s that OT environments have constraints that break the assumptions behind those controls. Some devices can’t run agents. Some systems can’t tolerate latency. Some vendors void support agreements if you change configurations. And patching may require downtime that operations simply cannot accept.
That’s why effective OT security tends to emphasize compensating controls and “surgical” containment: strong network segmentation, industrial intrusion prevention and anomaly detection, tightly governed remote access, and asset visibility that can survive in fragile environments. A recurring theme from the session was that you must meet OT where it is—design controls that respect safety and uptime while still meaningfully reducing the probability of compromise and the blast radius of an incident.
If there’s one low-cost exercise that creates significant value, it’s a purpose-built tabletop exercise (TTX) for OT incidents. Wollam described customer environments where plant teams had never participated in a tabletop—ever. Security planning had been done with lawyers and IT administrators, while the people who actually run OT networks weren’t in the room. That’s a recipe for false confidence.
A good OT tabletop clarifies roles, escalation paths, and operational priorities. It tests whether you can isolate a compromised segment without halting the entire plant. It forces the question many leaders avoid: if an OT environment is breached, do you trust the integrity of device configurations—or do you need a clean restoration path? And it surfaces the cross-functional dependencies that matter most: safety, operations, facilities, legal, PR, IT, and third-party vendors.
Most importantly, tabletops convert abstract risk into shared understanding—making it easier to justify budget and prioritize projects.
One of the hardest truths in OT security is that many organizations have no standing budget for it—because historically, they didn’t perceive a need. That means the first “project” is often not a deployment; it’s a business case. Wollam emphasized that assessments can be valuable, but jumping straight into a solution is usually tough unless you already have executive sponsorship. The programs that move fastest tend to have buy-in from the top of the house—because leadership must justify funding before anything operational can change.
For IT leaders, the takeaway is to treat OT security as an enterprise risk and resilience initiative rather than “another security tool.” Tie it to measurable business outcomes: reduced downtime risk, improved safety posture, compliance readiness, insurance leverage, and better recovery capability. And be explicit about the operating model: who owns decisions, how changes are approved, how vendors are managed, and how security requirements are embedded into maintenance cycles.
The session highlighted a simple heuristic: if an organization (or business unit) has OT, cyber-physical systems, industrial IoT, or medical IoT, that’s where leaders should be asking deeper questions now. These systems are foundational—“the stuff that makes the world spin,” as Wollam put it. Unlike many IT breaches that end in credit monitoring and settlements, OT incidents can drive extended downtime, safety outcomes, and ripple effects that touch communities and critical infrastructure.
1. Map your OT reality. Identify where OT/CPS exists (plants, facilities, logistics, building automation, labs, medical environments). Build a high-level asset and connectivity map: remote access paths, vendor links, and interdependencies with IT.
2. Establish governance. Define who owns risk decisions across IT/OT. Create a joint steering model that includes operations, engineering, facilities, safety, and security.
3. Run an OT-focused tabletop exercise. Pick one representative site and simulate a credible incident. Capture gaps in roles, isolation capability, communications, and recovery confidence.
4. Prioritize “containment first” controls. Focus on segmentation, controlled remote access, monitoring/visibility, and backup/restore integrity for critical configurations.
5. Build the business case. Translate risk into operational terms: downtime cost, safety exposure, compliance obligations, and recovery timelines. Use tabletop findings as evidence.
6. Design a phased roadmap. OT security modernization is a multi-year journey. Plan for quick wins, then deeper architecture changes aligned to maintenance windows and vendor cycles.
In conclusion: the future may feel scary, but the opportunity is bright
In Wollam’s words, “the future seems scary—but the opportunity shines really bright.” The message for IT leaders is not panic; it’s clarity. OT and cyber-physical security are on the upswing of the risk curve, and every year brings more real-world examples that force investment. Leaders who act now—by aligning stakeholders, validating response readiness, and designing pragmatic controls—will not only reduce the odds of a catastrophic incident, they’ll be better positioned to fund modernization and resilience in the physical systems their organizations depend on.
