Remote Access and Third Parties

Why remote access matters so much

Most industrial sites are unstaffed or lightly staffed at night, spread over a large area, and full of equipment that only the vendor fully understands. Remote access saves hours of driving and gets an expert onto a problem in minutes. It is also, by definition, a path from outside into the systems that move valves and switch breakers, which makes it one of the routes attackers look for first.

The pattern recurs in public incident reports. In the December 2015 attacks on Ukrainian distribution companies, attackers opened breakers remotely using legitimate credentials. In 2026, CISA warned (advisory AA26-097A) that actors linked to Iran had manipulated programmable logic controllers (PLCs) that were reachable directly from the internet. And in 2025, attackers reportedly opened a valve at a Norwegian dam through a web-accessible control panel with a weak password. US agencies led by CISA call remote access "a major weakness in OT" in their April 2026 joint guide on adapting zero trust principles to operational technology.

None of this means remote access should be banned; it means it should be designed, not just allowed to grow. See threats and notable incidents for the background of these cases.

Who needs access, and why

• Your own engineers and on-call staff, to diagnose an alarm at night or adjust a configuration without driving to a remote substation.
• Vendors, for warranty support, diagnostics of their own equipment, and sometimes as a contractual condition for support.
• System integrators and service providers, who built or maintain a part of the installation and know its configuration best.

Vendor remote access is the access an outside company's staff uses to reach your industrial systems from their own location. It deserves special care because you control neither their devices nor their staff turnover nor their own security. Historically it was often arranged by the vendor itself: a modem in the cabinet, a permanent VPN tunnel, or a remote support tool installed on the HMI during commissioning, still running years later with the same password.

The needs also differ in kind. Viewing values and logs is far less risky than changing a controller's program, and a session on a historian at site level is less risky than one on a protection relay. A good design lets you grant exactly the access a task needs.

A secure remote access architecture

Secure remote access for OT is a design in which every remote session enters through one controlled path: strong authentication, an encrypted tunnel or broker that ends in the industrial DMZ, a hardened intermediate host from which the work is done, and firewall rules that allow only that host to reach the specific targets. Nothing on the internet or the office network can reach an OT device directly.

The building blocks are familiar from IT, applied more strictly:

• Multi-factor authentication (MFA) at the entry point, preferably phishing-resistant. The zero trust guide asks for MFA "even if only at the jump host level" where devices behind it cannot support it.
• A VPN or remote access broker that ends in the industrial DMZ, not inside the OT network. Brokers that only expose specific applications to specific users limit what a stolen login can reach.
• A jump host (see jump servers): a hardened machine in the DMZ with only the tools needed for the work. The 2026 zero trust guide strongly recommends "dedicated, hardened jump boxes within the OT demilitarized zone (DMZ) acting as the sole entry point for remote access". The user's own laptop, with whatever it carries, never connects to the OT network.
• Firewall rules that allow only the jump host to reach the agreed targets on the agreed protocols, ideally opened only for the duration of an approved session. In IEC 62443 terms this path is a conduit between zones.

Session control and recording

Session recording captures what a remote user did during a session, as video of the screen, a log of commands and keystrokes, or both, together with who connected, when and to what. It serves three purposes: it deters misuse, it shows exactly what changed when something goes wrong afterward, and it is evidence in an investigation. Recording is most useful combined with live control: the control room can see that a session is active, watch it, and end it immediately.

Principles for remote access

Government guidance converges on the same principles. CISA's "Primary Mitigations to Reduce Cyber Threats to Operational Technology" (May 2025, with FBI, EPA and DOE) lists five: remove OT connections to the public internet, change default passwords, secure remote access with a VPN and phishing-resistant MFA, segment IT and OT, and practice manual operations. The "Secure connectivity principles for OT" (January 2026), led by the UK National Cyber Security Centre and also published by NCSC-NL and other agencies, add centralizing and standardizing connections, logging and monitoring all connectivity, and having a plan to isolate OT quickly. In practice:

• No direct path from the internet to OT. Not for a PLC's web interface, not for a "temporary" port forward, not for a vendor modem. Check regularly from outside that nothing is exposed.
• MFA for every remote session, see MFA and passwordless.
• Least privilege: access to the specific systems and functions a task needs, not to "the OT network" (see least privilege).
• Just-in-time and time-boxed: accounts are enabled for an approved window and disabled afterward, as in privileged access management. The zero trust guide names privileged access management as needed for vendor and emergency access.
• Approval per session, tied to a ticket or change, by someone who knows the state of the plant at that moment.
• Recording and logging of every session, kept long enough to investigate.
• Separate credentials per person, also at the vendor: "vendor-support" shared by twenty engineers makes every log useless and survives every resignation.
• No always-on vendor VPNs. A tunnel that is permanently up is a permanent path for whoever controls the vendor's side.
• Patch the entry points fast. VPN gateways, brokers and jump hosts face outward; the zero trust guide asks for a faster patch cadence for edge and remote-access systems than for the controllers behind them.

Example: checking remote access requests

Remote access platforms enforce rules like these before they open a session. This sketch shows the logic: each request is checked for a named account, MFA, a target zone that may be reached remotely, and an approved change that covers this account, this zone and this moment. Helix Controls is a fictional vendor; the zone names are invented.

# Check remote-access requests against the access policy before the gateway opens a session.
from datetime import datetime

# Approved maintenance windows: ticket -> (named account, target zone, start, end)
APPROVED = {
    "CHG-2041": ("helix-pjansen", "substation-north", "2026-10-06 09:00", "2026-10-06 12:00"),
    "CHG-2042": ("eng-mvisser", "control-center", "2026-10-06 13:00", "2026-10-06 15:00"),
}
SHARED_ACCOUNTS = {"vendor", "support", "admin"}
ALLOWED_ZONES = {"substation-north", "control-center"}   # safety systems are never remote

REQUESTS = [
    {"account": "helix-pjansen", "ticket": "CHG-2041", "zone": "substation-north",
     "time": "2026-10-06 09:30", "mfa": True},
    {"account": "support", "ticket": "CHG-2041", "zone": "substation-north",
     "time": "2026-10-06 10:00", "mfa": True},
    {"account": "eng-mvisser", "ticket": "CHG-2042", "zone": "control-center",
     "time": "2026-10-06 16:10", "mfa": True},
    {"account": "helix-pjansen", "ticket": "CHG-2041", "zone": "safety-system",
     "time": "2026-10-06 10:15", "mfa": False},
]


def evaluate(req):
    reasons = []
    if req["account"] in SHARED_ACCOUNTS:
        reasons.append("shared account, not a named person")
    if not req["mfa"]:
        reasons.append("no MFA")
    if req["zone"] not in ALLOWED_ZONES:
        reasons.append(f"zone '{req['zone']}' is not reachable remotely")
    approval = APPROVED.get(req["ticket"])
    if approval is None:
        reasons.append("no approved change")
    else:
        account, zone, start, end = approval
        if req["account"] != account or req["zone"] != zone:
            reasons.append(f"{req['ticket']} does not cover this account and zone")
        moment = datetime.fromisoformat(req["time"])
        if not datetime.fromisoformat(start) <= moment <= datetime.fromisoformat(end):
            reasons.append(f"outside window {start[11:]}-{end[11:]}")
    return ("ALLOW", ["all checks passed"]) if not reasons else ("DENY", reasons)


for req in REQUESTS:
    decision, reasons = evaluate(req)
    print(f"{decision:<5} {req['account']:<20} {req['zone']:<17} {req['time'][11:]}")
    for reason in reasons:
        print(f"      - {reason}")

ALLOW helix-pjansen        substation-north  09:30
      - all checks passed
DENY  support              substation-north  10:00
      - shared account, not a named person
      - CHG-2041 does not cover this account and zone
DENY  eng-mvisser          control-center    16:10
      - outside window 13:00-15:00
DENY  helix-pjansen        safety-system     10:15
      - no MFA
      - zone 'safety-system' is not reachable remotely
      - CHG-2041 does not cover this account and zone

Every denial gives a reason, which helps the requester fix the request and helps auditors later. Note the third request: the account, MFA and zone are fine, but the approved window has ended. A session that is still needed after its window gets a new approval rather than an automatic extension. The last request is denied for three independent reasons; a real platform would also raise an alert for a vendor account trying to reach a safety system.

Remote support tools

Remote support and screen-sharing tools of the kind used by help desks are easy to install and work through almost any firewall, because they connect outward to the tool vendor's cloud service. On an HMI or engineering workstation, that is precisely the problem: such a tool creates its own path into OT that bypasses the DMZ, the jump host, the approval and the recording. Often it runs permanently, with a password shared among everyone who ever needed it. See third-party remote access tools for how these tools work.

Two public cases illustrate the risk, with care about what is known:

• Oldsmar, Florida (2021): a water treatment plant where a remote support tool with a shared password was in use. The event was first announced as a remote intrusion that tried to raise a chemical dose; in 2023 the city's former manager said it was most likely an employee error. No official investigation results were made public, so it remains unresolved. Either way, an always-available remote tool on the HMI was part of the picture.
• TeamViewer (2024): the company reported an intrusion into its own corporate IT environment in June 2024, which it attributed to the group known as APT29 or Midnight Blizzard, and stated that its product environment and customer data were not affected. The lesson is broader than one vendor: the company behind your remote access tool is part of your attack surface.

Third-party risk

Third-party risk is the risk that a supplier, integrator or service provider weakens your security, through its access to your systems, through the products and software it delivers, or through its own compromise. In OT the dependence is deep: the vendor writes the firmware, the integrator built the control logic, and the service provider has the passwords.

A supply chain attack is the worst case: attackers compromise a trusted supplier to reach its customers. But everyday third-party risk is more mundane: a vendor laptop carrying malware, an engineer who leaves the vendor but keeps working credentials, a delivered system with default passwords.

Ways to manage it:

• Contracts that set security requirements: named accounts, MFA, use of your remote access path only, notification of incidents and of staff leaving, security updates for an agreed period, and the right to verify. See supplier management.
• IEC 62443 requirements: IEC 62443-2-4 sets security requirements for service providers such as integrators and maintenance companies, and IEC 62443-4-1 and 4-2 cover the secure development process and technical security of the products themselves. Asking suppliers for conformity gives a shared, checkable language.
• Verification of what is delivered: no default passwords, no undocumented remote access, firmware and software from the vendor's genuine source.
• Offboarding: access ends when the contract or the project ends, and accounts are reviewed regularly.

Regulation increasingly requires this:

See OT regulation.