Company
Support
Login
Book a Demo
Contact Us
View Categories

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?
PatternWhere it appliesPrimary 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.