An Internet-Reachable Siemens S7 PLC Is Now an Active-Risk Asset

An internet-reachable Siemens S7 PLC should now be treated as an active-risk asset, although reachability alone is not evidence of compromise. Secure it without disrupting production by verifying the controller and every remote path first, removing unintended exposure, restricting engineering access, testing updates offline and establishing passive monitoring.

Do not begin with an active scan or an untested firmware change. An August 19 multi-agency advisory warns of an active threat to internet-exposed or insufficiently segmented S7-200, S7-300, S7-400, S7-1200 and S7-1500 controllers; its principal mitigations include inventory, applicable patches, internet isolation, access controls and anomaly monitoring.

Establish the inventory without touching the process

Start with evidence that already exists: network diagrams, controller backups, engineering projects, switch tables, firewall rules, remote-access records and maintenance contracts. For each controller, record the CPU family and order number, firmware version, IP address, process served, engineering software, safety relevance, responsible owner and approved maintenance window.

Reconcile those records with passive network observations before sending discovery traffic. Identify the systems that communicate with the controller over TCP port 102, the engineering stations running TIA Portal or STEP 7, and any HMIs, historians or vendor systems that depend on the same route. An undocumented controller or connection is a finding to investigate, not permission to probe a safety-sensitive network aggressively.

Trace access beyond the plant firewall. Check VPN concentrators, jump hosts, cellular routers, cloud-managed gateways and integrator-maintained appliances. Require each integrator to identify its entry point, named users, source addresses, authentication method, access schedule and operational owner; a PLC on a private address can still be reachable through an overly permissive support path.

Remove exposure before changing the controller

Eliminate direct and indirect internet reachability before altering PLC firmware or logic. At the perimeter, deny unsolicited inbound TCP port 102 and confirm that network address translation, port forwarding or a remote-support appliance does not recreate the route. Tenable’s mitigation guidance recommends blocking TCP/102 at the perimeter, checking for unauthorized IT-to-OT routing and including third-party remote paths in the exposure review.

Make firewall and routing changes through the plant’s management-of-change process. Controls engineering should confirm required communications, fail-safe behavior and rollback steps before enforcement. If removing a support route immediately would interrupt production, place it behind an organization-controlled VPN and OT jump host, restrict its sources and destinations, and expire authorization when the approved work ends.

Segmentation must also constrain lateral movement. Place controllers in production-cell zones, permit only documented conduits from required HMIs, engineering stations and support services, and deny general corporate-network access. Validate the boundary from outside the OT zone rather than scanning the controller itself.

Make engineering access explicit and accountable

Limit TIA Portal and STEP 7 access to approved, managed engineering workstations. Each host should have an identified owner, controlled administrative privileges and no routine email or web-browsing role. Firewall rules should permit engineering protocols only from those hosts to the controllers they are authorized to maintain.

Remote engineers and integrators should enter through an organization-controlled service using multi-factor authentication, named individual accounts and time-bounded approval. Log the user, source, destination, connection times and associated work order. Shared accounts and permanent tunnels weaken accountability and preserve access after the maintenance need has ended.

Replace default or weak credentials with strong, unique passwords and enable protection levels supported by the specific CPU and firmware. Store recovery credentials under a controlled operational procedure. Because credential and protection changes can affect engineering workflows, verify during the maintenance window that authorized staff can reconnect and restore the approved project.

Test firmware and engineering updates offline

There is no universal update for every S7 controller. Determine the exact CPU, hardware revision and firmware, then consult the matching ProductCERT advisory and device documentation. The Siemens ProductCERT bulletin, published in July 2025 and updated on August 21, 2026, recommends current device and system versions, disconnection from inadequately secured networks or added firewall protection, and strong unique non-default passwords.

Reproduce the production configuration on a spare controller, test rack or vendor-supported development environment. Check communications with the relevant HMI, distributed I/O, drives, safety functions and engineering software, along with startup behavior and restoration of a known-good project. Document the firmware file, integrity verification, prerequisites, expected downtime, backup, rollback method and approvers.

Schedule the production update only after controls engineering, operations and the integrator accept the test result. If no compatible update is available or an outage has not been approved, retain restrictive segmentation and increase monitoring. Compensating controls reduce exposure but do not change the underlying firmware state.

Monitor passively before active assessment

Observe control traffic from a switch mirror port, network tap or another point that does not sit inline. Establish which engineering hosts normally initiate S7comm sessions, when authorized changes occur and which operations are expected. This baseline can expose an unexplained connection without adding traffic to the PLC.

Alert on TCP/102 scanning, repeated connection attempts, S7comm sessions from unapproved hosts, unexpected PUT/GET or other write activity, and configuration changes outside maintenance windows. A single alert is not proof of compromise; evaluate it against the approved engineering inventory, access logs and work schedule.

If monitoring reveals unexplained writes or engineering access, preserve available logs and controller evidence, involve operations and incident response, and use the site’s tested isolation procedure. Do not power-cycle the controller, upload a project or run an intrusive scan merely to confirm suspicion. The production-safe order is verification, controlled containment, authorized access, tested remediation and continuous observation.

Also read:

• 31% of Breaches Start With Software Flaws—Asset Risk Must Catch Up
• IoMT Is Delivering Care Now—but Every New Connection Expands the Risk
• How to Get Internet Access in China Without Roaming Fees