Why are OPC-UA and Modbus vulnerable to cyberattacks?
Modbus has no native authentication or encryption. Every command travels in plaintext, and any device on the network can send instructions to any PLC. OPC-UA offers security features like certificate-based authentication and message encryption, but these are rarely implemented correctly in production environments. Both protocols run on equipment that cannot install security agents, which makes inline isolation the most practical method to protect them.
Every factory that connects PLCs, HMIs or SCADA systems to a corporate network opens a path that attackers can follow from a phishing email straight to a production line. OPC-UA and Modbus are the two most widely used industrial protocols, and both were designed in an era when cybersecurity was not a consideration. The devices that speak these protocols run for decades, cannot be patched easily, and sit on networks that are increasingly connected to IT infrastructure. This guide breaks down where each protocol falls short, how attackers exploit the gap between IT and OT, and how inline isolation protects production without requiring software on any industrial device.
What OPC-UA is and where its security falls short
OPC-UA (Open Platform Communications Unified Architecture) is the standard for interoperability in industrial automation. It replaces the older, Windows-dependent OPC Classic with a platform-independent framework that models data as objects in an address space. Two communication models dominate: client-server, where an HMI connects to a PLC to read or write data, and publish-subscribe (PubSub), where a publisher pushes data to multiple subscribers simultaneously.
The protocol was designed with security built in. Application-level authentication uses X.509 certificates. Transport-level security signs and encrypts messages using AES and RSA. User authentication supports tokens, Kerberos and certificates. Access control lists determine which actions a user can perform on specific nodes.
That sounds solid on paper. In practice, three problems undermine it.
First, the specification spans 14 parts and is extraordinarily complex. Different vendors implement it differently, and inconsistencies between implementations create exploitable gaps. The German Federal Office for Information Security (BSI) analysed OPC-UA version 1.04 and found that the “SecurityPolicy: None” setting, intended for testing, is frequently left active in production to avoid compatibility issues or performance overhead.
Second, the specification does not enforce password strength. Brute-force attacks against user accounts remain viable in environments where default or weak credentials persist.
Third, the complexity of the stack itself produces vulnerabilities. Between 2022 and 2026, research teams from Claroty and Kaspersky have documented critical flaws in OPC-UA implementations from major vendors. These include denial-of-service attacks through malformed certificate chains and chunk flooding, memory corruption via malformed UTF-8 processing, and resource exhaustion from excessive secure channel requests. Each vulnerability reinforces the same conclusion: native security only works when implementation is flawless and configuration is strict. On a factory floor with legacy firmware and limited OT security expertise, that assumption rarely holds.
Why Modbus was never designed to be secure
Modbus is the oldest and most widely deployed industrial protocol. Its popularity comes from its simplicity: the protocol reads and writes registers (16-bit values) and coils (1-bit values). Nothing more. That simplicity is also its biggest weakness.
The protocol exists in three main variants. Modbus RTU communicates over serial connections (RS-485 or RS-232) using slave IDs. Modbus ASCII is a less efficient serial variant using readable characters. Modbus TCP/IP wraps Modbus frames in TCP packets over port 502 and is the variant most commonly exposed to network-based attacks.
None of these variants include any form of security. No authentication verifies whether a command comes from an authorised SCADA system or an attacker’s laptop. No encryption protects data in transit, so process values and control commands travel in plaintext. Attackers can abuse standard function codes to write registers, change setpoints, stop motors or open valves. And because Modbus has no session tracking or timestamps, legitimate commands can be recorded and replayed at will.
In 2018, the Modbus Organization introduced Modbus/TCP Security, which wraps traffic in a TLS tunnel for mutual authentication and encryption. Adoption in 2026 remains minimal. Many PLCs and RTUs run on 8-bit microcontrollers with kilobytes of memory, physically incapable of handling TLS cryptographic operations. The latency that TLS adds is unacceptable in real-time processes where milliseconds matter. And managing thousands of digital certificates across a factory floor without reliable internet connectivity is a logistical challenge most OT teams are not equipped to handle.
The result: Modbus devices sold today still default to the unencrypted variant for backward compatibility.
How attackers exploit the IT-OT bridge
The attack path is consistent across incidents. It starts in the IT network, not on the factory floor.
An attacker gains initial access through phishing, credential theft or a vulnerable public-facing system. From there, they move laterally through the IT environment until they reach a system that bridges IT and OT. This might be an engineering workstation with dual network connections, a poorly configured firewall, or a vendor VPN that grants broad access to the production network. Once inside the OT segment, the lack of authentication in Modbus and the frequent misconfiguration of OPC-UA make protocol manipulation straightforward.
Industry data supports this pattern. Dragos reported that more than 75% of OT incidents originate in the IT network, with lateral movement as the primary technique. The average dwell time in OT environments, the period an attacker remains undetected, sits around 42 days. That gives adversaries weeks to map processes, identify critical controllers, and plan their attack.
Europe has become a primary target for operationally motivated attacks. Groups like ELECTRUM have conducted destructive operations against energy infrastructure in Ukraine and Poland, targeting heat and renewable energy systems. Water utilities across multiple European countries have reported intrusions through internet-exposed HMIs using default credentials or known Modbus exploits. The shift from espionage to active disruption means the consequences of an OT breach are no longer limited to data theft. They extend to physical damage, production loss and public safety.
Understanding how these attack paths work in practice is covered in more depth in our IT-OT convergence guide, which walks through three specific scenarios and the controls that stop each one.
Current approaches and why they fall short
Most organisations rely on one or more of these methods to protect industrial networks. Each addresses part of the problem.
| Approach | What it does | Limitation |
|---|---|---|
| VLAN segmentation | Separates networks into zones | Flat within segments, no protocol inspection, no device-level control |
| Industrial firewall (DPI) | Filters OT traffic at the command level | Expensive per site, complex rule management, adds latency, bypass hardware needed for failover |
| OT monitoring (Claroty, Nozomi, Dragos) | Detects anomalies via passive network tap | Reactive only, cannot prevent an attack in progress |
| Data diodes | Enforces one-way traffic flow | Blocks legitimate bidirectional communication needed for many OT workflows |
| Jump servers | Provides a controlled access point to OT | Single point of failure, no per-device isolation, broad access once connected |
The gap is clear. VLAN segmentation and firewalls operate at the network level but cannot enforce per-device policies. OT monitoring tools provide visibility but not prevention. Data diodes are too restrictive for environments that need bidirectional communication. Jump servers concentrate risk rather than distributing control.
What is missing is an approach that combines prevention with per-device granularity, works without agents on the endpoint, and fits into a broader security architecture rather than standing alone. For context on why network segmentation alone falls short in 2026, the linked guide covers the evolution from VLANs to identity-based isolation.
How inline isolation protects without agents
Inline isolation takes a fundamentally different approach. Instead of trying to identify malicious traffic in a stream of allowed communication, it starts from zero trust: nothing passes unless explicitly permitted.
Jimber’s NIAC (Network Isolation Access Controller) hardware sits physically between the OT device and the network switch. It does not require any software on the PLC, HMI or sensor. The appliance inspects and controls all traffic passing through it based on explicit allow rules. A PLC that needs to communicate with a specific MES server gets a policy permitting exactly that path. All other communication is blocked by default.
Think of it as a lock system on a canal. Traffic flows only through defined channels, in defined directions, to defined destinations. Everything else hits a closed gate.
The NIAC identifies devices through traffic fingerprinting based on MAC address, communication patterns and deep packet inspection signatures. It learns normal behaviour in monitoring mode before switching to enforcement. This phased approach means production is never interrupted during deployment. A typical mid-market production floor with 20 to 50 critical devices can be fully covered in days, not months.
Because NIAC is part of Jimber’s unified SASE platform, the same console that manages ZTNA for office workers and SWG policies for web traffic also manages isolation policies for factory devices. IT and OT security live in one place. This is the IT-OT bridge in practice: not a standalone OT security product, but an extension of the same Zero Trust architecture that already protects your IT environment.
For manufacturing environments specifically, the linked guide covers deployment patterns for PLCs, HMIs and production lines in detail.
IEC 62443 and NIS2: what compliance expects
Two regulatory frameworks shape how European manufacturers must approach industrial protocol security.
IEC 62443 defines a zone-and-conduit model for industrial automation security. Assets are grouped into security zones, and all communication between zones flows through controlled conduits. While not legally mandatory in Belgium, the CyberFundamentals (CyFun) framework references IEC 62443 principles, and manufacturers in regulated sectors like pharma, food and energy commonly use it as their baseline.
NIS2 is legally binding. The Belgian transposition requires essential entities to implement proportionate technical measures for risk management, report significant incidents to the CCB within 24 hours, and accept board-level liability for non-compliance. The CyFun framework translates these obligations into concrete controls.
Several CyFun controls map directly to the protection that inline isolation provides:
| CyFun control | Relevance for OPC-UA / Modbus | How NIAC addresses it |
|---|---|---|
| AC-3.2 Access control | Restricting who can send commands to industrial devices | Only authorised systems can reach the PLC through the NIAC boundary |
| PR.AC-4 Network security | Isolating critical segments per IEC 62443 | Hardware-level barrier between IT and OT, per-device enforcement |
| SC-7 Boundary protection | Controlling traffic at the IT-OT boundary | NIAC acts as the inline gatekeeper for all cross-boundary data exchange |
Essential entities must submit their first CyFun self-assessment at Basic or Important level by April 2026. For many production companies, deploying an IT-OT bridge is the fastest path to meeting segmentation and access control requirements without redesigning the existing network. The device posture checks guide covers how posture verification maps to additional CyFun controls for managed endpoints.
Jimber’s centralised logging covers the NIS2 audit trail for OT access. Every connection attempt, every policy decision, every blocked communication is recorded in the same console that handles IT security events. When auditors ask for evidence that your microsegmentation controls extend to industrial devices, you can demonstrate it from a single interface.
Frequently asked questions
Can you secure Modbus without replacing the PLCs?
Yes. Inline isolation works at the network level, between the PLC and the switch. The PLC does not need new firmware, new software or any modification. The NIAC appliance enforces communication rules externally, so the PLC continues operating exactly as before. Only the traffic it can send and receive changes.
Does inline isolation add latency to production traffic?
The latency added by NIAC hardware is measured in microseconds, not milliseconds. For the vast majority of industrial processes, including those using Modbus RTU/TCP and OPC-UA, this is undetectable. Real-time processes with sub-millisecond requirements should be tested during the monitoring phase before enforcement is activated.
How does inline isolation differ from a firewall?
A firewall inspects traffic passing through it and attempts to identify malicious patterns. It requires complex rule sets, introduces measurable latency during deep packet inspection, and fails open or closed depending on configuration. Inline isolation starts from a default-deny posture. No traffic passes unless a specific allow rule exists. It operates per device rather than per segment, and it does not require rule sets that grow with every new application or protocol.
Which industrial protocols does inline isolation support?
NIAC operates at the network level and is protocol-agnostic in its enforcement model. It controls which devices can communicate with which destinations, regardless of whether the traffic uses Modbus TCP, OPC-UA, BACnet, PROFINET, EtherNet/IP or proprietary protocols. Protocol-specific policies can be layered on top of the network-level isolation.
Do I need OT monitoring AND inline isolation?
They serve different purposes. OT monitoring tools like Claroty, Nozomi or Dragos provide visibility into what is happening on the network and detect anomalies. Inline isolation prevents unauthorised communication from happening in the first place. Monitoring tells you something unusual occurred. Isolation ensures it cannot reach a critical device. The strongest posture combines both: prevention through isolation, detection through monitoring.
How does this fit into a broader SASE architecture?
NIAC is a component of Jimber’s SASE platform. The same management console that handles ZTNA, SWG, FWaaS and SD-WAN also manages NIAC policies. This means IT teams do not need a separate tool, separate training or separate reporting for OT security. Factory devices appear alongside office devices in a single policy engine, with unified logging for compliance.
Ready to extend Zero Trust to the factory floor without agents, downtime or a network redesign? Book a demo and walk through how NIAC fits your production environment.
