Architecture & Differentiation

Cross-reference: Part 1, Implementation approaches.

Part 1 notes that a best-practice OT remote access architecture must close the path when no session is active, bind every action to a named individual, and keep the trust boundary out of the enterprise attack surface.

This section shows how BifrostConnect differs architecturally from the three most common alternatives in the context of OT access. The comparison applies to trust boundary placement in OT environments specifically. Modern Zero Trust and SASE architectures address related problems in IT environments through different patterns; the discussion below is deliberately scoped to OT.

Three questions that expose the difference (in OT context):

• Where is the trust boundary? In a VPN it is the network edge; in ZTNA it is a cloud broker; in a jump host it is a reachable server; in BifrostConnect it is a physical hardware device the operator never logs into. In OT, a trust boundary that requires inbound connectivity is a trust boundary that can be probed, scanned, or exploited from the vendor or internet side.
• What is the attack surface when no session is active? A VPN concentrator on the OT boundary is always on. A jump host in the DMZ is always listening. BifrostConnect’s Bifrost Unit maintains only an outbound connection and listens on no inbound port. This is the OT Island principle in practice: OT calls out, OT never receives.
• What is the failure mode if the broker is compromised? A compromised VPN concentrator exposes the OT network. A compromised jump host gives an attacker a dwell position inside L3. A compromised Bifrost Unit cannot be reached inbound, cannot be logged into locally, and cannot boot alternative firmware. The Service-side trust boundary is a separate hardening surface (see Architectural transparency below).

Architecturally, BifrostConnect implements the OT Island Principle. OT initiates outbound, OT never accepts inbound. The Bifrost Unit is the enforcement point of that principle at the OT boundary. The consequence is that the OT environment remains an island: reachable only through explicitly activated, time-limited, identity-bound sessions brokered by the Bifrost Unit’s outbound connection.

BifrostConnect occupies the access-and-governance layer. Defence in depth keeps each layer with its specialist. The following pairings produce a stronger architecture than any single product attempting to cover the full stack:

• Endpoint Detection and Response on engineering stations: keep your EDR vendor for malware detection on the station. AccessGuard governs who connects and what they do; EDR observes what runs once they are in. The two are complementary recording layers.
• Network intrusion detection on the OT network: keep an OT-IDS for protocol-level DPI. Co-deploy alongside BifrostConnect, with both feeding the SIEM. Correlation produces the joint forensic view that neither product alone can.
• Credential vaulting at enterprise scale: keep your PAM platform for credential rotation and vaulting. BifrostConnect sits upstream as the access-and-audit layer. Mapping ownership cleanly avoids overlap and keeps the credential audit trail in PAM.
• Industrial telemetry backbone: BifrostConnect is the governance-and-access layer for human sessions; keep your industrial telemetry transport (OPC UA aggregator, MQTT broker, historian) for continuous machine-to-machine data flow.
• IT remote access: for enterprise IT with standard endpoints and SaaS applications, ZTNA platforms cover the IT use case. BifrostConnect is the OT-specific complement – keep both, scoped to their respective domains.

Cross-reference: Part 1, Implementation approaches.

BifrostConnect is the governance and access layer. Defence in depth requires monitoring, inspection and isolation layers. The relationships below are co-deployments: BifrostConnect and the co-deployed products operate independently on the same network, correlated at the SIEM layer. Unless stated otherwise, there is no API-level integration with shared data model or certified integration tests.

Matrix – suggested optional co-implementations: