The Bifrost Manager is the governance control plane: user provisioning, group membership, access policy, audit log retention, SIEM forwarding. Admin compromise is therefore a high-impact event. The deployment options below make admin compromise harder and detection faster.
Architectural properties already in place:
- Mandatory MFA on Manager admin accounts (Auth0). MFA is not optional and cannot be disabled at the org level.
- Audit logging captures every admin action (group changes, policy edits, user provisioning). Forwarded to customer SIEM on Dedicated Cloud / on-premises tiers.
- Least-Privilege role model: Privileged User scope is bound to assigned groups; Admin scope is bound to the organisation. Scope creep requires an explicit role change.
Deployment options to harden further:
- Federate admin sign-in to your enterprise IdP, then apply hardware-token MFA, conditional access, and impossible-travel rules already in place for IT admins.
- On Dedicated Cloud / on-premises, restrict Manager access to specific IP ranges or VPN-only paths. The Manager becomes a corporate-network application rather than an internet-exposed one.
- Forward Manager admin actions to SIEM and tune detection rules: bulk group-membership changes, sudden policy relaxations, off-hours admin sign-ins, role escalations.
- Operate a four-eyes principle on policy changes: require a second admin to approve material changes to access scope. Document the approval in the runbook so it is auditable. For organisations where four-eyes must be product-enforced rather than procedurally enforced, the Bifrost Manager policy engine is designed to support this pattern.
- For multi-customer service providers, deploy separate Manager tenants per customer engagement to prevent cross-tenant data bleeding at the governance layer.
Cross-reference: Part 1, Compliance maturity matrix.
Part 1’s compliance maturity matrix distinguishes ‘required’, ‘best practice’ and ‘structurally unsolvable’. This section is the deployment-side companion: each subsection names a deployment decision and the secure-by-default implementation that delivers the compliance evidence Part 1 calls for. The intent is to ship a hardened deployment, not to enumerate gaps.
Enforced session recording is the evidence backbone of every scenario. Choose the recording layer that matches where the programming software lives:
- Software on engineering station (Scenarios 1 and 2): deploy AccessGuard. H.264 video, DPAPI-encrypted at rest on the station.
- Software on vendor PC (Scenarios 3 and 4): the recording layer is SessionGuard, designed to capture WebRTC screen and keystrokes into a customer-deployed VM.
- For protocol-level evidence (Modbus, OPC UA, S7comm, IEC-104): co-deploy an OT-IDS that captures the wire side. The two recording layers together give the complete forensic chain.
The ‘forced session recording, no matter where your programming licenses are located’ claim holds when the appropriate layer is deployed. The deployment step is what makes the claim real; treat it as part of go-live, not as an optional feature.
Personal data note. Session recordings produced by SessionGuard or AccessGuard typically contain personal data within the meaning of the EU General Data Protection Regulation (GDPR). The technical enforcement described here does not remove that obligation: the deployment architect must define a retention period, storage location and access control, data-subject rights handling, and a lawful processing ground for the recordings, independently of NIS2 status. See Part 1, ‘Personal data note’, for the principle-level statement.
SessionGuard is designed to run on a customer-deployed and customer-maintained VM, one per vendor engagement. Plan the VM as a first-class deployment artefact, not an afterthought:
- Build, ownership and patch responsibility assigned before the first session – typically OT operations or central IT.
- Customer-controlled storage for recordings so the evidence chain is auditable and never leaves the customer’s perimeter.
- Acceptance test as a go-live gate: confirm (a) sessions cannot start when the VM is unreachable, (b) recordings land in customer storage, (c) tampering alerts reach the SOC. Document the test result in the runbook.
- Per-engagement isolation: separate VMs for separate customer-vendor relationships so cross-tenant evidence cannot bleed.
AccessGuard operates as a localhost-only agent on the engineering station, bound to 127.0.0.1:7531. The vendor accesses it from the engineering station itself; the agent is not exposed on the OT network, which prevents lateral movement. The supported delivery path is the AccessGuard browser session itself; KVM switches, TeamViewer and AnyDesk are out of scope.
Make AccessGuard the only authorized vendor delivery path on the station, and remove or block the others as part of the access policy. The recorded path becomes the only path – which is the evidence model the auditor expects. AccessGuard’s feature set and hardening continue to mature; track product release notes alongside scheduled operations changes.
- Direct Tunnel Access client (macOS and Windows, installed lightweight client): supports multi-user parallel access and subnet mapping. Does not currently support port-forwarding. Use when the vendor’s workflow benefits from one-to-many or many-to-one access patterns through the Bifrost Manager, and the technician PC can have the lightweight client installed.
Out of the box on the Plug & Play plan, Direct Tunnel Access subnet mappings are permanent. Organisations operating under NIS2 Art. 21(2)(i) or BEK 260 §55 stk. 2 should operate Bifrost Manager on the Advanced plan or Dedicated Cloud tier, which enables Time-Based Access for Direct IP Tunnel so subnet mappings inherit a default time bound. This converts the default-permanent posture to default-just-in-time, which matches the Zero Standing Privilege framing in Part 1.
Direct Native Access streams video via WebRTC. It carries the highest isolation (no IP path) and is the right default for screen-level commissioning, incident response, and legacy gear interaction. For high-latency WAN paths or slow LTE links, prefer Direct Tunnel or schedule the work over a higher-bandwidth path. Match the access model to the task; do not retrofit by exception.
A Bifrost-to-Bifrost tunnel (Clientless Tunnel Access) requires a Bifrost Unit on both the operator and the OT environment side. The hardware footprint doubles, but so does the control plane: the tunnel terminates on dedicated hardware on each end, with no general-purpose laptop in the path. Deploy this pattern when the assurance level demands it – typically BEK 260 §62 segmentation requirements during vendor access on Class 1 or 2 sites.
Native SIEM forwarding and enterprise SSO (SAML 2.0, OAuth 2.0, AD, LDAP via Auth0) are delivered on BifrostConnect Dedicated Cloud and on-premises Manager tiers. Procure the right tier at the start so the SSO trust chain and SIEM correlation pipeline are established before the first vendor session – retrofitting after go-live is a documentation burden the rollout can avoid.
Service providers and vendor technicians servicing multiple customers should isolate each engagement deliberately:
- Separate SessionGuard VMs per customer engagement. Recordings never share storage between customer relationships.
- Separate Bifrost Manager tenants for separate customer contracts; or, where a single tenant is preferred, scoped groups with explicit tenant-level access boundaries.
- Document the isolation model in the engagement contract so the customer auditor can trace the segmentation evidence.
Remote firmware updates are moments of heightened risk on OT assets. The Bifrost Unit’s own firmware updates are signed, postponed during active sessions, and verified before application. For OT endpoint firmware updates conducted through the Unit, layer compensating controls so the update path matches the evidence requirements:
- Stage the firmware on a customer-controlled file server before the session, not on the vendor’s laptop.
- Validate hash and signature against the vendor’s published baseline before the update is applied.
- Test rollback in a non-production environment first; confirm the rollback path works.
- Record the entire update session in SessionGuard or AccessGuard so the change is reconstructable.