Remote access to a PLC, HMI, or SCADA system should never require exposing a port to the Internet. A modern OT network security architecture prioritizes outbound connections, encrypted VPN tunnels, strong authentication, segmentation, and comprehensive access logging. The goal is simple: to enable remote industrial maintenance without turning the production network into an exposed target.
Why Public Ports Are Dangerous in an OT Environment
Industrial networks have long been designed as isolated environments. PLCs, drives, HMIs, robots, engineering workstations, and SCADA servers communicated over local networks, often without strong authentication mechanisms, because they were not supposed to be accessible from the outside.
This assumption no longer holds true. Remote maintenance, multi-site monitoring, cloud connections, external integrators, and IT/OT convergence have multiplied the number of access points. When a public port is opened to industrial equipment, several risks immediately arise:
- Automatic discovery via Internet scanning;
- Exposure of RDP, VNC, SSH, HTTP, HTTPS, Modbus TCP, or OPC UA services;
- Connection attempts using weak or reused credentials;
- Exploitation of unpatched firmware;
- Lack of actionable logging;
- Excessive access to the OT network after compromise;
- Difficulty in properly revoking a subcontractor’s access;
- Potential propagation from IT to OT if segmentation is insufficient.
The problem isn’t just technical. It also involves compliance, operational responsibility, and the ability to prove who logged in, when, from where, and to which device.
The principle: no incoming openings
The best approach is to eliminate the need to expose a public port. Instead of waiting for a connection from the Internet, the industrial gateway located in the factory or at the remote site establishes an outbound tunnel to a controlled infrastructure on its own.
This model is often referred to as outbound only. It performs well under OT constraints, as it works even behind a carrier NAT, a 4G connection, a strict firewall, or a locked-down corporate connection.
In this architecture, the OT network does not publish anything on the Internet. The tunnel is initiated from the inside, encrypted, authenticated, and controlled by access policies.
Zero Trust Architecture Tailored for OT
Zero Trust as applied to industry is not about simply piling on traditional IT tools. It involves applying the principle of least privilege in a context where equipment is sometimes outdated, fragile, cannot be patched, or lacks native authentication.
A Zero Trust OT architecture is based on four questions:
- Who is requesting access?
- To which equipment?
- For how long?
- With what level of evidence and logging?
A technician does not need access to the entire industrial network. A PLC integrator may need temporary access to a specific PLC. A monitoring provider may need access to an HMI or a SCADA server, but not to drives, cameras, or office workstations.
tip Guiding Principle Industrial remote access should never be general network access. It must be targeted, time-limited, logged, and revocable.
Comparison of OT Remote Access Approaches
Not all remote access methods carry the same level of risk. The following table summarizes the most significant differences.
| Approach | Internet Exposure | Traceability | OT Risk | Recommended Use |
|---|---|---|---|---|
| Port forwarding to PLC | Very high | Low | Critical | Should be avoided |
| Public RDP or VNC | Very high | Variable | Critical | Should be avoided |
| Global VPN without segmentation | Medium | Medium | High | Should be strictly limited |
| Outbound VPN with OT filtering | Low | Good | Controlled | Recommended |
| Zero Trust access per device | Very low | High | Controlled | Recommended for critical sites |
The key difference lies in the level of granularity. A global VPN often gives the impression of security because the tunnel is encrypted, but it can grant overly broad access once the user is connected.
OpenVPN and IPsec: The Role of the Encrypted Tunnel
OpenVPN and IPsec are two proven technologies for creating encrypted tunnels. In an Eziwan architecture, they can be used to transport industrial data streams between the gateway and the concentrator without making OT devices directly visible.
The tunnel offers several benefits:
- communication encryption;
- certificate-based authentication;
- stable private addressing;
- firewall traversal via outbound connections;
- centralized access rules;
- revocation of a site or user without requiring action on the PLCs.
OpenVPN is often valued for its ease of use, its ability to traverse NAT effectively, and its compatibility with TCP port 443. IPsec is widely used in enterprise network infrastructures and can deliver excellent performance with hardware acceleration. The choice depends on IT constraints, the central firewall, the level of administrative support available, and internal policies.
Strong Authentication and X.509 Certificates
Shared passwords are one of the most common vulnerabilities in industrial remote maintenance. They are passed around among internal teams, system integrators, suppliers, and on-call staff. They are rarely changed at the right time and become difficult to trace back to a specific person.
A healthier architecture is based on individual identities:
- one certificate per user or per device;
- independent revocation;
- a limited validity period;
- multi-factor authentication for sensitive access;
- permissions associated with a role, a site, a device, or a time range.
The certificate verifies technical identity. MFA reduces the risk associated with the theft of a device or a secret. The access policy limits what the user can actually do once logged in.
OT/IT Segmentation: Zones and Channels
OT security isn’t limited to VPNs. You also need to control what the tunnel can access. Best practices inspired by IEC 62443 use the concepts of zones and conduits: devices with similar risk levels are grouped together, and traffic between zones is explicitly authorized.
This separation prevents a maintenance access point from becoming a general route between the information system and the workshop. It also limits lateral movement in the event of a security breach.
Minimum Filtering Rules
An OT gateway must deny access by default and allow only necessary traffic. The rules must be clear, documented, and reviewable.
| Source | Destination | Protocol | Action | Justification |
|---|---|---|---|---|
| Authorized Technician | Line 1 PLC | Modbus TCP 502 | Allow | PLC maintenance approved |
| Authorized Technician | Shop HMI | HTTPS 443 | Allow | Local interface diagnostics |
| SCADA Server | Line 2 PLC | OPC UA 4840 | Allow | Industrial monitoring |
| Eziwan Gateway | VPN Concentrator | OpenVPN or IPsec | Allow | Encrypted outbound tunnel |
| IT Network | Entire OT Network | All | Block | Cross-network access denied |
| Internet | PLCs | All | Block | No public ports exposed |
This logic is simple, but it changes everything: the OT network is no longer accessible by default. Each data flow becomes an explicit decision.
NIS2 Logging and Traceability
The NIS2 Directive raises the bar for cyber governance, risk management, business continuity, and incident response for many European organizations. In France, ANSSI supports this effort with resources such as the Cyber France Framework.
For an OT network, the traceability of remote access is becoming a key factor. It is not enough to know that a VPN was active; it must be possible to reconstruct a session.
A useful audit log must include:
- user identity;
- authentication method;
- start date and time;
- end date and time;
- affected site;
- target device;
- protocol used;
- source IP address;
- destination IP address;
- policy decision applied;
- connection result;
- revocation or failure events.
Audit Information Logs must be exportable, time-stamped, and retained in accordance with the company’s internal policy. Their value depends as much on their accuracy as on their ability to be reviewed during an audit or after an incident.
Anomaly Detection
Remote access security doesn’t end with authentication. A technically valid session can still be suspicious. It is therefore useful to trigger alerts for unusual behavior.
Examples of relevant anomalies in OT:
- Login outside authorized hours;
- Access from an unusual geographic location;
- Attempt to access unauthorized equipment;
- Data volume exceeding normal patterns;
- Repeated MFA failures;
- Sudden change in protocol;
- Prolonged activity during an unscheduled period;
- A subcontractor logging in after the contract has ended;
- Access to multiple OT zones without justification.
These alerts must be actionable. Too many generic alerts end up being ignored. A good anomaly rule should specify who is affected, which equipment is targeted, and why the event deviates from expected behavior.
Revoking Access: The Often-Overlooked Step
Secure remote access must be easy to revoke. This is particularly important in industrial environments where multiple contractors may work on the same production line.
The revocation must cover:
- an employee’s departure;
- the end of a subcontractor’s contract;
- loss or theft of a workstation;
- suspected compromise;
- a change in the scope of operations;
- the end of an on-call period or a maintenance window.
Revocation via certificate is cleaner than a shared password. It allows an identity to be invalidated without disrupting all other users and without having to reconfigure industrial equipment.
Temporary Access and Time Slots
Not all OT accesses need to be permanent. To reduce the risk, it is best to grant temporary permissions:
- Access valid only during a work order;
- Time slot linked to a work order;
- Restricted to business days;
- Prior approval required for critical areas;
- Automatic expiration after the work order is completed;
- Manual renewal if the operation takes longer than expected.
This model is particularly useful for system integrators, machine maintenance technicians, PLC suppliers, and on-call teams.
Common Use Cases
OT security without public ports applies to many industrial environments.
| Use Case | Requirement | Recommended Architecture |
|---|---|---|
| PLC Remote Maintenance | One-time access to a PLC | Outbound VPN, MFA, IP and port filtering |
| Multi-site SCADA Monitoring | Continuous data collection | Permanent tunnel, segmentation, network monitoring |
| Vendor maintenance | Limited access to a single machine | Temporary access, automatic revocation, logging |
| Remote 4G site | No fiber | Industrial gateway, dual SIM, outbound VPN |
| Cybersecurity audit | Proof of access | Exportable logs, timestamping, documented policies |
| IT/OT separation | Reduced lateral movement | Industrial DMZ, zones and conduits, denial-by-default |
For remote sites without fiber, this architecture can be combined with an Eziwan gateway and an industrial connectivity solution. For organizations that want to centralize multi-site access, the Eziwan Cloud option allows them to consolidate tunnels, policies, and logs.
Best Practices for Curing
An architecture without a public port significantly reduces exposure, but it must be supplemented by hardening measures.
- Disable unnecessary services on the gateway;
- Change all default credentials;
- Separate administration, monitoring, and maintenance;
- Use individual certificates;
- Enable MFA for critical access points;
- Limit traffic by IP address, port, and protocol;
- Log accepted and rejected connections;
- Regularly test certificate revocation;
- Update firmware according to a validated procedure;
- Back up the gateway configuration;
- Document routes, VLANs, rules, and accounts;
- Integrate logs into the SIEM, if available.
Common Mistake An encrypted VPN is not enough if the connected user can access the entire OT network. Security comes from a combination of encryption, identity verification, segmentation, filtering, and traceability.
Sample Access Policy
Here is an example of a simple policy for a factory with an automated production line.
Role: PLC Integrator
Authorized sites: Plant A
Supported devices: PLC-L1, HMI-L1
Allowed protocols: Modbus TCP 502, HTTPS 443
Hours: Monday through Friday, 8:00 a.m.–6:00 p.m.
MFA : obligatoire
Maximum session duration: 2 hours
Logging: complete
Expiration: automatic after 7 days
This policy provides sufficient access to perform work without opening up the rest of the network. It is also understandable to the OT, IT, CISO, and an auditor.
How Eziwan Secures OT Remote Access
Eziwan implements a remote access architecture designed for industrial environments: outbound tunnel, OpenVPN or IPsec VPN, strong authentication, segmentation, filtering, and centralized auditing. The gateway is installed as close as possible to the OT network, while user access is controlled from a centralized infrastructure.
Key features include:
- No incoming ports published on the industrial site;
- Encrypted outbound tunnel from the gateway;
- Individual X.509 certificates;
- TOTP MFA for sensitive access;
- access policies by user, site, and device;
- filtering of industrial traffic;
- exportable audit log;
- rapid revocation of access;
- monitoring of tunnel status;
- alerts for abnormal behavior.
This approach makes it possible to maintain the industry’s operational constraints while significantly reducing Internet exposure.
Implementation Plan
Securing an OT network without public ports can be done in stages.
1. Map Existing Access Points
Identify open ports, existing VPNs, shared accounts, service providers, accessible PLCs, and SCADA feeds. This step often reveals forgotten access points.
2. Eliminate direct exposure
Disable port forwarding to PLCs, HMIs, Windows workstations, SCADA servers, and administration interfaces. Replace them with a controlled outbound tunnel.
3. Define the OT Zones
Group equipment by criticality, line, workshop, or function. A pump area, a processing area, a packaging area, or an energy area do not necessarily have to share the same permissions.
4. Create Access Policies
Define permissions by role: in-house automation engineer, vendor maintenance technician, operations technician, network administrator, supervisor. Each role must have a clearly defined scope.
5. Enable MFA and Certificates
Replace shared secrets with individual identities. Enable MFA for critical control systems, SCADA servers, and vendor access.
6. Test the logging
Verify that each session generates a usable log: user, device, protocol, time, security decision, and result.
7. Test the revocation
Purposely delete a test account and verify that it no longer works. This simple check prevents you from discovering too late that an old account is still active.
Conclusion
Securing an industrial OT network is not simply a matter of making a public port less visible. The right strategy involves eliminating inbound exposure, establishing encrypted outbound tunnels, authenticating each user, segmenting industrial zones, and logging all significant actions.
With an Eziwan architecture, technicians and service providers can access the PLCs, HMIs, and SCADA systems they actually need, without opening ports to the Internet and without granting general access to the production network. This provides a solid foundation for reducing cyber risk, improving traceability, and preparing for compliance requirements related to NIS2, IEC 62443, and best practices in industrial cybersecurity.
Further Reading
- Industrial Cybersecurity — Best practices for securing your OT networks end-to-end
- Industrial VPN — Encrypt communications to your PLCs without exposing public ports
- NIS2 for Industry — Bring your OT security into compliance with the NIS2 Directive
- Industrial Remote Access — Secure access to OT equipment without a VPN exposed to the internet
- OT Remote Access Cybersecurity — Specifically secure remote access traffic to your industrial networks