Operational Technology

OT environments often present significantly higher risks compared to standard IT environments. This heightened vulnerability stems from the widespread use of obsolete products and the severe consequences that can result from a cyber attack, including potential loss of human life. The prevalence of obsolete products in OT systems often makes them less capable of defending against attacks, and increases reliance on strong segmentation and compensating controls. 

Obsolete products may also be referred to as legacy products. However the broader term ‘obsolete products’ encompasses unsupported devices, and also those that lack the required security features. In this guidance, obsolete products refer to both software and physical assets. However, this does not include the use of legacy protocols by these devices for device-to-device communications.

To mitigate risks in these environments, it is crucial to restrict opportunities for lateral movement from the IT environment to the OT environment. The identity used for access to the PAW solution should be specific to OT and segregated from any IT. This prevents an attacker using the identity as a lateral movement route between your IT and OT domains. 

Principle 1.2 of the NCSC PAW guidance describes how to identify high-risk accesses. However, where your OT environment contains obsolete products, additional considerations should be made.

A SCADA platform will typically have four general functions: administration, configuration, control, and monitoring. Each of these functions requires access to the same software, but at different privilege tiers to perform discrete functions. An obsolete SCADA system is typically:

• running outdated software
• running an unsupported operating system
• communicating via insecure protocols

As a result, the user privilege level controls within the application can no longer be trusted to effectively separate low-risk roles (such as monitoring) from high-risk roles (like control or administration). The potential for a vulnerability in the outdated OS or software to cause privilege escalation poses an unacceptable risk. To mitigate this risk, all roles must be considered high-risk, and access should be restricted to a PAW.

In scenarios where disruption to a system would have national impact, you may need to treat the data within the OT system as privileged. Such OT systems are high-value targets for attackers. If this risk is substantial, or if the data from OT systems is deemed overly sensitive, implementing a PAW should be considered for all OT user tiers, including for monitoring functions.

Where you are using a modern SCADA solution which is regularly updated and kept on a supported operating system, you can place trust higher levels of trust in the software's user privilege level controls. You should ensure that engineers change context before making highly privileged actions, such as by requiring them to switch accounts from a monitoring user to an administrator, or by mandating a second form of authentication for privileged actions. Refer to the NCSC's guidance on Multi-factor authentication for your corporate online services to select an appropriate method.

User accounts follow the Privileged Access Management principles, with non-permanently assigned access to only the privileges required for their role:

In this scenario this would mean creating:

• A default role (where users can monitor the environment with only the privileges required to view the data relevant to their role).
• A privileged role for users who need to configure, control and monitor in the environment. This should be restricted to only those users who need this ability, use MFA for elevating to the role and require access from a PAW. 
• A privileged role for users who require the ability to manage other users and their respective roles within the system. This access should be regarded as highly sensitive, necessitating active monitoring and auditing of new privileged users to ensure security and compliance. Access to this role should be tightly controlled and limited in numbers, using MFA for elevating to the role and require access from a PAW.

For monitoring actions from a lower trust device you should put in place additional controls. This could include:

• unidirectional flow controls between the low-trust device and the system 
• replicating the monitoring data to another datastore to prevent direct access to the privileged system (preferably this segmentation should be enforced via a hardware control such as a data diode)

PAW principle 5.2 describes how a PAW needn’t be an isolated system, but rather one with highly restricted network connectivity. OT environments traditionally rely on ‘air-gapped’ solutions. This doesn’t mean that a PAW should have general internet access, but it does mean it should be able to access the services it requires to either stay secure or carry out its function. The current air gap approach causes several issues in the context of a PAW:

• When deployed as a fully isolated system, the lack of connectivity from these devices leads to a lack of visibility over the privileged actions taken on the device. This prevents effective monitoring and detection of malicious actions from these devices.
• The lack of connectivity to these isolated systems leads to the un-patchable system anti-pattern. This leaves systems insecure and readily exploitable if a device is connected to the internet or physical access to the device is gained.
• An isolated system tends to lack centralisation and it is common for device controls and policies to be set ‘per device’, and only verified at time of commissioning. This means that there is no trust established in the controls to protect these devices over their lifetime.
• It can encourage the use of high-risk technologies and/or shadow IT or processes. When systems are isolated, usability issues quickly arise as engineers want to transfer error logs or configuration files to the device. This often drives the need for un-auditable and high-risk uses of USB media.

Using a more connected approach to deploy a PAW ensures that the system can remain trusted beyond initial commissioning. Through establishing effective technical controls, the reliance on human or procedural controls can be reduced.

Connectivity in an OT context could mean network connectivity to receive operating systems updates. But it could also be used to facilitate connectivity for licensing of OT applications, or to access vendor support portals. 

It’s important to maintain a central record of all allowed network routes, and to make sure these routes are limited to only those required. You should also make sure that the device controls outlined under PAW principle 5 prevent any downloaded media from being executed on the device. For highly critical OT environments (such as Operators of Essential Services), the connectivity model of a PAW must be balanced against your organisation’s resilience requirements, as outlined in PAW principle 2.2.

Highly critical or high-threat OT environments should still make sure they can receive security updates and other architectural benefits, but can still operate in an isolated state. If connectivity to any supporting services (such as a cloud-based MDM) is lost, the device should still be able to operate. This may involve falling back to on-premises identity services. The ability to operate in sustained isolated modes should be thoroughly tested. There should be a defined process to establish which threat scenario (or security incident) would necessitate your organisation isolating your OT environment.

Implementing a PAW solution isn’t just about deploying a locked-down management device, but requires a more holistic approach as explained in PAW principle 1.1. In OT environments, this is an opportunity to challenge the current ways of working for remote access into your critical networks and assets.

Remote access by integrators, vendors and third parties is increasingly common in OT in maintenance and support contracts. It is still common for these solutions to rely on fixed site-to-site VPNs that require 24/7 access. On top of this, there isn’t always an effective monitoring strategy in place to flag anomalous behaviour via these access routes. 

When investing in a PAW solution, it’s essential that you also review these additional remote access routes which could weaken the effectiveness of your PAW. You need to ensure that the third-party connections can be equally trusted (or protected through additional guardrails).

Any access by third parties into your environment should use Privileged Access Management and the access must be provided using the following methods:

• ‘Just in time’ administration; where instead of the credential being used to access an administration interface, it's used to request access instead. If the request is approved, then temporary elevated privileges are provided for the access.
• ‘Just enough’ administration. This is another way of describing the concept of least privilege. The roles and responsibilities of the access should be defined in advance. When an administrator requests access to an administration interface, they should be prompted to select one of these defined restricted roles.

For third-party access, additional functionality (such as session recording and auditing) may be desirable to verify actions taken during the access. When a third party is accessing privileged functions that your organisation would perform from a PAW, you should mandate that the third party also uses a PAW, as covered in PAW principle 3.1.

One of the biggest challenges facing an effective PAW deployment in OT organisations is the need to also administer obsolete products. It is common for OT equipment to rely on applications that are no longer supported on modern operating systems. This drives the requirement for PAWs to run virtualisation technologies, as discussed in PAW principle 6.1. 

Designing what applications your PAW needs should be an opportunity to document and understand your dependence on obsolete products. You should identify areas where software is required to support only a small number of users or systems. This knowledge should help you to prioritise migration strategies away from obsolete products.

In January 2025, CISA published ‘Secure by Demand: Priority Considerations for Operational Technology Owners and Operators when Selecting Digital Products’. This document reinforces the need for vendors to better enable operators to migrate applications within support contracts to new operating systems, and states that organisations should “Ensure that running software on modern operating systems does not needlessly invalidate the support agreement”. OT organisations should seek out vendors who will support applications throughout their lifecycle, and migrate them to modern operating systems when required. 

In the OT context, it is also important to establish if an application is suitable for a high-trust device. Virtualisation should also be considered where there is low confidence in the security of the application, but it must be used to apply some separation to the host. This could include when:

• an application no longer receives updates (regardless if it supports running on an up-to-date operating system)
• an application requires highly privileged local user permissions to execute 

The segregated networks seen in OT environments mean that engineers will use non-network routes for data transfer to fulfil configuration or administration functions. However, USB (or other removable media) present major risks to trusted administration devices. These transfer methods provide a route onto the device that avoids network-based controls.

USB media is a well-established exploitation route for OT networks, as seen in past cyber attacks such as Stuxnet. It allows attackers to jump into OT networks, taking advantage of the reliance of perimeter security to protect obsolete products rather than technical controls within the environment. 

Building a PAW solution should be seen as an opportunity to reduce your organisation's reliance on removable media. PAW principle 7 will help you architect a more secure network-based transfer model to harness the benefits of the trusted PAW platform. This should focus on ensuring all transfers to your OT environment are audited, authenticated, automated and inspected. Crucially this should include file transfers coming from your third-party vendors, integrators and/or suppliers. 

Where your organisation is unable to remove the risk of removable media, you should ensure that the only removable media used is approved and provisioned by the organisation, ideally allocated to named users with limited connectivity so the media can only connect to the specified PAW device. PAW principle 5.4 includes advice on how to remove unnecessary device features, applications and functionality.

All removable media should also be scanned before and after use on external scanning stations to ensure no known malicious files are present. A well-architected PAW should also prevent untrusted code and non-approved applications from executing on the device, to further mitigate the risks posed by removable media.

For more guidance on using PAWs within OT environments, we recommend organisations read the following publications.

• The UK’s Industrial Control Systems Community of Interest (ICS COI) guidance on the management of removable media
• NIST’s Guide to Operational Technology (OT) Security: SP 800-82