Zero-Trust Cybersecurity for Industrial Control Systems: Protecting Industrial OT Networks

The zero-trust model applied to industrial OT networks involves not trusting any access by default, even when it comes from a technician, a service provider, an internal workstation, or a network already connected to the site. Every connection to a PLC, SCADA system, HMI, or industrial gateway must be authenticated, authorized, restricted, logged, and revocable. For Siemens, Schneider, Rockwell, or multi-vendor environments, this approach reduces the exposure of PLCs without hindering maintenance and monitoring needs.

The Problem

The traditional security model often relies on a perimeter: a firewall protects the entry point, and devices located inside the network are considered relatively trustworthy. In industrial OT networks, this approach is flawed. PLCs cannot always be updated quickly, some industrial protocols do not include native strong authentication, engineering workstations are critical, and the traditional air gap has often disappeared with remote monitoring, remote maintenance, the IIoT, and cloud connectivity.

Field teams are aware of the most common risks.

• A shared, generic VPN can expose the OT network too broadly if an account, workstation, or configuration file is compromised.

• Industrial protocols such as Modbus/TCP, EtherNet/IP, or certain PROFINET applications may transmit commands or data without sufficient application-level encryption, depending on the configuration.

• Service provider access is sometimes left open indefinitely, without a maintenance window, without specific restrictions, and without regular review.

• Flat OT networks allow non-critical equipment to communicate with sensitive production controllers or SCADA servers.

• Older PLCs and HMIs may rely on fixed software versions, which requires compensating for this through networking, segmentation, and monitoring.

• The access logs are incomplete: it becomes difficult to determine which user logged in, when, from where, and to which device.

• Default or shared passwords are still in use on some industrial equipment, particularly when inventory and password-change procedures are not properly managed.

• Production data, recipes, process parameters, and machine statuses may be transferred between zones without adequate controls.

• The NIS2 requirements and the principles of IEC 62443 underscore the need to document, restrict, track, and audit access to industrial systems.

Zero trust is not about blocking the OT. It involves removing implicit access rights and replacing them with explicit, context-based, and verifiable access rights.

Why Zero Trust Is Suited for OT Networks

In IT, zero trust is often associated with user identity, workstations, and SaaS applications. In OT, it must be adapted to industrial constraints: availability, safety, long cycles, legacy protocols, equipment that is difficult to patch, and third-party service provider interventions.

The central idea remains the same: never assume that a user or device is trustworthy simply because it is “on the right network.”

Zero Trust Principle	Practical OT Application	Example
Explicitly verify	Authenticate every remote access	Personalized account and MFA for a technician
Least privilege	Limit access to necessary equipment	Access to a Siemens CPU, not the entire VLAN
Segmentation	Isolate zones and conduits	Line 1 separated from Line 2
Continuous monitoring	Log and alert	Service provider connection outside scheduled hours
Rapid revocation	Immediately revoke a privilege	Deactivation of a compromised certificate
Resilience	Maintain local operations	The PLC remains controllable on-site

This approach is particularly useful when multiple parties are involved in the same systems: in-house maintenance teams, automation engineers, machine manufacturers, system integrators, SCADA software vendors, telecom operators, and subcontractors.

Zero-Trust Architecture for PLCs and SCADA

A zero-trust OT architecture is based on zones, conduits, and a control point between remote users and industrial devices. The gateway should not be merely a transparent tunnel: it must enforce access rules, log sessions, and enable rapid revocation.

The OT network retains its local functions. PLCs, HMIs, and SCADA systems continue to operate on-site, but external access is filtered, tracked, and limited to specific needs.

Our Approach

Eziwan implements a zero-trust approach for OT networks by combining identity management, secure tunnels, device-specific rules, segmentation, time windows, monitoring, and audit logs. The goal is to replace permanent and shared access with access that is role-based, limited, observable, and revocable.

• Identity-based access: Each technician or service provider has their own login credentials, certificates, or access rights, with no shared VPN accounts.

• Least-privileged access: Each user has access only to the equipment necessary for their duties.

• Time windows: Service provider access may automatically expire after the authorized maintenance period.

• Network microsegmentation: Sites, lines, or OT zones are isolated by default, with explicit rules between them.

• Real-time audit logs: Logins, logout attempts, session durations, accessed resources, and security events are recorded.

• Anomaly detection: alerts for connections outside scheduled hours, unauthorized attempts, or unusual behavior.

• Rapid isolation: A user, rule, or piece of equipment can be isolated without the need for on-site visits when the architecture allows it.

• OT password management: inventory of sensitive equipment, identification of weak access points, and a controlled update workflow.

• Encryption of remote data streams: Unencrypted OT protocols can be encapsulated within a secure tunnel between the authorized user and the industrial access point.

• Incident response procedures: containment, revocation, logging, and recovery templates to minimize improvisation during a crisis.

This approach integrates with an Eziwan gateway, monitoring via the Eziwan cloud, and industrial connectivity architectures.

Key Features

User-Specific VPN

Each technician and service provider must have their own access. A certificate, configuration, or named account makes it possible to know who is logging in and to revoke a user’s access without affecting others.

The benefit is immediate: if an account is compromised, it can be deactivated individually. The other technicians retain their access rights, and the investigation can proceed based on a clear identity.

Role-Based Access Control for the OT

RBAC, or role-based access control, must be adapted to the realities of the industry. An operator, an in-house automation engineer, a Siemens integrator, a Schneider service provider, and a Rockwell support representative do not all require the same level of access.

Examples of possible roles:

• Operator: Viewing reports or accessing a limited interface.

• Maintenance Technician: troubleshooting and overseeing a specific area.

• Automation Engineer: Access to authorized PLCs and engineering tools.

• Construction contractor: temporary access to the equipment under its responsibility.

• OT Administrator: managing rules, users, and audits.

The role should not be created simply for convenience. It must describe a real need: site, area, equipment, protocol, duration, and level of action.

Temporary Maintenance Windows

Permanent access is one of the weaknesses of OT networks. A time window allows a service provider to be granted access for four hours, one day, or a scheduled period, after which access is automatically revoked.

This mechanism reduces the number of instances where revocation is overlooked. It also provides clear evidence: the connection was authorized during a specific time window for a specific operation.

OT Network Microsegmentation

Microsegmentation involves dividing the network into smaller, more manageable segments. It limits the spread of an incident and reduces unnecessary paths to critical equipment.

The technician at Site A should not be able to access Site B simply because he is connected to the same VPN concentrator. Segmentation must be implemented across the network, not just within an application.

Audit logs for NIS2 and IEC 62443 compliance

Logs are essential for demonstrating control over access. They are used for operations, auditing, incident analysis, and internal compliance.

A useful log must contain at least the following:

• User identity.

• Organization or related role.

• Session start and end times.

• OT source and destination IP addresses.

• Affected equipment or area.

• Access rule applied.

• Attempts rejected.

• Modification or revocation of rights.

• Unusual connection events.

It is important to be specific about the scope: a network gateway can log connections, traffic, and applied rules. Detailed traceability of internal changes to a PLC also depends on engineering tools, equipment logs, and change procedures.

Real-time alerts for anomalies

Zero trust isn’t just an entry-point control. It must generate alerts when something deviates from expected behavior.

Examples of relevant alerts:

• Login outside of business hours.

• Attempt to access an unauthorized automated system.

• Repeated authentication failure.

• Connection from an unusual source.

• Abnormal traffic volume to an OT zone.

• Use of a service provider account for unplanned work.

• Critical rule change.

These alerts can be sent via email, webhook, monitoring, SIEM, or a ticketing tool, depending on the organization.

Emergency Isolation

When suspicious behavior is detected, the team must be able to act quickly. Emergency isolation may involve deactivating an account, revoking a certificate, disabling an access rule, isolating a gateway, or blocking traffic to a specific area.

The goal is not to shut down the plant at the first sign of doubt. The aim is to have a series of graduated, documented, and reversible measures in place.

SIEM and SOAR Integration

Eziwan events can be fed into a SIEM or security monitoring system to be correlated with other signals: directory services, EDR, firewalls, Windows logs, SCADA events, network alerts, or support tickets.

This integration helps the SOC distinguish between normal activity and suspicious behavior. It also triggers SOAR playbooks when the organization uses them: alert enrichment, notification, ticket creation, access revocation, or validation requests.

Example of a Zero-Trust OT Access Policy

A zero-trust policy must be understandable to both OT and IT teams. It should avoid implicit rules and clearly describe access rights.

profils:
  automaticien_interne:
    authentification:
      mfa: obligatoire
      compte: nominatif
    ressources:
      - site: usine_nord
        zone: ligne_1
        equipements:
          - automate_s7_1500
          - ihm_ligne_1
        protocoles:
          - tia_portal
          - https
    horaires:
      autorise: heures_ouvrées
    journalisation: obligatoire

  prestataire_machine:
    authentification:
      mfa: obligatoire
      certificat: individuel
    ressources:
      - site: usine_nord
        zone: cellule_robotisee
        equipements:
          - plc_compactlogix
          - ihm_panelview
    fenetre_maintenance:
      debut: "2026-06-25T08:00:00+02:00"
      fin: "2026-06-25T12:00:00+02:00"
    journalisation: obligatoire
    expiration: automatique

This formalization prevents overly broad access. It also facilitates auditing, since each right is linked to an operational justification.

Industrial Protocols: Limitations and Mitigation Measures

Zero-trust OT must take into account the protocols that are actually in use. Some industrial protocols were designed for closed networks, with few or no native authentication and encryption mechanisms. Others have more secure variants or configurations, but these are not always available on existing equipment.

Protocol or practice	Common risk	Mitigation measure
Modbus/TCP	Potential commands if network access is authorized	IP filtering, encrypted tunnel, segmentation
EtherNet/IP	Broad discovery and access depending on topology	Explicit paths, rules per device
PROFINET	Sensitive to topology and local traffic	Zone isolation, controlled engineering access
OPC UA	Security dependent on certificates and policies	Certificates, encryption, account management
HMI Web Interfaces	Weak or outdated passwords	Upstream MFA, filtering, controlled changes
RDP or VNC	Frequent target if exposed	No Internet exposure, access via gateway

When a control system cannot be hardened directly, security measures around it must be strengthened: segmentation, filtering, identity management, monitoring, asset inventory, and change management procedures.

Zero Trust, NIS2, and IEC 62443

NIS2 and IEC 62443 are not synonymous with zero trust, but their requirements align in several areas: risk management, access control, segmentation, logging, incident management, business continuity, and governance.

A zero-trust OT architecture can help achieve these goals.

Requirement	Implementation of a zero-trust OT approach
Access Management	Personalized accounts, MFA, revocation
Least Privilege	Rights limited by device and duration
Segmentation	Isolated OT zones, controlled conduits
Traceability	Connection logs, denied access, and changes
Vendor Management	Temporary and auditable vendor access
Incident Response	Rapid isolation, evidence, and procedures
Continuity	Controlled access without direct exposure

Compliance cannot be achieved through a tool alone. It depends on the overall architecture, procedures, operational evidence, and governance. Eziwan provides useful technical building blocks to help meet these requirements.

The Lifecycle of a Zero-Trust Connection

A zero-trust connection to an OT device follows a specific sequence: request, authentication, context verification, authorization, logging, limited access, monitoring, and termination.

This sequence makes access transparent and verifiable. It avoids the model in which an open VPN grants access to an entire network without any context.

OT Password Management

Default passwords, shared passwords, or passwords that are never changed remain a common problem in industrial environments. However, any changes must be planned carefully: some equipment is outdated, some accounts are used by applications, and an untested change could cause an outage.

A realistic approach includes:

• Inventory of equipment with local authentication.

• Identification of default or shared accounts.

• Classification by criticality.

• Test changes on non-critical equipment or during a maintenance window.

• Documentation of application dependencies.

• Secure storage of secrets.

• Deleting unnecessary accounts.

• Periodic review of provider access.

Zero trust reduces reliance on local passwords by implementing strong controls upstream, but it does not eliminate the need to address weak accounts on the devices themselves.

OT Incident Response

If a security breach is suspected, teams must know what to do before a crisis occurs. The IT incident response plan must be simple, practical, and tailored to production constraints.

The first steps must ensure personal safety and maintain local operations. In the OT, isolating a piece of equipment does not always mean shutting it down. It is important to distinguish between disconnecting remote access, network isolation, switching to local mode, and shutting down production.

Best Practices for Deployment

An OT zero-trust project should be implemented in phases. It is best to start with the most exposed access points and then expand segmentation and policies.

• Map existing sites, areas, control panels, HMIs, SCADA systems, engineering stations, and access points.

• Identify service providers and manufacturers that have remote access.

• Delete shared accounts as soon as possible.

• Implement personalized accounts and strong authentication.

• Define OT zones and authorized conduits.

• Limit the rules by equipment, protocol, and duration.

• Log access attempts and denials.

• Test real-world industry tools: TIA Portal, Control Expert, Studio 5000, OPC UA, and web interfaces.

• Set up actionable alerts.

• Document the revocation and emergency procedures.

• Review the rights on a regular basis.

This approach makes it possible to quickly improve safety without requiring a drastic overhaul of the industrial network.

Common Mistakes to Avoid

Confusing VPN with Zero Trust

A VPN encrypts a tunnel, but it does not guarantee any privileges. While a VPN provides access to the entire OT network, it does not solve the underlying problem. Zero trust enforces specific rules based on the user, device, protocol, and context.

Segment only on paper

A network diagram is not enough. Segmentation must be implemented through technical rules, tested, documented, and monitored. It must be verified that an unauthorized user cannot access a restricted area.

Forget About Service Providers

Service providers often have access to sensitive information, which is sometimes maintained for years. They must be integrated into the same model as internal teams: a personal account, MFA, time window, limited scope, and logs.

Strive for perfection before taking action

Implementing a full zero-trust model can take time. It’s better to start by removing shared access, revoking unnecessary permanent access, and logging critical connections than to delay taking any action while waiting for an ideal architecture.

Neglecting business tests

A rule that is too strict can block an engineering tool or monitoring system. Each rule must be tested with actual applications, in a controlled environment, with the relevant teams.

Zero-Trust OT Maturity Checklist

Area	Question	Priority
Inventory	Are PLCs, HMIs, SCADA systems, and remote access points inventoried?	High
Identity	Does each user have a personal account?	High
MFA	Is strong authentication enabled for remote access?	High
Least Privilege	Are permissions limited to necessary equipment?	High
Service Providers	Do external accesses expire automatically?	High
Segmentation	Are OT zones isolated by default?	High
Logs	Are connections and denied access attempts logged?	High
Alerts	Do anomalies trigger actionable notifications?	Medium
Revocation	Can access be revoked quickly?	High
Incident	Is there an OT containment procedure?	High
Audit	Can evidence be exported for review?	Medium

This checklist provides a practical starting point for assessing a site’s situation and prioritizing actions.

How Eziwan Helps Protect Industrial Control Systems

Eziwan provides a control point between remote users and OT networks. The solution helps replace implicit access with explicit, controlled, and traceable access.

OT Request	Eziwan’s Response	Benefit
Secure Remote Access	Encrypted Tunnels and Named Accounts	Fewer Shared Access Points
Least Privilege	Rules by Device or Zone	Reduced Attack Surface
Service Providers	Time windows and revocation	No more forgotten permanent access
Segmentation	Gateways between zones and channels	Isolation of critical perimeters
Audit	Session logs and events	Evidence for investigations and compliance
Incident	Rapid access revocation	Simpler containment
Monitoring	Alerts and SIEM integration	Faster detection
Continuity	Controlled architecture	Remote maintenance without direct exposure

This approach allows manufacturers to enhance the security of PLCs, SCADA systems, and OT equipment without sacrificing remote maintenance capabilities.

Conclusion

Zero-trust cybersecurity for industrial control systems isn’t just a slogan—it’s a practical approach to restricting access, reducing privileges, segmenting networks, tracking connections, and responding more quickly in the event of an incident. In OT networks, where devices cannot always be patched quickly and where availability remains a top priority, this approach provides realistic and incremental protection.

Eziwan helps implement this model with role-based access, secure tunnels, device-specific rules, maintenance windows, audit logs, alerts, and rapid isolation. For manufacturers subject to NIS2 or IEC 62443 requirements—or internal cybersecurity constraints—this is a pragmatic way to translate zero-trust principles into operational controls in the field.

Further Reading

• Industrial Cybersecurity — the fundamentals of OT security and best practices in the field
• Traditional VPN vs. Industrial Remote Access — why zero trust outperforms traditional VPNs in OT environments
• Industrial Remote Access — Implement remote access without exposing public ports
• NIS2 for Industry — Align your zero-trust strategy with NIS2 requirements
• OT Remote Access Cybersecurity — Specifically secure remote access to your OT networks