The latest warning about Siemens S7 Series PLCs is not just another patching exercise. It is a reminder that a controller connected to the Internet is exposed by design. The practical response is architectural: keep the PLC on the OT network, close the S7comm path, and move the process data users need through a controlled connection.
An active threat, not a theoretical risk
In August 2026, CISA, the NSA, FBI, Department of Energy and Environmental Protection Agency warned of active threats targeting Siemens S7-200, S7-300, S7-400, S7-1200 and S7-1500 controllers, including safety-related models.
Threat actors are using Internet scanning services to find exposed PLCs and AI-assisted scripts built around open-source snap7 libraries. The tools can imitate legitimate monitoring software and provide read/write access to PLC memory, configuration data and ladder logic through S7comm on TCP port 102.
For manufacturers, utilities and other critical-infrastructure operators, the consequences can include production disruption, equipment damage, safety incidents, sensitive-data loss and extended downtime. The advisory recommends firmware and software updates, stronger credentials, monitoring, and PLC hardening. Those actions are necessary. They do not, however, make an Internet-accessible PLC safe.
Exposure cannot be patched away
Patching may address vulnerabilities in software. But it does not remove an exposed service from the Internet, eliminate unauthorized routing, or prevent an attacker from scanning a reachable device. A fully patched PLC that remains accessible through TCP port 102 is still an attractive target.
The first architectural decision is therefore straightforward: PLCs should not be Internet-facing. Perimeter firewalls should block port 102, and network teams should verify that no route allows corporate or external systems to reach the industrial network directly.
That creates a practical challenge. Plants still need to deliver process data to historians, analytics platforms, maintenance systems, cloud services and authorized engineering teams. The answer is not to open new paths to the controller. It is to separate control access from data access.
Tunnel/mirroring keeps the PLCs local and connects the data
A tunnel/mirroring approach can move data securely from the PLC to users outside the plant. A secured tunnel allows a connection to originate inside the OT network and travel outward to a DMZ or controlled IT endpoint. The PLC remains on its protected industrial network, while selected process data is delivered to approved systems outside it.
A tunnel/mirroring approach can move data securely from the PLC to users outside the plant. A secured tunnel allows a connection to originate inside the OT network and travel outward to a DMZ or controlled IT endpoint. Source: Skkynet
With no inbound connection required at the OT firewall, there is no exposed listening service for Internet scanners to discover. A secure tunnel also avoids making a VPN the basic transport mechanism for routine data access. Remote users and enterprise applications receive the information they need without exposing a network route to the PLC.
This is particularly useful in plants with legacy controllers that cannot be replaced quickly or redesigned to support current security features. The controller and its local engineering interface can remain in place while the data boundary is redesigned around a small number of controlled endpoints.
Use the DMZ as a boundary, not a shortcut
The CISA guidance calls for a DMZ separating OT and IT networks, and specifically recommends unidirectional gateways for historian connections where appropriate. A DMZ should not become a collection of forwarded ports and permanent exceptions. It should be a controlled exchange point with defined data paths, authenticated endpoints and no unauthorized routing back into OT.
Secure tunnel/mirroring supports this model by connecting an OT-side endpoint outward to a DMZ endpoint. A second connection can then deliver data from the DMZ to IT or cloud systems. The source data is mirrored at each node, allowing approved clients to access it locally while preserving the network boundary.
This matters when data crosses more than one network hop. If a connection fails, downstream users need to know immediately that the data is no longer current. Silent staleness can be as dangerous as outright data loss when operators or business systems act on an apparently valid value. A good tunnel/mirroring system propagates connection-quality information and maintains data consistency across the chain.
Ideally, the tunnel should be able to accommodate OPC UA, OPC DA, MQTT, Modbus and other industrial data sources in addition to keeping the PLC’s S7comm service within the OT network. The control protocol stays local; the data-access path is managed separately.
When the data must move only one way
Some organizations require historian or analytics data to leave OT while allowing absolutely nothing back in. In that case, a data diode can provide an additional layer of isolation.
Software data-diode operation can discard incoming application data at the source without processing it. Hardware data diodes can block incoming packets entirely. Either approach creates strictly unidirectional flow, so a compromised receiving system cannot send application data back toward the plant.
This does impose limitations. Bidirectional control, acknowledgments and transactional exchanges are not suitable for a one-way link. The architecture must therefore distinguish between data that can safely leave the plant and commands that require a separately controlled, authenticated process.
Architecture complements hardening
Secure tunnel/mirroring such as implemented by Skkynet’s Cogent DataHub software provides a way to build a controlled data path. It does not replace Siemens updates, PLC protection settings, multi-factor authentication or ICS-aware monitoring. It complements those measures by removing direct exposure, keeping inbound firewall ports closed, and maintaining controlled data access through a DMZ or data diode.
For organizations responding to the S7 threat, the sequence is clear: inventory the controllers, apply current patches, block TCP port 102, verify firewall and routing rules, review third-party access, and move required process data through an outbound-only architecture. The goal is simple: Keep the PLCs isolated while allowing the data to flow securely.
