The Most Dangerous Myths in OT Cyber Security

If you spend any amount of time around operational technology environments, you start to hear the same things repeatedly. They’re said with confidence, usually with good intent, and often by people who are genuinely trying to do the right thing. The problem is that many of these statements aren’t quite true, or they’re only true in very specific circumstances, and over time they’ve been stretched into almost fact, facts that people stop questioning. That’s where a lot of trouble starts. 

OT cyber security has a habit of overly simplifying complex, highly contextual environments into similar narratives. Those narratives then get reused across industries, sites, and architectures that look nothing alike. Eventually, they turn into myths. 

Below are some of the things we at Cyro Cyber hear in real conversations, during engagements, and in design discussions, and while they’re often said casually, they have very real consequences for how environments are treated, managed, secured, how risk is measured, recorded, and how decisions get justified.

Why do these myths exist in the first place? 

OT environments are by their nature, complex. They span decades of technology use and change, involve safety-critical processes, and sit at the intersection of engineering, operations, and IT. Most people involved in them are rightly cautious about change, because getting it wrong can have serious outcomes to the public, often failing to deliver the core services the organisation exists to deliver.  

In that context, simplified rules feel useful. They reduce uncertainty and give people something concrete to hold onto. The issue is that many of these rules were never meant to be universal. Some were based on how systems looked twenty or thirty years ago. Others were always shorthand, but over time the nuance got lost. 

Once that happens, the statements stop being prompts for discussion and start being used to shut conversations down, and that’s when they become dangerous.

Myth 1:“OT, ICS, SCADA, DCS - it’s all the same thing” 

One of the most common problems we see is basic terminology being used loosely or interchangeably. OT, ICS, SCADA, and DCS are often treated as synonyms for “not IT”, which feels convenient but quickly becomes unhelpful. 

These terms refer to different layers and different types of architecture. SCADA systems tend to be geographically dispersed, with wide area communications and very different latency and resilience considerations. DCS environments are usually process driven and confined to a single facility. ICS is a broader category, and OT, broader still. 

When people aren’t precise about what they’re talking about, they often end up talking past each other. One person has a SCADA pipeline in mind, another is thinking about a refinery, and both are using the word “OT”. From a security perspective, that leads to design decisions that don’t quite fit the environment they’re being applied to. 

Being specific about terminology goes beyond being pedantic, and it’s imperative to get it right if you want to understand your risks properly. 

The truth: These terms describe distinct architectures with unique risk profiles. Treating them as synonyms leads to security designs that fail to fit the physical reality. 

Myth 2: “OT is completely different from IT” 

There’s a long-standing idea that OT environments are fundamentally alien, made up of mysterious systems that have nothing in common with corporate IT. At the very lowest levels, that can be true. PLCs, sensors, and actuators are specialised devices with very particular behaviours. But once you move up the stack, things are different. Engineering workstations, HMIs and management systems are frequently just standard servers and desktops running common operating systems and databases. Many of them would look perfectly at home in an office environment. 

The mistake comes when people think “OT is different” and apply it indiscriminately. That can lead to environments where basic protections are avoided because of an assumption that they must be inappropriate. In reality, a lot of the same weaknesses that exist in IT also exist in OT, simply in a different context. Therefore, understanding where IT thinking applies, and where it doesn’t, is far more useful than treating the entire environment as untouchable. 

Truth: While the physical layer is unique, the management layer relies on standard hardware and operating systems that inherit the same vulnerabilities found in corporate IT. 

Myth 3: “IT/OT convergence is something new” 

IT/OT convergence is often spoken about as though it’s just starting to happen, or as though organisations can choose when to deal with it. This is simply not true. 

The moment control systems were connected to Ethernet networks and started using TCP/IP, convergence happened. That was decades ago. Many OT environments have been running on standard networking protocols for longer than some of the people now responsible for securing them. 

What organisations are actually dealing with today is the accumulated technical debt from that early convergence, when connectivity was added for operational reasons and security simply wasn’t part of the conversation. Hence, calling this a new trend makes it feel optional. In practice, the exposure already exists, whether it’s being actively managed or not. 

The truth: Convergence happened decades ago when control systems adopted TCP/IP. Today’s challenge is managing the accumulated technical debt of those early connections. 

Myth 4: “We’re air-gapped, so external threats don’t apply” 

Air gaps come up constantly, and almost never mean what people think they mean. A true air gap requires complete isolation - no inbound connectivity, no data transfers, no updates, no removable media, no remote support. Maintaining that over time is extremely difficult, and for many organisations it would actively get in the way of operational efficiently. 

In most environments, data moves in and out in ways that don’t get counted as “connections”. Vendor remote access, laptops, USB devices, telemetry data feeding corporate systems… all of these create pathways. Saying an environment is air-gapped while relying on those mechanisms is contradictory, even if it feels intuitive. History has already shown how fragile this assumption is. An air gap doesn’t remove risk… it just changes how an attacker has to approach the problem. 

The truth: True air gaps are virtually non-existent. Data transfer via vendors, USBs, and maintenance gateways creates pathways for attackers regardless of network isolation. 

Myth 5: “In OT, availability always comes first” 

Another idea that gets repeated a lot is that OT security priorities can be reduced to availability above all else. While availability is often critical, treating it as universally dominant misses some important realities. 

In many environments, integrity failures are safety incidents. Incorrect sensor data can be far more dangerous than a system being unavailable. In others, confidentiality matters enormously. Pharmaceutical processes, gas, hydrogen, and nuclear environments all involve information that would cause serious harm if exposed. 

Risk priorities depend entirely on context. Industry, process, safety implications, and regulatory exposure all matter. Simplifying that into a single rule makes conversations easier, but it doesn’t make decisions better. 

The truth: Risk is contextual - in many environments, data integrity (safety) or confidentiality (IP) are just as critical as system uptime. 

Myth 6: “You can’t test or interact with OT networks” 

There’s a persistent fear that OT networks are so fragile that any interaction will cause systems to fail. That belief often comes from older technologies and from very real incidents in the past, but it doesn’t reflect how most modern environments operate today. 

OT networks do need to be treated carefully, and they can’t be approached in the same way as corporate IT, but that doesn’t mean assessment is impossible. It just means it must be deliberate, protocol aware, and carried out by people who understand the environment they’re working in. Saying “testing” can’t be done at all often ends up being a convenient way to avoid finding out what the real issues are. 

The truth: Passive analysis and protocol aware testing allow for safe assessment. Avoiding them simply leaves vulnerabilities undiscovered. 

Myth 7: “Security tools don’t belong in OT” 

Similar thinking shows up around endpoint protection and patching. Many people remember a time when antivirus caused performance issues or wasn’t supported by vendors, but in 2026 the landscape has moved on. Major OT vendors now validate and support security tooling on their platforms, and the threat environment has changed significantly. Ransomware doesn’t care whether a Windows system is in an office or on a plant floor.  

The truth: Modern tooling is built to be OT-aware, ensuring you can detect threats without disrupting the process. 

So… what now? 

These myths are common for a reason - because OT environments are hard, and because simplifying them feels like a way to reduce risk. Unfortunately, in our experience, those simplifications often end up doing the opposite. 

Good OT security starts with being precise, honest about trade-offs, and willing to challenge assumptions that no longer hold. That takes more effort than repeating familiar phrases, but it leads to decisions that reflect how environments operate today. 

As part of our OT Series, in the articles that follow, we’ll take each of these myths on directly and unpack what’s really going on beneath them, drawing on real experience from CNI, IT, and OT environments.  

In the meantime, if any of these myths sound familiar in your environment, get in touch with us at Cyro. We can help you look at your OT networks, identify where assumptions are putting you at risk, and work out practical steps to secure your systems without unnecessary downtime. 

Enquire Now

One of our experts will be in touch shortly to better understand your requirements and challenges.