BifrostConnect Blog
BifrostConnect's Blog
"AD-HOC VENDOR ACCESS" as a state vs as an architecture
For a decade, vendor remote access has taken one of three standard forms:
- An IoT gateway hard-mounted to the DIN rail
- A permanent VPN
- Remote-control software running on the host
The gateway sits permanently in the cabinet, configured by default for vendor-initiated access at any time. The VPN tunnel does the same thing without the hardware: a standing path into your network that stays configured and reachable, there for the vendor to use on their schedule rather than yours. Remote-control software does it once more, with no box and no tunnel, but with a standing agent inside your production environment that anyone with the credentials can reach.
Most remote access in OT operates this way. The vendor controls the door. You, the facility owner, manage the locks.
But legitimate vendor access has quietly become one of the most common entry paths into industrial systems, and the conversation is now whether it is time to change the best-practice standard for how you let third parties into your systems. Yes, operational data has real value, but in many OT environments that value does not justify the risk of an exposed or compromised system.
With BifrostConnect, the deployment model is different
A technician needs to troubleshoot your production system. The Bifrost Unit, which has been sitting unplugged between sessions, is brought online by the customer. Access is granted through the Manager. The session exists only while it is needed. When it ends, the unit goes back into its unplugged state.
The vendor does not get to decide when the path opens. The customer does. This is not just a feature. It is a different model of where the access path lives.
Why this matters in OT
Always-on vendor access changes whose security you depend on. Standing infrastructure and persistent vendor credentials become part of your attack surface. If either is compromised, the attacker does not need to break in. They inherit a path that is already there, already trusted, already open.
It is also access you cannot fully govern, because you did not initiate it. The connection opens on the vendor's schedule, not yours, and you are defending it every hour of every day, including the hours when no one is watching.
OT raises the stakes further. An IT system can usually be reimaged. A breach in production control can create physical consequences: process upset, safety exposure, shutdown. A standing path is not one more thing to secure. It is a permanent, high-consequence liability that has to be justified, monitored, and defended for as long as it exists. Most of the time it exists for convenience.
The always-on model inverts the security question. Instead of asking "why does the vendor need this standing connection?", it asks "how do we secure this standing connection?". You spend your energy defending something that should perhaps not have needed to exist.
"But we can switch it off"
This is a fair response from teams running a permanently installed gateway with an off-switch, a key switch, or scheduled access controlled by the customer. The intent is right. The gap is in what "off" actually means on a device that lives in the cabinet — and that gap is wider than it looks.
A permanently installed gateway that has been switched off is still a device in your environment. It is still cabled to the OT network. Its firmware is still resident. Its management interface is still ready to respond to the command that turns it back on. "Off" is a state applied to a live system. It depends on the firmware being uncompromised, on the configuration not being changed later, and on the management plane being unreachable to anyone who should not have it. If any one of those assumptions slips, the device is back on.
A Bifrost Unit between sessions is not a device in your environment in the operational sense. It is unplugged. It is not on the network. There is no firmware running for anyone to reach over the network. There is no configuration to compromise remotely. The disconnection is physical, not logical.
That distinction shapes everything that follows.
Attack surface between sessions
A permanent device that is set to off still has firmware, an Ethernet connection, and a management plane that has to be defended whether or not it is currently in use. A unit that is unplugged has none of those exposed. It is not a networked target until the customer chooses to bring it online.
Resilience to platform-side risk
Devices that are not connected to a network cannot be reached by one. A fleet of Bifrost Units sitting unplugged across customer sites is not exposed to platform-side incidents in the way a fleet of permanently connected devices would be. Signed firmware and verified boot extend that protection even when units come online, so a compromised management plane cannot push a malicious image.
Operational simplicity
A permanent installation needs firmware management, configuration governance, and ongoing verification that the off-state is actually set. A unit that is unplugged needs none of that to be safe between sessions. Updates apply on the customer's schedule, on a unit they choose to bring online, rather than on a live device sitting in the OT cabinet.
A human-in-the-loop control
When the customer brings the unit online and grants a session in the Manager, a person on site makes an active decision: access, now, for this purpose. No control is absolute, and a human in the loop is no exception. But it adds a layer that is separate from the technical controls and that leaves a clear, on-site record.
When "ad-hoc" as a state simply does not apply
- A new machine arrives at a site with no network and no operating system, and there is no installed device to switch on.
- A site refuses a permanent box in the cabinet at all, and there is nothing to install.
- An incident isolates the network, and the installed device went down with everything else.
A portable, customer-controlled unit with the ability to both deliver the secure access path and the end-point control handles each of these by design, because it does not require the OT environment to host it.
This is the difference between ad-hoc as a state and ad-hoc as an architecture. The first is a setting on a device that lives in your environment. The second is a device that does not live in your environment at all.
The compliance model shifts too
Most regulations are written with the assumption that you are defending standing infrastructure third parties can reach: authenticate harder, log deeper, segment tighter.
If there is no inbound port for the vendor to reach, and no device on the network between sessions, the compliance picture changes. The question shifts from "how do we defend this?" to "how do we govern third-party access to it?" — from securing an always-present risk to authorising an on-demand one.
A unit that is unplugged between sessions is not a vendor access path that needs defending. It is a tool the customer brings out when they choose to.
The change is not from one tool to another. It is from defending a connection that always exists to governing one that only exists when you decide. From locks on a door that will always be there to a door that is only there when you open it.
Source: Verizon, 2025 Data Breach Investigations Report. Analysis of 22,052 security incidents and 12,195 confirmed data breaches.
Full report: 2025 DBIR Full Report |
Executive summary: 2025 DBIR Executive Summary
About the Author:
Emilie Lerche Fenger is the Head of Sales and Marketing at BifrostConnect, where she leads the company’s commercial strategy and cybersecurity aligned market positioning. With eight years of experience working with remote access and critical infrastructure, she focuses on understanding real operational challenges, shaping thought leadership and driving strategic initiatives that support NIS2 readiness and resilient IT OT collaboration.
Minimum compliance cannot protect critical infrastructure. NIS2 requires continuous improvement and real capability building, not checklist thinking.
Can you answer all five questions about vendor access to your OT systems? Discover what secure, auditable remote access looks like for critical infrastructure.
