Designing safer links: secure connectivity for operational technology
If you work in operational technology (OT), you know that the way your systems connect – to each other, to IT networks, and to the wider world – has a direct impact on your safety, resilience and ability to defend against cyber threats.
Earlier this year, the NCSC published guidance on Creating and maintaining a definitive view of your OT architecture, designed to help OT organisations to gain an accurate and complete record of their environment. This guidance set the foundation; if you don't have a complete, current understanding of your whole environment, effective cyber security controls can’t be designed, implemented or maintained.
Building on that foundation, the NCSC has today published new guidance setting out new Secure connectivity principles for operational technology. These principles will help your organisation design, review, and secure the connectivity within and to your OT systems, transforming system understanding into positive cyber security action.
Why secure connectivity matters
Connectivity in OT environments brings benefits such as remote monitoring, predictive maintenance, and integrated analytics. But it also expands the attack surface. Legacy and obsolete devices, complex vendor supply chains, and remote access arrangements can all introduce risks that may lead to downtime, safety incidents or even environmental harm.
Many historic OT environments were never designed with modern connectivity in mind. As a result, security gaps can be hard to close once systems are operational. The new guidance provides principles for ensuring that future connectivity decisions are risk-aware, security-driven, and implemented with resilience ‘built in’, while also encouraging retrospective improvements to existing architecture.
From principles to practice
The guidance outlines eight core principles, from balancing risk and opportunity before connecting, to limiting exposure, hardening boundaries, and ensuring logging and monitoring. These are not minimal compliance requirements; they’re goals to help you make the right design choices for your OT.
These principles provide a clear framework for designing secure OT connectivity across a variety of use cases. Developed from the NCSC’s experience working with operators of essential services and informed by engagement with industry, they are grounded in practical measures that organisations can realistically implement. To support this work we have also produced a worked example on safe data sharing from an OT environment to demonstrate how this can be practically applied. The example illustrates how data can be shared with OEMs (or other external parties) whilst managing cyber security risks to the OT environment.
We thank the National Protective Security Authority (NPSA) for their collaboration in producing this guidance.
Next steps
Just as the guidance on creating and maintaining a definitive view of OT architecture aimed to give you the visibility to inform decisions, the new secure connectivity principles aim to help you take actions. By systematically applying these principles to all connections – whether new, revised, or existing – you can reduce your attack surface, improve incident response options, and maintain the trust and safety of your operations.
The stronger your connectivity design, the harder it becomes for adversaries to cause disruption – whether their target is your data, your process, or the critical services your OT supports. We encourage OT owners, operators, integrators, and vendors to put these principles into practice.
This guidance has been produced by the NCSC in partnership with:
Australian Signals Directorate (ASD)
US Cybersecurity and Infrastructure Security Agency (CISA)
Canadian Centre for Cyber Security (Cyber Centre),
US Federal Bureau of Investigation (FBI)
New Zealand’s National Cyber Security Centre (NCSC-NZ)
Netherland's National Cyber Security Centre (NCSC-NL)
Germany’s Federal Office for Information Security (BSI)
We thank all our partners who have contributed to this guidance.
David G, Security Architect NCSC
Share and print this article
Written by
