An industrial process is, at its core, a sequence with physical consequences; a child of an engineered system that executes precise choreography in harmony with other systems.
Whether the environment is energy, manufacturing, transportation, mining, or other industrial operations, processes depend on precise timing, sequence, and control. Each step depends on something happening at the right moment, in the right order, at the right rate—and on every device in that chain reporting accurately about what it just did.
That is an engineering observation rather than a dramatic one. But it carries a security implication that a conventional network review is not built to surface. In an industrial environment, timing and sequence integrity are part of what keeps operations safe and reliable. An enterprise security assessment measures data exposure and confidentiality. It is not designed to answer whether a physical process still behaves the way its engineers intended.
That gap—between how we assess information risk and how industrial operations actually work—is where operational technology (OT) security begins.
OT security is not IT security applied to industrial equipment. And the harder half of the job is not technical at all. It is our responsibility, as cyber leaders, to translate that difference into operational and business terms that leadership can act on. A core challenge for cyber leaders is translating OT architecture and cyber risk into operational, financial, and business terms.
A Practitioner’s Vantage Point
I have spent roughly 27 years as a cybersecurity practitioner, including five to seven years building operational technology practices at AT&T and EY before becoming CISO at Arctic Slope Regional Corporation. ASRC is continuing to mature cybersecurity architecture across complex brownfield operational environments, including the use of layered segmentation and controlled trust boundaries to improve resilience.
What I want to share here are lessons from that work, because the same pattern shows up across industrial sectors. The central lesson is this: OT security is not IT security applied to industrial equipment. And the harder half of the job is not technical at all. It is our responsibility, as cyber leaders, to translate that difference into operational and business terms that leadership can act on. A core challenge for cyber leaders is translating OT architecture and cyber risk into operational, financial, and business terms.
What Changes Past the DMZ
The clearest way to explain the difference to a non-specialist is to draw a line at the DMZ—the boundary between the enterprise network and the industrial environment—and describe what changes once you cross it.
Traditional IT security techniques may require different approaches in OT because availability, safety, equipment sensitivity, operational requirements, and vendor constraints must all be considered. Many industrial environments rely heavily on passive monitoring and network-based visibility.
Protocols change. OT traffic commonly runs on UDP rather than TCP. It is faster and less reliable by design, which suits simple, repetitive instructions: open this valve, hold this temperature, report this reading.
Assessment methods change. Active scanning techniques commonly used in IT may not be appropriate for all OT environments and should be carefully validated against operational, safety, and vendor requirements before they are used against a live process.
Endpoint strategy changes. Many industrial devices were not designed to support traditional endpoint agents, which makes network visibility and compensating controls especially important. OT environments therefore rely heavily on passive monitoring and network-based visibility rather than on the agent-based telemetry that enterprise security teams take for granted.The takeaway for security leaders is not that the IT toolkit is less effective past the DMZ. It is that parts of it must be validated with operations and engineering before they are used at all, and that the controls we substitute in their place—visibility, segmentation, disciplined access—carry more of the weight.
Legacy by Design, Not Neglect
Across the industrial sector, control technologies and operating systems often remain in service far longer than traditional enterprise IT because operational reliability and equipment lifecycles are measured differently. There is a persistent assumption that long-lived industrial systems are simply outdated systems that nobody got around to replacing. That assumption misreads the engineering.
OT devices are intentionally minimal. A packet tells a system to raise a temperature, move a volume, or trigger a sensor. That simplicity is deliberate, and it is a large part of why these systems are so reliable. It also means they include few built-in security controls, and that firmware can often be patched but rarely meaningfully upgraded.
Industrial technology is often designed for operating lives measured in decades rather than years. A system may continue performing its intended function reliably long after the operating system or firmware would be considered obsolete in a traditional IT environment. Some industrial systems remain in production for decades precisely because replacing or materially changing a stable component can introduce operational risk. That makes segmentation, monitoring, compensating controls, and disciplined lifecycle risk management especially important.The “if it isn’t broken” mindset that engineers bring to these environments is a rational position, not evidence of neglect. Our job is not to argue with it. It is to build an architecture that lets that reliability continue safely in a more connected threat environment. That engineering mindset appropriately prioritizes process stability, which makes compensating controls, segmentation, monitoring, and lifecycle risk management particularly important.
Segmentation, and the Purdue Model in Plain Terms
The Purdue Model is a way of describing an industrial environment in layers, from the business network down to the sensors and controllers touching the physical process. Its practical value for leadership is that it makes the question of containment visible.
Think of a flat network as a single chain. A compromise anywhere on that chain can reach everything connected to it. Segmentation breaks the chain into meaningful security zones with controlled communications paths, so that compromise in one portion of the environment does not automatically provide access to another.
That is the whole argument, and it is worth stating that plainly, because the investment case has to compete on its merits. OT cybersecurity investments compete with many legitimate operational and capital priorities, which makes a clear business case essential. Segmentation is not a repair for something that broke. Segmentation is a resilience investment designed to limit the consequence of a future event, rather than a repair of a past one.
Why This Matters Now
The threat environment has changed as industrial systems have become more connected to enterprise networks, remote access, vendors, and digital supply chains. At the same time, nation-state and criminal actors continue to show sustained interest in critical infrastructure.
Neither of those developments depends on any particular headline. That is what makes them worth planning around. The exposure that matters is structural: connectivity that was added incrementally, for good operational reasons, into environments that were originally designed to be isolated.
Stuxnet: An Enduring Lesson
Stuxnet remains the clearest historical illustration of the point. Malware introduced by USB altered the operating speed of centrifuges until the equipment damaged itself. What is striking, looking back, is how unremarkable the mechanics were. The significance was never the sophistication. It was the demonstration that a digital entry point could be used to affect a physical process.
Stuxnet demonstrated an enduring OT security principle: cyber activity can move beyond data loss and affect a physical process. Modern OT security therefore focuses not only on preventing intrusion, but on containing compromise and operational consequence.
Translating OT Risk for Leadership
If there is one thing I would ask cyber leaders to take from this, it is that the translation problem belongs to us.
Technical frameworks become meaningful at the executive level when they are translated into operational resilience, safety, business continuity, and financial exposure. A board does not need to know what sits at Level 2 of the Purdue Model. It needs to understand what keeps running when something goes wrong, how quickly operations recover, and what the organization has done to make sure a problem in one place stays in one place.
The most useful anchor I have found is business interruption. For industrial organizations, even relatively short periods of unplanned downtime can create significant operational and financial consequences, like degraded production and unplanned shutdowns. That allows cybersecurity investments to be evaluated against business interruption and recovery risk rather than purely technical metrics. Published industry research gives a sense of scale: Siemens’ The True Cost of Downtime study has put unplanned downtime in oil and gas in the range of roughly half a million dollars per hour, with costs across industrial sectors rising sharply over the past several years. Figures like these vary widely with commodity prices, facility type, and restart requirements, and every organization should model its own—but they establish that the conversation belongs in operational and financial terms.
Insurance is becoming a second useful anchor. Cyber insurers are placing greater emphasis on whether represented controls are implemented and whether material findings are appropriately managed. Organizations should coordinate with risk management, brokers, insurers, and counsel to understand policy-specific requirements. The governance point for security leaders is straightforward: an assessment finding is not closed when the report is filed.Standard cyber hygiene remains necessary in industrial organizations. It is simply not sufficient on its own.
The Next Stage of OT Resilience
The most interesting work in this field is ahead of us, not behind us. The areas I would watch, and the areas I would encourage other security leaders to invest attention in, are these:
- Evolving approaches to zero trust in OT, and what those principles mean in environments where availability and safety come first
- Secure vendor and remote access, which is where much of the new connectivity has entered
- Better asset visibility, since nothing else scales without it
- Identity and access controls extended sensibly into industrial environments
- Recovery and operational resilience, including how quickly a process can be brought back safely
- The questions executives should be asking about OT risk, and how we equip them to ask better ones
Practical Guidance
For security leaders responsible for industrial environments, a few practices travel well across sectors:
- Establish clearly where IT ends and OT begins, and treat that boundary as a governed, controlled line rather than an assumed one.
- Use OT-appropriate discovery and monitoring techniques, and carefully validate active assessment methods with operations, engineering, and relevant vendors before deployment.
- Establish meaningful security zones and controlled communications paths so that compromise in one portion of the environment does not automatically provide access to another.
- Maintain an inventory of long-lived industrial systems and manage them through documented lifecycle risk management, compensating controls, and monitoring.
- Treat assessment and penetration-test findings as items to be managed to closure, and coordinate that work with risk management, brokers, insurers, and counsel.
- Frame the case for executives in operational, safety, continuity, and financial terms rather than framework terminology.
- Establish formal remediation governance for material assessment findings and coordinate with risk management and insurers where policy requirements warrant.
What We Are Actually Protecting
Return to where we started: a process running exactly as designed, with the sequence holding and the margins intact. Very little about that picture shows up on a conventional network review, which is precisely why it deserves a different kind of attention.
The goal of OT cybersecurity is not to make industrial systems behave like IT. It is to preserve the reliability and safety those systems were built to provide while giving operators the resilience required for today’s threat environment.