Overview and Framework Mapping

This is Part 2 of a two-part publication by BifrostConnect. Part 1 is a vendor-neutral best-practice framework for third-party access to operational technology, written to stand alone as a reference for threat modelling, scenario analysis and regulatory mapping.

This Part 2 is the implementation companion: it describes how to deploy BifrostConnect, so the controls Part 1 calls for are delivered securely, what each deployment decision means for the resulting evidence chain, and where to harden the trust boundaries the architecture introduces. No claim is made that BifrostConnect is the only way to implement Part 1’s recommendations; several of the compensating controls can be realized with other architectures. Where regulatory wording is interpreted, the interpretation aligns with the guidance issued by Styrelsen for Samfundssikkerhed (SAMSIK) on the Danish NIS2 implementation (Vejledning til NIS 2-loven, June to August 2025).

Cross-references in the form ‘(Part 1, Scenario X)’ point the reader back to the corresponding section of Part 1.

Note on figures and product specifications: text descriptions, figures and architectural diagrams in this guide reflect the target architecture of the BifrostConnect product family. Some components (including AccessGuard and SessionGuard) and some governance patterns (including per-session approval workflows) are deployed where the regulatory regime or operational governance requires them, and may not be present in default deployments. Specific feature availability per plan tier and per release phase is documented separately in current product documentation; reach out to BifrostConnect for the latest availability matrix.

Part 1 defines four scenarios, a threat model, two complementary architectural lenses (Purdue topology and OT Island direction), and a single operational principle (Zero Standing Privilege). Part 2 is organised around the same structure. The table below shows the mapping.

Part 1 distinguishes two fundamentally different access models. Part 2 uses these consistently throughout:

• Hardware-based KVM/console access (Direct Native Access): The operator receives a video stream of the endpoint’s display via WebRTC. No network-layer connectivity is established. The operator’s device never joins the OT network and has no IP-level access to OT assets. The trust boundary is physical hardware.
• Session-scoped IP tunnels (Direct Tunnel Access): The operator’s device receives scoped subnet-level IP connectivity to specific endpoints for the session duration. This is temporary network-layer connectivity, tighter than VPN but fundamentally different from KVM. The operator’s device can send packets to specified OT endpoints within the tunnel scope.

These are not equivalent security models. KVM provides isolation without network participation. IP tunnels provide scoped network participation with session controls. Both implement Zero Standing Privilege but at different layers.

Part 1 defines Zero Standing Privilege as ‘session-based access, closed by default’. No user should hold a pre-existing, persistent path into the OT network. Access is policy-authorized in advance, opened on session start, used, recorded and torn down, in that order, for every session.

BifrostConnect implements this through administrator-defined access policy in Bifrost Manager (per-user, per-Unit, per-subnet), session-based teardown for Direct Native Access (KVM, SSH, Serial), and time-bound subnet mappings for Direct Tunnel Access (Time-Based Access on Advanced plan and Dedicated Cloud tier). Per-session approval workflows, where a vendor request triggers explicit administrator confirmation before the session opens, are an architectural extension that can be deployed where the regulatory regime or operational governance requires it; the underlying policy engine in Bifrost Manager is designed to support this pattern.

The architecture is realized through the Bifrost Unit’s outbound-only posture. The Bifrost Unit maintains only an outbound connection to the BifrostConnect Service on port 443 (WebRTC and MQTT over WSS). No inbound port is open on the OT network. For KVM/console sessions (Direct Native Access), no network-layer connectivity is established at all; the operator sees a video stream without joining the OT network. For IP tunnel sessions (Direct Tunnel Access), scoped subnet-level connectivity is established for the session duration only, with unsolicited inbound traffic blocked by default.

Part 1 introduces the OT Island Principle as a directional complement to Purdue: OT calls out, OT never receives. Architecturally, BifrostConnect implements this principle: the Bifrost Unit initiates outbound connections to the BifrostConnect Service; it accepts no inbound connections. The OT environment remains an island. The Bifrost Unit is the enforcement point of the outbound-only principle at the OT boundary.

The outbound-only posture does not by itself require hardware: a software agent can also be outbound-initiated. The Bifrost Unit exists as dedicated hardware for the trust properties a software agent running on a customer-managed OT host cannot guarantee. Its SoC secure-boot fuses are burnt at manufacture and are non-reversible, so it cannot boot alternative firmware; it runs a stripped industrial Linux with no local users, no SSH, no local web services, and no physical service or debugging ports; firmware updates are signed and delivered over-the-air only; and its battery and built-in LTE provide an out-of-band path independent of the customer network. A general-purpose host running a software agent inherits that host’s users, services, patch state, and exploitable surface; the dedicated Unit does not.