--- title: Core Framework description: "The five core principles What are the five core principles of the third-party OT access framework? 1 Zero standing privilege Access exists only inside a bounded window; before and after, privilege is zero. Dedicated section below 2 The OT island…" url: "https://bifrostconnect.com/knowledge-center/core-framework/" updated: "2026-07-08" category: Best Practice Guide --- # Core Framework The five core principles What are the five core principles of the third-party OT access framework? 1 Zero standing privilege Access exists only inside a bounded window; before and after, privilege is zero. Dedicated section below 2 The OT island principle OT initiates outbound; OT does not accept inbound. Dedicated section below 3 Defence in depth No single control is load-bearing; six layers wrap the asset, including session evidence and monitoring so that misuse is detected and answered, not only prevented. Dedicated section below 4 Minimum viable controls scale to context The same five common control gates (identity, authorisation, session evidence, kill-switch, supply-chain assurance) apply across every pattern, but the implementation depth scales with maturity. Cross-cutting 5 Verification over assumption Every claim in this guide is anchored in a verifiable clause; every implementation should be acceptance-tested. Cross-cutting ℹ Principles 1, 2, and 3 each anchor a dedicated section later in this guide. Principles 4 and 5 are cross-cutting and applied throughout the patterns and methodology. THE FOUR ACCESS PATTERNS AT A GLANCE What are the four OT access patterns at a glance? | Pattern | Where it applies | Primary control | | --- | --- | --- | | **A · Large OT, customer station** | Utility, pharma, large-scale industrial – station owned and managed by customer | Enterprise IAM + jump host + PAM wraps the existing station | | **B · Large OT, vendor laptop** | Large-site commissioning – vendor laptop enters the network | NAC + vendor DMZ + OT-IDS contain an untrusted device | | **C · Small OT, customer station** | Small water utility, district heating – station present, no IT staff | Control sits at the station: local identity + offline MFA + recording + log export | | **D · Small OT, vendor laptop** | Hardest case: small utility plus vendor-owned device with no enterprise infra | Hardware broker at the boundary: scoped access + session evidence + log export | Each pattern is treated in full under Four OT Access Patterns later in this guide. The table above is the at-a-glance version; the detailed sections give the per-pattern controls, framework anchors, and failure modes. Recommended first actions (30 days) What are the recommended first actions to take within 30 days to improve third-party OT access security? 1 Inventory every active third-party remote-access path into OT 2 Verify default credentials have been changed 3 Enable session logging on existing remote-access channels 4 Identify the assets that fall under each of Patterns A through D 5 Plan migration of any always-on tunnel toward time-bounded access The detailed phase plan is in section Implementation priority. Scope note — IEC 62443-2-1:2024 This guide is one element of a complete cybersecurity programme. 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 third-party access; readers building a complete OT cybersecurity programme should treat it as one chapter, not the whole book. THE CENTRAL INSIGHT What is the central insight about third-party remote access risk in OT environments? Every remote session a third-party vendor opens into Operational Technology is a potential supply-chain risk vector. The risk is rarely the vendor alone; it is the architecture that lets a single set of standing credentials become a standing path into a Programmable Logic Controller (PLC) or Supervisory Control and Data Acquisition (SCADA) station, compounded where the supplier's own security maturity is low. The problem is not Virtual Private Network (VPN) as a technology. NIST SP 800-82 Rev. 3, Guide to Operational Technology (OT) Security, recognises VPN as a valid component of strong authentication and encryption for remote access. The 2015 attack on the Ukrainian power grid is the canonical illustration: adversaries operated SCADA through legitimate remote access and stolen VPN credentials, not through a flaw in VPN itself. The problem is flat, persistent, multi-purpose remote access without per-session brokering, time-bounding, or evidence. The fix is brokered, time-bound, recorded, and revocable access. This guide presents that pattern in vendor-neutral terms, anchored in eight frameworks: the EU NIS2 Directive (2022/2555); the Danish NIS2 implementation (LOV nr. 434 af 6. maj 2025 - Lov om foranstaltninger til sikring af et højt cybersikkerhedsniveau); BEK nr. 260 af 6. marts 2025 with the underlying Danish law on resilience and preparedness in the energy sector; the IEC 62443 series, specifically IEC 62443-3-3:2019 (system security requirements), IEC 62443-2-4:2024 (service provider security programme), and IEC 62443-2-1:2024 (asset owner cybersecurity programme); NIST SP 800-82 Rev. 3, Guide to Operational Technology (OT) Security (2023); NIST SP 800-207 (Zero Trust Architecture, 2020); the joint UK-led NCSC Secure Connectivity Principles for Operational Technology (published 18 March 2024); and the joint US-led CISA Adapting Zero Trust Principles to Operational Technology (29 April 2026). Where a claim cannot be traced to a specific verified clause, this guide does not make it.