Architecture & Principles

This guide describes requirements and principles, not a specific architecture. Organisations may implement these requirements through various architectural approaches including but not limited to: VPN combined with Privileged Access Management, hardware-enforced network segmentation with out-of-band access broker, cloud-brokered session management, traditional jump-host designs with strict access governance, or hybrid combinations thereof. Where this guide describes specific implementation patterns (for example brokered, time-bounded sessions in Figure 2 panel B), the patterns are illustrative of how the principles can be satisfied, not the only architecture that satisfies them.

Chief Information Security Officers (CISOs), OT security architects, compliance officers, and risk managers at critical infrastructure operators. Also relevant for system integrators, vendors performing remote work into customer OT, and auditors evaluating third-party access controls.

This guide covers third-party remote access to OT systems via controlled conduits, where a human operator (vendor technician, engineer, integrator) initiates a session into operational technology. Out of scope: physical site access, IT-only systems above the demilitarised zone (DMZ), the broader OT-IT convergence in the office layer, and machine-to-machine (M2M) traffic between OT components. M2M access does not involve a human session and therefore cannot be addressed by session brokering or recording; for device-level identity and authentication of M2M traffic, readers should reference IEC 62443-4-2 (technical security requirements for IACS components). The guide is deliberately vendor-neutral; it names control patterns and standard clauses, not products.

Every claim in this guide is traceable to a clause-level entry in the source citations below, which records verbatim primary citations from the official PDFs and licensed standards: NIS2 (EU 2022/2555), the Danish NIS2 implementation act (LOV nr. 434 af 6. maj 2025), BEK nr. 260 af 6. marts 2025 for the energy sector, NIST SP 800-207, NIST SP 800-53 Rev. 5, NIST SP 800-82 Rev. 3, and the IEC 62443 series, specifically DS/EN IEC 62443-3-3:2019 (system security requirements), DS/EN IEC 62443-2-4:2024 (service provider security program requirements), and DS/EN IEC 62443-2-1:2024 (asset owner cybersecurity programme requirements). The guide also draws on the joint UK-led Secure Connectivity Principles for Operational Technology (NCSC et al., published 18 March 2024) and the joint US-led CISA Adapting Zero Trust Principles to Operational Technology (CISA, DoW, DOE, FBI, DOS with NIST contributions, 29 April 2026). Empty cells in the compliance crosswalk (Figure 7) are deliberate and labelled with the reason; they are honest gaps, not fabricated coverage. Per IEC 62443-2-1:2024, asset owners are required to maintain a cybersecurity management system (CSMS) covering risk analysis, access control, supplier governance, and incident response. This guide addresses one element of that programme: third-party operational technology access. Readers building a complete OT cybersecurity programme should treat this guide as one chapter, not the whole book. Two distinct claim types appear in this guide. REQUIREMENT statements reproduce the wording of a specific legal or standards clause and carry a direct citation to its source PDF. GUIDE INTERPRETATION statements express this guide’s reading of how a requirement should be met in practice; they build on primary text but add engineering judgment. The two are distinguished in-line where the distinction is load-bearing for an audit reader, using the labels REQUIREMENT and GUIDE INTERPRETATION in bold small caps.

BifrostConnect is the publisher of this guide and is itself a third-party vendor inside its own customer environments. The same principles advocated here – brokered, time-bound, recorded, and revocable access – govern BifrostConnect’s own operational and support access to customer systems. This guide presents an architectural pattern that would hold even if BifrostConnect were not the publisher; the pattern is intellectually consistent with how any serious third-party vendor, including this one, should be treated by an asset owner. The architectural patterns described in this guide align with the publisher’s product approach, which may create blind spots regarding alternative architectures; readers are encouraged to read the Architectural neutrality section above and to evaluate alternative implementations on their own merits. Product-anchored implementation detail is deliberately deferred to the companion document BifrostConnect Implementation Guide (Del 2).

Before any control discussion, this guide adopts the Purdue Model as a shared vocabulary for OT zones. The model originated in the Purdue Enterprise Reference Architecture (Theodore Williams, 1990) and was subsequently adopted by ISA-95 / IEC 62264 and by NIST SP 800-82 Rev. 3 as the standard reference frame for industrial control system (ICS) topology. Level 3.5 is an industrial DMZ layer that sits between Level 3 and Level 2; it is not a Purdue level in the original sense but is consistently treated as a named zone in modern OT architectures and in NIST SP 800-82 Rev. 3. Six Purdue levels, plus an industrial demilitarised zone (DMZ) at Level 3.5, from top to bottom: Level 5 Enterprise (Enterprise Resource Planning, Customer Relationship Management, business email); Level 4 Business Logistics (Manufacturing Execution Systems, scheduling); Level 3 Site Operations (historian, plant-level analytics); Level 3.5 the OT demilitarised zone (jump host, vendor proxy); Level 2 Area Supervisory (Human-Machine Interface, SCADA); Level 1 Basic Control (PLC, Remote Terminal Unit); Level 0 Physical Process (sensors, actuators). The deeper the zone, the higher the blast radius and the fewer the legitimate remote-access use cases. Third-party access typically targets Levels 2 and 1, where engineering tools meet controllers. That is the zone this guide is about.

Figure 1. The Purdue Model. Six Purdue levels plus an industrial DMZ at Level 3.5, with blast radius increasing from Level 5 to Level 0. Third-party access typically targets Levels 2 and 1. Source: ISA-95 / IEC 62264 reference architecture; NIST SP 800-82 Rev. 3.

A single directional rule governs the architecture of every defensible pattern in this guide: OT calls out (initiates outbound). OT never receives. The operational zone initiates outbound sessions to an external broker when work is needed; the zone does not accept inbound connections from any external network. Inbound paths are structurally absent, not blocked by configuration. This principle is the shape common to Patterns A through D, and it is the structural answer that lets a single pattern satisfy disparate regulatory regimes at once. Anchors. NIST SP 800-207 Tenet 3 (per-session access) and Tenet 6 (dynamic, strictly enforced authentication and authorisation) together describe an access model in which the resource does not listen for callers; the caller requests, and a policy engine grants. IEC 62443-3-3 SR 1.13 (access via untrusted networks) requires the control system to monitor and control all methods of access to the control system via untrusted networks; the cleanest way to monitor and control is to not accept them inbound at all. The OT Island Principle is the architectural phrasing of these two anchors. Brownfield reality. Most OT environments contain legacy systems that require inbound connections, lack outbound-only capability, or run protocols pre-dating modern segmentation. The OT Island Principle remains the target for new builds, refurbishments, and any system whose vendor offers a path to outbound-only operation. Where migration cannot be immediate, compensating controls shall include continuous monitoring of inbound paths, strict session time-boxing, VLAN isolation of legacy segments, and an explicit migration plan with a verified end date. The principle is the destination toward which exceptions migrate.

Two regulatory shifts make 2024 to 2026 the inflection point for third-party OT access. First, the EU NIS2 Directive (2022/2555) replaced checklist compliance with outcome-based, board-accountable risk management. Article 21(2) names ten technical and organisational measures that essential and important entities must implement. Three of them bear directly on third-party access: litra (d) supply-chain security, litra (i) human resources security, access control policies and asset management, and litra (j) multi-factor authentication. Second, in the Danish energy sector, Lov om styrket beredskab i energisektoren §§ 6, 7 and 8 codify the same direction at national law. §6 stk. 2 nr. 3 requires identification and access-control policies that protect against unauthorised access. §6 stk. 2 nr. 7 imposes supply-chain security between the entity and its direct suppliers and service providers. §8 stk. 2 nr. 6 requires logging that supports alarms, investigation, and incident handling. §8 stk. 2 nr. 10 requires MFA or continuous authentication and access protection against unauthorised access. BEK 260, the executive order issued under this law, derives its technical detail directly from §§ 6 to 8. The pattern is consistent across both instruments: the regulator is no longer asking whether the firewall is configured. The regulator is asking who accessed what, when, for what work, with what approval, and where the evidence is. This guide answers those questions in pattern terms.