OT Security for Critical Infrastructure: A Practical Leadership Guide

Ask a room of executives who protects the systems that keep the water flowing, the power on or the production line moving, and you'll usually get a pause. That pause is the problem. Operational Technology (OT) security for critical infrastructure is not just a tooling question; it's a leadership question. Here's how I approach it with the organizations I work with, pulled together from several earlier posts into one practical guide.

Why OT security is different from IT security

OT runs physical processes: pumps, valves, turbines, conveyors, building systems, etc. Those environments often run controllers and HMIs (Human-Machine Interfaces) that are 15 or 20 years old, can't be patched on a normal schedule, and were never designed to sit on a connected network. In IT, confidentiality usually comes first. In OT, availability and safety come first; a "fix" that stops the plant can do more harm than the threat it was meant to stop.

Well, that's why copying the IT security playbook into the plant rarely works. Scanning that is routine on an office network can knock over a fragile controller. Change windows are measured in months, not hours. And the people who know the process best (operators and engineers) often don't report to the security team at all.

Start with ownership: who "owns the risk"?

From what I've seen, the biggest gap in most OT programs isn't technology; it's that nobody clearly owns the risk. IT assumes operations has it. Operations assumes IT has it. The board assumes someone does. Before buying anything, name a single accountable owner for OT cyber risk, give that person a seat with both operations and security leadership, and write down who decides what during an incident. If you can't name the owner today, that's step one. (I go deeper on this in Who Owns OT Security in Your Company?)

Know what you have before you defend it

You can't protect assets you can't see. A good OT asset inventory lists every controller, HMI, engineering workstation, historian and remote access path, plus firmware versions and who supports each one. Use passive discovery where possible so you're not poking fragile devices, and validate it with walkdowns. Then map how data and commands actually flow between zones; quite simply, most surprises live in those connections.

Segment, then control remote access

Two controls tend to buy the most risk reduction for the money:

• Segmentation. Separate IT from OT, and separate OT zones from each other, using the zones-and-conduits model in ISA/IEC 62443. A ransomware infection on the business network should not have a clear path to the control network. The Colonial Pipeline shutdown in 2021 showed how an IT incident can still stop operations when the boundary and the business dependencies aren't well understood.

• Remote access. Vendors and integrators often have standing remote connections nobody remembers approving. Put every remote path through a monitored jump point with multi-factor authentication, time-limited access and session logging; and turn off what nobody can justify.

Patch what you can, compensate where you can't

Many OT assets can't be patched quickly, and some never will be. That's ok, as long as it's a decision and not an accident. Prioritize vulnerabilities that are actually exploitable and reachable in your environment (CISA's Known Exploited Vulnerabilities catalog is a good filter), schedule patches with operations during planned outages, and use compensating controls such as allowlisting, network restrictions and closer monitoring for the rest. Document the accepted risk and who accepted it.

Monitor for the bad day, and practice it

OT-aware network monitoring helps you spot unusual commands, new devices and unexpected connections that general IT tools usually miss. But detection only matters if people know what to do next. Build an OT incident response plan with operations at the table: when do you isolate, who can authorize shutting down a process, how do you run in manual mode, and how do you restore controller configurations from known-good backups? Then run tabletop exercises at least once a year. Have the plan in place, then work the plan.

Use the frameworks, don't drown in them

You don't need to invent your own approach. NIST SP 800-82 Rev. 3 (Guide to Operational Technology Security) gives a solid overall structure; ISA/IEC 62443 covers zones, conduits and security levels in depth; and the NIST Cybersecurity Framework (CSF) 2.0 gives leadership a common language for governance and reporting. Pick one as your backbone, map the others to it, and measure progress against it each quarter.

Make it a business conversation

Boards fund what they understand. Instead of reporting the number of alerts, report risk in operational terms: hours of downtime avoided, safety exposure reduced, regulatory findings closed, and the cost of an outage compared with the cost of the controls. My doctoral research looks at the return on investment of incident response, and the pattern holds there too: the organizations that tie OT security to uptime and safety tend to get sustained funding; the ones that talk only about threats usually don't.

Where outside help fits

Many mid-sized operators don't need a full-time OT security leader yet; they need someone to stand up governance, set priorities and coach the internal team until it can run on its own. That's where a fractional vCISO (virtual Chief Information Security Officer) or an experienced OT advisor fits: assess the current state, build a realistic roadmap, and help leadership "own the risk" long-term.

A short checklist to start this quarter

1. Name one accountable owner for OT cyber risk.

2. Build or refresh the OT asset inventory and data-flow map.

3. Review every remote access path and remove what can't be justified.

4. Confirm IT/OT segmentation actually blocks what you think it blocks.

5. Run one OT incident tabletop with operations, IT and leadership together.

None of this is glamorous, ha. But it's what keeps critical services running when something goes wrong. If you'd like a second set of eyes on your OT security program, get in touch.