In October 2025, the UK’s National Cyber Security Centre (NCSC) released new guidance on using Privileged Access Workstations (PAWs) in Operational Technology (OT) environments. This guidance builds directly on NCSC’s core Principles for Secure Privileged Access Workstations, published earlier in March 2025, and adapts them for the realities of industrial environments.
At a high-level, the message is straightforward:
High risk access to OT systems should only occur from highly trusted devices.
But as anyone who has spent time in a control room, plant floor, or substation knows, translating that principle into practice can be anything but simple. This post reviews the key ideas in the NCSC guidance, highlights what it gets right, and (more importantly) provides practical advice for implementing and securing PAWs in real OT environments without breaking operations or engineer workflows.
Why PAWs Matter More in OT
The NCSC starts from a premise that most OT practitioners already understand intuitively: the consequences of compromise in OT are fundamentally different from IT. Some of the reasons why include:
- Compromise can create immediate safety risks
- Impacts can cascade into national-scale disruption
- Legacy and obsolete systems are common
Because of these differences, the guidance emphasizes that OT access must be treated as “high-risk” far more than would be the case in IT environments. In particular:
- Administration, configuration, and control functions are always high-risk
- In obsolete or unsupported systems, even monitoring access may need to be treated as privileged
- Identities used to access OT must be segregated from IT identities to prevent lateral movement
This framing is critical. Many OT incidents don’t start with a sophisticated exploit. They start with credential reuse, shared engineering workstations, or compromised laptops which are connected “just this once” for just “this one small thing.”
Engineering Workstations are PAWs (Whether you call them that or not)
One of the strongest aspects of the guidance is its explicit acknowledgement of how OT works, stating plainly that Engineering Workstations (EWs)1 already are privileged access workstations, even though they may have not been treated as such in the past. It identifies three types of EWs which are generally used in industry:
- Fixed workstations: Physical systems located onsite in the OT environment, they are often isolated from other networks, but shared by multiple people, often with shared accounts.
- Remote access: Systems used for remote administration or control of OT systems, generally using specialized software.
- Local access: Portable devices for provisioning, maintenance, or support of OT devices, generally connected to the field devices using USB, serial, ethernet, or (more recently) Bluetooth.
Rather than ripping out and replacing EWs, organizations should apply PAWs principles to protecting them.
Obsolete Systems Change the Trust Model
A recurring theme throughout the guidance is the prevalence of obsolete products, not just unsupported operating systems, but software and devices that lack basic security controls.
This has two important implications:
Application-level role separation may be meaningless
On legacy SCADA systems, privilege escalation vulnerabilities or insecure protocols make it unsafe to assume that users with “monitoring” access are low risk.
More users may require PAW-based access than expected
In high-impact environments, the NCSC recommends treating all access (including monitoring) as privileged as any compromise could have serious consequences.
This aligns closely with what we see in the field. Many organizations believe they have role separation, but those controls exist only on paper.
Air Gaps vs. Constrained Connectivity: A Needed Reality Check
The section of the guidance which will likely generate the most controversy is the section which addresses air-gapped PAWs, saying that rather than being a cure-all, truly air-gapped, isolated PAWs create long-term security and operational risks.
The guidance identifies several anti-patterns that will be familiar to most OT teams:
- Isolated systems that never receive security updates
- No visibility into privileged actions along with lack of centralized logging
- Per-device configuration drift over time
- Increased reliance on USB drives and other uncontrolled transfer mechanisms
Instead, the guidance recommends highly constrained connectivity, not isolation. That may include:
- Access to update services
- Licensing servers
- Vendor support portals
- Centralized management and/or logging
Crucially, the guidance also stresses resilience:
- PAWs must still operate safely if connectivity is lost
- Fallback identity and management mechanisms must be implemented and tested
- Isolation should be a deliberate response to threat scenarios, not the default state
This “constrained connectivity” needs to be enforced for all access, including vendor or system integrator remote access. This leads to a more mature posture and allows for incident response to be implemented in a quicker, more thorough manner.
Practical Tips for Implementing PAWs in OT
Based on both the NCSC guidance and real-world deployments, here are practical steps that help PAW management programs succeed.
Start with Use Cases, Not Devices
Identify which actions are high risk:
- Configuration changes
- Firmware updates
- User management
- Safety system interaction
Design PAW access around those actions first.
Separate OT Identity Early
One of the early steps in your PAWs management program should be separating OT access from corporate access workflows.
- Create OT-specific identities
- Prevent credential reuse between IT and OT
- Enforce MFA for privileged OT access
This alone can significantly reduce blast radius.
Treat USB Usage as a Risk Signal
USB usage often indicates broken workflows, overly isolated systems, or missing file transfer solutions. Figure out how to fix the process which is leading to workers having to go around the network to manually use USB drives to do their job. This has the added benefit of making your Operators and Engineers workflows much more streamlined, which helps to build goodwill across your organization.
Align PAWs with Your Architecture Work
Managing and monitoring PAWs is most effective when paired with clear zone-and-conduit models, documented access paths, and defined trust boundaries. Managing your privileged account activities is not a substitute for having a defined security architecture. The secure architecture and resilient privileged access management workflows complement each other.
Final Thoughts
The NCSC’s PAWs guidance for OT environments is notable not because it introduces radical new ideas, but because it acknowledges industrial reality without lowering the security bar.
It recognizes that:
- Legacy is unavoidable
- Engineers need usable systems
- Isolation alone is not security
- Privileged access is one of the highest leverage control points in OT
For organizations serious about reducing OT cyber risk, PAWs are not an optional “IT security concept.” They are a foundational control and one that, when implemented pragmatically, improves both security and operational discipline.
If you are already investing in asset inventory, segmentation, or remote access improvements, PAWs should be part of that same conversation, not a parallel project.
How Enaxy Can Help
Enaxy works with critical infrastructure operators to design and implement pragmatic PAW solutions that work in real-world OT environments, not just in policy documents. From selecting appropriate architectures to integrating with segmentation, access control, and monitoring strategies, we help align privileged access protections with operational realities.
Ready to reduce your OT risk where it matters most? Reach out at info@enaxy.com and let’s make PAWs work for your environment, not against it.
1 I generally see and use the term “EWS” for Engineering Workstation, but I’ll use “EWs” throughout this article in deference to the NCSC.