The machine builder needs a way into its controller to diagnose a fault in an hour instead of three days. Your plant needs certainty that nobody rides the same channel into the production network at three in the morning on a Saturday. The two needs are not in conflict. They only need architecture — instead of the modem plugged in "for commissioning" that has been sitting there since 2019. Below: what usually fails, how to build a service channel you never have to switch off, and exactly what to put in the integrator contract.
Why remote access is the usual way into an OT network
Not because it is badly built. Because by design it crosses the boundary that every other control is guarding. Firewalls, segmentation and media control stop unauthorised traffic; a service channel is authorised traffic, so it passes.
Four properties of the typical installation make it worse. First, the channel is created during commissioning, when the priority is getting the line running, and it is never redesigned afterwards. Second, the credentials are shared: one "service" account known to four of the supplier's engineers and two former employees. Third, it is on permanently, because that is convenient. Fourth, there is no log, so nobody can answer "who connected last month".
The consequence does not have to be spectacular to be expensive. The common scenario is not a targeted attack but an infected service laptop carrying malware into the machine network, or a change made remotely without a ticket, after which nobody can restore the previous version of the program.
NIS2 and the Polish cybersecurity act: what your obligations depend on
The NIS2 directive and the Polish act implementing it do not place identical obligations on everyone. The scope depends first of all on whether a company is classified as a key or an important entity, and that follows from the sector and the size of the business, not from the number of controllers on the floor. Some manufacturing plants fall inside directly; others arrive indirectly, as a supplier to an entity already covered that pushes the requirements down the supply chain through contract terms.
We quote no deadlines and no thresholds here. The state of the law and the timetable for registration and reporting duties have to be checked against the current text of the act and the announcements of the competent authority — this is exactly the area where an article from last year misleads and relying on it costs money. Treat the rest of this guide as engineering that is worth doing regardless of classification: if it turns out you are covered, it is already done; if not, you have still cut a real risk of downtime.
One thing holds regardless of classification: a supplier that requires remote access is part of your supply chain, and supplier risk is a distinct and explicit theme in NIS2. That is why the contract section at the end of this guide matters more than the choice of product.
Segmentation: office, an intermediate zone and the machine network
The foundation is not the access tool but where it leads at all. The target structure has three layers:
- The office network — mail, business systems, staff computers. There is no route from it straight to the controllers.
- The intermediate zone — everything that has to talk both ways lives here: the data gateway, the historian, the service access point. Traffic into and out of this zone is described by firewall rules.
- The machine network — controllers, panels, drives. There is no connection initiated from outside straight into this zone; everything goes through the intermediate zone.
The service engineer does not log in to the controller. They log in to a jump host in the intermediate zone — a machine with the engineering environment installed, from which selected devices are visible. That single element changes the arithmetic: the session can be recorded, the software is controlled, and file transfer happens in one observed place. It is also worth splitting the machine network itself into segments per line or per cell, so that access granted to one machine is not access to the whole plant.
If you are building a production data layer in parallel, design both together: data flowing out of the machines and the service channel flowing in use the same intermediate zone. We describe that on the machine data collection page.
A VPN or a remote-service platform
| Criterion | Classic VPN | Remote-service platform |
|---|---|---|
| What the engineer gets | an address on the network, usually broader access than needed | a connection to named devices |
| Who initiates the connection | the outside party, into the plant firewall | the device in the plant, outbound to a rendezvous server |
| Session approval | has to be added procedurally | usually built in, key switch on the cabinet included |
| Session record | firewall logs, rarely read | who, when, to what and for how long |
| Several suppliers | separate configuration and rules for each | one platform, separated permissions |
| Dependency | on your own IT team | on the platform vendor and its infrastructure |
An example of the platform category is Siemens SINEMA Remote Connect: devices in the plant establish an outbound connection to a server, and permissions are assigned per person and per device. Other automation vendors and network hardware makers offer comparable products. The choice of product is secondary to whether you have an intermediate zone and a rule for granting access.
When a classic VPN is enough: a small plant, one supplier, one defined scope and the discipline to maintain the rules. When it stops being enough: several suppliers, each wanting its own tunnel, and nobody able to say who connected last month or why.
Per-session approval and logging
The rule that removes most of the problem: access is off by default and someone in the plant turns it on. Implementations, simplest first: a key switch on the cabinet that physically establishes the connection; session approval in the platform console by a named person; a time window opened against a service ticket and closed automatically when it expires.
On top of that, a record from which you can reconstruct who connected, from which account, when, to which device, for how long and against which ticket. For work that touches the program, add a session recording or a copy of the project before and after. The sentence "they changed something remotely on Friday and since Monday the machine drops cycles" is far cheaper to resolve when there is something to check it against.
Credentials: the end of the shared "service" account
- named accounts for every one of the supplier's engineers, never a single shared one;
- multi-factor authentication at the entrance to the platform or the jump host;
- permissions bound to devices, not to the whole network;
- a procedure for revoking access when the supplier's staff changes, with a deadline written into the contract;
- controller and panel passwords in the company password manager, not in the project file and not on a note inside the cabinet;
- a periodic review of the account list — quarterly is enough, as long as it actually happens.
What to put in the integrator contract
- The access channel — named explicitly, with a ban on installing private modems, cellular routers and remote-desktop tools without written consent.
- Scope — the list of devices covered, as an annex updated at every change.
- Mode — access on request, approved on the plant side; no permanent access.
- Accounts and authentication — named, with a list of people and an obligation to report changes within an agreed time.
- Logging — consent to session recording and the plant's right to inspect it.
- Software changes — each one reported, described and handed over in source, with a copy taken beforehand.
- Incident reporting — a deadline for notifying the plant of an incident at the supplier that could affect your installation.
- Subcontractors — named, on the same terms, with no quiet passing of access down the chain.
- End of cooperation — a deadline for revoking access and handing over all passwords and sources.
- A standard for the future — the same terms as a fixed annex to every subsequent order.
That annex is cheaper than an audit and more effective than a firewall, because it acts at the stage where the architecture has not been built yet. If you are ordering software work, agree it together with the scope of Siemens PLC, HMI and SCADA programming.
IEC 62443 as a design reference
The standard the industry refers to when designing security for control systems is the IEC 62443 family. It introduces zones and conduits, security levels, and separate requirements for the device manufacturer, the integrator and the end user. We use it as a design reference for segmentation and access rules.
To say it plainly: we hold no certification against it, and citing a standard is not a declaration of conformity with it. If your customer requires certified proof, that calls for a certification body, not an integrator. Separating those two things in a commercial conversation saves misunderstandings later.
A minimum plan for the next quarter
- List every remote access channel that exists today, including the ones only one person in maintenance knows about. This is usually the most surprising part of the exercise.
- Disconnect the ones nobody has used in six months. If something breaks, you will find out within a week and learn what the channel was for.
- Stand up a jump host and route your largest supplier's access through it.
- Introduce named accounts and plant-side session approval.
- Add the contract annex to the next order, and to all the ones after it.
The first four are days of work, not months, and they need neither a change of supplier nor a new capital budget. The fifth costs nothing and lasts longest.