Remote access, but not the kind you remember

The manufacturer's service organisation lead opens their part of the technical meeting with a question that seems uncontroversial. What is the procedure for establishing the VPN tunnel from their service centre to the plant? Will it be IPsec or SSL? Who issues the certificates? Is there a preferred vendor for the gateway appliance?

They are not asking whether there will be a tunnel. They are asking how the tunnel will be configured. The answer they expect is a routine technical exchange about gateway types, encryption parameters and credential exchange. The answer they receive is that there will not be a tunnel.

Persistent connectivity from the manufacturer's office to the plant is a 2015 architecture. It has been the industry default for a decade, embedded in long-term service agreements, condition-monitoring contracts and the operational habits of every major manufacturer in the wind, solar, battery and inverter markets. It is the way maintenance has been done. Under EU expectations, applied to an EU-financed project, it is not the way maintenance will be done.

No IPsec tunnel. No SSL VPN. No AnyDesk, TeamViewer, Splashtop, or any of the other commercial remote access tools that have proliferated in industrial maintenance. No standing connectivity of any kind, in any protocol, on any schedule. The manufacturer does not live inside the perimeter. They visit it, for as long as a specific task requires, under conditions that the asset owner controls.

This is the most operationally consequential of the architectural changes in this series, because it touches the manufacturer's business model. The long-term service agreement presupposes the ability to observe the asset and to intervene when it underperforms. The manufacturer's first reaction is usually that without persistent connectivity, neither observation nor intervention is possible. The first reaction is wrong. Both are possible. Neither requires the manufacturer to be inside the perimeter.

Why persistent connectivity is no longer on the table

Three reasons converge.

Each persistent tunnel is a standing attack path. A VPN from a manufacturer's service network into the plant means that any compromise of the manufacturer's network — credential theft, malware on a service engineer's laptop, a successful phishing campaign against a maintenance team member, an unpatched vulnerability in the manufacturer's gateway appliance — propagates directly into the OT environment. The asset owner has no visibility into the manufacturer's internal security posture and no contractual standing to audit it deeply. Trusting that the manufacturer's network is secure enough to be inside the OT perimeter is an architectural decision the asset owner cannot validate and the lender cannot accept.

NIS2 supply chain assurance requires actively controlled access. The operator's obligations under Article 21 include managing supply chain security, controlling access to network and information systems, and being able to demonstrate to a regulator that those controls are in place. A persistent tunnel that the manufacturer can use at any time, on any schedule, without prior approval and without session-level visibility, is not actively controlled. It is access on the supplier's terms.

The audit trail is the system of record. Under NIS2 and the broader EU cybersecurity framework, the operator is expected to know who accessed what, when, for what purpose, under whose authorisation. A persistent tunnel cannot produce that audit trail at the granularity required. It can show that a tunnel was up; it cannot reliably show which engineer did which action against which asset during which window.

The result is not a softer version of the old architecture. It is a different architecture entirely.

What replaces it

Two patterns running in parallel.

Telemetry flows out. Condition monitoring, performance analytics, fault prediction, fleet benchmarking — everything the manufacturer needs to observe the asset — runs through a unidirectional gateway from the plant out to the manufacturer's cloud. The gateway is a piece of hardware that physically permits data to flow in one direction only, by design rather than by configuration. Commercial implementations include Waterfall Security Solutions, Owl Cyber Defense and several others; the principle is the same across vendors. The manufacturer receives a continuous, near-real-time stream of operational data, processes it in their own analytics environment, runs whatever machine learning models or expert system rules they wish, and generates reports, alerts and recommendations. None of this requires inbound connectivity. The manufacturer can know everything they need to know about the asset's behaviour without ever connecting to it.

Maintenance access is brokered. When something needs to be done that requires the manufacturer to interact with the asset — investigating a fault, applying a configuration change, running a diagnostic, deploying a patch — the manufacturer requests access through a secure remote access broker operated by the asset owner. The broker is not a tunnel. It is a mediated session that opens for a defined purpose, for a defined duration, against a defined target, with defined privileges, and that closes when the work is done or the time expires.

Common platforms come from two product genealogies: OT-purpose-built (Claroty xDome Secure Access, Dispel, Xage, Waterfall HERA) and IT-PAM products extended for OT use (CyberArk Privileged Session Manager for SSH and RDP, BeyondTrust Privileged Remote Access), with several others in each category. The technology differs between platforms; the operational model is the same.

What a session actually looks like

Walk through a typical maintenance session.

The manufacturer's named engineer — vetted in advance under the asset owner's onboarding process, with credentials provisioned in the asset owner's identity system — opens a service ticket. The ticket states the asset to be accessed, the work to be performed, the protocols required (SSH, HTTPS, RDP, vendor-specific tool), the duration estimated, and the change reference if the work modifies configuration.

The asset owner's authorising authority — typically a control room engineer with appropriate delegation — reviews the ticket. They confirm the asset is in a state that permits the work, that no conflicting activity is in progress, that the requested duration is reasonable, and that the change reference is approved. They authorise the session.

The engineer authenticates to the broker with multi-factor authentication. The broker establishes the session through a controlled jump host. The engineer interacts with the target through their browser or through a thin client; their own laptop never directly speaks to the target. The session is recorded in full — keystrokes, screen capture, file transfer attempts, command output.

During the session, the engineer can perform the work specified in the ticket. They cannot perform work outside that scope. The clipboard is disabled in both directions. File transfer is disabled by default and requires a separate, named justification if needed. The session has a hard expiry; if the work runs longer than expected, the engineer requests an extension and the authorising authority decides.

There is one further restriction that often surprises manufacturers. Within the session, write actions are not automatic. The conduit firewall is typically configured to permit read-only protocol behaviour by default. A manufacturer's engineer connecting to a controller's web interface may see the configuration screens correctly, but find that submitting a form returns an error — because the HTTP POST, PUT, PATCH or DELETE method has been blocked at the ICS firewall. SCADA write function codes (Modbus 5, 6, 15, 16; the IEC 60870-5-104 write ASDUs; the OPC UA Write service) are similarly blocked by default. Write privilege is requested separately, naming the specific action to be performed, with the exact target and the exact value, and is approved separately by an authority with appropriate seniority. The firewall then opens the specific write path for the specific session.

This is what IEC 62443-3-3 SR 5.1 — information flow enforcement — looks like in practice. Reads do not become writes by default. Writes are explicit, approved, time-bounded, and recorded. The principle is the same as the access principle for the session itself: nothing is implicit, nothing is durable, nothing is reusable without re-authorisation.

How availability guarantees still work

The manufacturer's concern, often expressed quietly at this point in the meeting, is that the long-term service agreement's performance commitments — availability above 97 per cent, mean time to recover within a stated number of hours, response times for critical faults — cannot be met without persistent access. The concern is understandable but mistaken.

What persistent access actually provides for a service agreement is two things: continuous observation of the asset, and the ability to intervene quickly when intervention is required. Both can be provided without standing connectivity.

Continuous observation comes from the telemetry stream. The manufacturer's monitoring centre sees every value, every alarm, every operational state, with latency measured in seconds. Many manufacturers find that the telemetry available under a structured unidirectional architecture is richer and more reliable than what they were previously pulling through a VPN, because the gateway is engineered for high-throughput one-way flow and the data model is specified rather than improvised at each site.

Rapid intervention is a process question, not an architecture question. The mean time to first technical engagement under a brokered access model depends on how the on-call rotation, the authorisation workflow, and the broker provisioning are designed. With pre-approved emergency-response procedures, named on-call engineers whose credentials are already provisioned in the asset owner's identity system, and an authorising authority on duty round the clock, first technical engagement within ten to fifteen minutes of an alert is achievable. For service agreements written against well-designed availability targets, this is comfortably within the required response time.

The manufacturers who push back hardest on this model are often the ones whose previous service economics depended on routine remote intervention rather than scheduled, structured engagement. The shift to brokered access tends to surface a different operational rhythm — fewer ad-hoc connections, more deliberate work, more documented changes — that is, in the long run, better for the asset and better for the audit trail. The service agreement price may need to reflect that shift. The availability guarantee does not need to.

At proposal stage

The manufacturer who proposes a persistent VPN for service access is proposing a model that the lender will not accept and the operator cannot offer. The proposal will be returned with comments asking the manufacturer to restate their service model around brokered access and unidirectional telemetry.

A bid that arrives with the new model already understood — that lists named on-call engineers who would be onboarded into the asset owner's identity system, that specifies the protocols required for typical maintenance tasks, that proposes a telemetry data model for the unidirectional flow, that estimates duty cycle for brokered sessions — is a bid that has done its homework. The conversation about how to deliver the service agreement against the asset owner's access model becomes a structured operational discussion rather than a renegotiation of the architectural premise.

The deeper point is that the manufacturer's presence inside the perimeter is not a precondition for the manufacturer's value. The value sits in the engineering judgement of the service organisation — knowing what to look for in the data, knowing what to do, knowing what risks the asset is carrying. None of that requires the engineer to be inside the network. It requires them to see the data, to communicate with the asset owner, and to act through the controlled mechanism the asset owner provides.

The next article moves to the controller board itself, and to the one component on it that asset owners have come to insist on removing physically rather than disabling in firmware: the cellular modem that arrives for "emergency support".

This article reflects the regulatory and standards landscape at publication. References to IEC 62443 may be superseded by revisions of that standard; NIS2 transposition continues to evolve across member states; named commercial products are illustrative rather than endorsements. If a citation has rotted or a clause has moved, LinkedIn is the way to flag it.