Over the last few years, OT cybersecurity has moved from being a relatively niche topic to becoming a serious priority for industrial organizations. Plants are investing in firewalls, network segmentation, endpoint protection, vulnerability management, monitoring tools and cybersecurity standards. Organizations are developing policies and procedures, conducting assessments and building dedicated OT cybersecurity teams. All of this is important, but there is one question I believe we need to ask more often: Does the cybersecurity program actually work on the plant floor?

This question comes from working at the intersection of instrumentation, control systems, industrial operations and OT cybersecurity. The more I work in this space, the more I realize that OT cybersecurity cannot simply be treated as another IT cybersecurity project. The technology may look similar in some cases, but the environment is completely different. In a process plant, a computer is not always just a computer. It may be connected to a control loop, a compressor, a boiler, a safety system or a production process running 24/7. A seemingly simple cybersecurity action can therefore have consequences far beyond the IT environment.

That is where OT cybersecurity needs a different mindset.

The Plant Comes First

One of the biggest lessons I have learned is that you cannot design effective OT cybersecurity without understanding the operation. Before asking how to secure a system, we should understand what that system actually does. What process does it control? What happens if it becomes unavailable? What happens if an engineer loses access to it? What happens if a controller is restarted? What happens if communication between two systems is interrupted? And perhaps most importantly, what happens if someone makes an unauthorized change?

These questions are just as important as knowing which firewall, antivirus or monitoring solution should be deployed. An OT cybersecurity professional therefore needs to understand more than networks and vulnerabilities. They need to understand control loops, interlocks, permissives, alarms, trips, engineering workstations and the operational consequences of taking a system offline.

For example, patching a normal office computer may be a relatively straightforward exercise. Patching a control-system workstation can be very different. The patch may not yet have been validated by the control-system vendor. There may be dependencies with other applications, and the system may only be accessible during a planned maintenance window. Restarting it may simply not be practical while the plant is running.

So the OT question is not simply, “Why isn’t this system patched?” The better question is, “What is the risk, and what is the safest practical way to manage it without creating a bigger operational risk?” That difference is very important.

Don’t Just Copy IT Practices into OT

One of the easiest mistakes organizations can make is to take existing IT cybersecurity policies and apply them directly to OT. The intention is understandable because many organizations already have mature IT policies covering patching, antivirus, password management, access control, backups and vulnerability management. However, the way those controls are implemented in an industrial environment often needs to be different.

Take removable media as an example. From an IT perspective, the easiest policy may be to simply prohibit USB devices. But in an industrial environment, technicians and engineers may genuinely need to transfer configuration files, diagnostic information or software updates to systems that are isolated from the corporate network. The answer should not be to ignore the risk. It should be to control the activity through approved media, malware scanning, sanitization, authorization and traceability.

The same applies to vendor access, patch management and other cybersecurity controls. I have come to strongly believe that practical controls outperform unrealistic policies. A policy that nobody can realistically follow will eventually be bypassed. A practical control that people understand and can follow becomes part of the operation.

This is one of the fundamental differences between simply having an OT cybersecurity policy and having an OT cybersecurity program that actually works.

Start With the Process, Not the Network Diagram

OT cybersecurity discussions often start with architecture diagrams. Where is Level 3? Where is Level 2? Where should the firewall be? How should the DMZ be designed? How should the network be segmented? These are all important questions, but I believe the first question should be much simpler: What are we actually trying to protect?

The starting point should be the process. We need to identify the critical production systems, understand the control systems supporting those processes, identify safety-critical systems and understand how the plant behaves when a particular system becomes unavailable. Only then can we properly understand the cyber risk.

A vulnerability on a system that has no meaningful connection to a critical process may be very different from a vulnerability affecting an engineering workstation that can modify a critical control system. This is why OT asset management should not simply be an exercise in creating an inventory. We need context around the assets. We need to know what they do, what they communicate with, who maintains them and what happens if they fail.

Asset Inventory Is Only the Beginning

Having an asset inventory is important, but I don’t think we should stop there. Imagine finding the following assets in an industrial network: a DCS operator station, a DCS engineering workstation, a safety controller, a PLC, a vibration monitoring system, a historian and a network switch. All of them are assets, but they don’t carry the same operational risk.

A safety controller and a workstation used for engineering configuration should not be treated in exactly the same way as a system that is simply collecting non-critical data. For every critical asset, we should be able to answer some basic questions: What is it? What does it control? What systems does it depend on? Who maintains it? What happens if it becomes unavailable? And how would we recover it?

Those answers are much more useful than simply knowing an IP address and operating system version. Asset visibility should ultimately help the organization make better risk-based decisions.

Backups Are Not the Same as Recovery

Another area where I think industrial organizations need to change their mindset is backups. Many organizations can confidently say, “We have backups.” But I would ask another question: Have you actually restored the system?

A backup that has never been tested is only an assumption of recoverability. In OT, recovery can be particularly complicated because we may need application backups, controller configurations, engineering files, system images and other information required to bring a system back into service.

This is why I see golden backups and tested restoration procedures as an important part of OT cybersecurity. The real question is not whether we have a backup. The real question is whether, if the system is lost today, we can safely restore it.

That is where backup becomes resilience.

OT Cybersecurity Cannot Be Owned by IT Alone

I strongly believe that OT cybersecurity works best when IT, cybersecurity, engineering, maintenance and operations work together. IT and cybersecurity teams bring important expertise in network security, identity management, endpoint protection, threat detection and security architecture. But the I&C and operations teams understand the process.

They know the control philosophy. They understand the interlocks, permissives, alarms and trips. They know which systems can be restarted and which cannot. They know what happens when a particular signal is lost. They understand the difference between a theoretical risk and a risk that can actually affect the plant.

That knowledge is extremely valuable. The strongest OT cybersecurity programs are therefore not built by putting cybersecurity around operations. They are built by integrating cybersecurity into operations.

People Are Still One of Our Most Important Controls

We talk a lot about technology in cybersecurity: firewalls, IDS, EDR, network monitoring, segmentation and vulnerability scanners. But at the end of the day, people are still interacting with the systems. A technician connects a laptop, an engineer changes a configuration, a vendor troubleshoots equipment, a maintenance team uses removable media and an operator responds to an unexpected alarm. Every one of these activities can introduce cyber risk.

This is why OT cybersecurity awareness should not be limited to generic phishing training. The technician needs to understand the risk of uncontrolled USB devices. The engineer needs to understand the consequences of unauthorized configuration changes. The operator needs to understand what unusual system behavior could look like. The supervisor needs to understand why a cybersecurity requirement may sometimes need to be planned around the operating condition of the plant.

People are much more likely to follow cybersecurity practices when they understand why those practices matter to their job. In my experience, awareness becomes much more effective when cybersecurity is connected to the actual equipment and processes people work with every day.

The Real Test Comes During an Outage

I have also found that OT cybersecurity becomes particularly challenging during major maintenance activities and plant turnarounds. During normal operation, the OT environment is relatively stable. During an outage, almost everything changes. There are more people on site, more contractors, more vendor engineers, more laptops, more configuration changes, more temporary connections and more equipment being disconnected, modified and recommissioned.

At the same time, there is always pressure to complete the work within the planned schedule. This is exactly when cybersecurity needs to become more practical, not less. Before the outage, critical configurations should be backed up. During the work, temporary connections and removable media should be controlled. Vendor access should be properly managed. Changes should be documented, and before returning equipment to service, configurations and cybersecurity controls should be verified.

Cybersecurity cannot be a checklist added at the end of a turnaround. It needs to be part of the turnaround plan from the beginning.

Standards Give Us Direction, But They Don’t Run the Plant

Standards such as IEC 62443 provide an excellent foundation for building OT cybersecurity programs. They help organizations establish structure, define security requirements and develop a common language. However, implementing a standard should not become the final objective.

The real test is what happens during an actual incident. Can we detect it? Can we understand its impact on the process? Can we contain it? Can we continue operating safely? Can we recover the affected system? Can we restore the plant to a known-good state? And can we learn from what happened?

Compliance is important, but resilience is the outcome we are actually looking for.

The Goal Is Not Perfect Security

I don’t think any industrial organization can realistically achieve perfect cybersecurity. There will always be legacy systems, vulnerabilities and operational constraints. There will always be situations where security, reliability, safety and production requirements have to be balanced.

The goal should therefore be resilience.

We should know our assets. We should understand our risks. We should protect the systems that matter most. We should detect abnormal activity. We should have a response plan. And most importantly, we should be able to recover.

This requires technology, but it also requires governance, processes and people.

One Simple Question

There is one question I would encourage OT cybersecurity teams to ask when designing any new control:

Would this still work at 3 a.m.?

Imagine that a critical piece of equipment has failed. Production is under pressure. A vendor is on the phone. The maintenance team needs access to a system, and the control engineer needs to troubleshoot the problem. Would the cybersecurity control still work?

If yes, we probably have something practical.

If no, perhaps we need to rethink the control.

This does not mean lowering cybersecurity standards. It means designing cybersecurity around the reality of industrial operations.

From Cybersecurity to Cyber Resilience

For me, this is ultimately what OT cybersecurity is about. It is not about having the most sophisticated security technology. It is not about having the longest cybersecurity policy or achieving a perfect compliance score. It is about protecting people, the process and the ability of the plant to operate safely and reliably.

We need cybersecurity professionals who understand the plant. We need engineers who understand cybersecurity. We need policies that people can actually follow. We need controls that work within operational constraints, and we need recovery strategies that have been tested before we actually need them.

OT cybersecurity should not be an IT project deployed into an industrial environment. It is an operational discipline supported by cybersecurity technology.

The best OT cybersecurity program is not necessarily the one with the most technology. It is the one that provides meaningful protection while allowing the plant to continue doing what it is designed to do.

Because on the plant floor, cybersecurity only succeeds when security and operations succeed together.