The Cybersecurity and Infrastructure Security Agency, in collaboration with UK’s National Cyber Security Centre, or NCSC-UK, the FBI and international partners recently released a new set of guidelines called Secure Connectivity Principles for Operational Technology.

This new guidance outlines new Secure connectivity principles for operational technology. These principles can be applied to help OT operators design, review, and secure the connectivity within and to OT systems to transform the understanding of connectivity security into a defined cybersecurity action.

This guidance guidance marks a definitive shift in many ways. Firstly, it acknowledges that connectivity, in any form, be it for remote maintenance, analytics, and OEM support is an important business requirement and cannot be compromised. The guidance calls for the risks associated with connectivity to be managed in a diligent manner that doesn’t compromise business outcomes or strains resources. Notably it also mentions that connectivity cannot be considered as a default state of operation that is not bound by any guard rails.   

This guidance also moves away from "box-ticking" and surface level compliance toward a goal-oriented framework that understands the risk and calls out ways to deal with the risk. The guidance also calls for OT security be treated as a foundational requirement for physical safety and operational uptime.

Let’s now take a detailed look at this guidance and its implications for enterprises everywhere.

Before we do that, don’t forget to check our previous blog post on “The Eurail B.V breach report,” here.

Prioritize actions as per resource constraints
In the initial part of the guidance document itself, there is a reference to the resource constraints encountered by enterprises. The guidance recognizes this challenge and recommends that enterprises focus their mitigation efforts in a staggered way while prioritizing the risks. Some topics that should be considered as per the guidance are:

•  Significance of the underlying asset/operation: the role and impact of the device or process to your operations, including the ability to control and/or monitor key functions.

•  Back-ups: the presence of fail-safe systems or redundant systems that maintain availability and reduce the risk of unsafe operating conditions or service outages.

•  Time to implement: The time it would take to implement the change, considering the currently available funds and complexity. It has to be understood that the cheapest option may not be the most impactful option to securing connectivity.

•  Active threat activity from attackers ranging in sophistication, including the consideration for current geo-political events, specific threats and the potential national security significance of an enterprise and/or customers’ organizations

The core principles of secure OT connectivity

The NCSC condenses secure connectivity into eight strategic pillars. We should view these not as independent tasks, but as a layered defense-in-depth strategy.

•       Segment networks: Wherever obsolete products are present, segmentation and network controls should be deployed. These may help manage the associated risks. However, organizations should consider such measures as short-term interventions and assess if these measures are sufficient while establishing a timeline for asset replacement

•  Balance risks and opportunities: Every connection must have a documented business case for it to exist. If you can’t define the "why" and the "who" (senior risk owner), the connection simply shouldn’t exist. At each stage of the design process the enterprise should assess if the connectivity is able to meet the risk-thresholds defined in the business case and learn whether it aligns with your organizational threat context or not.

• Understand and address supply chain risks: It is essential to manage the supply chain risk associated with procuring new products (especially when the product originates in or has components that originate in high risk geographies or where the source of origin of the product or the component itself is unknown or unclear). Enterprises need to ensure that devices are secure by design and developed following a secure product development lifecycle. This helps reduce the risk of introducing vulnerabilities through third-party components or insecure design practices

• Limit exposure: Exposure management is about shrinking the attack surface and the risk associated. This means removing inbound port exposure and ensuring connections are only initiated from within the OT environment. In situations wherein the systems outside the OT environment need access to OT assets (such as for instance for OEM remote support), the use of brokered connections is recommended through a secure gateway that is located in a separate, security-controlled segment such as a demilitarized zone (DMZ). A brokered connection is essentially a method where the external party connects to an intermediary system (the broker). This system then securely relays the connection to the OT asset. This ensures that the OT system is never directly exposed to the internet or external networks, and that all access is mediated, monitored, and controlled.

• Manage your public visibility: by using external attack surface management

• (EASM) tools or other internet-facing asset discovery tools, enterprises should work to identify accidental or unmanaged exposure well before attackers do. These discovery tools index internet-connected assets and protocols, allowing anyone to find exposed web servers, remote access portals, or industrial devices. EASM tools can be used to reduce your attack surface and the likelihood of being targeted. If enterprise systems are visible to these scanning services then they are highly likely to be found and targeted by malicious actors, significantly increasing the risk to these systems.

• Centralize and standardize: Ad-hoc "shadow OT" connections lie at the heart of the problem. Consolidating access points allows for uniform security controls and easier monitoring.

• Secure protocols: Move away from clear-text legacy protocols wherever possible and instead use standardized, encrypted, and authenticated paths.

• Harden the boundary: Your boundary (such as firewalls, DMZs, gateways) is your primary defense. It must be modern, modular, and capable of deep packet inspection to stop threats from entering.

• Limit the impact of compromise: Always assume a breach will happen. Use segmentation to prevent lateral movement and "contamination" of the wider process.

• Log and monitor: If you can’t see it, you can’t defend it. Monitoring is your "last line of defense" to catch anomalous behavior before it impacts the physical process.

• Establish an isolation plan: Connectivity must be "detachable." You need a "big red button" plan to physically or logically isolate OT from IT/Internet during an active incident without crashing the plant.

The "push-only" mandate

One of the most critical technical recommendations in the NCSC guidance is the move toward "Push-Only" architectures. This requires a deep dive.

In a traditional IT environment, enterprises are used to unchallenged bidirectional requests. In high-security OT, the NCSC advises that no listening ports should be open on the OT side of the DMZ. All data be it’s telemetry for a cloud twin or logs for a SOC, must be "pushed" from the higher-trust OT zone to the lower-trust corporate zone.

Such a simple architectural choice goes a long way in eliminating a massive class of remote exploitation vulnerabilities.

Secure connectivity checklist for enterprises

Based on the NCSC framework, OT operators can use the below checklist to audit their current OT connectivity posture and adjust the gaps as per this NCSC guideline.

Phase 1: Governance and risk

• [ ] Business case audit: Does every external connection (OEM, Remote Access, Cloud) have a signed-off business case and a named Senior Risk Owner? Is the business case justified and validated with documentation?

• [ ] Asset inventory: Do you have a "Definitive Architecture View" that includes all third-party endpoints and "shadow" cellular modems? Do you?

• [ ] Dependency mapping: Have you identified if any OT functions rely on external cloud services to operate? (Can the plant run if the internet is down?)

Phase 2: Architectural hardening

• [ ] Inbound exposure: Have all inbound ports (listening ports) on the OT boundary been closed?

• [ ] Push-only data flows: Is OT data being "pushed" to the DMZ rather than being "pulled" by external systems?

• [ ] Protocol standardization: Are you using modern, encrypted protocols (e.g., OPC-UA with security, HTTPS, MQTT with TLS) for all boundary-crossing traffic?

• [ ] Managed DMZ: Is there a functional DMZ between IT and OT where all traffic terminates and is re-authenticated?

Phase 3: Defensive Operations

• [ ] Zero-Trust remote access: Is remote access restricted to specific assets, time-limited, and enforced via Multi-Factor Authentication (MFA)?

• [ ] Segmented logging: Are logs from boundary devices (Firewalls, IDS) being sent to a central, secure repository for real-time analysis?

• [ ] Protocol inspection: Do your boundary firewalls perform "Deep Packet Inspection" (DPI) to ensure that OT protocols are only carrying valid industrial commands?

Phase 4: Resilience and recovery

• [ ] Isolation playbook: Do you have a tested "Kill Switch" procedure to isolate the OT network in under 15 minutes during a suspected breach?

• [ ] Manual fallback: Can your operators safely shut down or run the process manually if the network connectivity is lost?

• [ ] Black-start readiness: Will your security controls (Firewalls/IDS) hinder a "Black-Start" recovery of the plant after a total power loss?

You can read the full document on this guidance here.

Book a free consultation on secure connectivity with Shieldworkz

Test drive our NDR solution for OT security, here.