OT Vendor Remote Access for CISOs: A Safe, Auditable Support Model
OT Vendor Remote Access for CISOs: A Safe, Auditable Support Model
OT Vendor Remote Access Is an Operating Model, Not a VPN Setting
OT vendor remote access is the controlled, time-bounded way a supplier, integrator, or specialist reaches a specific industrial asset or support system without gaining open-ended access to the operational environment. The issue is not whether outside expertise is legitimate. In many plants, it is essential. The issue is whether that support path gives the organisation a defensible answer to five questions: who connected, why they connected, what they could reach, what they did, and how the connection was stopped.
This is where an apparently routine support arrangement becomes a CISO decision. A third party may need to diagnose a variable-speed drive, repair an HMI configuration, validate a PLC program, or support an emergency outage. The same path can also become a bridge from a compromised vendor identity into a process network. CISA’s May 2025 OT mitigation guidance advises owners and operators to remove OT connections from the public internet and, where remote access is essential, use private connectivity, strong authentication, least privilege for the specific asset and role, and disabled dormant accounts.[1]
The wrong response is a blanket ban that leaves maintenance teams without safe support. The equally dangerous response is a permanent vendor VPN, shared account, or unmanaged remote-desktop tool. A good OT vendor remote access model makes the permitted path clear, observable, and reversible. It also makes the safe fallback clear when identity, connectivity, or the support platform fails.
CISO takeaway: Treat every external connection to OT as a temporary, owned, auditable business change. If the organisation cannot explain the asset, time window, technical purpose, approving person, and termination method, access should not be live.
For the broader network architecture that contains the support path, see the existing OT network segmentation guide. For the wider control environment, start with ICS security fundamentals. This article focuses on the difficult operational layer between a signed vendor contract and a live connection into a plant.
Why Vendor Access Fails in Practice
Vendor access often starts as a practical exception. A supplier needs to commission equipment at short notice. A specialist must investigate a failure outside normal working hours. An engineering team needs an application that is not installed locally. The fastest route can be a shared VPN credential, a port forwarded through an edge device, or a remote-support agent installed years ago and forgotten.
Those shortcuts create three problems. First, they blur identity. A team cannot reliably establish which person used a shared account or whether that person still works for the vendor. Second, they blur scope. A supplier who needs a single engineering workstation may inherit a broad route into a supervisory network. Third, they blur recovery. If an access path is compromised, the people responding to the incident may not know which session to terminate, what remote tool is present, or whether the process can remain safe while access is removed.
CISA warns that remote-access software is regularly co-opted by threat actors. Its guidance does not say that every remote-support tool is unsafe. It says the organisation must govern the way a useful tool is deployed, authenticated, monitored, and removed.[2] In OT, that governance has to account for safety, uptime, maintenance windows, and the physical consequence of a wrong command.
The practical test is simple. Imagine that a vendor account is used at 02:00 on a weekend. Can the duty manager answer the following within minutes?
| Question | Evidence the organisation should have | Why it matters |
|---|---|---|
| Who is using the account? | Named individual identity, employer, MFA event, approved request | Removes shared-account ambiguity. |
| Why is the session active? | Ticket, work order, scope, scheduled window, asset owner approval | Connects technical access to an operational purpose. |
| What can the session reach? | Defined route, jump-host policy, asset allow list, protocol restrictions | Limits lateral movement and accidental overreach. |
| What happened during the session? | Session record, command or configuration logs, firewall and identity telemetry | Supports investigation, change assurance, and supplier accountability. |
| How is access stopped safely? | Owner, revocation action, manual fallback, tested break-glass procedure | Prevents an access-control response from creating an operational failure. |
If those answers require searching old emails or calling several people, the access model is not ready for a serious incident.
Design the Support Path Before You Approve the Tool
A CISO does not need to select a particular commercial product to define a sound OT vendor remote access pattern. The essential design question is whether the connection is forced through a controlled path that separates enterprise access from the operational asset.
A useful baseline is:
- Named vendor identity and an approved request. A vendor person should authenticate as themselves, not as a generic supplier account. The request should identify the asset, work objective, planned time, approving operational owner, and rollback or safe-state plan.
- Strong authentication and a controlled entry point. CISA recommends strong passwords and phishing-resistant MFA where remote access is required.[1] The external user should enter through an approved access service, rather than directly to an OT device or an internet-exposed engineering workstation.
- A separate industrial DMZ or controlled support zone. The connection should terminate in a screened environment, typically a jump host or broker in an industrial DMZ. It should not create a direct route from the internet or a vendor network into a control zone.
- A narrow final connection. From the support zone, policy should allow only the named tool, destination, protocol, and time window necessary for the work. The asset owner should be able to explain why each permitted path exists.
- Recording, logs, and a deliberate exit. Sessions should create evidence. The vendor account should expire or be disabled when the work ends. A review should confirm that the intended change occurred and no unexpected route remains.
This pattern complements, rather than replaces, a broader Zero Trust implementation. It applies the same practical principles: verify explicitly, grant only the access required for the task, and assume that a credential or device can be compromised. In an OT setting, the implementation must also preserve safe operation if the broker, MFA service, or communication path becomes unavailable.
The Industrial DMZ Is a Decision Boundary
The industrial DMZ should not be treated as a diagram box that automatically makes a remote-access design safe. Its value lies in forcing the organisation to define and observe the handoff. A vendor may connect to a controlled host, but the host should not become a general-purpose workstation with unrestricted tools, persistent credentials, and broad administrator rights.
Consider the difference between two models. In the first, a vendor signs into a shared VPN and can browse multiple network ranges. In the second, a named vendor uses MFA to access a dedicated jump host, during an approved maintenance window, and can reach only the named engineering workstation or HMI required by the ticket. The second model is not flawless, but it provides a much smaller and more observable path.
NIST’s OT security guidance emphasises the special importance of performance, reliability, and safety requirements in industrial environments.[3] That is why the final design needs an operations review. A technically elegant access broker is not acceptable if it introduces unacceptable latency, blocks a safety response, or prevents a maintenance team from restoring a process during an emergency.
Build Identity, Approval, and Supplier Governance Into the Workflow
A support architecture without an operating process quickly turns into a collection of exceptions. The operational model should establish what happens before, during, and after a vendor session.
Before the session
The request should identify the individual, supplier, asset or service, technical reason, maintenance window, expected actions, data handling needs, and the operational owner who can stop or extend the work. For higher-consequence changes, require a second approver from operations or engineering. The approval should be linked to a change record rather than an informal message.
The supplier agreement should reinforce this workflow. Require named accounts, prompt notification of personnel changes, prohibition of shared credentials, MFA participation, and agreement to session logging. It should specify who is responsible for maintaining the remote-support software, reviewing accounts, and reporting suspected compromise.
During the session
An OT vendor remote access session should be enabled only for the approved window. The vendor should not inherit standing local administrator privileges or a route to unrelated systems. Where feasible, use a dedicated support host or virtual desktop and avoid storing reusable credentials on it. Log sign-in, MFA, asset connection, privilege elevation, file transfer, configuration activity, and the session end.
The level of control should reflect consequence. A vendor who needs read-only diagnostics for a packaging line does not need the same path as a specialist who must change safety-adjacent logic. A high-consequence activity may justify live operational observation, a separate engineering approval, a tested backup, and a confirmed safe-state plan before the session begins.
After the session
Disable access, remove temporary permission, and close the change record only after the asset owner confirms the expected outcome. Review whether the session created a new route, account, tool installation, scheduled task, or configuration artifact. That final step is often neglected, but it is the difference between a temporary support path and a permanent exposure.
CISA’s ICS practice library includes specific guidance on configuring and managing remote access for industrial control systems.[4] The lesson for CISOs is not that every site should use identical controls. The lesson is that remote access needs an engineered, managed process, not a promise that a supplier will be careful.
Plan for Emergency Access Without Creating a Permanent Back Door
The hardest design question is the legitimate emergency. A process outage may require specialist support immediately. If the answer is “use the normal path, but faster,” the organisation must be able to activate the path quickly without discarding identity, logging, or approval controls.
A break-glass process should be narrow and tested. It should define who may invoke it, what evidence is captured, which assets it permits, how long the session lasts, and who performs the post-event review. It should never mean a permanently enabled universal account kept for convenience.
Manual fallback matters as much as emergency connectivity. CISA recommends practising and maintaining the ability to operate OT systems manually, including tested business-continuity, fail-safe, islanding, backup, and standby procedures.[1] Before the organisation ends a suspicious session or disables a remote-access platform, the operational owner should understand what staff will lose and whether the process can be maintained safely.
This is also where the incident-response program should meet the OT operating model. A response playbook should identify the authority to terminate a vendor session, the logs needed to reconstruct the session, the people who assess process consequence, and the escalation path when a remote-support channel is suspected of compromise.
A 90-Day CISO Roadmap for OT Vendor Remote Access
The objective is not to redesign every supplier relationship at once. The objective is to replace invisible or standing access with a controlled pattern that can be repeated.
| Timeframe | CISO outcome | Work to complete | Evidence to retain |
|---|---|---|---|
| Days 1 to 30 | Establish ownership and exposure baseline | Inventory vendors, remote tools, accounts, public-facing paths, target assets, and current approval routes. Identify dormant and shared access. | Vendor-access register, asset mapping, exposure findings, accountable owners. |
| Days 31 to 60 | Pilot the safe path | Select one supplier and one low-to-moderate consequence use case. Implement named identity, MFA, approved entry point, time-bound access, logging, and a closure review. | Test plan, approved flow, session evidence, operations acceptance, rollback record. |
| Days 61 to 90 | Standardise and measure | Publish the minimum access pattern, contract language, exception process, and incident handoff. Expand only after operations confirms the pilot is safe and usable. | Standard, exception register, monthly metrics, tabletop or recovery exercise results. |
Do not treat asset inventory as paperwork. CISA’s OT inventory guidance starts with scope, ownership, asset attributes, criticality, and communication pathways because those facts make a support-access decision possible.[5] A CISO cannot safely approve a vendor path to an asset that no one has classified, mapped, or assigned to an operational owner.
Measure What the Board and Operations Team Need to Know
The most useful dashboard does not count VPN accounts alone. It shows whether support access is becoming more controlled without making operations less safe.
| Measure | What it indicates | Desired direction |
|---|---|---|
| Named, MFA-protected vendor access coverage | Whether suppliers are moving away from shared or weakly authenticated access | Increase toward complete coverage. |
| Dormant external accounts | Unnecessary standing access | Reduce to zero or an approved exception list. |
| Sessions tied to a valid work order | Whether access is connected to operational purpose | Increase toward complete traceability. |
| Time-bound sessions automatically closed | Whether the access model has a reliable exit | Increase toward complete closure. |
| Unsupported remote tools or exposed OT paths | Uncontrolled support channels | Reduce rapidly, with operations-approved remediation. |
| Session reviews completed for high-consequence work | Whether accountability survives the maintenance window | Increase toward complete review. |
| Tested emergency and manual fallback scenarios | Whether the site can respond without causing avoidable downtime | Test regularly and record lessons. |
A board report should explain the consequence, not just the technology. For example: “Ninety percent of vendor support sessions are now named, MFA-protected, logged, and tied to a work order; the remaining ten percent are risk-accepted exceptions with a remediation date.” That statement is more useful than a list of firewall rules because it connects access control to operational resilience.
Questions to Ask Before Signing Off
Before approving OT vendor remote access, a CISO should be able to ask, and receive credible answers to, the following questions.
- Does the supplier use named individuals and phishing-resistant MFA, or is access shared among a team?
- Is the target OT asset removed from direct public exposure?
- Does the path terminate in a controlled support zone or industrial DMZ before reaching the operational environment?
- Is the permitted destination, protocol, privilege, and time window defined for each type of work?
- Can operations safely continue if the access broker, identity provider, or remote-support tool becomes unavailable?
- Are sessions recorded and logs retained long enough to support engineering review and incident investigation?
- Who can terminate a suspicious session, and who decides whether it is safe to do so?
- Is the supplier contract aligned with the technical controls, including account lifecycle and incident notification?
The aim is not to make vendor support painful. It is to make it trustworthy. A well-run OT vendor remote access program gives suppliers a predictable path, gives operators an approved way to obtain help, gives engineers a controlled workspace, and gives the CISO evidence that an external connection will not silently become an uncontrolled route into the process environment.
References
[1]: CISA, Primary Mitigations to Reduce Cyber Threats to Operational Technology
[2]: CISA, Guide to Securing Remote Access Software
[3]: NIST SP 800-82 Rev. 3, Guide to Operational Technology Security
[4]: CISA, ICS Recommended Practices
[5]: CISA, Foundations of OT Cybersecurity Asset Inventory Guidance
About Author
