Remote access to a Siemens S7, Schneider Electric Modicon, or Rockwell Allen-Bradley PLC has become essential for diagnosing a malfunction, adjusting a program, assisting a customer, or maintaining a production line. However, poorly designed remote access can also become a direct gateway into the OT network. The goal, therefore, is not simply to “connect to the PLC,” but to provide temporary, authenticated, segmented, logged, and controllable access managed by the industrial site.
The Problem of Remote Access to PLCs
In many industrial environments, remote access to PLCs has been added over time, one machine at a time, often in response to a maintenance emergency. The result is rarely consistent: a manufacturer-provided 4G modem, a local VPN router, an exposed RDP session, a shared account, a monitoring workstation used as a relay, or permanent access left active “just in case.”
These practices pose several major risks.
-
RDP, VNC, or VPN configurations exposed to the Internet are prime targets for ransomware campaigns targeting industrial sites.
-
Machine manufacturers sometimes maintain their own 3G, 4G, or 5G connections for each piece of equipment, which entails recurring costs and limited oversight by the operator.
-
Access rights are rarely managed by technical staff: a shared password is passed around among automation engineers, integrators, subcontractors, and internal teams.
-
Traceability is insufficient: in the event of an incident, it becomes difficult to prove who logged in, when, on which machine, and for how long.
-
The IT/OT separation is compromised when remote access allows users to access more resources than necessary.
-
Production teams often lack real-time visibility into active connections.
Secure industrial remote access must address these issues without disrupting the business tools already in use: TIA Portal, STEP 7, EcoStruxure Control Expert, Unity Pro, Studio 5000 Logix Designer, FactoryTalk, OPC UA clients, network diagnostic tools, or embedded web interfaces.
Why a Standard VPN Isn’t Always Enough
A traditional enterprise VPN is often designed to connect a user to the information system. In an OT context, the challenge is different: access must be granted to a specific area, for a limited period of time, with strict rules regarding authorized devices, protocols, and users.
A VPN that is too broad can grant access to entire subnets, even though the technician only needs a PLC, an HMI, and a monitoring server. This model increases the attack surface and complicates post-incident investigations.
| Approach | Advantage | Limitations in an OT environment |
|---|---|---|
| RDP to a local workstation | Easy to set up | High risk if exposed, dependence on the workstation, poor traceability |
| 4G modem per machine | Independent of the client network | Scattered access points, multiple costs, difficult to monitor |
| General-purpose corporate VPN | Centralized IT management | Access often too broad for OT |
| Dedicated industrial gateway | Fine-grained segmentation, logs, local control | Requires a dedicated architecture from the start |
The proper approach is to set up a controlled gateway between the remote user and the industrial network, and then apply the principle of least privilege.
Recommended Architecture for Secure PLC Access
A robust architecture is based on three clearly separated zones: the remote user, the secure access zone, and the OT network. The gateway should not be merely a transparent tunnel; it must enforce access rules, generate logs, and allow the site to maintain control over connections.
This separation makes it possible to balance remote maintenance with industrial cybersecurity requirements. The technician works with their usual tools, but can only see resources that have been explicitly authorized.
Typical Use Cases
Remote access to PLCs applies to several operational scenarios, each with its own constraints.
Maintenance of a Siemens S7 PLC
For the Siemens S7-1200 and S7-1500, automation engineers generally use TIA Portal. Access may be required to download a program, view function blocks, diagnose a CPU, analyze an I/O module, or monitor PROFINET communication.
Traffic should be limited to the relevant PLCs and only the workstations that are strictly necessary. It is recommended not to open up the entire industrial VLAN if only one CPU needs to be accessed.
Examples of resources to authorize as needed:
-
Siemens S7-1200 or S7-1500 CPU.
-
Siemens Comfort Panel or Unified Panel HMI.
-
Local engineering server, only if the project cannot be opened from the remote workstation.
-
Network diagnostic IP address, if PROFINET analysis is required.
Service on the Schneider M340 or M580
Schneider Modicon M340 and M580 PLCs are often maintained using EcoStruxure Control Expert or Unity Pro in older installations. Remote access can be used to read a PLC’s status, diagnose redundancy, verify Modbus/TCP communication, or adjust process logic.
The key point is to distinguish between access to the PLC and access to the rest of the industrial network. A service provider working on one line must not access equipment on another line without explicit authorization.
Allen-Bradley ControlLogix or CompactLogix Diagnostics
Within the Rockwell Automation ecosystem, maintenance tasks are often performed using Studio 5000 Logix Designer, RSLinx Classic, FactoryTalk, or EtherNet/IP diagnostic tools. Architectures may include ControlLogix and CompactLogix controllers, PanelView panels, PowerFlex drives, and remote I/O modules.
Remote access must take into account the network discovery used by certain tools. Whenever possible, it is better to configure explicit access paths to devices rather than allowing overly broad discovery.
Our Approach
The Eziwan approach involves replacing scattered access points with a single, managed, and monitored gateway. This gateway covers the OT network of the site or a specific industrial zone, depending on the chosen segmentation.
-
Replacing proprietary 4G modems with a single piece of equipment: a single Eziwan gateway can support multiple PLCs, HMIs, and industrial devices.
-
Secure connections: Access is routed through an encrypted VPN tunnel, with strong authentication and user-specific permissions.
-
Role-based control: A Siemens automation engineer, a Schneider systems integrator, and a Rockwell service provider may have different scopes of responsibility.
-
Evidence in the event of a dispute: Sessions are logged with timestamped logs, which are useful for auditing, incident analysis, and internal compliance.
-
Connection notifications: The site manager can be notified when a technician or contractor connects to a PLC.
-
Reduced attack surface: No RDP or automation services need to be directly exposed to the Internet.
This approach integrates naturally with an industrial connectivity strategy and can leverage centralized monitoring in the Eziwan cloud, without turning the OT network into an open extension of the IS.
The Principle of Least Privilege Applied to the WTO
The principle of least privilege is simple to state: a user should have access only to the resources they need, when they need them, with the necessary level of access. In OT, this principle must be translated into concrete rules.
| Item to Check | Best Practice | Example |
|---|---|---|
| User | Named account | prenom.nom@entreprise.fr |
| Duration | Time-limited session | Access authorized during a scheduled intervention |
| Network scope | Restricted IP or subnet | Access to 192.168.10.20 only |
| Protocol | Strictly necessary ports | PLC engineering, HTTPS HMI, OPC UA if required |
| Validation | Local approval or internal procedure | Access granted by the maintenance manager |
| Logging | Centralized logs | Time, user, destination, duration |
This level of granularity avoids the pitfall of a “universal VPN,” which works from a technical standpoint but exposes the industrial network too broadly.
Sample Access Policy
An access policy can be described in simple terms before being implemented in the gateway. The key is to link each permission to a real-world use case.
profils:
automaticien_siemens:
utilisateurs:
- technicien.siemens@example.com
ressources:
- nom: CPU_S7_1500_Ligne_1
ip: 192.168.10.20
protocoles:
- tia_portal
- nom: IHM_Ligne_1
ip: 192.168.10.30
protocoles:
- https
duree_session: 4h
journalisation: obligatoire
prestataire_schneider:
utilisateurs:
- support.machine@example.com
ressources:
- nom: M580_Process
ip: 192.168.20.15
protocoles:
- control_expert
- modbus_tcp
validation_site: obligatoire
journalisation: obligatoire
This type of model makes access rights understandable to IT, OT, and maintenance teams. It avoids implicit rules that are difficult to audit.
Workflow for a Remote Maintenance Session
A secure session must follow a clear cycle: request, authentication, connection, operation, logging, and termination. This cycle is just as important as tunnel encryption.
This approach provides the site with an operational overview: who is involved, what they are working on, and for how long.
IT/OT Segmentation: The Critical Control Point
IT/OT segmentation is one of the cornerstones of industrial cybersecurity. It limits the spread of an incident between the information system and the production environment.
Secure remote access to a PLC must comply with this segmentation.
-
The VPN tunnel must not create a general route to the entire OT network.
-
Traffic must be filtered by destination, protocol, and user.
-
Vendor access must be separate from internal access.
-
Connections must be able to be revoked quickly.
-
Logs must be stored in a location that cannot be modified by the remote user.
This approach is consistent with the best practices for defense in depth recommended in industrial cybersecurity standards, particularly the ANSSI guidelines and the principles of the IEC 62443 standard. While not intended to replace a comprehensive risk analysis, it provides a practical foundation for reducing exposure.
Industrial Protocols and Points to Consider
PLC engineering tools rely on different protocols depending on the brand and generation of equipment. Therefore, overly generic rules should be avoided.
| Ecosystem | Common Tools | Points to Consider |
|---|---|---|
| Siemens S7 | TIA Portal, STEP 7 | Routing to CPU, HMI, PROFINET diagnostics |
| Schneider Electric | Control Expert, Unity Pro | Modicon M340/M580 access, Modbus/TCP, redundancy |
| Rockwell Automation | Studio 5000, RSLinx, FactoryTalk | EtherNet/IP paths, network discovery, PanelView |
| Monitoring | SCADA, OPC UA, web interfaces | Application ports, certificates, application accounts |
| Network | Ping, SNMP, targeted scan | Allow only necessary diagnostics |
Automatic discovery flows can be convenient, but they can also unnecessarily broaden access. Whenever possible, use fixed IP addresses, explicit paths, and documented rules.
Audit Logs: What to Log
Logging is essential for operations, security, and as evidence in the event of a dispute. A useful log is not limited to “connection successful.”
A good access log should contain at least the following:
-
The user’s name.
-
The company or the associated role.
-
The start and end times of the session.
-
The source IP address and the OT resource accessed.
-
The access rules that apply.
-
Notifications sent to the site.
-
Connection errors or failed attempts.
-
The ticket ID or service request ID, if the organization uses one.
The goal is not to monitor the business logic of each automation action, but to have reliable proof of the login context.
Common Mistakes to Avoid
Certain errors occur frequently in OT remote access projects.
Exposing a Windows Workstation via RDP
A Windows workstation used as a relay may seem convenient. But if it is directly exposed or poorly protected, it becomes an obvious target. Even when protected by a VPN, you still need to manage updates, local accounts, administrator privileges, logs, and the risks of relaying traffic to other areas.
Sharing a VPN Account Among Multiple Technicians
A shared account undermines traceability. It becomes impossible to determine who performed a task. In the event of a PLC program error, an unauthorized modification, or a contractual dispute, this lack of specific attribution is a real problem.
Keep Access Points Open at All Times
Permanent access increases the risk of misuse or compromise. Access should be granted only for a specific task and then revoked. When permanent access is justified, it must be offset by stricter rules, enhanced monitoring, and regular reviews.
Allow the Entire OT Subnet
Allowing 192.168.0.0/16 or an entire VLAN is rarely necessary for a targeted intervention. The rule should be based on the specific need: which PLC, which HMI, which server, which protocol, and for how long.
Best Practices for Deployment
A project for secure PLC remote access is being developed in collaboration with the maintenance, automation, IT, and cybersecurity teams. Technology alone is not enough if the operational model remains unclear.
-
Map the relevant PLCs, HMIs, drives, SCADA servers, and network equipment.
-
Categorize access by profile: in-house automation engineer, machine manufacturer, system integrator, software vendor support, and multi-site maintenance.
-
Define rules on a per-resource basis rather than for the entire network.
-
Set up multi-factor authentication for remote accounts.
-
Establish a documented emergency procedure with a limited duration and retroactive approval if necessary.
-
Test actual industry tools: TIA Portal, Control Expert, Studio 5000, web clients, and monitoring systems.
-
Verify that the logs are usable by the relevant teams.
-
Periodically review vendor accounts and delete those that are no longer needed.
Sample Pre-Launch Checklist
Before granting remote access to the PLCs, a simple validation process helps prevent blind spots.
| Check | Item to Verify | Expected Status |
|---|---|---|
| Identity | Does each technician have a personal account? | Required |
| MFA | Is strong authentication enabled? | Required |
| Scope | Are authorized IP addresses documented? | Required |
| Duration | Are sessions time-limited? | Recommended |
| Logs | Are connections time-stamped? | Required |
| Notification | Is the site notified of logins? | Recommended |
| Revocation | Can access be revoked quickly? | Required |
| Business Test | Do the automation tools actually work? | Required |
This checklist should be tailored to the site’s level of criticality, but it provides a practical starting point.
Integration with an Industrial Zero-Trust Strategy
Applying zero trust to OT does not mean blocking all remote maintenance. It means that every access attempt must be verified, restricted, and monitorable. The network is no longer considered trustworthy by default simply because a user has established a VPN connection.
In an industrial zero-trust framework:
-
The user’s identity is verified before each login.
-
The connection context is taken into account.
-
Rights are granted on a strictly limited basis.
-
Sessions are logged.
-
Access rights are reviewed regularly.
-
Exceptions are documented.
This approach is particularly well-suited for multi-vendor environments, specialized machinery, remote sites, and organizations that need to demonstrate their control over OT access.
When to Use a Gateway by Site or by Zone
A single gateway can support multiple devices, but simplification should not be confused with excessive centralization. The appropriate division depends on the industrial architecture.
One gateway per site is appropriate when the lines share the same OT zone and the access rules remain easy to maintain. One gateway per zone is preferable when criticality levels differ, for example, between a packaging line, a critical process area, and an isolated robotic cell.
The key selection criterion is operational mastery: the architecture must remain understandable to the teams that use it.
Conclusion
Remote access to PLCs is no longer a convenience reserved for machine builders: it is an operational necessity for reducing response times, securing production lines, and maintaining industrial equipment spread across multiple sites. However, it must be designed as sensitive OT access, not as a simple, generic VPN.
An architecture based on an industrial gateway, named accounts, strong authentication, fine-grained segmentation, and audit logs enables automation engineers to connect to Siemens S7, Schneider M340/M580, or Allen-Bradley PLCs without unnecessarily exposing the industrial network. To learn more, explore Eziwan’s solutions for industrial gateways, secure cloud, and OT connectivity.
Further Reading
- Industrial Remote Access — The Basics of Secure Remote Access to OT Equipment
- Siemens S7 Remote Access — Connect remotely to your Siemens S7-300, S7-400, and S7-1500 PLCs
- Schneider Remote Access — secure remote maintenance of Schneider Modicon M340 and M580 PLCs
- Industrial Remote Diagnostics — diagnose your equipment remotely without on-site intervention
- Industrial VPN — secure communication tunnels to your PLCs and HMIs
- Monitoring and Remote Support — remotely monitor and troubleshoot your entire OT infrastructure