Scenario Implementation – Scenario 3

Part 1 defines four scenarios derived from two axes: where the programming software is located (engineering station vs vendor PC) and the scale of the OT operation (small with no SOC vs large with SOC, PAM, SIEM). Each scenario maps to a specific BifrostConnect product mix.The figure below shows the four implementations side by side. The detailed configuration for each scenario follows in the next four sections.

Part 1 requirement recap: Small utility, software licensed on the vendor technician’s own PC (common for Danish water sector). The vendor travels to the site with their own laptop and connects it to the OT network. Part 1 identifies this as the highest proportional risk: an uncontrolled device in direct contact with PLCs, with no enterprise IT to harden it.

BifrostConnect implementation. Primary products: Unattended Bifrost Unit + Direct Tunnel Access + SessionGuard (enforced session recording to a customer-controlled log server when deployed per the hardening guidance) + Bifrost Manager. The SessionGuard recording engine is designed to be packaged with the Direct Tunnel Access client and must be installed on the technician PC.

Configuration:

• Bifrost Unit deployed on the OT network as the access gateway. Unattended variant is the canonical default (admin-initiated session via Manager + MFA + mobile-app verification); the attended variant is selected where on-site personnel must physically authorise each session via the Unit’s TOTP button.
• Bifrost Unit maintains outbound-only connection to BifrostConnect Service on port 443 (4G or WAN). OT Island principle enforced: outbound only, no inbound port open.
• Vendor PC connects via Direct Tunnel Access (WireGuard tunnel, scoped to specific subnet/IP) or Direct Native Access (browser KVM, no network-layer connectivity). The choice determines the security profile.
  • Direct Native Access (KVM): vendor PC has zero network access to OT assets. Video stream only. Highest isolation.
  • Direct Tunnel Access: vendor PC gets scoped, temporary IP connectivity. Necessary when vendor software must send IP traffic to PLC. Lower isolation than Direct Native Access but still session-scoped and recorded.
• SessionGuard is designed to deploy on a customer-owned recording VM per vendor engagement. WebRTC screen capture and keystroke logging flow directly from the vendor operator console to the customer’s VM by design.
• Physical masquerading on the Bifrost Unit ensures only the Unit’s IP is visible to OT equipment.
• TOTP button on the attended Unit enforces on-site consent for every session.

Compliance evidence mapping (Part 1, Scenario 3 regulatory alignment):

Implementation requirements for Scenario 3. Scenario 3 is the highest-risk quadrant by Part 1’s analysis (vendor PC, small OT). The following deployment decisions make the BifrostConnect control envelope hold:

• Recording layer ownership: SessionGuard is designed to capture the operator’s screen and keystrokes. Pair it with OT-IDS co-deployment when protocol-level evidence on Modbus / OPC UA / S7comm is also required – the two recordings together produce the complete forensic chain.
• Recording VM as a deployment dependency: SessionGuard is designed to run on a customer-deployed VM per engagement. Schedule the VM build, ownership and patch responsibility before the first vendor session. The recording claim is real once the VM is in place.
• Acceptance test as a go-live gate: validate three properties before the first production session: (a) the session cannot start when the recording VM is unreachable, (b) recordings land in customer-controlled storage, (c) tampering alerts reach the SOC. Document the test result in the rollout runbook.
• Operator-side platform: deploy the Direct Tunnel Access client (installed lightweight client on macOS / Windows; supports multi-user parallel access and subnet mapping). Match the deployment to the vendor’s tooling rather than retrofitting later.
• Access model selection: when KVM (Direct Native Access) covers the vendor’s task, use it – the vendor PC then has zero IP path to OT. Reserve Direct Tunnel Access for tasks that genuinely need IP-level interaction (e.g. firmware uploads, multi-port debug). Documenting the choice per task closes the audit trail.

Maturity profile: minimum viable vs target state (Scenario 3). Scenario 3 is Part 1’s highest-risk quadrant. Minimum viable closes the BEK 260 §§29-32 (supplier procedures), §§51-53 and §55 stk. 2 and NIS2 supply-chain gap; target state adds the depth needed for sites where the regulator will examine the deployment after an incident.