Security Architecture Reference

Part 1 closes with a residual-risk section listing what no architecture can solve on its own. This section is the deployment-side companion: a deliberate enumeration of what BifrostConnect does not protect against, written so the procurement reviewer, the auditor, and the security architect see the same boundary the engineering team does. The intent is operational honesty, not understatement of capability.

Compromise of the vendor endpoint before the session opens. If a vendor laptop is already compromised with a keylogger, a remote-access trojan, or in-process malware, the BifrostConnect session faithfully transports whatever the operator does on that laptop. SessionGuard is designed to capture the evidence; AccessGuard is designed to scope the application surface; neither prevents legitimate-looking malicious instructions from reaching the OT endpoint during an authorised session. Mitigation lies in vendor endpoint hygiene contracts, EDR on the technician PC, and (where the workload allows) preferring Direct Native Access (KVM) over Direct Tunnel Access so the vendor PC does not gain IP-layer access at all.

Compromise of the identity provider or MFA layer. BifrostConnect relies on Auth0 for Manager-side MFA and on the customer’s federated identity provider for SSO on Dedicated Cloud and on-premises tiers. A compromise of Auth0 or of the customer IdP undermines the identity binding of every session that depends on it. The Hardening Manager Admin Governance section names the deployment options that reduce the blast radius (federation, hardware-token MFA, IP allowlisting, four-eyes principle on policy changes); the residual exposure is the assurance level of the upstream identity infrastructure itself.

Misuse during a legitimately approved session. An authorised technician within an approved session retains authority for the duration of that session. Session recording (where deployed) and SIEM-forwarded alerts on anomalous command sequences support detection and revocation; they do not prevent the action while it occurs. This is the classic insider-threat residual that Part 1 addresses through the procedural controls (background checks, two-person rules for high-risk work, separation of approval authority).

Threat vectors outside the third-party access scope. Phishing of asset-owner staff, IT-side compromise that pivots into OT through other paths, SOHO-router compromise of the kind Volt Typhoon uses, supply-chain attacks on the OT software the vendor ships, physical-access attacks on the Bifrost Unit hardware, and protocol-level vulnerabilities in the OT endpoint itself are all outside what a remote-access broker can address. BifrostConnect occupies the access-and-governance layer; complete OT defence requires the layered architecture Part 1 describes, with EDR on stations, OT-IDS on the wire, NDR for east-west monitoring, and the procedural and contractual controls Part 1’s residual-risk section enumerates.

Naming these limits is itself part of the control envelope. A buyer who knows where BifrostConnect ends can build the rest of the programme without misplaced confidence; a buyer who does not, will discover the limits during an incident.

Based on BifrostConnect Security Documentation, Version 2.2.2 (2026).

Management plane, the four access methods, and the twelve security properties of the system: Bifrost Manager (control plane) → Bifrost Unit (outbound-only, port 443) → Direct Native Access, Direct Tunnel Access, Clientless Tunnel Access, each with a session governance add-on (SessionGuard and/or AccessGuard).

1. TLS 1.2 / 1.3 control plane
2. WireGuard (ChaCha20-Poly1305) for DTA
3. WebRTC DTLS-SRTP for DNA (end-to-end)
4. Private keys never leave the client
5. TURN relay cannot decrypt traffic
6. Outbound-only, single port 443
7. No SSH, no local web services or users
8. SoC secure-boot fuses (non-reversible)
9. Signed, OTA-only firmware
10. Auth0 multi-factor authentication
11. SSO (SAML / OAuth2 / AD / LDAP)
12. Least-privilege roles + JIT access

• Control plane: TLS 1.2 or 1.3 for all HTTPS endpoints and MQTT over WebSocket Secure.
• WireGuard for Direct Tunnel Access traffic, based on Netbird, using ChaCha20-Poly1305 AEAD with Curve25519 ECDH and BLAKE2s (the WireGuard cipher suite).
• WebRTC with DTLS-SRTP for session-based access (Direct Native Access). End-to-end encrypted between browser and Bifrost Unit.
• Private WireGuard keys never leave the client machine.
• Relay service operates as a TURN server and cannot decrypt traffic it relays.

WireGuard cipher suite per the WireGuard whitepaper at https://www.wireguard.com/papers/wireguard.pdf. Retrieved 2026-05-07.

• Auth0 multi-factor authentication for the Bifrost Manager.
• SSO via SAML, OAuth2, AD, LDAP (Dedicated Cloud / on-premises).
• Least Privilege role model: Privileged User operates within assigned groups; Admin operates within organisation.
• Just-in-Time: session-based access types terminate at session end; Direct Tunnel Access subnet mappings can be time-based or permanent.
• Audit logging for tracking, recording and reviewing actions across the client organisation.

• Attended Units: TOTP generated by physical button press, 60-second default lifespan (configurable by admin). Operator must log in to the Manager or browser session with credentials plus 8-digit TOTP.
• Unattended Units: admin-initiated access via Manager with credentials + MFA. TOTP not applicable.
• Each Unit is either Attended or Unattended; selection is embedded for the product lifespan.

• Session duration, count, WAN IP of Bifrost Unit, approximate location (cell tower-based for 4G), battery and signal strength, traffic statistics, unique serial.
• No session content is stored. No GPS on the Bifrost Unit.
• Data stored within BifrostConnect infrastructure. No telemetry shared with Netbird. WiFi passwords hashed on the Unit, not stored in the Service.