Secure remote access to PLCs means one controlled path into production, with strong authentication, least-privilege rights, approval by the plant and a log of every session. Ad hoc routers fitted by machine builders do the opposite. US agencies list securing remote access to OT among their primary mitigations, calling for a private connection, VPN with phishing-resistant multi-factor authentication, role-based least privilege and the removal of dormant accounts (CISA). Germany's BSI includes intrusion via remote maintenance access in its top ten threats to industrial control systems (BSI-CS 005).

As a company that supports machines remotely from India, we depend on remote access every day. Here is the design we recommend to plants and machine builders, and the habits that make it work.

Why the usual set-up is risky

Remote access exists for good reasons. Machine builders cannot send a technician for every fault, and plants cannot afford a line standing for a day while someone travels. The goal is not to stop remote access but to control it. A typical German plant has collected remote access the way a kitchen drawer collects cables. A 4G router in the cabinet of line 2, installed by the machine builder in 2017. A remote desktop tool on the HMI PC of line 4. A VPN account for a supplier who left the company. None of them shows up in the firewall rules, and nobody knows who connected last week.

The CISA guidance is blunt about the first step: remove OT connections to the public internet, because devices exposed there are easy targets. Any router that gives a machine a public address, even briefly, belongs on the list to replace.

A reference design for secure remote access to PLCs

  1. One entry point. All remote access arrives at the plant's own gateway in an OT DMZ, never directly into a machine network.
  2. Strong identity. Named accounts for every external engineer, with multi-factor authentication. No shared logins.
  3. Jump host. Sessions run on a hardened engineering station in the DMZ that holds TIA Portal, TwinCAT or CODESYS. The external engineer never puts their own laptop on your network.
  4. Least privilege. Each account reaches only the PLCs and HMIs of the machine it supports, through a defined conduit.
  5. Plant approval. Access is switched on per session by someone on site, for a set time, and switched off afterwards.
  6. Logging and recording. Every session is logged; for write access to safety-relevant code, record it.
Dense rows of blue patch cables connected to network patch panels in a rack
Every remote access path ends somewhere in a rack like this. The design question is whether it ends in a controlled DMZ or directly in a machine network.

Read-only first, write access by exception

Most remote support calls are diagnostic: why did the sequence stop, which sensor is missing, what does the alarm mean. Read-only access answers them. Give external engineers online monitoring rights by default and grant write access, such as a program download, only for a specific job with someone on site watching. On S7-1500 and TwinCAT controllers, access levels and project protection make this split practical.

How the design maps to IEC 62443 and NIS2

In IEC 62443 terms, and in line with the system requirements of IEC 62443-3-3, remote access is a conduit from an external zone into the OT DMZ, and from there a further conduit into a specific machine zone. Each has documented rules and an owner. Under NIS2 in Germany, a single controlled access path with named users and logs is strong evidence of risk management and supply chain security, and the logs help you meet the 24-hour early warning if something goes wrong.

For machine builders, the Machinery Regulation adds a reason of its own. A safety software update delivered remotely after the machine is placed on the market must appear in the machine's intervention log, which has to be kept for five years. Your remote service concept should write that log automatically.

Partition Your OT Network into Zones - Unlocking the Key to Enhanced Cybersecurity

Automation World

This video is hosted on YouTube. Playing it loads content from Google, which may set cookies.

Watch on YouTube
Zoning is the foundation of secure remote access: the external path should end in a defined zone, not inside the machine network.

Habits that make it work at 2 a.m.

A remote access system that is secure but slow will be bypassed the first time a line stops on a night shift. Design for the emergency case:

  • A short, written call-out procedure: who on site enables access, how they reach the supplier, and how long access stays open.
  • Pre-approved accounts for the supplier's on-call engineers, kept current, with dormant accounts removed every quarter.
  • Engineering software and project archives already on the jump host, with the right versions.
  • A test session every few months, so that the first real use is not the first use.

What machine builders should offer

If you build machines, make secure remote service part of your standard offer instead of an afterthought. Document how your service engineers connect, which accounts and rights they need, and how the customer controls access. Offer to connect through the customer's own remote access system. Plants covered by NIS2 increasingly expect this, and a clear answer shortens tenders.

How we use it

Wartens supports commissioning and changes for German clients remotely, so we work inside our clients' remote access systems every week. We help plants design the zoning and conduits behind them, and we deliver PLC code and documentation that fits a controlled change process. See our automation engineering services.

Next step: send us a list of the remote access paths you know about. We will suggest a target design and a migration order that keeps your suppliers able to help. Contact us.