InfoSec Made Easy
OT Security Leadership | NCSC Guidance Series
Why the OT boundary is your primary defensive line — and what it takes to make it hold
In most OT environments, the devices and systems inside the network were not designed to defend themselves. Legacy PLCs, older SCADA components, and even relatively modern field devices often lack the security capabilities needed to withstand direct attack — they have no meaningful authentication for incoming commands, no ability to detect or respond to malicious traffic, and limited logging capabilities that would allow forensic investigation after a compromise. Their security was always intended to be provided by the environment around them, not by themselves.
This reality makes the OT boundary the primary line of defense. If the boundary holds, the internal systems are protected despite their own security limitations. If the boundary fails, those internal systems are exposed with minimal ability to detect or resist exploitation. Principle 5 of the NCSC's Secure Connectivity Principles for Operational Technology addresses this directly: because OT devices cannot adequately defend themselves, the boundary must be hardened well enough to compensate for the security limitations of the systems it protects.
For security leaders, this creates a specific governance and architectural challenge. The boundary must be capable enough to defend the entire environment behind it. It must be flexible enough to adapt as threats evolve. It must be maintainable without disrupting OT operations. And it must remain current — an outdated, unpatched boundary device is worse than no boundary at all, because it creates false assurance while providing diminishing protection against modern threats.
Why OT Boundary Hardening Is Different from IT Perimeter Security
Security leaders who come from IT backgrounds sometimes approach OT boundary hardening as a straightforward application of enterprise perimeter security principles. In practice, the OT context creates constraints that require different thinking in several important areas.
Availability requirements in OT environments are typically far more stringent than in IT. In many OT environments, a maintenance window for security updates may be available only a few times per year, and the consequences of unexpected downtime — a process that stops, a safety system that becomes unavailable, a service delivery interruption — can be severe. This means that boundary hardening activities that are routine in IT — applying patches, changing configurations, deploying new controls — must be carefully planned in OT to avoid creating the operational disruptions they are designed to prevent.
At the same time, the NCSC guidance is unequivocal that boundary devices must be current. Boundary assets must not be obsolete, must be routinely updated with the latest firmware, and must be replaced before they reach end-of-life. Devices located at the edge of the network — precisely where boundary controls sit — are the most exposed to attack and the most likely to be exploited if known vulnerabilities are present. An outdated boundary device is not just ineffective; it is an active liability that hands adversaries a known exploitation path into the OT environment.
The resolution to this tension is careful lifecycle management of boundary assets. Organizations should select boundary devices from vendors with strong security development practices, active vulnerability disclosure programs, and reliable patching cadences. They should schedule security updates on the most frequent schedule that operational constraints allow. They should plan replacements before devices reach end-of-life, rather than carrying them past supported lifecycles. And they should deploy boundary assets in architectures that allow maintenance without creating single points of failure — so that updating one component does not require taking the entire boundary offline.
💡 Pro Tip: When selecting OT boundary devices, treat vendor support lifecycle as a first-order evaluation criterion, not an afterthought. A next-generation firewall with a seven-year support commitment and a reliable quarterly patching cadence is a better choice for an OT environment than a more technically capable device whose vendor has a poor track record of security updates or a short support lifecycle. OT environments make it hard to replace devices frequently — so the security durability of the device's support model matters as much as its current technical capabilities.
Defence in Depth: Layers That Matter
The NCSC guidance is explicit that a single boundary control is not sufficient. If a device or system is directly exposed to an external network with only one line of defence, the failure or compromise of that single control gives an attacker immediate and complete access. Defence in depth — the layering of multiple independent security controls — ensures that an attacker who defeats one layer still faces additional barriers before reaching the systems they are targeting.
For OT boundary hardening, defence in depth means implementing security at multiple layers of the network architecture. External-facing controls at the outermost boundary filter the broadest categories of unwanted traffic. DMZ controls provide a buffer zone where external-facing services can be hosted without direct access to the OT network. Internal boundary controls between the DMZ and the OT network enforce additional restrictions on what traffic can enter the OT environment. And, as addressed in later principles, monitoring and detection add a layer that can identify threats that have bypassed the preventive controls.
This layered approach is more valuable than it might initially appear, because it accounts for the reality that no single control is perfect. Vulnerabilities in boundary devices are discovered and disclosed regularly. Zero-day exploits exist. Misconfigurations happen. A defence-in-depth architecture ensures that the security of the entire OT environment is not contingent on the perfection of any single control.
The Core Hardening Controls
The NCSC guidance provides a specific and practical list of boundary hardening controls that organizations should implement. These are not aspirational goals — they are the baseline that every OT boundary should meet, regardless of the sophistication of the wider security program.
Remove unused services and ports: Every service and port that is enabled on a boundary device but not actively required for operations is an unnecessary attack surface. Boundary devices should be configured with a deny-all default, with only explicitly required services enabled. This configuration should be reviewed and validated whenever the device is updated or reconfigured, because patches and configuration changes can inadvertently re-enable services that were previously disabled.
Implement phishing-resistant MFA for external services: Any human-to-machine connectivity that crosses the OT boundary should require multi-factor authentication. Standard password-based authentication is insufficient for boundary access — passwords can be phished, stolen, or compromised in credential breaches without the account owner's knowledge. Phishing-resistant MFA — hardware security keys, device-bound passkeys, or similar mechanisms — provides significantly stronger protection against the credential-based attacks that are among the most common initial access vectors in OT compromises.
Change default passwords: No device deployed in an OT network should retain default credentials. Default passwords are publicly documented for most commercial devices — they are the first thing an attacker tries, and exploiting a default credential is trivial. Every boundary device, every network appliance, every component with a management interface should have its credentials changed before deployment, and organizations should have a password policy that governs how credentials are generated, stored, and managed.
Enforce least privilege: Both human-to-machine and machine-to-machine connectivity at the OT boundary should follow the principle of least privilege — granting only the permissions required for the specific task, not broad access to the wider environment. Human-to-machine connections should be user-aware, creating audit trails tied to specific individuals rather than shared accounts. And human access rights should be integrated into joiner-mover-leaver processes, ensuring that access is revoked when people change roles or leave the organization.
Use context-aware access controls: Where available, access decisions should factor in contextual signals beyond simple credential validation. Device type, device location, device configuration state, and user behavior patterns can all inform whether a given access request should be permitted or flagged for additional scrutiny. Context-aware controls are particularly valuable for detecting anomalous access patterns — a vendor account that normally connects from a specific geographic location suddenly accessing the system from an unexpected location warrants additional verification, even if the credentials are valid.
Enforce unidirectional traffic flows: Where possible, OT boundary controls should enforce outbound-only connections, preventing external systems from initiating connections to OT assets. The NCSC guidance notes that at its simplest, this can be achieved through protocol choice (UDP for outbound data flows) and network policy enforcement. In high-threat environments, hardware-based controls provide stronger assurance of directionality.
📋 Example: Boundary Hardening Audit in Practice
A utility conducting an OT boundary hardening audit discovers the following across its OT boundary devices: three devices using factory-default credentials, two boundary firewalls running firmware versions more than two years old with known critical vulnerabilities, one remote access gateway with 47 open ports (of which 12 are not documented as required), vendor access configured with shared credentials rather than individual accounts, and no MFA enforced for any external connections. Each of these findings is individually serious; together, they represent a boundary that provides the appearance of protection without the substance. The audit findings become the action list for a structured hardening program, prioritized by risk — default credentials and MFA gaps first, then firmware updates, then access control remediation. Twelve months later, none of those findings remain open. The boundary is genuinely hardened, not just documented as hardened.
Hardware-Based Controls: Data Diodes and Cross-Domain Solutions
For OT environments with the highest risk profiles — critical national infrastructure, systems where compromise could cause physical harm or environmental damage — the NCSC guidance introduces hardware-based controls that provide stronger assurance of data flow restrictions than software-only controls can offer.
Data diodes enforce data directionality through hardware — the physical design of the device makes bidirectional communication impossible, not just unenforced. Unlike a firewall rule that could theoretically be misconfigured or overridden, a data diode's unidirectionality is a physical property of the device. This provides a level of assurance about data flow direction that software controls cannot match. The guidance notes that data diodes are particularly useful for ingesting hard-to-inspect data — logs, network captures, telemetry — into isolated security monitoring environments while maintaining the isolation of the OT network.
Cross-domain solutions go further, providing a comprehensive architectural approach to enabling risk-managed data exchange across trust boundaries. Unlike a simple data diode, a cross-domain solution includes security controls across multiple layers of the network stack, with hardware security controls at key boundaries. The NCSC has published dedicated Cross Domain principles for organizations that need to operate at this level of assurance.
The guidance includes an important caution about anti-patterns in hardware-based controls. A diode in each direction — effectively attempting to create bidirectional communication using two unidirectional hardware devices, with software on the trusted side to orchestrate the flows — is specifically identified as an anti-pattern. This configuration is not equivalent to a cross-domain solution and provides much weaker security guarantees than it appears to. Security leaders evaluating hardware-based boundary controls should understand this distinction clearly and avoid architectures that mimic the appearance of strong hardware controls without the actual security properties.
Third-Party Security Requirements at the Boundary
When a third party designs or implements connectivity into your OT environment, the boundary hardening requirements do not relax. The NCSC guidance is explicit that organizations must ensure that third-party connectivity solutions align with their security expectations — not just the security expectations that the third party holds for themselves. This is a governance challenge that requires contractual clarity, technical review of proposed solutions, and ongoing oversight of how third-party connectivity is actually implemented and maintained.
In practice, this means defining minimum security requirements for all OT connectivity solutions as part of procurement and contracting processes. It means conducting technical security reviews of third-party connectivity designs before they are implemented, not after. And it means maintaining the right to audit how third-party connectivity is configured and maintained throughout the life of the arrangement — not just at the point of initial deployment.
📋 Key Ideas: What Strong Principle 5 Implementation Looks Like
- OT boundary devices are current-generation, actively supported, running current firmware, and scheduled for replacement before end-of-life.
- Boundary devices are configured with deny-all defaults, with only explicitly required services and ports enabled and documented.
- All external human-to-machine access requires phishing-resistant MFA — no exceptions for vendor or operational convenience.
- No default credentials exist on any boundary or OT network device; a password management process governs credential generation and storage.
- Least-privilege access is enforced, with individual accounts for all human access and JML processes ensuring timely access revocation.
- Defence-in-depth architecture ensures that no single control failure gives an attacker direct access to OT systems.
- High-risk environments have evaluated hardware-based controls (data diodes, cross-domain solutions) and implemented them where the risk profile warrants the investment.
The Regulatory Dimension: Boundary Security as a Compliance Requirement
Boundary hardening is one of the most heavily scrutinized areas in critical infrastructure security regulation. Frameworks governing OT security — from IEC 62443 to sector-specific standards in energy, water, and transportation — include explicit requirements for perimeter security, access control, and patch management that map directly to the controls described in Principle 5. Organizations that cannot demonstrate current, maintained, and configured boundary devices will face findings in regulatory examinations regardless of the sophistication of their broader security program.
For compliance professionals, the hardening controls in Principle 5 provide a useful checklist for assessing whether OT boundary controls meet the expectations of applicable regulatory frameworks. The combination of device currency, credential management, MFA, least privilege, and documented configuration provides a comprehensive evidence base for demonstrating boundary security maturity — both to regulators and to the organization's own leadership.
💭 Final Thought
The OT boundary is where the security of the entire environment is either defended or surrendered. The systems behind it cannot adequately defend themselves. The processes they control cannot afford disruption. The consequences of a boundary failure in critical infrastructure can extend far beyond data loss — into physical harm, environmental damage, and disruption to essential services that people depend on. Investing in boundary hardening is not just a technical security measure. It is a commitment to the people and communities that depend on the safe and reliable operation of the systems inside that boundary. That is worth the investment, the operational discipline, and the organizational effort required to maintain it properly.
This article is part of the InfoSec Made Easy series on the NCSC Secure Connectivity Principles for Operational Technology. Read the full series at www.infosecmadeeasy.com.