Picture a packaged dosing skid installed during a shutdown two years ago. During commissioning, the OEM was given a site-to-site VPN so its controls engineer could reach a Windows engineering workstation and troubleshoot the PLC.
The project finished. The engineer has since left the supplier. Yet the VPN tunnel still exists, the firewall rule still permits access, and a generic support account remains active because nobody defined when it should be removed.
That scenario is hypothetical, but it shows the real problem. “We use MFA” tells me very little on its own. I want to know which connection exists, who can activate it, where it lands and what happens when the original reason for it disappears.
The Forgotten Access Is Often a Route, Not Just an Account
A plant can disable a user and still leave the route they used intact.
Take a vendor support appliance installed with a compressor package. It may maintain an outbound connection to the supplier’s cloud service, while authentication happens at the supplier’s end. If the plant only reviews Active Directory and VPN accounts, that connection may never appear in the audit.
The Colonial Pipeline incident offers a useful non-chemical example. The attacker entered through a legacy VPN profile using valid credentials. The profile wasn’t believed to be active and didn’t use the MFA applied to the company’s newer remote-access system.
The useful lesson isn’t simply “use MFA”. A connection assumed to be obsolete was still technically usable.
That’s why I’d inventory remote access as a set of pathways, not just usernames. VPN tunnels, remote desktop gateways, vendor appliances, cellular routers and cloud portals all count if they can still carry a session towards OT.
Trace the Connection All the Way to the Asset
“The supplier can access the PLC” isn’t specific enough.
Suppose an analyser manufacturer needs to investigate unstable readings. The supplier’s engineer connects through a named VPN account. That session terminates in an industrial DMZ, where the engineer uses RDP to reach a maintenance workstation. A firewall rule then permits traffic from that workstation to the analyser network.
Now there is something useful to inspect.
I’d check whether the VPN account belongs to one named person or is shared between several engineers. I’d check whether the firewall rule permits one destination or an entire subnet. I’d also establish what the engineer can do once connected.
That distinction can be significant. Allowing traffic only to 10.20.40.35 creates a defined destination. Allowing 10.20.40.0/24 potentially exposes every device on that network.
The same applies to permissions. An analyser engineer who only needs to inspect diagnostics may not need access to engineering software capable of changing controller logic.
I’d also look beyond the first machine. If the supplier reaches one maintenance workstation, can they then start another RDP session into an engineering station elsewhere in the OT environment?
For me, least privilege should answer a precise question: which host can this person reach, using which protocol, with which privileges, for how long?
If nobody can answer that from the actual configuration, the access isn’t well understood.
Make Access Expire When the Job Ends
I’m wary of access arrangements that depend on somebody remembering to clean them up later.
If an OEM needs privileged access for a software upgrade on 12 October, the account or entitlement should expire after the approved maintenance window. If the work isn’t finished, somebody can authorise an extension.
That’s safer than creating “OEM_Support” with no expiry date and assuming engineering will remember to request its removal.
The same principle should apply to people.
Suppose a supplier has three controls engineers authorised to support a site. One leaves the company. If all three use a shared supplier account, the plant may have no reliable way to remove the former employee without changing credentials for everyone. Named accounts make that process much clearer.
There also needs to be a named internal owner. “IT” isn’t enough. For example, the controls engineer responsible for the package might confirm the business need, while the OT administrator implements the access and removes it when the job closes.
Know What Normal Remote Access Looks Like
Logs only help if somebody knows what should be happening.
Imagine a remote-access record shows a supplier connection at 02:13 on a Wednesday. There was no maintenance scheduled, production was running normally and nobody on shift requested support.
That is very different from a named OEM engineer connecting at 14:00 during an approved maintenance window to troubleshoot a valve-positioning problem.
The plant should be able to establish who connected, through which route, when the session started and which system was reached. Otherwise, “we log remote access” can provide a false sense of visibility.
There have been several examples of this problem occurring across multiple industries. The Maroochy Shire incident from Australia involved a former engineer retaining company equipment after employment and using access that hadn’t been fully accounted for, even after known privileged accounts were disabled.
That case is useful because it shows the difference between removing the access you know about and proving that no alternative route remains.
Prove a Connection Is Unused Before Removing It
I wouldn’t leave an unexplained connection enabled indefinitely, but I also wouldn’t switch it off just because nobody recognises the firewall rule.
Imagine a scenario where engineers find an old OEM router attached to a boiler management package and the project file says “remote support”. Before removing this, the engineer must complete the following tests:
What traffic does it actually carry?
Does it connect externally only when an engineer requests support?
Does it send condition-monitoring data every five minutes?
Is it used for automatic fault reporting?
If no one knows the answers to these, the plant can test the dependency under controlled conditions. During an agreed maintenance window, the remote route could be blocked while engineers confirm that local control, alarms, historian feeds, and expected support functions continue to operate normally.
If nothing changes, the team has evidence that the connection may no longer be required. If a service stops working, the dependency has finally been identified and can be documented before a permanent change is made.
That’s more useful than either leaving the route open indefinitely or disconnecting it on assumption.
I’d leave a plant manager with the following simple question:
If a supplier contract ended at 17:00 today, could you identify every account, tunnel, appliance and cloud connection that the supplier could use, establish exactly what each one reaches, and remove those routes without disrupting another plant function?
If answering that requires several departments to reconstruct the history from old emails and commissioning records, the plant doesn’t yet have full ownership of its remote-access lifecycle.
