Is it safe to expose S7comm to the internet?

Why Internet Exposure Changes the Risk Profile

S7comm is designed for controlled industrial environments, not for direct public reachability. Once it is exposed to the internet, the protocol no longer sits behind the trust assumptions of an OT zone, which means unauthorised discovery, probing, and command traffic become far more likely. That exposure is especially dangerous because PLC communications often support real operational processes, not just information exchange.

When you think about exposure, the main issue is not whether an attacker already knows your asset inventory. Internet scanning routinely finds exposed industrial services, and once a protocol like S7comm is visible, it can be targeted for reconnaissance, manipulation, or disruption. The safer default is to treat any public exposure as an exception that needs a strong business and technical justification.

How to Reduce Exposure Without Breaking Operations

The first control is architectural: keep S7comm inside segmented OT networks and avoid direct internet routing to controllers. Where remote engineering is required, place access behind controlled remote access paths and restrict who can reach the protocol, when they can reach it, and from which approved source systems. A practical design uses network segmentation, allowlisting, and tightly governed jump paths rather than broad inbound access.

For environments that need third-party or vendor support, the important distinction is between access to a managed session and exposure of the protocol itself. The protocol should remain reachable only through approved engineering paths, ideally with strong authentication, session control, and monitoring around the access broker. If the only way to make remote work function is to publish S7comm directly, the design is already too permissive.

For OT teams building a broader control baseline, the OT Security Guide is the best starting point because it ties segmentation, industrial DMZs, and protocol-specific exposure into one operating model.

What Monitoring Should Look for on Exposed Industrial Protocol Paths

Monitoring matters because internet exposure often turns an otherwise quiet protocol into a source of weak signals that are easy to miss. Watch for S7 traffic from outside approved engineering workstations, unusual source geographies, repeated connection attempts, and command patterns that do not match maintenance windows or normal plant activity. That visibility helps distinguish legitimate remote operations from reconnaissance and active tampering.

You should also monitor for changes in who is talking to the PLC, not just whether the PLC is still online. A lot of industrial compromise starts with discovery and low-and-slow interaction, so the absence of obvious disruption is not reassurance. If a public-facing path exists at all, treat it as a high-value detection surface and review logs for unexpected sessions, failed access attempts, and abnormal engineering access behaviour.

Risk and Threat Considerations

Public exposure increases the chance that S7comm will be scanned, fingerprinted, and abused by unauthorised parties. In an OT environment, that can shift a simple exposure issue into a process-safety issue because controller communications may influence real-world equipment behaviour, not just data availability.

Failure mechanism: Internet access bypasses the segmentation and trust boundaries that normally contain industrial traffic, allowing attackers to discover reachable PLCs, attempt unauthorised commands, or interfere with controller communications.

Impact: The likely consequences include unauthorised manipulation, disrupted operations, loss of view, and in severe cases process instability or safety impact if controller interactions are altered at the wrong time.

Practitioner Guidance

What to verify: Confirm that no public IP, NAT rule, VPN exception, or firewall path exposes S7comm directly. Check both the network edge and any remote access tooling, because exposure often appears through a forgotten rule rather than an intentional design choice.

Decision rule: If remote access is needed, allow the engineer to reach a controlled access point, not the PLC protocol itself. If you cannot explain which asset is allowed to talk S7comm, from where, and for what purpose, the access model is too broad.

Practitioner takeaway: The safe pattern is to broker access to the plant, not publish the control protocol to the internet; once S7comm is internet-reachable, the risk becomes both cyber and operational.

Related resources from NHI Mgmt Group

• How do security teams know whether an email driven attachment workflow is safe enough to expose to the internet?
• Is it safe to expose Port 53 for DNS to the internet?
• Is it safe to expose Port 135 (RPC) to the internet?
• Is it safe to expose port 27017 for MongoDB to the internet?