Scope: A strategic assessment of Zero Trust implementation across United States defence and civilian operational technology environments, with comparative implications for European critical infrastructure, examining the October 2026 NSA guidance, the April 2026 CISA interagency framework, the NIST security architecture, and implementation priorities through 2031.

Executive Summary — Bottom Line Up Front

The October 2026 intervention by the United States National Security Agency marks an important evolution in operational technology cybersecurity: critical infrastructure protection can no longer depend principally upon network isolation, trusted internal connections, or the assumption that equipment controlling physical processes will remain beyond an adversary’s reach. The central security requirement is to preserve safe, authorised control of industrial operations even when an identity, engineering workstation, supplier connection, or adjacent digital system has been compromised. This represents a shift from defending the industrial network as a perimeter to defending individual operational capabilities, access pathways, and physical consequences.

The NSA’s 8 October 2026 Cybersecurity Information Sheet, Hardening Department of War Critical Operational Technology Environments with Zero Trust Principles, places particular emphasis on legacy systems whose operational importance has outlasted their original security architecture. Although directed primarily towards National Security Systems, Department of War environments and the Defence Industrial Base, the underlying risk applies to electricity networks, water treatment, transportation, industrial manufacturing, agricultural infrastructure, healthcare facilities and government buildings. The NSA explicitly identifies potentially catastrophic consequences for national security, economic security, public health and safety. NSA Releases Zero Trust Guidance for Protecting Operational Technology Systems — NSA — October 2026

The technical difficulty is structural rather than exclusively financial. Numerous operational technologies remain mechanically reliable while lacking capabilities associated with contemporary cybersecurity, including strong authentication, encrypted communications, detailed event logging, security updates and granular access enforcement. Unlike conventional enterprise computing, operational environments cannot necessarily tolerate aggressive vulnerability scanning, untested software changes, repeated authentication exchanges, additional communication latency or unscheduled shutdowns. Security measures that are appropriate for administrative networks may introduce unacceptable hazards when applied directly to industrial control systems.

The joint CISA guidance of 29 April 2026, Adapting Zero Trust Principles to Operational Technology, therefore rejects the indiscriminate transplantation of enterprise Zero Trust controls into industrial environments. Its governing principle is that security improvements must be compatible with the physical processes, availability requirements and safety constraints of the systems being protected. It recommends comprehensive asset visibility, supply-chain governance, identity and access management, network segmentation, secure remote access, tailored vulnerability management, monitoring and recoverability. Adapting Zero Trust Principles to Operational Technology — CISA, DoW, DOE, FBI and DOS — April 2026

The principal analytical judgment is that the highest immediate return will generally come from controlling pathways into legacy environments rather than attempting to retrofit every ageing controller with modern security functionality. The initial priorities should be to eliminate unmanaged external access, identify operationally consequential assets and dependencies, establish enforceable boundaries between industrial functions, protect engineering workstations, constrain privileged activity and validate that containment measures cannot interrupt essential control functions. These measures cannot eliminate vulnerabilities inside obsolete equipment, but they can reduce the opportunities for an initial compromise to become an industrial incident.

The distinction between a protected connection and an authorised physical action is particularly important. A maintenance contractor might authenticate successfully through an encrypted remote-access system yet still possess unnecessary rights to alter controller logic, disrupt adjacent devices or change operating parameters. A mature Zero Trust policy must therefore bind access to a verified identity, designated resource, permitted operation, approved maintenance purpose and defined duration, subject to operational authorisation.

The NSA’s reported selection of 26 high-impact activities from an 84-activity defence OT framework offers a potentially valuable prioritisation mechanism, particularly for organisations unable to replace legacy systems immediately. However, the existence of a defined activity catalogue must not be confused with verified implementation or demonstrated risk reduction. Regulators should distinguish control deployment from operational effectiveness and require evidence that a compromised account or workstation cannot acquire unauthorised control of critical processes.

The strongest unresolved quantitative issue is the absence of a sufficiently comparable, authoritative cross-sector inventory establishing the proportion of operational equipment that is ageing, unsupported, remotely accessible, or incapable of native Zero Trust enforcement. Without such baselines, national estimates of exposure and the effectiveness of proposed investments remain uncertain.

The resulting policy priority is a safety-led, consequence-based modernisation programme, combining near-term compensating controls with procurement requirements that progressively remove unsupported protocols, insecure configuration mechanisms, uncontrolled vendor dependencies and insufficient forensic visibility. Modernisation becomes urgent where an essential physical process cannot be adequately isolated, independently protected, safely recovered or operated within an acceptable residual-risk envelope.

Europe’s Cybersecurity Funding: Italy’s Resilience Gap

Zero Trust and Critical Infrastructure: The Industrial Cost of Trusting Obsolete Systems

The United States is demanding stronger cybersecurity assurances from critical infrastructure operators while much of the equipment responsible for essential physical processes cannot enforce them. The National Security Agency’s intervention of 8 October 2026 exposes a contradiction with direct consequences for national security, industrial investment and public finances: governments can require tighter control over digital access, but cannot legislate modern authentication, trustworthy logging or secure configuration management into controllers designed without those capabilities. Replacing entire industrial systems is expensive and operationally disruptive; leaving them connected through insufficiently governed access arrangements creates opportunities for hostile interference. The central policy question is therefore not how quickly operators can adopt Zero Trust terminology, but whether regulators can force a measurable reduction in the authority that compromised digital systems exercise over physical infrastructure without undermining the services they are supposed to protect.

The NSA Has Changed the Standard of Protection, Not the Equipment Beneath It

On 8 October 2026, the National Security Agency published Hardening Department of War Critical Operational Technology Environments with Zero Trust Principles, placing legacy operational technology within a security framework traditionally associated with enterprise networks and sensitive information systems. Its principal audience comprises National Security Systems, Department of War environments and the Defence Industrial Base, but the implications extend to electricity, water, transportation, manufacturing and government facilities.

The underlying shift concerns the definition of security. A facility is no longer adequately protected simply because its industrial network is separated from the internet or its maintenance connections are encrypted. An authenticated supplier can still possess excessive programming permissions; a compromised engineering workstation can still reach unrelated controllers; and a trusted internal application may retain the ability to alter operating parameters beyond its legitimate purpose.

The NSA’s guidance draws on a reported selection of 26 high-impact activities from an 84-activity framework, concentrating attention on measures intended to reduce consequential industrial exposure. The published announcement establishes the agency’s policy direction, although the complete activity-level catalogue requires separate verification before its individual measures can be ranked authoritatively.

This distinction matters because Zero Trust is not a substitute for industrial engineering. NIST SP 800-207, Zero Trust Architecture, establishes the principle that access to protected resources must depend on explicit policy rather than presumed trust arising from network location. In operational technology, however, the resource may be a controller capable of changing a physical process. The resulting decision must govern not merely who can connect, but who can observe, configure, programme or command a particular machine.

The Numbers Reveal a Governance Deficit Before They Reveal an Equipment Crisis

The most revealing evidence concerns the government’s incomplete knowledge of the systems it is attempting to secure.

In its report of 30 September 2026, the United States Government Accountability Office examined networked-device inventory requirements across 22 civilian federal agencies. Fifteen had established inventories, eleven were maintaining them, ten had included all required information, and only seven had satisfied all three requirements. That final figure represents 31.8% of the agencies examined.

GAO-26-108937, Internet of Things: OMB Action Needed to Ensure Agencies Secure Their Networked Devices

These figures do not measure the proportion of vulnerable industrial controllers in the United States. They reveal something more directly relevant to implementation: even organisations subject to central federal requirements struggle to maintain dependable records of networked equipment. An infrastructure operator cannot reliably restrict access to consequential industrial assets when it cannot establish what exists, which processes the equipment controls or which external systems retain administrative authority.

The scale of the civilian problem is considerable. In May 2026, GAO described a United States water and wastewater sector comprising close to 170,000 systems, with substantial differences in staffing, financial capacity and cybersecurity maturity. Separately, the Environmental Protection Agency reported in February 2026 that cybersecurity vulnerabilities had been identified at 277 water systems during 2025 through its assistance activities.

GAO-26-109159, Critical Infrastructure Protection: Actions Needed to Address Persistent Cybersecurity Threats to the Water and Wastewater Sector

EPA, EPA Actions Help Safeguard Water Systems from Cyberattacks — February 2026

Neither the 277 systems nor the federal inventory figures provide a national vulnerability prevalence rate. Their significance lies in the relationship between exposure, fragmented responsibility and the limited resources available to correct weaknesses.

The 2024 GAO investigation into CISA’s operational technology support activities documented a threat-hunting and incident-response service staffed, at the time examined, by four federal employees and five contractors. The officials involved considered this insufficient for simultaneous major incidents across multiple OT locations. Twelve of thirteen selected nonfederal organisations nevertheless reported positive experiences with CISA’s services, indicating that the problem concerned capacity and coordination as well as technical competence.

GAO-24-106576, Cybersecurity: Improvements Needed in Addressing Risks to Operational Technology

The fiscal contradiction is evident. Governments are expanding cybersecurity expectations across enormous and heterogeneous industrial estates while the institutions responsible for asset visibility, technical assistance and regulatory oversight still face documented implementation limitations.

Attackers Exploit Industrial Authority More Easily Than Operators Can Replace It

The vulnerability of ageing operational technology does not necessarily arise from sophisticated exploitation of industrial firmware. In many cases, the decisive weakness is an access relationship that permits an authenticated or network-connected party to exercise more authority than the physical process requires.

The joint advisory concerning Iranian Islamic Revolutionary Guard Corps-affiliated CyberAv3ngers operations documented at least 75 compromised devices in the United States between November 2023 and January 2024, including at least 34 associated with water and wastewater systems. The campaign targeted Unitronics programmable logic controllers, exploiting exposed interfaces and inadequate credential protections.

CISA Advisory AA23-335A, IRGC-Affiliated Cyber Actors Exploit PLCs in Multiple Sectors — Updated December 2024

The distinction between access and consequence remains important. Documented activity included interference with controller configurations and restoration, but the number of compromised devices cannot be converted into a national estimate of physical damage. In November 2023, an affected water authority disconnected a compromised device and continued operating manually, with no known threat to the municipality’s drinking-water supply.

That incident illustrates the industrial value of independent operating capabilities. A cyber intrusion can remain limited when local controls, manual procedures and engineering safeguards prevent access to a digital interface from becoming irreversible control over a physical process.

State-sponsored prepositioning presents a different concern. The February 2024 joint advisory on Volt Typhoon described persistent access to American critical infrastructure networks by actors associated with the People’s Republic of China. The documented techniques included legitimate administrative tools and compromised credentials, highlighting the possibility of maintaining access without immediately causing physical disruption.

CISA, NSA, FBI and International Partners, PRC State-Sponsored Actors Compromise and Maintain Persistent Access to U.S. Critical Infrastructure — February 2024

The industrial consequence is that a controller can remain mechanically reliable while becoming strategically exposed through its maintenance workstation, supplier connection or supporting identity system. Replacing that controller may require software migration, commissioning, safety validation and production downtime. Restricting the pathway through which it can be reached may produce earlier protection, but only if the restriction can distinguish authorised diagnostics from unauthorised programming.

Artificial intelligence intensifies the pressure without eliminating those engineering distinctions. The NSA’s October 2026 assessment identifies AI-assisted reconnaissance and faster exploitation as emerging operational concerns. Yet automated analysis of industrial documentation does not, by itself, establish reliable knowledge of a facility’s physical behaviour. The immediate risk is that established weaknesses can be discovered and exploited more efficiently while operators remain constrained by maintenance windows and equipment compatibility.

Procurement Determines Whether Today’s Workarounds Become Tomorrow’s Liabilities

The economic mechanism connecting cybersecurity to industrial policy lies in procurement.

A controller purchased without secure configuration management, useful event logging or independently maintainable software can impose costs throughout its operating life. The infrastructure owner may subsequently require additional gateways, monitoring systems, privileged-access platforms and specialist engineering support merely to compensate for capabilities that were absent from the original equipment.

On 13 January 2025, CISA and international partners published Secure by Demand: Priority Considerations for Operational Technology Owners and Operators when Selecting Digital Products. The guidance identified twelve procurement considerations, including secure defaults, strong authentication, secure communications, configuration management, logging, vulnerability management, upgrade tooling and operator ownership.

Secure by Demand — CISA and International Partners — January 2025

The commercially significant requirement is operator independence. A utility that cannot restore controller configurations without proprietary supplier infrastructure remains exposed to the availability, contractual conduct and technical support of that manufacturer. A factory whose engineering application requires an unsupported operating system may be unable to adopt ordinary security updates without threatening production continuity.

Secure procurement therefore changes the distribution of lifecycle costs. Manufacturers must be evaluated not only on equipment performance and purchase price, but also on authentication, configuration integrity, support obligations, restoration rights and the cost of operating their products securely over time.

The transition cannot be accomplished through procurement rules alone. Existing facilities may require protocol gateways, protected engineering environments, passive monitoring or controlled remote-access systems while replacement is planned. But these compensating controls must remain accountable investments, not permanent excuses for retaining equipment whose vulnerabilities cannot be sufficiently contained.

For defence production, the consequences extend into national industrial capacity. A compromised engineering platform may interrupt manufacturing or raise doubts about the integrity of critical production configurations without requiring the attacker to damage machinery directly. The NSA’s October 2026 guidance accordingly places industrial access governance within the protection of defence-related operational capabilities, rather than treating it as an ordinary administrative IT problem.

Regulation Can Demand Assurance, but Cannot Create Maintenance Windows

The April 2026 interagency document Adapting Zero Trust Principles to Operational Technology addresses the limitation that general cybersecurity mandates can overlook: industrial processes cannot always tolerate continuous active inspection, repeated authentication exchanges, untested software modifications or unscheduled shutdowns.

Adapting Zero Trust Principles to Operational Technology — CISA and Partner Agencies — April 2026

A security gateway that prevents unauthorised access but delays a time-critical industrial communication may introduce a new hazard. A centrally managed identity service that improves accountability but blocks emergency maintenance during an outage may weaken operational resilience. A firmware update that removes a known vulnerability but invalidates an established controller configuration may impose costs that exceed the purchase price of the equipment itself.

Regulatory performance must therefore be assessed through tested outcomes. Operators should demonstrate that a compromised supplier account cannot access unrelated controllers, that programming authority is restricted to approved engineering functions, and that critical processes remain operable or safely recoverable when supporting digital infrastructure fails.

The United States already possesses evidence that administrative requirements can outpace implementation capacity. GAO’s September 2026 findings on federal inventories illustrate this difficulty, while its separate report on cybersecurity regulatory harmonisation recorded concerns from selected industry representatives about overlapping and conflicting obligations, particularly in incident reporting.

GAO-26-109197, Cybersecurity Regulations: Industry Panelists Identify Duplication and Conflicts and Ways to Address Them — September 2026

A workable regulatory model would require comparable evidence of industrial protection without mandating identical products or architectures across fundamentally different physical processes. The standard should be demonstrable restriction of unauthorised control, documented engineering compatibility and credible restoration capability, not procurement of a prescribed cybersecurity platform.

Europe Shares the Exposure but Not a Single Regulatory System

For European infrastructure operators, the American transition towards OT Zero Trust intersects with an existing legal framework rather than entering a regulatory vacuum.

Directive (EU) 2022/2555, NIS2, establishes cybersecurity risk-management obligations for covered entities, addressing incident handling, business continuity, supply-chain security, asset management, access control and measures for evaluating cybersecurity effectiveness. Its requirements can support Zero Trust outcomes, but the Directive does not prescribe one identical technical architecture for every industrial installation.

Directive (EU) 2022/2555, Article 21 — European Parliament and Council — December 2022

The industrial implications differ across national economies. Italy must reconcile cybersecurity investment with the requirements of energy infrastructure, manufacturing and public-service operators managing heterogeneous equipment. France faces the interaction between industrial control security, critical energy functions, transport and defence-related facilities. Germany’s extensive manufacturing automation makes the relationship between supplier ecosystems, equipment compatibility and industrial maintenance particularly consequential. The United Kingdom shares many of the same technical exposures but operates through its own national regulatory arrangements.

The European Union’s Cyber Resilience Act, Regulation (EU) 2024/2847, adds a product-security dimension through horizontal cybersecurity requirements for products with digital elements within its scope. Its significance for industrial procurement is the movement towards stronger security responsibilities at the product level, although individual applicability and compliance dates must be determined under the Regulation rather than inferred from American guidance.

Regulation (EU) 2024/2847, Cyber Resilience Act — European Parliament and Council — October 2024

The January 2025 Secure-by-Demand initiative already involved cybersecurity authorities from several allied countries and European institutional participation. This creates scope for compatible procurement expectations and shared technical assurance, without eliminating differences in national law, industrial safety requirements or regulatory competence.

The industrial cost of divergence would arise where multinational manufacturers face inconsistent security specifications, while infrastructure operators must maintain incompatible evidence and reporting systems for equipment performing comparable functions. Regulatory convergence is valuable only if it reduces these costs while preserving demonstrable protection of physical processes.

The Next Twenty-Four Months Will Expose Who Has Authority Over Industrial Risk

Between October 2026 and October 2028, the decisive measure of progress will be whether infrastructure operators can move from declarations of cybersecurity maturity to verifiable control over access, configuration integrity and recovery.

The proposed 30-, 90- and 180-day implementation sequence offers a practical starting point: establish accountability and identify consequential exposure; restrict and validate the principal access pathways; then demonstrate containment and restoration under controlled compromise scenarios. These intervals are an analytical implementation proposal, not statutory deadlines or a verified NSA activity schedule.

The medium-term investment decision is equally concrete. Equipment that can be reliably isolated, maintained and restored may remain operational under tested compensating protection. Equipment whose configuration cannot be verified, whose privileged access cannot be controlled or whose recovery depends on unavailable supplier capabilities becomes a candidate for accelerated replacement.

The financial burden will fall unevenly. Large industrial and defence operators may be able to integrate security improvements into scheduled capital programmes. Smaller water utilities, municipal infrastructure organisations and financially constrained essential-service providers may face recurring expenditure on specialist support and protective systems without possessing the capital needed for comprehensive renewal.

Governments will face a corresponding choice between funding targeted technical assistance and accepting uneven implementation across operators delivering essential services. Regulators will bear the institutional burden of distinguishing documented compliance from demonstrated effectiveness, while manufacturers will face increasing pressure to include security and recovery capabilities in baseline equipment.

The cost of inaction will not be confined to the balance sheets of infrastructure owners. Where a successful intrusion interrupts electricity, water, transportation, healthcare support or defence production, the consequences can extend to customers, taxpayers, industrial supply chains and public authorities responsible for maintaining essential services.

The NSA’s October 2026 intervention has therefore made the underlying industrial contradiction harder to ignore: critical infrastructure remains dependent on equipment designed for long operational lives, while its digital access arrangements were not necessarily designed to withstand persistent adversarial compromise. Over the following twenty-four months, the credible measure of policy will be the number and significance of physical functions demonstrably protected—not the number of organisations claiming to have adopted Zero Trust.

EU Cyber Resilience Act Reporting Rules Go Live as ENISA’s Single Reporting Platform Changes the Operating Model for Product Cybersecurity

---

Navigational Index — Three Strategic Pillars

Pillar I — Strategic Exposure, Adversarial Threats and the Legacy OT Constraint

Chapter 1. Strategic Context and Threat Environment

State-sponsored cyber operations, ransomware, AI-assisted threats, legacy infrastructure exposure, defence-specific requirements and sectoral risk across essential services.

Chapter 2. Technical and Operational Challenges of Legacy OT

Industrial controllers, SCADA systems, engineering workstations, insecure protocols, deterministic process requirements, unsupported equipment, safety systems and operational risk trade-offs.

Pillar II — Zero Trust Architecture, Compensating Controls and Industrial Modernisation

Chapter 3. Zero Trust Architecture Applied to Operational Technology

NIST architectural principles, NSA high-impact activities, identity and policy enforcement, resource-level authorisation, access governance and staged implementation.

Chapter 4. Compensating Controls, Segmentation and Operational Visibility

Industrial zones and conduits, controlled vendor access, privileged access management, passive monitoring, dependency inventories, safety separation, continuous verification and containment assurance.

Chapter 5. Procurement, Secure-by-Demand Requirements and Technology Improvement

Modernisation strategies, secure industrial procurement, protocol mediation, gateways, data diodes, equipment replacement, supplier accountability and governance of AI-enabled industrial analytics.

Pillar III — Government Implementation, Regulatory Assurance and Strategic Intelligence

Chapter 6. Implementation Roadmap, Risk Prioritisation and Governance

Risk-based sequencing, 30/90/180-day priorities, multiyear modernisation, engineering change control, sector-specific requirements, performance indicators, residual risk and regulatory oversight.

Chapter 7. Evidence Architecture, Analytical Methods and Priority Intelligence Questions

Primary-source hierarchy, OT dependency and consequence mapping, attack-path assessment, operational validation, programme evaluation, national exposure measurement and the priority intelligence requirements for regulators and national security authorities.

---

Banking System Under Fire: Why AI Is Forcing a New Cybersecurity Architecture for Global Finance

Master Abstract — The Strategic Transition from Network Trust to Physical-Process Assurance

The structural vulnerability of ageing industrial infrastructure

The fundamental cybersecurity problem facing operators of essential services is the growing divergence between the operational longevity of industrial technology and the security assumptions under which that technology was originally designed. Industrial equipment frequently remains economically useful long after its communications architecture, operating system, authentication mechanisms or vendor support arrangements have become obsolete. A controller that reliably operates a pump, regulates electrical equipment, supervises a railway subsystem or coordinates a building’s backup power supply may continue to satisfy its original engineering requirements while presenting vulnerabilities that cannot be resolved through conventional software maintenance.

This distinction matters because the consequences of compromised operational technology are not confined to information loss. An adversary who successfully penetrates an operational environment might interfere with industrial commands, manipulate measurements, interrupt supervisory visibility, alter equipment configurations or prevent personnel from restoring normal operations. The resulting effects depend upon the process architecture, existing protective systems, engineering safeguards and the degree of authority available to the attacker. Consequently, cybersecurity assurance must extend beyond the prevention of unauthorised network entry to the preservation of safe physical operation when some components can no longer be trusted.

The interagency CISA guidance documents these difficulties explicitly, identifying long equipment lifecycles, insecure industrial protocols, limited opportunities for intrusive testing, restricted maintenance windows and inadequate logging as persistent obstacles to modern cybersecurity implementation. These limitations make an unmodified enterprise security model inappropriate for many industrial environments. Adapting Zero Trust Principles to Operational Technology, pp. 6–8 — CISA and Partner Agencies — April 2026

The architectural significance of Zero Trust

The transition towards Zero Trust changes the basis on which access is granted. Under the framework established by NIST SP 800-207, the presence of a user, device or service inside a supposedly trusted network cannot, by itself, justify access to a protected resource. Access decisions must instead account for the identity of the requesting subject, the resource being accessed, relevant security conditions and the policy governing the intended operation. Applied to industrial environments, this model can significantly reduce excessive privileges and lateral movement, provided that policy enforcement does not introduce unacceptable hazards or impede legitimate industrial control.

The principal complication is that a substantial proportion of operational equipment cannot independently evaluate modern credentials, enforce granular authorisation or communicate securely. NIST SP 800-82 Revision 3 recognises that full Zero Trust integration may be impractical for certain programmable logic controllers, human-machine interfaces and other legacy components. Accordingly, it identifies the possibility of applying Zero Trust enforcement to compatible systems at higher architectural levels and around operational boundaries rather than requiring every industrial device to implement the same controls natively.

This creates a practical distinction between native Zero Trust capability, in which a resource can participate directly in identity and policy enforcement, and compensating Zero Trust protection, in which appropriately engineered gateways, segmentation controls, privileged-access mechanisms and monitored intermediary systems restrict access to a vulnerable resource. The distinction is essential for procurement, regulatory assessment and modernisation planning because the existence of a protective boundary must never be represented as proof that the underlying device has become intrinsically secure.

NIST SP 800-207, Zero Trust Architecture — NIST — August 2020 – NIST SP 800-82 Revision 3, Guide to Operational Technology Security, Section 5.2.3.4 — NIST — September 2023

Why implementation sequencing determines the security outcome

The highest-leverage implementation strategy is not necessarily the one that deploys the greatest number of security controls in the shortest period. Industrial safety and continuity require a sequence that first establishes what equipment exists, what physical process it supports, which communications are essential, who possesses the authority to change its state, and what consequences would follow from unauthorised access or loss of service. Without this knowledge, segmentation policies may interrupt necessary process communications, authentication changes may compromise emergency access, and security tools may create additional dependencies whose failure could affect normal control.

A defensible initial sequence therefore concentrates on establishing operational ownership, identifying critical dependencies, eliminating uncontrolled remote entry, isolating unnecessary pathways, protecting engineering workstations and creating passive visibility into relevant network and process activity. Subsequent stages can introduce more granular policy enforcement, stronger device identity, improved logging, protocol protections and replacement of unsupported components, subject to engineering verification and documented maintenance constraints.

The priority must be the demonstrated containment of physical consequences rather than the nominal deployment of products. A security programme should be judged by whether a compromised supplier account can still alter controller logic, whether an infected engineering workstation can communicate with unrelated safety-critical equipment, whether emergency operations remain possible during identity-system failure, and whether operators can restore a verified configuration without depending exclusively upon a compromised vendor environment.

The strategic importance of procurement, AI integration and institutional accountability

Cybersecurity improvements implemented around vulnerable equipment constitute a transitional protection strategy, not a permanent substitute for secure industrial design. Procurement requirements must progressively favour equipment supporting authenticated maintenance, trustworthy software and firmware updates, secure configuration management, adequate event recording, reliable recovery procedures and reduced dependence on unrestricted supplier access. The CISA interagency guidance specifically identifies procurement and supply-chain management as mechanisms for addressing security limitations that cannot be economically or safely eliminated from existing systems.

An additional challenge arises from connecting advanced analytics and artificial intelligence systems to industrial operations. Such systems may improve anomaly detection, maintenance planning and operator situational awareness, but they can also create new pathways between enterprise infrastructure, external data sources and equipment capable of affecting physical processes. The appropriate governing distinction is between systems that observe and recommend and systems that can independently authorise or execute physical control actions. For safety-critical operations, automated authority should remain bounded by independently enforced engineering constraints, approved operating envelopes, explicit change-control procedures and validated recovery arrangements.

The resulting requirement for government and regulators is to develop assurance regimes that evaluate whether cybersecurity controls preserve physical-process safety under realistic compromise conditions. Certification of individual products, the presence of a Zero Trust architecture, or a high percentage of completed implementation activities cannot independently establish this outcome. Effective regulatory oversight must combine technical evidence, engineering assessment, incident exercises, vendor accountability and measurable demonstrations of containment and recovery.

Europe’s Cyber Risk: Ransomware and Critical Systems

Key Evidence Table — Verified Institutional Baseline

Indicator	Value/status	Reference date	Definition/scope	Issuer	Exact source
NSA OT Zero Trust information sheet	Published	8 Oct 2026	Primarily NSS, DoW and DIB operational environments; wider relevance to critical infrastructure	NSA	Official release
NSA high-impact activities	26 reportedly selected from 84	Oct 2026	Defence OT activity framework; full individual activity mapping requires verification against the primary sheet	NSA	Official document announcement
Interagency OT Zero Trust guidance	Published, 28 pages	29 Apr 2026	Adaptation of Zero Trust to legacy OT, safety and availability constraints	CISA and partners	Primary PDF
NIST Zero Trust Architecture	Final, SP 800-207	Aug 2020	Resource-focused, contextual access decisions	NIST	Official publication
NIST OT Security Guide	Revision 3, final	Sep 2023	OT risk management, architectures, safeguards and security controls	NIST	Official publication
NIST OT Security Guide	Revision 4, initial public draft	21 Sep 2026	Proposed expansion covering Zero Trust, asset management, monitoring and additional OT sectors	NIST	Draft record
Cross-sector legacy exposure	No validated aggregate percentage established	Oct 2026	Unsupported or non-upgradable systems across critical sectors	Multiple authorities	CISA baseline
European implementation	Jurisdiction-specific assessment required	Oct 2026	EU, Italy, France, Germany and UK regulatory and industrial requirements	National and European authorities	To be assessed separately against applicable instruments

Evidence integrity: The official NSA announcement was verified, but the complete underlying information sheet could not be directly retrieved for activity-by-activity validation during this research. The reported 26-of-84 selection is therefore not treated here as a fully audited activity catalogue. The NIST Revision 4 document remains a public draft, not a replacement final standard.

Preliminary Implementation Priorities — Analytical Assessment

The following sequencing is an analytical proposal derived from the documented constraints and controls in NSA, CISA and NIST guidance. It is not presented as the NSA’s official ranking of its 26 activities.

Priority	Intervention	Expected protection	Principal operational constraint
Immediate	Inventory critical assets and dependencies	Identifies consequential exposure and essential communications	Incomplete documentation and discovery sensitivity
Immediate	Govern remote vendor and contractor access	Reduces uncontrolled external pathways and privileged persistence	Emergency maintenance and supplier dependence
Immediate	Protect engineering workstations	Restricts unauthorised configuration and logic changes	Legacy software compatibility
High	Segment industrial zones and conduits	Restricts lateral movement and cross-process compromise	Unknown process communications and timing dependencies
High	Establish monitoring at OT boundaries	Improves detection and investigation	Limited logging and potential monitoring interference
High	Validate safety and recovery dependencies	Preserves essential operations during cybersecurity failures	Production windows and test-environment limitations
Progressive	Modernise authentication and device security	Reduces dependence on perimeter-based protection	Unsupported controllers and interoperability
Strategic	Replace irreducibly insecure equipment	Removes structural vulnerabilities that compensating controls cannot eliminate	Capital expenditure, engineering redesign and downtime

The proposed sequence must be modified where local engineering assessment identifies unacceptable physical consequences, particularly for safety instrumented systems, critical electrical protection, emergency shutdown functions and systems whose communications or timing requirements cannot tolerate additional enforcement components.

Compensating Controls Versus Replacement — Decision Framework

Decision dimension	Compensating controls	Equipment replacement
Initial disruption	Potentially limited when applied externally	May require substantial shutdown or commissioning
Authentication	Can govern access through intermediary systems	Can provide native device authentication
Encryption	Can secure selected communication boundaries	Can support authenticated and encrypted native protocols
Logging	Can improve visibility through gateways and network sensors	Can provide device-level security event records
Legacy vulnerabilities	Reduces reachability and exploitation opportunities	May eliminate vulnerabilities associated with obsolete designs
Recovery independence	May remain dependent on original vendors and engineering tools	Can establish improved recovery capabilities if contractually required
Long-term residual risk	Persists within the protected legacy asset	Depends upon replacement architecture and lifecycle governance

The principal decision is not whether compensation or replacement is intrinsically superior. It is whether the residual consequences of compromise remain tolerable under actual operating conditions, including loss of identity infrastructure, malicious access through a trusted vendor, failure of a security gateway and recovery from a compromised engineering workstation.

Principal Data Gaps and Watch Indicators

National exposure and equipment age. The available guidance establishes the existence and operational importance of legacy technology but does not provide a statistically representative inventory of obsolete controllers, unpatchable workstations, unsupported building automation systems or critical devices lacking authenticated communications. National-level regulatory planning requires a consistent measurement method distinguishing chronological age, end-of-support status, exploitable configuration and operational consequence.

Effectiveness of the NSA activity catalogue. The specific contribution of the 26 high-impact activities should be evaluated against actual compromise scenarios rather than inferred from implementation status. The decisive evidence would include controlled exercises, independently assessed containment outcomes and documented operational compatibility across different industrial architectures.

Remote-access governance. Regulators require evidence distinguishing access channels protected by encryption and multifactor authentication from sessions subject to genuine task-level authorisation, destination restrictions, operator approval and revocation. A technically protected connection may still confer excessive operational authority.

Safety and availability during enforcement failure. The most consequential test is whether enforcement infrastructure can fail without compromising necessary control, protection or emergency operations. Validation must distinguish the failure behaviour of monitoring gateways, access-policy services, identity dependencies, remote support infrastructure and controllers themselves.

Procurement and supplier dependency. Operators need evidence of whether manufacturers can supply security event logs, authenticated configuration mechanisms, secure updates, independently restorable backups, vulnerability information and supportable migration pathways without unacceptable cost or operational constraints.

AI-enabled operational authority. The principal emerging assurance issue is whether analytical or automated systems can indirectly acquire control authority through management interfaces, orchestration tools, maintenance platforms or engineering applications. Effective assurance must account for indirect control pathways, not only direct access to controllers.

Priority Intelligence Questions for Governments and Regulators

1. What proportion of safety-critical and high-consequence OT assets cannot support modern authentication, logging, encryption or reliable security maintenance?

2. Which of the NSA’s 26 high-impact activities are already implemented across defence, energy, water, transport, manufacturing and government facilities, and how consistently are their outcomes validated?

3. To what extent do privileged vendor connections create unmanaged pathways between enterprise networks and equipment capable of changing physical processes?

4. Which combinations of segmentation, controlled access and passive monitoring demonstrably prevent lateral movement without interfering with necessary communications?

5. What residual attack paths remain after compensating controls are implemented around unsupported industrial equipment?

6. How frequently do actual OT incident exercises demonstrate that safe operations can continue following compromise of an account, workstation, remote-access gateway or associated identity service?

7. Which supplier dependencies prevent operators from independently restoring controllers, verifying logic integrity or replacing unsupported software?

8. What procurement requirements would most effectively improve native security capabilities without creating disproportionate costs or excluding viable industrial suppliers?

9. What measurable differences exist in incident detection, containment, restoration time and physical consequences between mature and immature OT access-governance programmes?

10. Under what technical, economic and safety conditions should regulators require accelerated equipment modernisation rather than continued reliance upon compensating controls?

Net Assessment — Decision Consequences

The available official evidence supports a high-confidence judgment that ageing operational technology creates a persistent cybersecurity challenge that cannot be resolved through conventional enterprise security measures alone. The NSA’s October 2026 intervention, the April 2026 CISA interagency guidance and the NIST security publications converge on the need for layered protection, reduced implicit trust, controlled access and explicit consideration of safety and availability.

There is moderate confidence that prioritising remotely accessible pathways, engineering workstation integrity, industrial segmentation and operational visibility will yield substantial early risk-reduction benefits across many ageing installations. That judgment rests on the relationship between common attack pathways and the controls designed to restrict them, rather than on a verified cross-sector measurement of implementation outcomes.

There is limited confidence in any universal quantitative estimate of the national ageing-equipment population, the effectiveness of the 26 selected activities or the financial return from particular modernisation strategies. Those questions require additional sector-specific evidence, actual asset inventories and controlled operational validation.

For the European Union, Italy, France, Germany and the United Kingdom, the same technical principles are materially relevant, but U.S. national security guidance cannot be treated as automatically establishing European regulatory obligations. Subsequent analysis must distinguish the legal applicability of European and national cybersecurity requirements from the operational value of American guidance and international industrial-security standards.

The decisive strategic conclusion is that Zero Trust for operational technology must be understood as an engineering and governance discipline designed to preserve authorised physical control under conditions of digital compromise. Its effectiveness will ultimately depend upon the ability of public authorities and infrastructure operators to demonstrate that a successful intrusion into one component does not automatically confer the ability to disrupt an essential service.

The governing choice for policymakers is therefore not between maintaining ageing infrastructure and introducing new cybersecurity technology. It is between continuing to accept poorly characterised dependencies and establishing a measurable, safety-compatible transition towards infrastructure whose critical functions remain protected even when individual digital components cease to be trustworthy.

---

---

PILLAR I — STRATEGIC EXPOSURE, ADVERSARIAL THREATS AND THE LEGACY OT CONSTRAINT

Chapter 1. Strategic Context and Threat Environment

Principal Strategic Judgment: Critical Infrastructure Cybersecurity Has Become a Question of National Operational Sovereignty

The strategic significance of operational technology cybersecurity in October 2026 extends well beyond the protection of industrial networks against unauthorised access. The central national security concern is the possibility that an adversary may acquire sufficient access to the digital systems governing physical infrastructure to influence the availability, integrity, reliability or safety of services upon which government authority, military readiness, economic production and civilian welfare depend. This exposure is particularly consequential in ageing industrial environments, where essential equipment often continues operating long after the manufacturers’ original cybersecurity assumptions, software support arrangements and communications technologies have become obsolete.

The National Security Agency’s cybersecurity information sheet, Hardening Department of War Critical Operational Technology Environments with Zero Trust Principles, published on 8 October 2026, should therefore be interpreted within a broader transition in national infrastructure protection policy. The agency’s emphasis on continuous verification, the assumption of possible compromise and the prevention of unauthorised lateral movement reflects recognition that industrial security cannot depend solely on the historical distinction between external networks and internally trusted control systems.

The NSA explicitly identifies consequences extending to national security, economic security, public health and safety, and highlights the possibility that hostile cyber operations may seek to deny, degrade, disrupt, deceive or destroy critical infrastructure capabilities. Its guidance is primarily directed at National Security Systems, Department of War environments and organisations within the Defence Industrial Base, although its technical implications extend to civilian infrastructure operators. The NSA also identifies the integration of advanced intelligent systems into operational technology as a source of additional attack surfaces and potential disruption opportunities.

NSA Releases Zero Trust Guidance for Protecting Operational Technology Systems — National Security Agency — October 2026

The importance of this development lies in the changing relationship between digital compromise and physical consequences. An enterprise network intrusion may expose confidential information, interrupt administrative services or enable financial extortion. A compromise involving operational technology may produce those same effects while also interfering with the physical processes that generate electricity, treat drinking water, regulate industrial temperatures, maintain transportation infrastructure, provide emergency power or protect hazardous industrial equipment.

These consequences are not automatic. Their severity depends on the design of the affected installation, the engineering authority available to the attacker, the presence of independent protective systems, the integrity of process measurements, and the ability of human operators to detect and correct abnormal conditions. Nevertheless, the possibility of crossing from cyber compromise into physical process manipulation fundamentally alters the standards by which security investments must be evaluated.

In conventional information security, success can often be measured through system availability, confidentiality, incident containment and restoration of data. In critical operational environments, such measures remain necessary but are insufficient. A cybersecurity intervention may prevent malware propagation while simultaneously interrupting communications essential to a production process. Conversely, an industrial controller may continue producing apparently normal outputs while an attacker has compromised its configuration integrity or the trustworthiness of the information presented to operators.

The resulting national security requirement is not simply to keep industrial systems online. It is to maintain authorised, observable and recoverable control over consequential physical processes, including under conditions in which one or more connected digital components are no longer trustworthy.

The Transformation of the Industrial Threat Environment: From Network Penetration to Strategic Prepositioning

The contemporary threat environment is distinguished by the coexistence of three different forms of adversarial activity: sustained state-sponsored intrusion intended to preserve access for potential future operations, economically motivated campaigns whose disruptive effects may extend into physical infrastructure, and opportunistic or politically motivated attacks against exposed industrial equipment.

These categories differ in resources, objectives, persistence and operational sophistication, but they can converge upon the same technical weaknesses. Poorly governed remote connections, reused credentials, externally accessible management interfaces, shared identity infrastructure and insufficient separation between enterprise computing and operational networks may be exploitable by actors with substantially different motivations.

The most strategically consequential case is persistent access undertaken before an overt military or political crisis. In February 2024, CISA, the NSA, FBI and international partners issued a joint advisory concerning People’s Republic of China state-sponsored activity associated with Volt Typhoon. The advisory described access to United States critical infrastructure networks using techniques designed to maintain a presence while avoiding conventional detection, including abuse of legitimate administrative tools and credentials.

The distinction between establishing access and exercising destructive capabilities is essential. The public evidence establishes persistent compromise of selected infrastructure-related environments and identifies preparation for potentially disruptive operations as a major security concern. It does not establish that every affected organisation experienced physical process interference, nor does it demonstrate that all intrusions necessarily resulted in operational control of industrial equipment.

PRC State-Sponsored Actors Compromise and Maintain Persistent Access to U.S. Critical Infrastructure — CISA, NSA, FBI and International Partners — February 2024

The relevance to Zero Trust is particularly direct because sophisticated intruders need not exploit a previously unknown industrial-controller vulnerability if an existing, apparently legitimate administrative relationship provides a pathway towards operational systems. A compromised identity service, a privileged engineering account or an inadequately restricted supplier connection may permit the attacker to move from an initial point of access towards progressively more consequential resources.

The April 2026 interagency guidance explicitly identifies the risk created by shared domains and credentials between IT and OT environments, observing that compromised enterprise identities can facilitate movement into operational networks. It also highlights compromised third-party software updates, supply-chain weaknesses and unrestricted supplier access as relevant intrusion mechanisms.

Adapting Zero Trust Principles to Operational Technology, pp. 6–7 — CISA, Department of War, Department of Energy, FBI and Department of State — April 2026

These findings produce an important strategic inference: a facility may maintain substantial perimeter security while remaining vulnerable to an adversary operating through access relationships that the organisation itself regards as legitimate. The danger is not limited to the technical compromise of a device. It includes the possibility that access privileges granted for normal maintenance, monitoring or systems administration can be used for purposes never authorised by the operator.

For national security authorities, this requires the intelligence assessment to move beyond identifying exposed assets and towards understanding which existing access relationships could permit manipulation of essential processes during a crisis. In particular, the national significance of an intrusion depends not only on the number of compromised systems but also on the functions they support, the availability of alternative operating modes and the potential for coordinated disruption across multiple facilities.

State-Sponsored Targeting of Industrial Controllers: Lessons from Documented Operations

The campaign associated with Iranian Islamic Revolutionary Guard Corps-affiliated actors operating under the CyberAv3ngers persona demonstrates how relatively elementary industrial security weaknesses can produce operationally serious compromises.

The joint CISA advisory, updated in December 2024, documented the targeting of Unitronics Vision Series programmable logic controllers and associated human-machine interfaces in multiple sectors. The affected equipment was accessible through the internet and, in documented instances, relied upon default credentials or lacked effective password protection.

The updated advisory reported at least 75 compromised devices in the United States between November 2023 and January 2024, including at least 34 associated with the water and wastewater sector. These figures refer to observed compromises within the specified investigation and should not be interpreted as an estimate of the entire population of exposed industrial controllers or the overall incidence of OT compromise.

The advisory also documented activities extending beyond visual defacement. Investigators identified the replacement of legitimate controller logic, interference with device access and changes that complicated restoration by legitimate operators. These findings establish that the threat was not confined to reputational disruption or unauthorised display messages: affected devices could be subjected to configuration manipulation with potential consequences for process integrity and recoverability.

IRGC-Affiliated Cyber Actors Exploit PLCs in Multiple Sectors, Including U.S. Water and Wastewater Systems Facilities — CISA, FBI, NSA, EPA and International Partners — Updated December 2024

This case is particularly informative because it demonstrates a relationship between modest initial technical requirements and potentially disproportionate operational consequences. A remotely accessible controller protected by inadequate credentials may be vulnerable without requiring the attacker to develop a sophisticated exploit against its firmware. Once access has been established, the resulting authority depends on the permissions and interfaces exposed by the device.

The practical lesson is that cybersecurity maturity cannot be inferred from the technical complexity of the attacker. A facility may possess highly engineered mechanical processes while relying on comparatively weak protections for the digital interfaces used to administer those processes.

Nevertheless, the public record also illustrates why operational consequences must be assessed precisely. In November 2023, CISA reported that an affected United States water authority disconnected a compromised device and switched to manual operations, with no known risk to the municipality’s drinking water or water supply. This establishes an example in which alternative operating arrangements limited the consequences of cyber compromise; it does not establish that manual operation would always be available or sufficient at other facilities.

Exploitation of Unitronics PLCs Used in Water and Wastewater Systems — CISA — November 2023

The appropriate strategic conclusion is that incident severity depends upon both the adversary’s access and the engineering resilience of the installation. Industrial cybersecurity protection must therefore be assessed alongside physical redundancy, independent safety functions, local operating capability, emergency procedures and the ability to restore trusted configurations.

Ransomware and the Industrial Availability Problem

Ransomware creates a different but equally important category of industrial exposure. Its economic objective generally centres on coercing victims through service disruption, data theft or denial of access to essential computing resources. In industrial environments, however, compromise of systems surrounding the production process can produce significant operational effects even without direct manipulation of programmable logic controllers.

A manufacturing plant may suspend production because engineering workstations, production scheduling systems, quality-control records or industrial historians are unavailable. A logistics operator may lose the capacity to coordinate cargo movements despite retaining functioning mechanical equipment. A healthcare facility may retain operating medical devices while losing access to supporting building systems, administrative applications or critical operational information.

These mechanisms mean that a cyber incident does not need to penetrate the lowest level of an industrial control architecture to affect the availability of the physical service.

The European Union Agency for Cybersecurity, ENISA, provides a relevant comparative threat baseline in its ENISA Threat Landscape 2025, which analysed 4,875 incidents covering the period from 1 July 2024 to 30 June 2025. The publication was subsequently revised in September 2026 to correct certain figures and presentation errors. Its incident universe is valuable for examining the wider European cyber threat environment, but it must not be treated as a representative statistical sample of successful attacks against industrial controllers.

ENISA Threat Landscape 2025 — European Union Agency for Cybersecurity — October 2025, revised September 2026

For operational technology, the most significant ransomware-related exposure often resides in dependencies that appear secondary from a mechanical engineering perspective but are indispensable for sustained operations. Industrial historians, virtualisation hosts, supervisory computers, engineering repositories and authentication servers may become operational single points of failure when facilities have gradually incorporated them into normal production procedures.

An effective risk assessment must therefore distinguish between three categories of disruption: direct compromise of control equipment, interruption of digital services required to supervise or maintain the process, and deliberate protective shutdown undertaken by operators because the integrity of their operational environment can no longer be established.

This third category deserves particular attention. A facility may halt production not because an adversary has physically damaged equipment, but because continued operation under uncertain digital conditions would create unacceptable safety, quality or regulatory risks. In those circumstances, cybersecurity failure becomes an operational availability problem through a legitimate engineering decision rather than through direct hostile manipulation of machinery.

Artificial Intelligence, Accelerated Reconnaissance and the Changing Economics of Attack

The increasing use of artificial intelligence in cyber operations introduces an additional dimension to the threat environment, although its effects require careful separation between demonstrated capabilities, official assessments and plausible future developments.

In its October 2026 announcement, the NSA explicitly warned that adversaries were employing advanced intelligent capabilities to automate reconnaissance, accelerate exploit development and increase the speed and scale of cyber campaigns. The agency also noted that integration of such technologies into operational environments creates additional risks and attack surfaces.

NSA Releases Zero Trust Guidance for Protecting Operational Technology Systems — NSA — October 2026

The most defensible interpretation is that intelligent automation can reduce the effort required for selected stages of an intrusion campaign, particularly those involving large quantities of publicly available technical material, exposed-system information, documentation and software weaknesses. It does not follow that such automation reliably enables an attacker to understand the physical behaviour of every industrial installation or to manipulate unfamiliar control systems without substantial domain knowledge.

Industrial environments impose constraints that distinguish them from conventional enterprise networks. The same nominal controller may perform different functions depending on the installed logic, connected instruments, process interlocks and operating procedures. Equipment documentation can describe available commands without revealing whether issuing those commands in a particular installation would have useful, ineffective or dangerous consequences.

For this reason, the effect of AI on operational technology threats should be analysed across distinct stages of the attack chain rather than expressed through a single unsupported estimate of increased attack probability.

Attack-chain stage	Potential contribution of AI-assisted methods	Industrial-specific limitation	Confidence in the mechanism
Target discovery	Classification of exposed services, documentation and probable supplier relationships	Internet visibility does not establish operational reachability	High
Reconnaissance	Faster analysis of protocols, configurations and technical documentation	Actual plant topology and control logic may remain unavailable	High
Initial intrusion	Assistance with phishing, scripting and examination of known weaknesses	Authentication, segmentation and access controls still determine reachability	Moderate to high
Privilege escalation	Assistance in identifying misconfigurations and permission relationships	Real access depends on installed systems and available credentials	Moderate
Lateral movement	Faster examination of reachable systems and administrative relationships	Industrial boundaries and proprietary communications may limit movement	Moderate
Physical-process manipulation	Potential support for interpreting control-system information	Requires dependable knowledge of process behaviour, constraints and protective functions	Limited generalisable evidence
Campaign coordination	Faster processing of information across multiple potential targets	Coordinated physical outcomes require site-specific preparation	Moderate
Defensive evasion	Potential assistance in adapting scripts and operational behaviour	OT-specific telemetry and process anomalies may remain observable	Moderate

Analytical classification: these confidence assessments concern the plausibility and technical basis of the mechanisms, not statistically measured success rates for AI-enabled OT attacks.

An additional consideration concerns the defensive integration of AI systems. In December 2025, the NSA and partner agencies published guidance specifically addressing secure AI integration within operational technology, recognising both the possible benefits of improved decision support and the new risks created by connecting analytical systems to safety- and mission-critical environments.

NSA, CISA and Partners Release Guidance on Integrating AI in Operational Technology — NSA — December 2025

For national security authorities, the principal concern is not that artificial intelligence necessarily renders established defences obsolete, but that it may enable adversaries to exploit already-existing weaknesses more rapidly than organisations can discover, validate and correct them. Facilities with incomplete inventories, extensive supplier connectivity and prolonged maintenance cycles may therefore face increasing pressure even where the underlying equipment has not changed.

The Scale of Legacy Infrastructure Exposure: What the Quantitative Record Actually Establishes

The ageing-equipment problem is widely recognised, but its national scale cannot presently be expressed through a single reliable percentage applying equally to energy, water, manufacturing, transportation, public health and government facilities.

One difficulty concerns the definition of legacy equipment. A device may be chronologically old while remaining supported and functionally maintainable. Another may be relatively recent yet already depend on obsolete software or insecure communications. A third may be operationally reliable but incapable of meeting modern cybersecurity requirements without substantial architectural changes.

These distinctions have important implications for government statistical assessments. Equipment age, manufacturer support status, cybersecurity capability, exposure to untrusted networks and physical consequence are related variables, but they are not interchangeable.

The United States Government Accountability Office provides a useful, although bounded, illustration of the legacy technology problem. In its July 2025 report on federal information systems, GAO reviewed 69 legacy systems and identified 11 among those most urgently requiring modernisation. These 11 systems ranged from approximately 23 to 60 years old and collectively accounted for approximately $754 million in annual operating and maintenance expenditure.

Of the 11 systems, eight used outdated programming languages, four had unsupported hardware or software, and seven operated with known cybersecurity vulnerabilities. The figures demonstrate continuing reliance upon difficult-to-modernise federal technologies, but the population principally concerns legacy information systems and must not be presented as a representative census of industrial controllers.

Information Technology: Agencies Need to Plan for Modernizing Critical Decades-Old Legacy Systems — U.S. Government Accountability Office, GAO-25-107795 — July 2025

The GAO findings are nevertheless relevant because industrial infrastructure increasingly depends upon conventional computing systems whose ageing software, operating environments and administrative applications may determine the availability of industrial functions. The boundary between legacy IT and legacy OT is therefore operationally significant but not always reflected in separate investment programmes.

A different quantitative observation comes from the Environmental Protection Agency. In February 2026, EPA reported that its Office of Water had identified cybersecurity vulnerabilities at 277 water systems during 2025, and had worked with affected organisations on tailored corrective measures, including authentication improvements and access restrictions.

This figure establishes the scale of one documented federal assistance activity. It does not establish the number or percentage of vulnerable water systems nationwide, and the population of systems examined through that activity cannot automatically be assumed to represent the national water sector.

EPA Actions Help Safeguard Water Systems from Cyberattacks — U.S. Environmental Protection Agency — February 2026

The distinction between documented exposure and population-wide inference is particularly important because the most relevant security characteristics may remain invisible to traditional asset statistics. A regulator may know the number of substations, pumping facilities or treatment plants under its jurisdiction without knowing how many rely upon unsupported engineering workstations, shared supplier credentials or industrial controllers that cannot produce useful security logs.

Comparative Evidence on Legacy Systems and Industrial Exposure

Evidence domain	Verified figure or finding	Population represented	What can legitimately be concluded	Principal limitation
Critical federal legacy systems	69 reviewed; 11 identified as most urgent	Selected United States federal information systems	Critical federal missions remain dependent on ageing technology	Not a national OT equipment census
Age of the 11 selected systems	Approximately 23–60 years	GAO priority systems	Some mission-critical platforms have exceptionally long service lives	System age is not equivalent to component age
Unsupported hardware or software	4 of 11	GAO priority systems	Manufacturer support gaps remain material	Deliberately selected, high-concern population
Known cybersecurity vulnerabilities	7 of 11	GAO priority systems	Critical legacy platforms can retain recognised vulnerabilities	Does not establish exploitability in all circumstances
Annual operating and maintenance cost	Approximately $754 million collectively	GAO’s 11 selected systems	Maintaining legacy systems can require substantial recurring expenditure	Includes non-OT systems; not a cybersecurity cost estimate
EPA water cybersecurity assistance	277 systems with identified vulnerabilities during 2025	Systems reached through a specific EPA activity	Material weaknesses were documented in a real operational sector	No national prevalence denominator
IRGC-affiliated PLC compromises	At least 75 devices, including at least 34 water-sector devices	Investigated U.S. compromises, Nov 2023–Jan 2024	Exposed controllers were compromised across multiple facilities	Incident population, not installed-base prevalence
ENISA European threat dataset	4,875 incidents	European cyber incidents, Jul 2024–Jun 2025	Provides broad cyber-threat context for European resilience	Not a representative OT-specific incident series

Sources: GAO-25-107795 — July 2025; EPA Water Cybersecurity Activities — February 2026; CISA Advisory AA23-335A — December 2024 Update; ENISA Threat Landscape 2025 — Revised September 2026.

The evidence supports a high-confidence conclusion that legacy systems and documented industrial weaknesses remain strategically consequential. It does not support an estimate claiming that a particular percentage of all national critical infrastructure equipment is obsolete, vulnerable or directly reachable by a hostile actor.

Sectoral Exposure: Different Physical Processes, Different Security Consequences

The strategic consequences of an operational technology compromise differ considerably among sectors. A common cybersecurity weakness can create distinct forms of physical exposure depending upon the industrial process, its response time, the availability of independent protective equipment and the extent of dependence upon centralised supervision.

In electricity systems, the critical concern includes the preservation of reliable generation, transmission, distribution and restoration capabilities. Operational technology may participate in generating-unit control, substation automation, protection coordination, network monitoring and supporting equipment. A compromise affecting supervisory data may have different consequences from an intrusion affecting protection settings or control commands. The former may impair visibility and decision-making; the latter may create opportunities for inappropriate switching or interference with electrical equipment, depending upon the architecture.

Water and wastewater infrastructure presents a different combination of service-continuity and public-health consequences. Operational technology may regulate pumps, treatment processes, reservoir levels, chemical dosing and distribution-system conditions. An interruption affecting a single monitoring interface may be manageable through local observation or manual control, while an event involving unreliable process measurements or unauthorised changes to treatment parameters may require more consequential operational intervention.

Transportation infrastructure contains multiple distinct operational environments rather than a single control-system model. Railway signalling, traffic management, port terminal equipment, airport facilities, tunnels and transportation-related energy systems can have fundamentally different safety requirements. In some cases, loss of communication is designed to trigger a restrictive or safe state. In others, continuity depends upon local controllers remaining capable of autonomous operation. The cybersecurity significance of an intervention therefore depends on the exact function of the affected equipment.

Agriculture and food-related infrastructure introduce dependencies involving irrigation controls, pumping equipment, storage conditions, refrigeration, industrial processing and distribution logistics. Their security exposure may be intensified by geographically dispersed assets, seasonal operating patterns and reliance upon third-party equipment servicing. A compromise affecting a remote irrigation controller may have a different consequence profile from one affecting refrigeration or temperature regulation at a major food-processing installation.

Public health infrastructure includes both conventional digital systems and operational technologies supporting medical services. The availability of electrical power, backup generation, environmental conditions, specialised medical gases and building automation can materially affect the continuity of healthcare services. A security intervention that disrupts environmental or power-control systems may create immediate operational problems even when clinical information systems and individual medical devices remain unaffected.

Government facilities and defence installations combine industrial functions with institutional and security requirements. Facilities may depend upon electrical distribution, backup power, physical access control, environmental management, communications infrastructure and mission-specific technical equipment. The significance of a compromise depends on whether the affected system supports ordinary facility operations or a function whose interruption could impair command, continuity of government or military capability.

Sector-Specific Operational Consequence Matrix

Sector	Representative OT dependency	Material compromise pathway	Potential physical or mission consequence	Most important consequence variable
Electricity	Generation controls, substations, grid-support equipment	Unauthorised configuration or commands	Equipment disruption, service interruption, impaired restoration	Protection independence and network redundancy
Water and wastewater	Pumps, dosing, treatment controls, reservoir monitoring	Controller compromise or unreliable telemetry	Service disruption, treatment uncertainty, public-health exposure	Independent measurements and manual operating capability
Rail transportation	Signalling interfaces, supervisory systems, supporting power	Loss or manipulation of supervisory functions	Restrictive operation, disruption or safety-related intervention	Safety integrity and fail-safe behaviour
Ports and logistics	Cranes, terminal automation, access systems	Compromise of control or supporting services	Cargo disruption, equipment unavailability, logistical delay	Manual fallback and control-system separation
Agriculture	Irrigation and storage controls	Remote access misuse or control failure	Production losses, equipment damage, resource misuse	Geographic dispersion and recovery time
Food manufacturing	Temperature, pressure and production controls	Engineering-system or process-integrity compromise	Production interruption, product-quality concerns	Process monitoring and independent safeguards
Hospitals	Backup power, ventilation, facility management	Interference with supporting OT	Loss of service resilience and potential patient-care disruption	Independence of essential facility functions
Government facilities	Building automation, access and electrical support	Compromise of shared facility-management networks	Operational disruption, loss of access or mission support	Dependence of essential functions upon facility OT
Defence industrial facilities	Industrial production, testing, environmental controls	Engineering or supplier-access compromise	Production delays, integrity concerns, mission impact	Critical manufacturing dependencies and trusted configuration

This table describes plausible mechanisms and consequences, not a ranking of observed incident frequencies. A sector-level determination requires facility-specific engineering evidence.

National Security Systems, the Defence Industrial Base and Civilian Infrastructure: Three Distinct Governance Problems

Although the NSA’s October 2026 information sheet addresses security challenges shared by many infrastructure operators, its principal institutional audience is not identical to the entire civilian critical infrastructure community.

National Security Systems operate within a framework associated with national defence, intelligence and other designated security functions. Their protection may involve additional information assurance, mission security and national security governance requirements not applicable to ordinary civilian operators. Department of War installations and associated operational environments may also be subject to mission-specific engineering standards and operational security requirements.

The Defence Industrial Base presents a different institutional structure. Defence contractors and suppliers may operate privately owned factories and production infrastructure while supporting government programmes involving sensitive technologies, military capabilities and strategically important supply chains. Their operational technology exposure must therefore be assessed not only as a potential interruption to commercial production but also as a possible dependency affecting national defence output or programme continuity.

Civilian critical infrastructure operators, by contrast, are governed through a more heterogeneous combination of sectoral legislation, regulatory oversight, industry standards, commercial obligations and national cybersecurity frameworks. A municipal water utility, an energy network operator, a manufacturing company and a major hospital may all rely upon industrial control systems but face different legal obligations, investment constraints and oversight arrangements.

The NSA’s technical recommendations can inform these civilian environments without converting a defence-oriented information sheet into a universally binding regulatory instrument.

The April 2026 CISA-led guidance is particularly relevant to this wider application because it states that its recommendations, although intended to assist United States government organisations, may be used by any organisation operating OT systems. It also explicitly recognises the need to adapt controls to operational constraints rather than impose an unchanged information-technology security architecture.

Adapting Zero Trust Principles to Operational Technology, pp. 2 and 5–8 — CISA and Partner Agencies — April 2026

The distinction matters for government policy because national-level cybersecurity guidance should identify the outcome expected of operators without assuming that all sectors possess the same technical capacity, staff availability or ability to finance equipment replacement.

A defensible government programme would consequently differentiate between minimum protective expectations applicable across critical sectors, additional assurance requirements for high-consequence processes and specialised obligations arising from national security or defence-related functions.

European Strategic Implications: Regulatory Convergence Without Operational Uniformity

The relevance of United States OT Zero Trust guidance to Europe is substantial because European infrastructure exhibits many of the same structural characteristics: long-lived industrial equipment, complex ownership arrangements, increasing connectivity, externally maintained systems and strong operational continuity requirements.

However, a European assessment must distinguish between the applicability of European cybersecurity law and the technical value of security principles developed by American authorities. The existence of similar vulnerabilities does not establish identical legal duties or identical enforcement mechanisms.

At the European Union level, the NIS2 framework establishes cybersecurity risk-management and supervisory obligations for covered entities across specified sectors. Its operational importance lies in requiring affected organisations to address security governance, incident handling, continuity, supply-chain risks and other cybersecurity measures through a legal framework broader than any individual technology architecture. Zero Trust may contribute to fulfilling relevant security objectives, but NIS2 does not prescribe the wholesale deployment of one specific Zero Trust product or architecture throughout legacy industrial facilities.

Directive (EU) 2022/2555 on Measures for a High Common Level of Cybersecurity Across the Union — European Parliament and Council — December 2022

Italy’s strategic challenge is especially relevant to energy infrastructure, industrial manufacturing, transport facilities and public-service systems characterised by heterogeneous equipment estates and substantial integration between domestic operators, international technology suppliers and industrial maintenance providers. The central implementation question is how sector-specific regulators, the national cybersecurity authority and infrastructure operators can translate legal risk-management requirements into verifiable protections for long-lived OT, without encouraging disruptive replacement programmes unsupported by engineering readiness.

France faces the corresponding requirement to integrate industrial cybersecurity with nationally significant energy, transportation, defence and public-service infrastructure. For highly consequential installations, cyber protection must remain aligned with independently established safety requirements and operational responsibilities. The relevant policy issue is not merely the adoption of modern digital identities, but the preservation of authorised industrial control across complex supplier and operator relationships.

Germany’s industrial exposure includes extensive manufacturing automation, energy infrastructure and interconnected industrial production. Its distinctive challenge is the interaction between highly specialised industrial equipment, long asset lifecycles and supplier ecosystems serving facilities that may have limited opportunities for extensive operational changes. A Zero Trust programme that imposes enterprise-style control mechanisms without detailed process engineering would risk increasing operational complexity rather than demonstrating improved resilience.

The United Kingdom operates under its own statutory and regulatory framework following its departure from the European Union. Its national cybersecurity institutions and sector regulators must therefore be assessed separately from EU implementation obligations. The technical requirements of protecting industrial equipment remain closely comparable, but differences in regulatory scope, institutional responsibilities and assurance arrangements can affect procurement and implementation choices.

At the European level, the principal opportunity is to align evidence requirements around common technical outcomes: controlled supplier access, adequate asset knowledge, segmentation compatible with industrial processes, integrity of engineering changes and validated recovery. Such convergence would permit stronger comparability between national programmes without assuming that a water utility, an electricity transmission operator and a defence production facility should deploy identical technical controls.

Chapter 1 — Key Judgments

The principal threat to national infrastructure resilience is not reducible to a single malware category, adversary or vulnerable industrial protocol. It arises from the interaction between interconnected operational environments, persistent access opportunities, long equipment lifecycles and the possibility that digital compromise may interfere with physical processes upon which essential services depend.

State-sponsored prepositioning represents a particularly consequential threat because persistent access may be retained for use during periods of political or military tension. Ransomware and opportunistic exploitation create different pathways to disruption, including through systems that support industrial operations without directly controlling machinery. AI-assisted cyber activity may increase the speed and efficiency of selected intrusion stages, although the extent of its impact upon successful physical-process manipulation remains insufficiently quantified.

The available official record documents significant vulnerabilities and actual compromises, but it does not support a single statistically reliable estimate of legacy OT exposure across all critical sectors. Governments should consequently avoid designing national investment programmes around unsupported prevalence figures and instead require evidence connecting vulnerable assets to their operational consequences.

The central strategic conclusion is that the protection of critical infrastructure must be evaluated at the level of essential physical functions, not merely at the level of networks, devices or cybersecurity products.

What Would Change the Chapter 1 Assessment

The assessment would materially change if authoritative cross-sector inventories demonstrated that vulnerable legacy systems were substantially less prevalent or more effectively isolated than currently documented, or if operational testing established that specific protection architectures consistently prevented an adversary from converting compromised credentials into meaningful control-system authority.

Conversely, verified evidence of coordinated intrusion campaigns producing simultaneous physical disruption across multiple infrastructure operators, or documented AI-enabled attacks capable of reliably manipulating diverse industrial processes without significant site-specific preparation, would increase the assessed strategic urgency of accelerated modernisation.

The most consequential missing evidence remains a comparable national baseline connecting asset age, support status, remote access, engineering authority, independent safety protections and the tested consequences of compromise.

Chapter 2. Technical and Operational Challenges of Legacy OT

Principal Judgment: The Central Engineering Problem Is the Incompatibility Between Modern Cybersecurity Assumptions and the Operational Requirements of Legacy Control Systems

The central technical challenge of securing ageing operational technology is that industrial equipment cannot necessarily accommodate the security controls now considered routine in enterprise computing without affecting the physical functions it was designed to perform. The difficulty is not confined to obsolete software or the absence of encryption. It arises from the architecture of industrial control itself, where controllers, sensors, actuators, communications networks, engineering applications and protective systems must operate as coordinated components of a physical process whose reliability, timing and safety requirements can exceed the flexibility available to cybersecurity administrators.

A conventional computing environment can often tolerate maintenance interruptions, authentication delays, operating-system restarts, endpoint inspection and software replacement within planned service windows. Industrial environments may instead rely upon equipment that performs the same control function continuously for years, communicates using protocols with limited security features, and depends upon software configurations that have been validated against a particular mechanical or electrical installation.

Replacing or modifying one component can affect relationships established through commissioning, engineering testing and operational experience. An apparently minor software or network change may alter communication timing, invalidate vendor support conditions, disrupt a supervisory interface or prevent technicians from recovering a controller following failure.

NIST SP 800-82 Revision 3 addresses precisely this distinction, establishing an OT-specific security framework organised around the unique performance, availability, reliability and safety requirements of systems that interact with the physical environment. The document’s expanded scope extends beyond conventional industrial control systems to include building automation, transportation, physical access control and environmental monitoring.

Guide to Operational Technology Security, NIST SP 800-82 Revision 3 — National Institute of Standards and Technology — September 2023

The CISA interagency guidance reinforces the same conclusion. It explicitly warns that blanket application of conventional IT-oriented Zero Trust capabilities to OT is neither reasonable nor feasible, given the physical and organisational constraints of operational environments.

Adapting Zero Trust Principles to Operational Technology, pp. 5–8 — CISA and Partner Agencies — April 2026

The policy consequence is significant. Industrial cybersecurity measures should be approved through an engineering risk-management process that evaluates not only their ability to reduce unauthorised access but also their possible effects on control-loop performance, equipment protection, emergency operations, process stability and restoration capabilities.

Industrial Control Architecture: Why Device Function Matters More Than Network Classification

The expression operational technology encompasses several distinct types of equipment that participate in the supervision, control or protection of physical processes. Treating them as one homogeneous device category can produce significant errors in both risk assessment and security architecture.

Programmable logic controllers execute control logic for machinery and processes. Distributed control systems coordinate larger or more complex industrial operations, often involving numerous controllers, operator stations and specialised communication networks. Supervisory control and data acquisition systems provide monitoring and supervisory functions across local or geographically dispersed installations. Human-machine interfaces present operating information and permit authorised personnel to interact with processes. Engineering workstations provide capabilities for configuring controllers, modifying logic, changing parameters, diagnosing faults and maintaining the technical configuration of an installation.

Field devices occupy another part of the architecture. Sensors measure process conditions such as pressure, temperature, flow or position; actuators change physical conditions through valves, motors, switches and related mechanisms. Safety instrumented systems and other independent protective equipment may be designed to detect hazardous conditions and move a process towards a defined safe state.

These categories frequently overlap in practice, and the functional relationships between them are more important than any assumed universal network topology.

A compromised operator workstation may permit improper supervisory commands but not necessarily allow modification of the controller’s internal logic. A compromised engineering workstation may provide broader configuration capabilities. A compromised sensor or measurement channel may undermine the validity of information upon which controllers or human operators rely. An intrusion affecting an independent safety system may have a different and potentially more consequential impact than one confined to ordinary process supervision.

The essential analytical distinction is therefore between the ability to observe a process, issue authorised operating commands, change control parameters, modify executable logic and interfere with independent protective functions.

Legacy OT Device Classes and Their Security Limitations

Component	Principal operational function	Common legacy security limitation	Consequence of compromise	Constraint on security modification
Programmable logic controller	Executes equipment or process-control logic	Limited authentication, insecure programming interfaces, insufficient audit records	Unauthorised changes to control logic or outputs	Timing requirements, firmware compatibility, production interruption
Remote terminal unit	Supervises remote processes and exchanges field data	Weak communication authentication, limited processing capacity	Manipulated remote commands or telemetry	Geographic dispersion, constrained communications
Distributed control system controller	Coordinates industrial process functions	Proprietary communications and legacy administration mechanisms	Process instability or unavailable control functions	Complex system integration and vendor validation
Human-machine interface	Presents process conditions and operator controls	Older operating systems, shared accounts, insufficient hardening	Misleading information or unauthorised operating commands	Application compatibility and continuous supervision requirements
Engineering workstation	Configures and maintains control equipment	Privileged software, removable-media exposure, unsupported platforms	Logic modification, malicious configuration, impaired restoration	Dependence on specific engineering tools and versions
Industrial historian	Records process information	Enterprise connectivity, service-account dependencies	Loss or manipulation of historical process data	Data continuity and integration requirements
Field sensor	Measures physical conditions	Limited device identity and integrity checking	Unreliable process input	Calibration and physical replacement constraints
Industrial actuator	Performs physical actions	Trust in upstream commands and local communications	Unauthorised or inappropriate physical action	Mechanical safety and response-time requirements
Safety controller	Executes defined protective functions	Legacy access controls, restricted update capability	Impaired or altered protective behaviour	Formal safety lifecycle, independence and validation
Building automation controller	Controls environmental and facility equipment	Shared management interfaces, legacy protocols	Disrupted ventilation, cooling, electrical or environmental functions	Facility continuity and specialist supplier dependence
Industrial gateway	Connects different control networks or protocols	Embedded firmware and inherited trust relationships	Bridging of otherwise separated environments	Availability and protocol-translation dependencies
Backup power controller	Supervises generators, transfer equipment or power-management functions	Weak management access and restricted security updates	Loss of power-system supervisory integrity	Emergency reliability and electrical protection requirements

The entries describe recognised technical risk classes rather than vulnerabilities present in every individual product. The applicable security properties must be verified against the installed device, firmware, configuration and communication architecture.

Source basis: NIST SP 800-82 Revision 3 — September 2023; CISA Interagency OT Zero Trust Guidance — April 2026.

Industrial Communication Protocols: Reliability Was Often Designed Before Adversarial Trust Became a Requirement

The communications architecture of legacy industrial systems represents one of the most persistent obstacles to comprehensive Zero Trust implementation.

Numerous industrial protocols were developed to exchange process values, commands and device information within environments assumed to be operationally controlled. The engineering priorities often centred on predictable communication, interoperability, low processing overhead and dependable operation over specialised industrial networks.

Strong cryptographic authentication, confidentiality, granular access authorisation and detailed security-event reporting were not always intrinsic requirements of these designs.

The result is a class of communications relationships in which a controller may accept messages based largely on protocol correctness and network reachability, rather than independently establishing whether the requesting entity possesses authority to perform the requested operation.

Modbus is a representative example. Traditional Modbus communications provide mechanisms for exchanging data and executing supported operations but do not inherently provide the full set of modern cryptographic identity and authorisation protections. A protected network path can reduce exposure, but the use of a secure communications tunnel does not automatically establish that every command carried inside the tunnel is appropriate.

DNP3 presents another important distinction. Older or insecure deployments may lack the authentication protections available through later secure-authentication mechanisms. The correct assessment is therefore configuration- and implementation-specific rather than a categorical judgment that all DNP3 systems are equally insecure.

Industrial Ethernet and proprietary controller protocols introduce further complexities. Some support modern security capabilities, while others rely upon device-specific trust models, legacy engineering software or protocol extensions whose actual security properties vary by implementation.

Building automation systems exhibit comparable difficulties, particularly where legacy management protocols coexist with internet-connected facility platforms and newer communications gateways. The presence of modern network infrastructure does not ensure that the devices communicating over it have acquired modern security capabilities.

Industrial Protocol Risk and Migration Considerations

Protocol or communication class	Legacy security concern	Available improvement pathway	Engineering concern before deployment
Traditional Modbus/TCP	No inherent modern command authentication or encryption	Restricted conduits, protocol-aware filtering, secure gateways	Legitimate function-code usage and device behaviour
Legacy Modbus serial	Physical or gateway-mediated trust	Controlled gateways and strictly managed serial access	Serial timing, addressing and gateway reliability
DNP3 without secure authentication	Potential acceptance of unauthenticated commands	Supported secure-authentication mechanisms or boundary controls	Interoperability and device support
OPC Classic	Dependence on older Windows and distributed-component security	Application modernisation or carefully managed interoperability gateways	Legacy application dependencies
OPC UA	Security depends on configured modes, credentials and trust stores	Proper certificate validation, secure configuration and access policies	Certificate lifecycle and application compatibility
BACnet legacy deployment	Potentially weak communication trust and management exposure	Network restrictions and supported secure transport options	Building controller compatibility and system integration
Proprietary PLC programming protocol	Potentially privileged configuration access with limited logging	Controlled engineering access and supported vendor protections	Vendor tooling and restoration requirements
Industrial wireless	Exposure depends on authentication, key management and topology	Strong supported wireless security and gateway policies	Connectivity reliability and industrial environment
Legacy serial fieldbus	Limited native cybersecurity functionality	Physical protection and boundary enforcement	Deterministic exchanges and gateway effects

A protocol assessment should differentiate the security functions available in a specification from those actually implemented, enabled and validated within the deployed system. The adoption of a more recent protocol name does not establish trustworthy configuration or access control.

Deterministic Timing, Latency and the Risk of Security-Induced Process Failure

The most important technical distinction between industrial and conventional enterprise environments concerns the relationship between computing behaviour and physical time.

Industrial control systems frequently execute repeated sequences of measurement, computation and output updates. Depending upon the application, the tolerable delays may be tightly constrained. An unexpected pause in communication, a delayed controller response or an overloaded processor may produce consequences that extend beyond temporary inconvenience.

The significance of a delay depends on the process and architecture. Some supervisory monitoring functions tolerate substantial communication latency. Other systems depend upon much faster response times, particularly where electrical protection, motion control or safety-related functions are involved.

It would be analytically incorrect to assign one universal maximum latency to operational technology. The appropriate tolerance must be derived from the engineered function and supported by commissioning data, vendor specifications and safety analysis.

Modern cybersecurity controls may affect these systems through several mechanisms. Inspection gateways can introduce processing delays or become communication bottlenecks. Authentication services can create dependencies on external identity infrastructure. Security agents can consume processor and memory resources on workstations with limited capacity. Active scanning can generate unexpected protocol requests or communication loads. Encryption can change packet characteristics or require processing capabilities unavailable to older devices.

The existence of these potential effects does not mean that modern security controls are inherently incompatible with OT. It means that their suitability depends on where they are installed, what communications they mediate, and whether their failure modes are compatible with the physical process.

For example, an identity-enforcing remote-access gateway may provide valuable protection at the boundary of an engineering network while remaining outside the time-critical communication path between a controller and its field devices. By contrast, inserting an unvalidated intermediary directly into a process-control loop may create a new dependency whose failure could interrupt industrial operations.

The April 2026 interagency guidance specifically warns that ordinary active scanning may cause legacy equipment to go offline and recommends cautious, OT-aware asset-discovery approaches, including passive observation where appropriate.

Adapting Zero Trust Principles to Operational Technology, pp. 7 and 10 — CISA and Partner Agencies — April 2026

Timing and Availability Risk by Operational Function

Industrial function	Typical timing characteristic	Security-change sensitivity	Required validation emphasis
Enterprise-to-OT reporting	Usually less time-critical than direct control	Moderate	Availability and integrity of exchanged information
Industrial historian collection	Periodic or event-driven	Variable	Data continuity, buffering and recovery
Supervisory SCADA communication	Process-dependent polling and event exchange	Moderate to high	Timeouts, operator visibility and control availability
PLC control execution	Repeated controller execution cycles	High where cycle timing is critical	Scan-cycle performance and control stability
Motion-control systems	Potentially tightly time-constrained	Very high	Determinism, jitter and equipment response
Electrical protection	Protection-specific rapid response requirements	Very high	Independent protection performance
Safety instrumented functions	Defined safety response times	Very high	Safety integrity and protective action
Building environmental control	Generally process-dependent and often slower	Variable	Environmental stability and fallback behaviour
Backup power transfer and supervision	Defined electrical and operational sequences	High	Transfer reliability and emergency-state behaviour

The table provides qualitative engineering distinctions. Actual timing limits must be derived from the installation’s approved design and testing records.

Engineering Workstations: A Concentration of Authority Often Overlooked in Asset Prioritisation

Engineering workstations warrant particular scrutiny because they may possess capabilities unavailable to ordinary operator interfaces. Their authorised functions can include programming controllers, downloading logic, modifying device parameters, changing communications configurations and performing diagnostic or maintenance operations.

This creates a concentration of operational authority that may be disproportionate to the apparent importance of the workstation as a conventional computing asset.

A workstation may be a commercially ordinary computer while holding software, credentials, project files and communications permissions that enable changes to critical industrial processes. Its compromise can consequently affect both the operational state of equipment and the integrity of the configuration records used to restore that equipment.

Legacy engineering applications introduce further difficulties. Some require particular versions of operating systems, libraries, drivers or vendor tools. Installing modern endpoint security software may be unsupported, while operating-system upgrades can invalidate compatibility with controllers or existing project files.

The situation becomes particularly concerning where a workstation is shared among technicians, uses broad privileges, relies on permanently connected maintenance interfaces or is permitted to communicate with numerous controllers across otherwise separated production areas.

From a risk perspective, the relevant question is not simply whether the workstation possesses antivirus software or current patches. It is whether compromise of that workstation would permit an adversary to make unauthorised changes to industrial equipment, whether those changes could be independently detected, and whether trusted configuration information would remain available for recovery.

A robust engineering assessment should examine the separation of routine observation from programming authority, the integrity of controller project files, the handling of removable media, the validation of software dependencies and the availability of trusted restoration mechanisms.

These concerns are consistent with the NIST OT security framework, which places technical security controls within a broader consideration of system architecture, operational function and risk consequences.

Guide to Operational Technology Security, NIST SP 800-82 Revision 3 — NIST — September 2023

The Problem of Limited Logging: When a Compromise Cannot Be Reliably Reconstructed

A further structural weakness of ageing operational technology concerns its limited ability to produce security-relevant records.

Modern enterprise systems may record successful and unsuccessful authentication, account changes, process execution, privileged activity, software installation and network connections. Older industrial controllers, by contrast, may expose only limited diagnostic information, operational alarms or records associated with normal control functions.

A controller may report a communication failure without identifying the requesting user, or permit a configuration change without recording a sufficiently detailed audit trail to establish who performed it, from which workstation, under which authority and with what effect on the industrial process.

This distinction affects both prevention and incident investigation.

Where device-level evidence is absent, security teams may be unable to distinguish legitimate maintenance from unauthorised activity by examining the controller alone. They may need to reconstruct the sequence from engineering workstation records, remote-access logs, network observations, configuration archives and physical-process measurements.

Even these sources may provide incomplete evidence. Encrypted connections can conceal application-level details from passive sensors, proprietary protocols may not be adequately decoded, and process measurements may demonstrate an abnormal state without establishing whether its cause was malicious, accidental or mechanical.

The April 2026 CISA guidance explicitly identifies the limited logging capabilities of older OT and recommends combining multiple data sources, including engineering files, network information, discrete events and physical-process data.

Adapting Zero Trust Principles to Operational Technology, pp. 7 and 18–20 — CISA and Partner Agencies — April 2026

The resulting operational requirement is to establish evidence that can answer three different questions: what digital activity occurred, whether it was authorised, and whether it changed the physical process.

A network connection record may establish that an engineering workstation communicated with a controller. A configuration archive may establish that a controller’s programmed logic changed. Process measurements may show how the installation behaved before and after the change. Only a properly correlated investigation can determine whether those observations support a conclusion of unauthorised interference.

Evidence Requirements for Industrial Incident Investigation

Evidence source	Principal evidentiary value	Important limitation	Assurance question
Remote-access logs	Identity, session timing and connection origin	May not reveal individual controller commands	Who entered the environment, and when?
Privileged-access records	Authorisation and use of elevated privileges	May not capture actions outside managed channels	Was the activity permitted for that user and task?
Engineering workstation logs	Software execution, project access and configuration activity	May be incomplete on legacy platforms	Which engineering tools were used?
Controller configuration archives	Evidence of logic or parameter changes	May lack reliable actor attribution	Did the installed configuration change?
Passive OT network monitoring	Communication relationships and protocol activity	Visibility may be limited by encryption or proprietary formats	Which devices exchanged relevant commands or data?
Industrial historian	Physical-process trends and recorded measurements	Data integrity depends on collection and storage paths	What happened to the process?
Operator records	Human observations and approved interventions	Documentation may be incomplete or retrospective	What actions were authorised or observed?
Maintenance records	Planned configuration changes and supplier activity	Informal work may not be documented	Was the intervention part of an approved activity?
Safety system event records	Protective-system activation and abnormal conditions	Some systems provide limited historical detail	Were safety functions demanded or impaired?
Trusted backups	Historical configuration comparison and restoration reference	Backup integrity may not be independently established	Can a known-good state be reconstructed?

The strategic importance of this evidence architecture lies in reducing uncertainty during an actual incident. If an operator cannot determine whether a controller has been altered, it may be forced to choose between continuing production under uncertain conditions and initiating a potentially costly shutdown.

Neither decision can be made responsibly without understanding the physical consequences of remaining in operation.

Cybersecurity Changes Can Themselves Become Industrial Hazards

The introduction of cybersecurity controls into ageing operational environments creates a dual-risk problem. Failure to implement adequate protection leaves the facility exposed to compromise, while poorly planned changes may introduce new failure modes.

This distinction becomes particularly important when cybersecurity modifications affect systems already subject to engineering certification, regulated operating procedures, contractual reliability requirements or formal safety assessments.

An industrial installation may have been commissioned on the basis of a specific combination of controller firmware, application software, network architecture and physical instrumentation. Even when individual components are technologically obsolete, the combined system may possess a well-understood operational history.

A new security component changes that history. The introduction of a firewall, inspection gateway, access proxy, authentication dependency or network segmentation policy may alter communication pathways. If a required flow is blocked, delayed or incorrectly classified, the resulting behaviour may affect operator visibility or process control.

Similarly, a security update may resolve a software vulnerability while creating incompatibility with a vendor application. A controller firmware change may improve security but require renewed testing of industrial functions. An endpoint security agent may interfere with older engineering software or introduce unpredictable performance effects.

The appropriate response is neither indiscriminate avoidance of cybersecurity upgrades nor unconditional deployment of the latest controls. It is the adoption of a rigorous management-of-change process that subjects security interventions to the same operational scrutiny as other consequential engineering modifications.

The CISA interagency guidance specifically recommends formal management-of-change procedures, multidisciplinary reviews and consideration of engineering, safety and physical constraints before modifying OT environments.

Adapting Zero Trust Principles to Operational Technology, pp. 10–11 — CISA and Partner Agencies — April 2026

Security Intervention Risk Assessment

Proposed intervention	Expected security improvement	Possible operational failure mode	Required engineering evidence
Firewall policy revision	Restricts unnecessary communications	Blocks legitimate control or diagnostic traffic	Validated communications matrix and rollback procedure
Network segmentation	Limits unauthorised reachability	Breaks undocumented dependencies	Verified topology and process-flow assessment
Identity-system integration	Improves user accountability	Denies access during identity infrastructure failure	Emergency-access and dependency testing
Endpoint protection deployment	Reduces workstation compromise exposure	Conflicts with engineering software or consumes resources	Vendor compatibility and performance testing
PLC firmware update	Corrects supported security weaknesses	Changes controller behaviour or invalidates compatibility	Approved firmware qualification and functional testing
Remote-access gateway deployment	Restricts external maintenance entry	Interrupts urgent supplier intervention	Emergency maintenance procedure and resilience testing
Passive monitoring deployment	Improves network visibility	Incorrect installation affects network equipment	Validated monitoring connection and load assessment
Protocol gateway introduction	Provides boundary protection or translation	Alters timing or message interpretation	Protocol compatibility and timing verification
Backup system redesign	Improves recoverability	Restored files may be incomplete or incompatible	Representative restoration exercise
Controller replacement	Removes selected legacy limitations	Commissioning errors or unintended process changes	Factory and site acceptance testing, safety review

This assessment must be performed against actual installation characteristics. The existence of a theoretical failure mode is not proof that a proposed control is unsafe, but neither is successful testing in a laboratory sufficient to establish compatibility with every industrial deployment.

Safety Instrumented Systems: A Boundary That Cybersecurity Must Not Undermine

Safety instrumented systems and other independently engineered protective functions require particular treatment because their purpose is not simply to maintain normal production. They are intended to reduce the consequences of hazardous process conditions by detecting defined states and performing protective actions.

In industrial installations where formal functional-safety standards apply, the protective system may be designed with specific requirements concerning independence, reliability, response time, diagnostic coverage and safety integrity. These properties cannot automatically be preserved when additional cybersecurity infrastructure is introduced into relevant communications or control paths.

The relationship between cybersecurity and functional safety is therefore complementary but not interchangeable.

Cybersecurity controls seek to reduce unauthorised access, manipulation and compromise. Functional-safety measures seek to reduce unacceptable physical hazards arising from defined equipment or process failures. A facility may possess strong network protection while relying upon inadequate physical safeguards, or maintain effective independent safety protection while exposing its ordinary control systems to unauthorised access.

Neither condition should be treated as sufficient assurance of overall cyber-physical resilience.

For example, restricting access to a controller can reduce opportunities for malicious configuration changes, but that restriction must not prevent a protective function from responding when required. Similarly, authentication or network enforcement should not create an external dependency whose failure prevents an appropriately designed safety system from performing its intended role.

The principal engineering objective is to ensure that cybersecurity measures preserve the independence, availability and validated behaviour of protective functions while reducing the likelihood that an attacker could compromise their configuration or supporting infrastructure.

The applicable technical requirements depend upon the installation’s safety lifecycle and adopted standards. The ISA/IEC 62443 family addresses industrial automation and control-system cybersecurity, while functional-safety assessments may additionally involve sector-specific instruments and standards, including IEC 61508 and IEC 61511 where applicable.

Guide to Operational Technology Security, NIST SP 800-82 Revision 3 — NIST — September 2023

Patching, Manufacturer Support and the Accumulation of Technical Debt

The inability to apply conventional patch-management practices is among the most persistent sources of residual risk in ageing OT.

Industrial devices may remain in service after manufacturers discontinue firmware updates or security support. Engineering workstations may require operating systems that no longer receive routine security maintenance. Replacement components may become difficult to obtain, and compatible engineering applications may depend upon versions that cannot readily be migrated.

These problems should be distinguished from situations in which an update exists but cannot safely be installed immediately. An unsupported device presents a structural limitation: the operator may be unable to obtain a corrective update even when a vulnerability is well understood. A supported device with restricted maintenance windows presents an implementation problem: remediation may be possible but requires engineering scheduling, testing and operational approval.

The distinction has consequences for capital planning.

Where a supported correction can be tested and safely deployed, a planned maintenance intervention may provide a reasonable risk-reduction pathway. Where no correction exists, the operator must evaluate the effectiveness and sustainability of external protections, restrictions on connectivity and eventual replacement.

The difficulty increases when industrial equipment forms part of a tightly integrated supplier ecosystem. A controller may require a particular workstation application, communications gateway or interface module. Replacing one element can produce a chain of compatibility changes, expanding the project from a cybersecurity upgrade into an industrial systems-integration exercise.

The true cost of modernisation may therefore include engineering design, software redevelopment, safety assessment, equipment testing, technician training, commissioning, production interruption and long-term support obligations.

An equipment replacement decision that considers only the purchase price of the new controller would consequently understate its actual financial and operational implications.

Legacy OT Technical Debt Classification

Technical debt category	Observable condition	Security consequence	Decision implication
Unsupported firmware	Manufacturer no longer supplies corrections	Known weaknesses may remain unresolved	Evaluate isolation, compensation and replacement
Unsupported operating system	Required workstation platform is no longer maintained	Increasing exposure through conventional computing vulnerabilities	Restrict use and plan software migration
Obsolete engineering application	Current versions cannot interact with existing controllers	Dependence on vulnerable maintenance environments	Preserve verified recovery capability while planning transition
Insecure protocol	Communications lack sufficient authentication or integrity protection	Command or data manipulation may be possible after network access	Introduce compatible boundary protection
Missing device audit functions	Configuration actions cannot be fully attributed	Reduced detection and investigation capability	Improve evidence collection around the device
Proprietary supplier dependence	Recovery requires vendor-controlled tools or infrastructure	Restoration and independence risks	Address contractual access and replacement requirements
Incomplete configuration records	Installed software or logic state is uncertain	Difficult incident assessment and restoration	Reconstruct trusted configuration baseline
Undocumented interfaces	Operators cannot fully identify required communications	Segmentation and maintenance risks	Validate dependencies before changes
Hardware obsolescence	Components and spares are difficult to obtain	Extended recovery from physical or cyber incidents	Develop replacement and spare-parts strategy
Unverified backup integrity	Files exist but cannot be demonstrated to restore operations	False confidence in recoverability	Conduct controlled restoration exercises

The accumulation of these weaknesses creates a form of industrial cybersecurity debt in which successive short-term decisions preserve operational continuity while making future intervention increasingly complex.

Recovery Is an Engineering Capability, Not Merely the Existence of Backup Files

A further difficulty concerns the assumption that the existence of digital backups guarantees recovery from compromise.

Industrial recovery can require substantially more than restoring an operating-system image or copying archived configuration files. Depending upon the installation, recovery may involve controller programming, restoration of safety-related parameters, communications settings, device calibration, application compatibility and validation of the process’s physical state.

A backed-up controller project is not necessarily a trusted or complete recovery package. It may lack the firmware version, dependencies, licensing information, specialist tools or configuration data needed to restore an equivalent operational state. In addition, backups created after an undetected compromise may preserve malicious or unauthorised changes.

NIST addressed this problem directly in June 2026 through SP 1339, OT Backup Quick Start Guide, which emphasises integrating backups with change management, maintaining them regularly, testing their usability and reviewing backup arrangements during recovery exercises.

OT Backup Quick Start Guide, NIST SP 1339 — National Institute of Standards and Technology — June 2026

The critical issue is therefore the integrity of the entire recovery chain.

A facility must be capable of establishing which configuration is trusted, determining whether relevant equipment remains physically safe, restoring necessary digital components and validating that normal operating conditions can be resumed.

This requirement becomes especially demanding where legacy industrial equipment depends on a small number of experienced technicians, discontinued applications or supplier-specific recovery procedures.

The absence of tested restoration capability should be treated as a material risk even if conventional cybersecurity controls appear mature.

Remote Maintenance and the Separation of Technical Access from Operational Authority

Remote maintenance is indispensable for many modern industrial operators, particularly where facilities are geographically dispersed, specialist technicians are scarce or vendor support must be obtained rapidly.

However, legacy remote-access arrangements may predate modern identity governance and may have been designed primarily to make equipment support convenient. Permanent VPN access, broad network permissions, shared accounts and supplier-controlled connections can therefore create an enduring exposure that is poorly aligned with the actual maintenance task.

The security problem is not resolved simply by replacing an unencrypted connection with an encrypted one.

A remote connection can be technically protected while still granting excessive access to equipment. A contractor authorised to inspect a particular device should not necessarily possess the ability to alter controller logic, change safety parameters or communicate with unrelated systems.

The distinction is between authentication, which establishes an identity or credential relationship, and operational authorisation, which determines what that identity is permitted to do in a particular industrial context.

In June 2026, NIST published SP 1800-45, Cybersecurity for the Water and Wastewater Sector: Build Architecture (Operational Technology Remote Access). The project developed and demonstrated three representative secure remote-access architectures for water utilities of different capacities using commercially available technologies.

This is especially significant because it provides documented implementation examples rather than relying exclusively upon abstract architectural principles. Nevertheless, a demonstrated reference architecture should not be interpreted as proof that the same configuration is immediately safe for every industrial process or legacy device.

Cybersecurity for the Water and Wastewater Sector: Build Architecture (Operational Technology Remote Access), NIST SP 1800-45 — NIST — June 2026

For ageing installations, a defensible remote-maintenance arrangement must account for the identity of the technician, the supplier’s contractual responsibility, the permitted destination, the specific maintenance function, the duration of access, the operational state of the equipment and the consequences of an error.

These questions introduce an essential governance boundary: a cybersecurity administrator should not independently authorise a physical-process change merely because the requesting user has passed technical authentication. Operational changes require authority derived from the facility’s engineering and management processes.

Evaluating the Consequences of Inaction and Poorly Planned Intervention

The essential decision facing operators is not a choice between a secure system and an insecure system. It is a comparison among imperfect operating conditions, each carrying a different combination of cyber exposure, physical hazard, financial cost and implementation uncertainty.

Maintaining the existing configuration avoids immediate engineering disruption but may preserve known vulnerabilities, excessive privileges and weak recovery capabilities. Introducing compensating controls may reduce reachable attack paths while creating additional devices, dependencies and maintenance requirements. Replacing equipment may remove fundamental security limitations but impose commissioning risk, capital expenditure and potential production interruption.

These options must be evaluated against the consequences of compromise rather than through the assumption that newer technology is automatically safer.

A long-established industrial controller may be mechanically reliable while presenting significant digital exposure. A newly installed controller may offer modern authentication and logging but remain operationally unsafe if incorrectly configured or integrated. A segmented network may reduce intrusion pathways while creating a new availability risk if its communication rules are incomplete.

The objective is to identify the combination of controls and operating arrangements that reduces the total risk to essential physical functions.

Operational Decision Matrix: Cyber Risk Versus Process Risk

Operating condition	Cybersecurity exposure	Physical-process concern	Appropriate decision basis
Legacy device is isolated and independently protected	Potentially limited external exposure	Device failure and local compromise remain possible	Verify isolation and recovery
Legacy device has controlled remote access	Residual credential and gateway exposure	Maintenance activity may affect production	Validate task-level permissions
Legacy device is directly internet-accessible	Unnecessary external attack exposure	Potential unauthorised process interaction	Treat exposure reduction as urgent
Patch is available but operationally untested	Known weakness persists until correction	Update may disrupt control functions	Controlled engineering qualification
Device is unsupported but operationally stable	Structural vulnerabilities may persist	Replacement may create commissioning risk	Compare compensating controls and replacement
Segmentation is proposed with incomplete topology information	Existing lateral-movement opportunities remain	Required communications could be blocked	Complete dependency validation first
Safety function depends on shared digital infrastructure	Compromise may affect multiple functions	Loss of independence may undermine safety	Reassess architecture and protective independence
Backup exists without restoration testing	Unknown recovery effectiveness	Extended outage or unsafe restoration	Conduct representative recovery validation
Supplier access cannot be independently controlled	Persistent third-party exposure	Unauthorised or poorly coordinated changes	Establish enforceable access ownership
Critical process cannot be protected or safely recovered	Potentially unacceptable residual exposure	Severe operational or safety consequences	Escalate modernisation priority

This decision matrix is intended to structure engineering judgment. It is not a substitute for quantitative risk analysis where reliable failure, consequence and operating data are available.

Governance Conflict Between IT Security, OT Engineering and Physical Safety

A recurring cause of ineffective industrial cybersecurity programmes is the separation of technical responsibilities across organisational boundaries.

Information technology teams may prioritise uniform security architecture, standardised software maintenance, centralised identity management and rapid vulnerability remediation. Operational engineers may prioritise process stability, deterministic performance, equipment reliability and preservation of validated configurations. Safety specialists may focus upon hazard reduction, protective-system independence and evidence that modifications do not compromise established safety requirements.

These perspectives are not inherently contradictory. The problem arises when decisions are made without integrating them.

A centrally imposed authentication requirement may strengthen access accountability while creating unacceptable dependence upon a remote identity service. An engineering decision to retain obsolete software may preserve equipment compatibility while introducing avoidable exposure through unnecessary network connectivity. A safety-driven requirement for independent protective functions may create additional architecture and monitoring obligations that ordinary cybersecurity programmes have not incorporated.

Effective governance requires the different technical communities to evaluate the same physical-process consequences and agree upon the authority governing changes.

The April 2026 interagency guidance emphasises this organisational requirement, recommending clear responsibilities, multidisciplinary participation and formal escalation procedures where Zero Trust controls might affect availability or safety.

Adapting Zero Trust Principles to Operational Technology, pp. 8–11 — CISA and Partner Agencies — April 2026

The practical implication is that the cybersecurity risk owner and the physical-process owner cannot operate as independent decision-makers when a proposed security change may affect essential operations.

The ultimate authorisation process should establish both whether a measure adequately reduces cybersecurity exposure and whether its implementation preserves the engineering conditions necessary for safe service delivery.

The Economic Consequence of Deferred Modernisation

Industrial cybersecurity modernisation also presents a capital-allocation problem that differs substantially from conventional information technology renewal.

The equipment most difficult to secure may not be the equipment most economically attractive to replace. A controller can remain reliable, perform its assigned function accurately and require little routine mechanical intervention while relying on obsolete digital interfaces.

Replacement may consequently offer limited immediate production benefits relative to its financial cost, even where the cybersecurity case for intervention is substantial.

Moreover, the capital cost of the replacement device may represent only part of the total expenditure. Engineering redesign, system integration, software migration, testing, training, commissioning and downtime can materially increase the investment required.

Deferring intervention may nevertheless accumulate costs through continued dependence on unsupported applications, specialist maintenance arrangements, additional monitoring infrastructure and increasingly complex recovery procedures.

This creates a potential mismatch between commercial investment incentives and the broader societal consequences of infrastructure disruption. A privately operated facility may rationally defer replacement where its expected direct losses are limited, while the consequences of failure could extend to communities, public services or interconnected infrastructure operators.

Government intervention may be justified where these external consequences are material and cannot be adequately addressed through ordinary operator incentives. Such intervention should nevertheless be based on demonstrated risk and operational feasibility rather than generalised assumptions about equipment age.

The GAO’s findings regarding critical federal legacy systems illustrate the persistence of costly maintenance burdens and incomplete modernisation planning, although those findings do not provide a direct cost model for replacing industrial control equipment.

Information Technology: Agencies Need to Plan for Modernizing Critical Decades-Old Legacy Systems — GAO — July 2025

The relevant economic assessment should compare the lifecycle cost and effectiveness of continued compensating protection with the full engineering and operational cost of modernisation.

Where external protections provide credible containment, recovery remains reliable and the remaining physical consequences are tolerable, replacement may reasonably be phased. Where the operator cannot limit unauthorised control, validate system integrity or restore essential services within an acceptable period, the economic case for continued deferral becomes increasingly difficult to sustain.

Chapter 2 — Key Judgments

The most serious technical limitations of ageing operational technology are not independent weaknesses that can be resolved through a uniform cybersecurity upgrade. Authentication, communications integrity, software support, logging, engineering access and recovery capability form part of an interconnected industrial architecture whose security properties must be assessed against actual physical operations.

Industrial protocols and controllers may lack the ability to enforce modern Zero Trust principles directly, while engineering workstations and maintenance connections may concentrate authority sufficient to alter consequential physical processes. At the same time, poorly planned cybersecurity interventions can affect communications timing, software compatibility, safety independence and service availability.

The central implementation challenge is therefore to protect vulnerable equipment without introducing new operational failure modes. This requires accurate knowledge of equipment functions, communications dependencies, maintenance arrangements and the consequences of both unauthorised access and protective intervention.

The evidence supports a high-confidence judgment that conventional enterprise patching, scanning, endpoint management and identity practices require substantial adaptation before application to many OT environments. It also supports the importance of independent engineering validation, formal change management and tested recovery.

There is lower confidence in the effectiveness of any particular compensating-control arrangement until its behaviour has been demonstrated under the relevant operating conditions, including component failure, loss of connectivity, emergency maintenance and restoration after compromise.

What Would Change the Chapter 2 Assessment

The assessment would change materially if technical testing demonstrated that particular security controls could be introduced into specified industrial environments without affecting timing, reliability, safety or recovery under credible failure conditions. Such evidence would support more ambitious and potentially faster modernisation.

Conversely, discovery of undocumented process dependencies, common-mode failures between security infrastructure and safety functions, or systematic inability to restore trusted controller configurations would increase the urgency of architectural redesign and replacement.

The decisive evidence required from operators consists of verified engineering configurations, actual communication dependencies, approved safety requirements, vendor support records, tested maintenance procedures and demonstrated restoration outcomes.

Open Official Record

The development of a national or sectoral legacy OT protection programme requires records that are rarely available in a comparable form across operators: asset-level support status, firmware and engineering-software dependencies, installed communications capabilities, actual remote-access permissions, documented industrial change windows, validated process-safety constraints and the time required to restore critical functions.

The public documentation establishes that these characteristics are necessary to evaluate the applicability and effectiveness of Zero Trust controls, but it does not provide a universal numerical threshold capable of determining when compensation is sufficient or replacement becomes mandatory.

The next analytical stage must therefore examine Zero Trust not as a generic network security doctrine, but as a resource- and operation-specific architecture whose enforcement mechanisms are selected according to what each industrial asset can support, what physical function it governs and which actions must remain possible under both normal and compromised conditions.

---

PILLAR II — ZERO TRUST ARCHITECTURE, COMPENSATING CONTROLS AND INDUSTRIAL MODERNISATION

Chapter 3. Zero Trust Architecture Applied to Operational Technology

Principal Strategic Judgment: Zero Trust Must Govern the Authority to Influence Physical Processes, Not Merely the Right to Enter Industrial Networks

The decisive architectural transformation introduced by Zero Trust in operational technology is the replacement of broad, location-based assumptions of legitimacy with explicitly governed relationships between identities, operational resources, permitted activities and physical-process conditions. In industrial systems, this transformation has greater significance than the adoption of multifactor authentication, additional firewalls or new network security equipment because it changes the definition of what constitutes an authorised action. A user who has legitimately entered an industrial environment does not automatically possess authority to modify every controller within that environment; a connected engineering workstation does not acquire unrestricted trust simply because it belongs to an approved network; and a supplier whose credentials have been authenticated does not thereby obtain permission to change the operating state of equipment without an associated engineering authorisation.

The National Institute of Standards and Technology established the conceptual foundations of this approach in Special Publication 800-207, Zero Trust Architecture, published in August 2020. Its model treats access as a relationship between a requesting subject and a protected resource, with decisions based on policy, identity, contextual information and the conditions under which access is requested. The resulting architecture includes a policy decision function and enforcement mechanisms capable of permitting, restricting or terminating access according to the applicable rules.

For industrial systems, however, the notion of a protected resource cannot be limited to an application, server or network endpoint. The resource may represent an industrial capability: the ability to observe reservoir levels, retrieve electrical protection settings, download a programmable controller’s configuration, modify a production recipe, alter a switching schedule or execute a maintenance operation. The corresponding access policy must account for the consequences of exercising that capability, not merely whether the user possesses valid credentials.

NIST SP 800-207, Zero Trust Architecture — National Institute of Standards and Technology — August 2020

This distinction explains why the implementation of Zero Trust in operational technology cannot be assessed through a simple count of authenticated devices or segmented networks. A facility may achieve excellent user authentication while continuing to grant broad programming rights to technicians who require only diagnostic access. It may introduce sophisticated network segmentation while leaving shared administrative credentials active across multiple production areas. It may protect its remote connections with modern encryption while allowing a supplier to communicate with controllers beyond the scope of an approved maintenance intervention.

Such arrangements improve selected technical properties without necessarily delivering the central Zero Trust outcome: the restriction of an authenticated or compromised identity to the minimum operational authority justified by its current task.

The October 2026 NSA cybersecurity information sheet, Hardening Department of War Critical Operational Technology Environments with Zero Trust Principles, positions this requirement within the security of Department of War systems, National Security Systems and Defence Industrial Base operations. The agency identifies continuous verification of users, devices, workflows and communications as a means of limiting unauthorised access, adversarial persistence and movement within critical infrastructure environments. Its institutional emphasis is consistent with NIST’s architecture, while its operational audience introduces additional requirements arising from mission assurance, national security and the potentially consequential physical effects of compromise.

NSA Releases Zero Trust Guidance for Protecting Operational Technology Systems — National Security Agency — October 2026

The April 2026 CISA-led interagency guidance supplies a further layer of operational interpretation. It recognises that older controllers, field devices and industrial applications may not support modern identity infrastructure or fine-grained access enforcement, and therefore proposes adapting Zero Trust to existing OT architecture rather than requiring a wholesale transformation of every component before useful security improvements become possible.

Adapting Zero Trust Principles to Operational Technology — CISA, Department of War, Department of Energy, FBI and Department of State — April 2026

Taken together, these instruments establish an important division between architectural doctrine and implementation engineering. NIST defines the principles and essential decision functions; the CISA interagency paper explains how these principles must be adapted to industrial constraints; and the NSA’s October intervention identifies their strategic importance for defence and other high-consequence operational environments. The additional priorities developed in this chapter constitute an analytical interpretation of that documented guidance and should not be mistaken for a verbatim NSA implementation programme.

The NIST Policy Model and Its Translation into Industrial Control Authority

NIST SP 800-207 describes a logical architecture in which access to resources is mediated through components performing policy decision, administration and enforcement functions. The Policy Engine evaluates relevant information and determines whether access should be granted; the Policy Administrator establishes or terminates the approved communication relationship; and the Policy Enforcement Point implements the resulting decision at the boundary between the requesting entity and the resource.

These functions may be implemented using different technologies and may be distributed across multiple systems. The logical architecture should not be confused with a requirement to deploy one particular product or create a single centralised component through which every industrial communication must pass.

In operational environments, such centralisation may itself be undesirable where failure of an enforcement system could interrupt normal control. The preferred implementation therefore depends on the location of the trust boundary and the criticality of the communications it governs.

For a remotely maintained water-pumping facility, an externally located access gateway may enforce supplier identity, approved destination, authorised session duration and permitted diagnostic functions. The underlying controller need not necessarily perform these checks itself, provided that the external mechanism can reliably enforce the intended restrictions without compromising necessary local control. In contrast, placing an authentication proxy into a time-critical protective communication path may create unacceptable operational dependency, particularly if the proxy requires connectivity to an external policy service before permitting an essential action.

The architectural principle remains constant, but the point at which it is implemented changes according to engineering requirements.

NIST Zero Trust Components and OT-Specific Implementation Responsibilities

NIST architectural element	Core function	OT-specific implementation	Critical implementation condition	Evidence of effective operation
Policy Engine	Determines whether access is authorised	Evaluates identity, resource, task, device condition, process authorisation and applicable restrictions	Decision rules must reflect operational authority and safety constraints	Recorded decisions correspond to approved maintenance or operational tasks
Policy Administrator	Establishes or terminates permitted access	Activates bounded maintenance sessions, credentials or gateway rules	Session establishment must not interfere with autonomous local control	Sessions open and close according to approved authorisations
Policy Enforcement Point	Applies access decisions	Industrial gateway, bastion, application proxy, firewall or capable endpoint	Enforcement must occur at a point that cannot be bypassed by the governed access path	Unauthorised access attempts are denied at the intended boundary
Identity infrastructure	Establishes accountable subjects	Individual technician, operator and service identities	Shared accounts and emergency procedures require explicit treatment	Actions can be attributed to approved identities where technically feasible
Device security information	Supplies relevant condition data	Managed workstation status, configuration integrity and approved device registration	Unsupported equipment may provide incomplete or unreliable attributes	Decisions are based on validated information rather than assumed compliance
Resource inventory	Identifies what is being protected	Named controllers, engineering services, historian interfaces and process functions	Resource identifiers must correspond to actual operating equipment	Policies refer to verified assets and operational functions
Activity and event records	Support monitoring and policy improvement	Gateway logs, engineering records, controller changes and process observations	Monitoring must not disrupt essential operations	Investigators can reconstruct the permitted and attempted actions
Trust algorithm or policy logic	Combines applicable conditions	Role, task, maintenance window, location, approval and resource sensitivity	Policy complexity must remain understandable and testable	Approval, denial and exception behaviour match documented requirements

Source-derived architecture: NIST SP 800-207. Industrial implementation examples and assurance conditions are analytical applications of the NIST model and the April 2026 CISA guidance.

The most important design consideration is the relationship between the Policy Enforcement Point and the resource being protected. An enforcement system can only constrain actions that pass through it or are otherwise subject to its authority. A firewall that restricts access to a controller may prevent certain network connections but cannot necessarily distinguish between a legitimate read operation and a dangerous configuration change if both are carried over the same permitted connection and the firewall lacks suitable protocol visibility.

Similarly, an identity-aware remote-access solution may prevent unauthorised users from opening a session while failing to distinguish between authorised observation and unauthorised programming once the session reaches the engineering application.

Accordingly, the scope of enforcement must be described at the level actually achieved. Network-level access restriction, authenticated session control, application-level command authorisation and controller-native permission enforcement are different security properties. They should not be represented as equivalent simply because each is associated with a Zero Trust programme.

Five Dimensions of Industrial Access Authority

An industrial access decision should combine at least five distinct dimensions: the identity of the requesting party, the identity and condition of the originating system, the resource or function being accessed, the precise operation requested and the operational context in which the activity is to occur.

A sixth dimension becomes necessary where an action can affect physical safety or production: the approval of the person or organisational function authorised to permit that intervention.

A maintenance contractor may have a valid corporate identity, use a compliant workstation and connect through an authenticated gateway, but none of these conditions independently establishes permission to change a pump controller’s programmed logic. The organisation must determine whether the maintenance task requires observation, diagnostic interrogation, parameter modification or full programming access, and whether the relevant operating conditions permit the activity.

These distinctions support an important refinement of conventional role-based access control. Roles remain useful, but the role alone may be insufficient. A person classified as an approved industrial maintenance technician might legitimately perform different operations at different facilities, on different days and under different engineering authorisations.

The relevant decision is therefore not simply whether the user belongs to the maintenance group. It is whether the user has authority to perform the particular operation on the particular resource during the particular approved task.

Example of Task-Bound Industrial Access Control

Consider an external contractor assigned to investigate anomalous telemetry from a named pumping controller at a water-treatment facility. The work order authorises inspection of measurement values and retrieval of selected diagnostic information during an approved two-hour maintenance window. It does not authorise modification of control logic, firmware, safety parameters or communications settings.

Under a conventional network-based access arrangement, the contractor might receive temporary VPN connectivity to the site’s engineering subnet. The contractor could then potentially reach multiple devices, depending on routing and firewall configurations. Even when the contractor’s identity is verified, the scope of technical access may exceed the operational requirement.

Under an appropriately implemented Zero Trust arrangement, the contractor’s authenticated session would terminate at a controlled intermediary. The intermediary would expose only the required diagnostic function associated with the designated controller. The session would expire automatically, and the approved actions would be recorded. Attempts to reach other controllers, alter programming or use unapproved protocols would be denied wherever the enforcement technology could reliably distinguish those actions.

This model establishes a separation between authorisation to connect and authorisation to affect industrial behaviour.

Policy attribute	Authorised condition	Rejected condition
User identity	Named contractor associated with an approved supplier	Unidentified or shared supplier account
Device identity	Registered maintenance workstation meeting defined access conditions	Unknown or non-approved endpoint
Maintenance authority	Approved work order linked to the requesting individual	No valid work order or expired approval
Destination	Designated pumping controller diagnostic interface	Adjacent controllers, safety systems or unrelated process devices
Permitted function	Read-only telemetry and approved diagnostics	Logic upload, configuration alteration or firmware replacement
Time restriction	Approved two-hour session	Persistent or indefinitely reusable access
Network route	Controlled gateway exposing the approved service	Direct routing to the wider OT subnet
Operational approval	Authorisation by the responsible facility engineer	Technical access granted without process-owner approval
Evidence	Session and relevant activity records retained	Unattributable or unmanaged maintenance activity
Session termination	Automatic expiry and operator-initiated revocation	Continued access after maintenance completion

The example is an analytical reference model, not a description of one deployed installation. Its feasibility depends on the engineering software, protocol, gateway capabilities and available application-level enforcement. Where the equipment cannot distinguish read operations from write operations, a read-only policy cannot be claimed merely because it appears in an access-management console.

In such circumstances, practical choices include a dedicated telemetry replication service, a diagnostic gateway capable of enforcing permitted operations, a monitored operator-mediated session or physical restrictions on programming capability. The chosen control must be tested against the actual equipment rather than assumed to operate as described by its configuration interface.

Continuous Verification in OT Cannot Mean Continuous Interference

Continuous verification is frequently misunderstood as requiring uninterrupted active interrogation of every user, device and process component. Such an interpretation would be inappropriate for many ageing industrial systems and would risk creating the very operational interference that Zero Trust is intended to prevent.

The more defensible interpretation is that access remains conditional upon the continuing validity of relevant policy information, with verification mechanisms selected according to the system’s technical capacity and operational sensitivity.

For an externally connected engineering workstation, access-control systems may reassess authentication validity, session duration, endpoint status and approved work orders. For a legacy controller that cannot support these functions, verification may occur at a controlled gateway, through network behaviour monitoring and by comparing observed activity with authorised operating patterns.

The frequency and intrusiveness of verification must reflect the protected operation. A remote maintenance session lasting several hours may require session monitoring and the ability to revoke access promptly, while a deterministic controller-to-controller exchange should not necessarily be interrupted by repeated identity challenges.

This approach aligns with the fundamental NIST principle that access is dynamically governed without requiring all components to execute the same security functions.

NIST SP 800-207, Zero Trust Architecture — NIST — August 2020

It also accords with the CISA interagency paper’s emphasis on adapting security mechanisms to the constraints of operational equipment and on avoiding security measures that jeopardise availability, reliability or safety.

Adapting Zero Trust Principles to Operational Technology, Sections Protect and Detect — CISA and Partner Agencies — April 2026

Identity Assurance for Users, Devices and Industrial Services

Industrial identity governance must address three different identity populations that are often conflated: human users, computing devices and non-human services.

Human identities include facility operators, maintenance engineers, safety personnel, system administrators, suppliers and emergency responders. Their permissions should be associated with accountable individuals wherever technically feasible, rather than permanent shared credentials.

Device identities concern engineering workstations, gateways, supervisory servers, managed controllers and other systems whose legitimacy affects access decisions. In newer equipment, device certificates or supported cryptographic mechanisms may provide strong assurance. In older systems, identity may need to be inferred or constrained through protected physical connections, approved gateway relationships or other compensating mechanisms.

Service identities govern communications between applications and systems, including data collection, historian services, industrial middleware and monitoring platforms. These relationships can become excessively privileged when service credentials are reused, embedded in application configurations or granted more permissions than their operational function requires.

The significance of service identity is particularly important for modern industrial convergence architectures. A historian service that collects process information should not automatically possess the right to modify controller configurations. A monitoring application that accesses operational measurements should not require unrestricted access to engineering systems. An enterprise analytics platform should not acquire control authority simply because it can retrieve data from an industrial server.

NIST SP 800-207A, published in September 2023, expands on identity-based access control for cloud-native applications, emphasising granular policies governing application and service identities. Although its reference architectures are primarily designed for modern distributed application environments, the underlying distinction between service identity and network location is relevant to the gateways, analytical platforms and integration services increasingly connected to OT.

NIST SP 800-207A, A Zero Trust Architecture Model for Access Control in Cloud-Native Applications in Multi-Cloud Environments — NIST — September 2023

The applicability of these mechanisms must nevertheless be limited to compatible components. A legacy field controller cannot be assumed to support an application identity framework simply because that framework is technically appropriate for the modern systems surrounding it.

Identity and Privilege Governance by Operational Role

Identity class	Legitimate function	Appropriate access model	Principal excessive-privilege risk	Required assurance
Control-room operator	Normal supervision and approved operating commands	Role-specific operating functions	Access to engineering or safety configuration	Separation of operating and engineering authority
Maintenance engineer	Diagnostics, calibration and approved changes	Task-linked privileges	Persistent programming rights across unrelated assets	Work-order and change-authorisation linkage
Vendor technician	Specialist diagnostics and contracted support	Time-limited, destination-restricted remote access	Permanent supplier connectivity	Operator-controlled session approval and revocation
OT cybersecurity analyst	Security observation and investigation	Read-oriented monitoring and approved diagnostic access	Uncontrolled active interrogation or intervention	OT-aware investigation procedures
IT identity administrator	Manage accounts and authentication services	Identity administration without automatic process control	Indirect acquisition of OT authority	Separation of identity management and engineering permission
OT system administrator	Maintain servers, gateways and supervisory platforms	Scoped platform administration	Cross-zone or cross-process privilege accumulation	Privileged session governance
Safety engineer	Maintain authorised protective-system configurations	Highly restricted safety lifecycle access	Unauthorised alteration of safety functions	Independent safety approval and validation
Historian service	Collect and store process information	Defined data acquisition permissions	Unnecessary controller write capability	Service identity and communication restrictions
Analytics platform	Retrieve authorised industrial data	Read-only mediated interface	Expansion from analytics into process control	Explicit prevention of write-capable pathways
Emergency maintenance identity	Support exceptional restoration actions	Controlled emergency access with retrospective accountability	Uncontrolled permanent emergency privilege	Documented activation, monitoring and review

This table represents recommended role separation. The necessary distribution of responsibilities will differ across installations, particularly in smaller utilities where the same employee may fulfil multiple operational roles. Organisational role overlap does not remove the need to distinguish the permissions used for each function.

The NSA’s 26 High-Impact Activities: What Can Be Established and What Requires Separate Verification

The October 2026 NSA document introduces a more concentrated approach to Zero Trust implementation for critical defence operational environments, referring to 26 high-impact activities selected from a broader 84-activity framework.

This numerical structure is important because it indicates a movement from a comprehensive activity catalogue towards a narrower set intended to concentrate attention on consequential implementation priorities. Nevertheless, the public release announcement does not reproduce the full individually numbered list, and the underlying PDF was not accessible for direct activity-by-activity verification in the current research session.

The distinction is substantive rather than editorial. It would be incorrect to construct 26 plausible OT security activities, assign them NSA activity identifiers and then represent the resulting catalogue as an authoritative transcription of the agency’s selections. The verified record supports the NSA’s general recommendations concerning Zero Trust, legacy OT, adversarial movement and defence-in-depth; it does not, on the basis of the accessible announcement alone, support attribution of a detailed invented ranking.

NSA Releases Zero Trust Guidance for Protecting Operational Technology Systems — NSA — October 2026

For practical purposes, the activity-selection problem can still be evaluated through a separate, explicitly analytical prioritisation based upon the CISA interagency guidance, NIST SP 800-207 and NIST SP 800-82. Such a prioritisation can identify which classes of action are most likely to reduce risk in ageing estates, what implementation prerequisites they require and which changes are potentially intrusive.

It must not be described as the official order of the NSA’s 26 activities until the complete primary catalogue has been examined.

Analytical Prioritisation of High-Impact Zero Trust Implementation Domains

Implementation domain	Principal security outcome	Typical dependency	Intrusiveness	Proposed relative sequence
Asset and process ownership	Identifies accountable resources and consequential functions	Engineering records and operator participation	Low	Foundational
Critical dependency identification	Distinguishes essential from unnecessary communications	Process knowledge and observed traffic	Low to moderate	Foundational
External access discovery	Identifies unmanaged supplier and maintenance pathways	Network, vendor and contract review	Low	Foundational
Individual identity accountability	Reduces anonymous and shared access	Identity governance and supplier cooperation	Moderate	Early
Privileged session control	Constrains high-authority activities	Managed entry paths and privileged-access tooling	Moderate	Early
Engineering workstation protection	Reduces compromise of programming authority	Application compatibility testing	Moderate	Early
Network boundary enforcement	Restricts movement between process environments	Verified communication requirements	Moderate to high	Early, after dependency validation
Controller configuration integrity	Detects unauthorised changes	Trusted project files and vendor tools	Low to moderate initially	Early to intermediate
Passive monitoring	Improves visibility without controller modification	Sensor placement and traffic access	Low to moderate	Early
Industrial protocol restrictions	Limits unnecessary commands and connections	Protocol understanding and capable enforcement	Moderate to high	Intermediate
Device identity modernisation	Reduces reliance on network location	Compatible hardware and lifecycle support	Variable	Intermediate to long term
Native cryptographic communications	Protects integrity and confidentiality where required	Protocol and equipment compatibility	Potentially high	Planned modernisation
Safety and recovery assurance	Establishes safe behaviour following failures or compromise	Engineering tests and approved procedures	Variable	Continuous
Equipment replacement	Removes irreducible structural weaknesses	Capital planning, procurement and commissioning	High	Consequence-driven

The sequence should not be interpreted as universal. A facility with externally exposed industrial controllers may need to restrict the exposure immediately, even before its inventory is complete. A facility with an existing, well-managed remote-access architecture but poor configuration integrity may derive greater immediate benefit from engineering-system protection and recovery assurance.

The critical requirement is to identify the relationship between each security intervention and a particular consequence-bearing attack path.

Architectural Maturity Must Be Measured Through Demonstrable Restrictions

A common weakness in cybersecurity maturity assessment is the treatment of technology deployment as evidence of successful risk reduction. The installation of an access-management platform, monitoring sensor or segmentation firewall provides evidence that a control exists; it does not establish that the control performs its intended function under realistic operating conditions.

For ageing industrial systems, the distinction should be expressed through testable assurance statements.

A remote-access programme is not mature merely because all supplier connections use multifactor authentication. It should demonstrate that a supplier whose credentials have been compromised cannot reach resources beyond the authorised maintenance scope.

A segmentation programme is not mature merely because the network has been divided into zones. It should demonstrate that a compromise in one zone cannot communicate with unrelated controllers through an overlooked management interface, vendor connection or shared service.

A configuration-integrity programme is not mature merely because backups exist. It should demonstrate that unauthorised controller changes can be identified and that a trusted configuration can be restored using available personnel and tools.

A device-identity programme is not mature merely because certificates have been issued. It should demonstrate that invalid, expired or unauthorised identities are rejected without jeopardising essential industrial operations.

These distinctions convert Zero Trust from an architectural aspiration into a set of falsifiable operational claims.

Architectural Assurance Statements and Required Evidence

Claimed Zero Trust outcome	Minimum evidence required	Failure condition invalidating the claim
Supplier access is task-restricted	Approved work order, policy, gateway configuration and representative test	Supplier can reach unrelated equipment
Controller programming is protected	Privilege configuration and authorised engineering workflow	Unapproved account can modify logic
Industrial zones are isolated	Traffic matrix, enforcement configuration and safe validation	Undocumented path bypasses the intended boundary
Access expires automatically	Session records and expiry test	Credentials or sessions remain effective beyond approval
Device identity is enforced	Validated identity mechanism and rejection testing	Unknown device gains equivalent permissions
Read-only analytics cannot control equipment	Interface design, enforced permissions and negative tests	Analytics pathway can issue write-capable commands
Emergency access remains available	Approved emergency procedure and representative exercise	Identity or gateway failure prevents essential intervention
Configuration integrity is maintained	Trusted baseline and change-comparison evidence	Material changes occur without detection
Recovery is independently achievable	Restoration procedure and tested dependencies	Recovery requires unavailable credentials, tools or vendor services

An assurance regime based on these statements would be more informative than a percentage of completed security activities alone. It would also make clear which controls remain provisional because they have not yet been subjected to operational validation.

Chapter 3 — Key Judgments

Zero Trust for operational technology is best understood as a framework for limiting the authority that identities, devices and services may exercise over protected industrial resources. Its defining feature is not the installation of a particular security product but the removal of assumptions that network presence, organisational affiliation or successful authentication automatically confer broad operational permission.

The highest-value architectural distinction is between network reachability and operational authority. The first determines whether a system can communicate with another; the second determines which industrial functions may be exercised through that communication. Effective protection requires both dimensions to be governed, particularly where legacy protocols and equipment cannot provide fine-grained enforcement natively.

The accessible NSA October 2026 announcement supports the strategic importance of Zero Trust and its application to critical legacy OT, but the complete 26-activity catalogue remains necessary for authoritative item-level mapping. The implementation priorities developed here are consequently analytical recommendations grounded in NIST and CISA guidance rather than a claimed transcription of NSA’s unpublished or inaccessible activity-level detail.

There is high confidence in the applicability of resource-focused authorisation and bounded privileged access to industrial environments. There is moderate confidence in the practical effectiveness of particular compensating implementations until their behaviour has been validated against the installed equipment, protocol characteristics and operational requirements.

What Would Change the Chapter 3 Assessment

Publication or direct examination of the complete NSA activity matrix could alter the alignment between the analytical priorities presented here and the agency’s intended implementation sequence. More importantly, operational test results demonstrating that particular enforcement architectures can reliably distinguish read, write, configuration and safety-related commands on legacy systems would strengthen the case for applying finer-grained access controls without immediate equipment replacement.

Conversely, evidence that an access-management architecture creates unacceptable dependencies or cannot prevent privilege escalation through permitted industrial protocols would require a more restrictive design, potentially including protocol mediation, supervised local access or accelerated modernisation.

Chapter 4. Compensating Controls, Segmentation and Operational Visibility

Principal Judgment: The Security of Legacy OT Depends on Enforceable Boundaries, Accurate Process Dependencies and the Ability to Demonstrate Containment

Compensating controls become strategically important where an industrial asset continues to perform an essential operational function but cannot independently satisfy contemporary cybersecurity requirements. Their purpose is not to conceal an equipment vulnerability or declare an obsolete controller equivalent to a modern secure device. It is to reduce the practical opportunities for exploiting that vulnerability, limit the authority available to a compromised identity, improve the likelihood of detecting unauthorised activity and preserve the ability to maintain or recover safe operations.

This distinction has direct implications for regulatory oversight and engineering assurance. A compensating control should be considered effective only when the operator can explain which specific exposure it addresses, which attack path it interrupts, what equipment or physical function it protects, how its effectiveness has been tested and what residual conditions remain outside its protective scope.

A firewall installed between an enterprise network and a production environment may reduce unauthorised connectivity across that boundary. It does not necessarily protect against a compromised engineering workstation already inside the production network, misuse of an authorised industrial protocol or malicious activity entering through a separate maintenance connection. A monitoring sensor may improve the ability to detect anomalous traffic, but it cannot prevent an attacker from issuing a harmful command unless a separate enforcement capability exists. A privileged-access platform may restrict external supplier sessions, but it cannot automatically guarantee that the permitted engineering application will distinguish safe diagnostic operations from configuration changes.

The April 2026 CISA interagency guidance recognises network segmentation, out-of-band detection, controlled remote access and other compensating mechanisms as necessary alternatives where direct implementation of Zero Trust functions would be impractical or disruptive. NIST SP 800-82 Revision 3 similarly places layered protections within an OT-specific assessment of system architecture, availability and safety.

Adapting Zero Trust Principles to Operational Technology, Sections Govern, Protect and Detect — CISA and Partner Agencies — April 2026

Guide to Operational Technology Security, NIST SP 800-82 Revision 3 — National Institute of Standards and Technology — September 2023

The central engineering objective is to establish a bounded industrial environment in which a compromise affecting one identity, workstation, service or communication pathway cannot automatically propagate into unrelated physical operations. Whether that objective can be achieved depends on the accuracy of the asset inventory, the completeness of the dependency model and the ability to enforce meaningful separation without interrupting authorised industrial communications.

Network Segmentation Must Follow Industrial Functions Rather Than Administrative Convenience

Network segmentation is frequently described as a method of dividing an organisation into smaller security domains. In operational technology, however, the placement of those boundaries has to follow genuine industrial dependencies rather than organisational departments, arbitrary address ranges or a generic interpretation of the Purdue enterprise-control hierarchy.

An industrial process may depend on several devices distributed across distinct physical locations, while equipment sharing the same cabinet or subnet may support functions with very different consequences of failure. Controllers associated with ordinary production, emergency shutdown, electrical protection and building management should not necessarily receive equivalent access policies merely because they are connected through similar networking technologies.

The industrial zones-and-conduits approach associated with ISA/IEC 62443 provides an established framework for considering these relationships. A zone groups assets according to relevant security requirements, while a conduit governs communication between zones. In practical implementation, the effectiveness of the model depends on whether the operator can establish which communications are genuinely necessary and whether the enforcement architecture can distinguish permitted from impermissible pathways.

CISA’s April 2026 guidance identifies the distinction between IT and OT segmentation directly. Enterprise segmentation commonly concentrates on protecting information, administering access and separating applications or organisational functions. OT segmentation must additionally protect physical processes, preserve reliability and accommodate operational communications that may not tolerate interruption.

The guidance explicitly observes that existing industrial practices, including physical separation and dedicated networks, already provide useful foundations for Zero Trust. It also warns that segmentation is not inherently sufficient: misconfigured virtual networks, overly permissive access rules and unintended connections can undermine apparent isolation.

Adapting Zero Trust Principles to Operational Technology, pp. 12–15 — CISA and Partner Agencies — April 2026

A consequence-based segmentation model therefore begins by identifying the physical process and the capabilities needed to sustain it. Only then can the operator determine which digital relationships should be permitted. This reverses the common practice of first drawing network boundaries and subsequently attempting to accommodate industrial traffic within them.

Industrial Zones, Conduits and Required Isolation

Architectural boundary	Industrial purpose	Recommended enforcement principle	Failure condition	Verification requirement
Enterprise IT to industrial DMZ	Exchange authorised business and operational information	Restrict communications to approved intermediary services	Enterprise system obtains direct controller access	Confirm no unauthorised route to process devices
Industrial DMZ to supervisory network	Permit controlled data exchange and maintenance services	Service-specific access, authentication and monitoring	Intermediary provides broad access to OT assets	Test destination and service restrictions
Supervisory network to controller zone	Support legitimate process supervision	Allow only required industrial communications	Unrelated workstation reaches controller programming interface	Validate permitted sources and operations
Production zone to safety-related zone	Preserve necessary safety information and independence	Strictly govern communications according to safety design	Production compromise can alter protective configuration	Engineering and safety-authority validation
Engineering environment to controllers	Support authorised configuration maintenance	Restrict programming authority to approved workflows	Engineering account accesses unrelated controllers	Controlled positive and negative access tests
Supplier environment to maintenance gateway	Enable time-limited external support	Named identity, MFA, approved destination and expiry	Supplier retains unrestricted persistent access	Session review and revocation testing
OT network to monitoring infrastructure	Collect telemetry without altering process operation	Prefer passive or appropriately isolated collection	Monitoring failure affects industrial availability	Validate monitoring failure behaviour
Facility-management network to mission-critical OT	Support essential building and mission functions	Separate unrelated facility management from critical equipment	Building management compromise affects mission-critical controls	Dependency and lateral-movement testing
OT to cloud analytics	Export approved operational data	Mediated, least-privilege outbound integration	Analytical service acquires direct control capability	Confirm inability to issue unauthorised writes

The principal value of this matrix is that it treats segmentation as a relationship between operational functions and security properties rather than a collection of firewall appliances. The exact boundaries must be established using the installed topology and the facility’s approved engineering requirements.

The Difference Between Physical Separation, VLANs, Firewalls and Microsegmentation

Physical separation can provide a strong reduction in network-based exposure when the resulting environments genuinely lack unapproved communication pathways. Nevertheless, a physically separated network may still be accessed through portable maintenance equipment, removable media, temporary vendor connections, wireless interfaces or devices that participate in multiple environments.

Consequently, a declaration that an industrial system is air-gapped should be supported by inspection and evidence of actual connectivity rather than accepted as a description of the network’s intended design.

Virtual LANs provide logical separation of network traffic but do not independently guarantee that inter-VLAN communication is denied. Their security properties depend on routing, switch configuration, administration and the controls applied at relevant boundaries.

Industrial firewalls can provide stronger enforcement where they restrict flows between clearly defined zones. Their effectiveness depends on correct rule design and, where necessary, an understanding of industrial application protocols. Permitting all traffic between two approved addresses may preserve connectivity while leaving important operational capabilities insufficiently restricted.

Microsegmentation can provide more granular restrictions between specific devices, applications or services. However, its application to older industrial environments may be constrained by equipment compatibility, communication timing and the absence of suitable enforcement mechanisms within endpoint devices.

The appropriate decision is therefore not whether the most granular theoretically available segmentation should always be deployed. It is whether the chosen architecture enforces the required restriction at a point compatible with the industrial process.

Where a legacy controller cannot enforce a device-specific policy, a surrounding gateway or controlled conduit may provide practical protection. Where a network already possesses effective physical separation, the most useful improvement may concern maintenance access and configuration governance rather than introducing a large additional inspection infrastructure.

Compensating-Control Effectiveness and Residual Exposure

Compensating control	Exposure addressed	Capability it does not establish	Most important validation test	Residual risk
Industrial firewall	Unnecessary communication between zones	Protection against all misuse of permitted traffic	Attempt prohibited zone crossing under controlled conditions	Authorised-channel abuse
Privileged-access gateway	Uncontrolled privileged entry	Intrinsic security of the accessed controller	Test destination, function and session restrictions	Excessive privileges inside permitted applications
Multifactor authentication	Use of credentials without the required additional factor	Safe or legitimate industrial commands	Confirm all governed entry paths require MFA	Authenticated malicious or mistaken actions
Passive monitoring	Limited visibility into industrial communications	Prevention of unauthorised commands	Validate detection against representative traffic	Undetected activity and limited protocol interpretation
Engineering workstation isolation	Exposure of controller programming tools	Integrity of previously modified controller logic	Test restrictions on workstation connectivity	Compromise originating inside the trusted zone
Application allowlisting	Execution of unapproved applications	Protection against misuse of approved applications	Confirm compatibility and enforcement on engineering software	Malicious use of permitted tools
Configuration comparison	Undetected changes to known configurations	Prevention of the initial modification	Introduce an approved test change and verify detection	Compromise between comparison intervals
Data diode	Unwanted reverse network communication on the protected path	Secure endpoints or completeness of all alternate paths	Verify directionality and bypass absence	Endpoint compromise and unmanaged parallel pathways
Protocol-aware gateway	Inappropriate protocol operations where supported	Semantic understanding of every industrial process command	Test allowed and prohibited protocol functions	Legitimate but operationally harmful commands
Offline trusted backup	Loss of recoverable configuration data	Automatic restoration of safe production	Representative restoration exercise	Incomplete files, incompatible software, physical-state uncertainty

The residual-risk column is especially important. It prevents a compensating measure from being interpreted as a complete solution to the weakness of the protected asset.

Operational Asset Inventories Must Become Dependency and Consequence Registers

Traditional equipment inventories commonly identify assets through serial numbers, addresses, manufacturers, models and installation locations. Such information remains useful for maintenance and lifecycle management, but it does not provide sufficient evidence to determine the consequences of cyber compromise.

For Zero Trust implementation, an asset register must establish the operational relationships between devices and the physical services they support. It should identify what process a controller influences, what equipment depends upon it, which workstations may administer it, which communications are required, who owns its configuration and how its loss or manipulation could affect the installation.

The April 2026 CISA guidance emphasises comprehensive asset visibility and recognises that passive discovery is often preferable for sensitive legacy equipment. It also notes that automated asset-discovery tools may provide incomplete results where networks are segmented, proprietary protocols are used or equipment is not continuously communicating.

This means that an operationally useful inventory cannot be generated exclusively from network traffic. It requires reconciliation with engineering drawings, process documentation, maintenance records, configuration repositories, physical inspection and the knowledge of personnel responsible for actual operations.

Adapting Zero Trust Principles to Operational Technology, pp. 9–10 — CISA and Partner Agencies — April 2026

The additional analytical requirement is to connect an asset’s technical characteristics to the consequences of losing or misusing its capabilities. A controller that supports a nonessential monitoring function may merit a different security investment from a similar controller whose configuration influences electrical protection or critical treatment operations.

Recommended Operational Asset and Dependency Register

Required field	Analytical purpose	Principal evidence source
Unique asset identifier	Persistent reference across maintenance and security records	Asset-management system
Physical location	Establishes installed equipment position	Engineering and facility records
Equipment manufacturer and model	Identifies support and technical capabilities	Manufacturer and procurement records
Hardware and firmware version	Determines compatibility and vulnerability relevance	Verified configuration records
Supported industrial protocols	Identifies communication and enforcement requirements	Engineering documentation and observed traffic
Physical process supported	Connects asset to operational function	Process engineering documentation
Consequence of loss	Establishes service and safety significance	Operational consequence assessment
Consequence of unauthorised modification	Identifies integrity-related hazards	Engineering and safety analysis
Required communication peers	Supports policy and segmentation decisions	Validated dependency mapping
Permitted operations	Distinguishes monitoring from control and programming	Engineering authorisation matrix
Engineering workstation dependency	Identifies privileged administration paths	Maintenance procedures
Remote support dependency	Establishes supplier exposure	Vendor and contract records
Operational owner	Establishes authority over normal use	Facility governance records
Maintenance owner	Establishes technical responsibility	Maintenance management records
Safety relevance	Identifies special review requirements	Approved safety documentation
Support lifecycle status	Determines available remediation options	Manufacturer records
Trusted configuration reference	Supports change detection and recovery	Configuration-management repository
Recovery time requirement	Links cybersecurity recovery to service resilience	Business continuity and engineering plans
Available fallback modes	Identifies manual or independent operating capabilities	Operating procedures
Last validated configuration	Establishes current assurance status	Change and commissioning records

Such a register becomes particularly valuable when used to identify concentrations of dependency. Multiple apparently independent industrial processes may rely upon a common engineering workstation, authentication server, gateway or vendor maintenance service. These relationships can create common-mode exposure that would not be evident from a device-by-device vulnerability assessment.

Continuous Monitoring Must Correlate Digital Activity With Physical Behaviour

Industrial monitoring should not be limited to identifying malicious signatures or unusual packet volumes. Its greater value lies in establishing whether observed communications correspond to the expected behaviour of the protected process and to approved operational activities.

This requires at least three complementary forms of observation.

Network monitoring identifies communication endpoints, protocols, directionality and changes in communication patterns. Configuration monitoring identifies changes to controller logic, firmware, engineering files and other settings affecting operational behaviour. Process monitoring examines relevant measurements and operating conditions to establish whether the physical system behaves consistently with engineering expectations.

No individual source can reliably answer every investigative question. An unexpected controller communication may be legitimate maintenance. A significant change in process measurements may result from mechanical failure rather than intrusion. An unauthorised configuration change may produce no immediate visible operational disturbance.

The CISA guidance distinguishes baseline-based monitoring, which compares activity with established normal patterns, from specification-based monitoring, which evaluates behaviour against defined permitted or expected operation. This distinction is especially useful in industrial environments because historically observed behaviour may include insecure practices that should not be accepted as legitimate merely because they occur regularly.

Adapting Zero Trust Principles to Operational Technology, pp. 18–20 — CISA and Partner Agencies — April 2026

For example, an engineering workstation may have historically communicated with many controllers because access restrictions were never implemented. A monitoring system trained exclusively on that history may regard unrestricted programming activity as normal. A specification-based policy could instead identify which controllers the workstation is authorised to manage and under which conditions.

The two methods should therefore be used as complementary sources of evidence. Historical baselines help detect unusual behaviour; engineering specifications help determine whether habitual behaviour is actually authorised.

Monitoring and Detection Assurance Matrix

Observation	Potential significance	Required corroboration	Risk of misinterpretation
New controller communication peer	Undocumented connectivity or intrusion pathway	Maintenance records and topology review	Legitimate commissioning activity
Unexpected engineering protocol	Unauthorised diagnostic or programming activity	Work orders and workstation records	Approved vendor troubleshooting
Controller configuration change	Possible integrity compromise	Trusted configuration comparison	Approved engineering modification
Unusual process measurement	Physical disturbance or data manipulation	Independent instruments and operator assessment	Mechanical failure or normal transient
Remote session outside approved period	Access governance failure	Gateway logs and emergency approvals	Poorly documented emergency intervention
New outbound connection from historian	Unapproved external integration	Application ownership and network records	Legitimate software update or data service
Repeated failed authentication	Credential misuse or configuration problem	Identity logs and operational context	Expired maintenance credentials
Change in protection-related settings	Potential safety or availability significance	Authorised engineering records	Approved recalibration or testing
Monitoring blind spot	Loss of detection coverage	Sensor health and network topology	Normal isolation of inactive equipment
Identity-service failure	Potential inability to authorise maintenance	Resilience testing and emergency procedures	Temporary administrative outage without process effect

The objective of monitoring is not to produce the maximum possible number of alerts. It is to develop evidence that can distinguish routine operational activity, technical failure, unauthorised digital intervention and physically consequential compromise.

Controlled Remote Access Requires Independent Operational Ownership

A remote-access session should have a technical owner responsible for the security mechanism and an operational owner responsible for the authorised work. The two responsibilities are distinct.

The technical owner may ensure that identity verification, session recording, credential protection and network restrictions are operating correctly. The operational owner determines whether the maintenance activity is necessary, whether it may be undertaken under current process conditions and whether the requested permissions are proportionate to the task.

This arrangement is particularly important for supplier support. Manufacturers and system integrators often possess specialised knowledge required to maintain complex industrial equipment. Their technical expertise does not remove the operator’s responsibility for deciding when access is permitted and which activities may be performed.

NIST SP 1800-45, published in June 2026, provides a practical contribution by demonstrating secure remote-access architectures for water and wastewater operators using commercially available technology. Its laboratory-based implementations show that meaningful protection can be developed for organisations with different resource capacities, although the published demonstrations do not replace site-specific commissioning and validation.

Cybersecurity for the Water and Wastewater Sector: Build Architecture, NIST SP 1800-45 — NIST — June 2026

The operational ownership principle also applies to emergency access. A facility may need to restore critical equipment when the ordinary authentication service, maintenance gateway or administrative network is unavailable. Emergency procedures must be designed so that necessary intervention remains possible without establishing uncontrolled permanent privileges.

A technically rigorous arrangement should define the circumstances under which emergency access can be activated, who can authorise it, what evidence will be retained and how the activity will be reviewed after normal operations resume.

Containment Assurance Must Be Demonstrated Under Controlled Compromise Conditions

The effectiveness of Zero Trust in OT ultimately depends upon whether a compromised component can be prevented from affecting unrelated or unauthorised industrial functions.

This can be examined through controlled assurance exercises that reproduce selected security failures without introducing unnecessary danger to production equipment.

A compromised supplier identity can be represented by an approved test account whose attempted access exceeds the assigned maintenance scope. A compromised workstation can be simulated through controlled attempts to communicate with unapproved destinations. A segmentation failure can be assessed by testing whether a restricted conduit permits unintended traffic. A loss of authentication infrastructure can be examined through approved resilience exercises that confirm the continued availability of necessary local operations.

These tests must be designed and authorised by the responsible engineers and cybersecurity personnel, particularly when they involve equipment supporting safety-critical functions.

The central purpose is to produce evidence about containment rather than simply demonstrate that an alert can be generated.

Recommended Containment Validation Programme

Controlled test	Security property evaluated	Required pass condition	Operational safeguard
Unauthorised supplier destination request	Destination restriction	Access to unrelated equipment is denied	Test through approved access gateway
Expired contractor session	Time-bound authorisation	Session is terminated and cannot be reused	Avoid interrupting active essential maintenance
Unapproved programming attempt	Separation of read and write authority	Programming action is prevented by an actual enforcement mechanism	Use test equipment or approved nonintrusive method
Cross-zone communication attempt	Segmentation effectiveness	Unauthorised route is blocked	Validate intended flows beforehand
Loss of remote identity service	Resilience of local operation	Essential process control continues	Engineering-approved failure exercise
Monitoring component failure	Independence of monitoring infrastructure	Industrial operation is unaffected	Verify sensor and network design
Trusted configuration comparison	Integrity assurance	Test change is detected and attributable	Use approved configuration test
Emergency access activation	Continuity and accountability	Authorised intervention remains possible and reviewable	Documented emergency procedure
Analytics write-attempt test	Prevention of indirect control	Analytical interface cannot alter process controls	Isolated testing or non-production validation
Recovery exercise	Restoration assurance	Trusted configuration and necessary operating functions are restored	Representative safe test environment

These tests are qualitative assurance measures. They should not be converted into numerical claims of risk reduction without defined baselines, documented test populations and reproducible outcome data.

Chapter 4 — Key Judgments

Compensating controls can materially improve the protection of ageing industrial equipment when they are designed around verified process dependencies and enforced at points that do not introduce unacceptable operational hazards. Their effectiveness depends on the ability to restrict actual attack paths rather than simply create additional nominal security layers.

Segmentation should be based on operational functions, required communications and physical consequences. Asset inventories must establish process ownership and dependencies, while monitoring must correlate digital activity with configuration integrity and physical behaviour.

Remote-access security requires the separation of technical authentication from engineering authorisation, particularly where supplier personnel possess powerful maintenance capabilities. Privileged sessions should be limited by identity, destination, permitted function, duration and operational approval wherever technically feasible.

The strongest evidence of security improvement is not the presence of a product or control but a controlled demonstration that compromise of one component does not permit unauthorised influence over other essential industrial functions.

What Would Change the Chapter 4 Assessment

The assessment would change if operational testing demonstrated that particular gateway, segmentation or monitoring technologies could not reliably enforce the intended policies against the installed industrial protocols, or if introducing those mechanisms created unacceptable communications dependencies.

Conversely, reproducible evidence of successful containment and safe recovery across representative installations would support wider adoption of common reference architectures, potentially reducing the engineering effort required for individual facilities.

Chapter 5. Procurement, Secure-by-Demand Requirements and Technology Improvement

Principal Strategic Judgment: Procurement Is the Mechanism Through Which Compensating Security Can Become Intrinsic Industrial Capability

The long-term effectiveness of Zero Trust in critical infrastructure will depend substantially upon whether industrial procurement practices eliminate the security limitations that operators currently compensate for through additional networks, gateways, access controls and organisational procedures. The challenge is not simply to purchase newer equipment, but to change the contractual and technical conditions under which industrial products enter service, remain supported, exchange information, receive configuration changes and can ultimately be replaced. Unless these conditions change, infrastructure operators risk perpetuating the same structural vulnerabilities within successive generations of equipment, even while their cybersecurity expenditure continues to increase.

This issue has particular importance for industrial systems because procurement decisions establish dependencies that may remain operationally significant for decades. Selecting a controller, industrial communication platform, supervisory application or safety-related subsystem can determine the available authentication mechanisms, configuration-management processes, recovery procedures, software dependencies and supplier relationships throughout much of the equipment’s service life.

A device purchased without sufficient logging may remain difficult to investigate after compromise. A proprietary configuration system may require continued dependence upon a single supplier. An insecure programming interface may create a need for external access restrictions that add complexity to future network changes. A product without a clearly defined support period may become an unavoidable modernisation problem before the associated mechanical equipment reaches the end of its useful life.

Consequently, cybersecurity procurement should be considered part of infrastructure resilience planning rather than an isolated technical purchasing decision.

The most directly applicable official instrument is the joint guidance Secure by Demand: Priority Considerations for Operational Technology Owners and Operators when Selecting Digital Products, published on 13 January 2025 by CISA with contributions from the NSA, FBI, EPA, TSA and international partners, including cybersecurity authorities from Australia, Canada, Germany, the Netherlands, New Zealand and the United Kingdom, as well as the European Commission’s Directorate-General for Communications Networks, Content and Technology.

The document identifies 12 priority security elements that industrial purchasers should consider when selecting digital products. These include configuration management, logging, open standards, operator ownership, data protection, secure defaults, secure communications, secure controls, strong authentication, threat modelling, vulnerability management and upgrade tooling.

Secure by Demand: Priority Considerations for Operational Technology Owners and Operators when Selecting Digital Products — CISA and International Partners — January 2025

The importance of the joint guidance lies in its attempt to alter the distribution of responsibility between manufacturers and infrastructure operators. Equipment purchasers have historically been required to build security around products whose design did not adequately incorporate contemporary protection requirements. Where essential security capabilities are included in the baseline product, operators can reduce their reliance upon complex external compensating measures and improve the consistency of security across future industrial installations.

The guidance is advisory and does not independently establish universal legal obligations. Nevertheless, it provides a substantive basis for public procurement criteria, supplier qualification, contract negotiation and regulatory expectations regarding the security properties of newly acquired operational equipment.

The Twelve Secure-by-Demand Requirements and Their Industrial Significance

Official procurement consideration	Required product capability	Strategic importance	Recommended procurement evidence
Configuration management	Track, back up and securely deploy configuration and engineering logic	Preserves integrity and recoverability of operating equipment	Demonstration of authenticated configuration changes and restoration
Logging in baseline products	Record configuration, security and relevant safety events	Enables attribution, investigation and assurance	Sample logs, supported formats and event-generation tests
Open standards	Support interoperable security and configuration functions	Reduces avoidable dependence on proprietary mechanisms	Protocol documentation and migration demonstration
Ownership	Give operators adequate autonomy over maintenance and changes	Reduces supplier-dependent recovery and access risks	Contractual rights and operator-controlled maintenance demonstration
Protection of data	Protect operational information and configurations	Reduces manipulation and unauthorised disclosure	Evidence of integrity and confidentiality controls
Secure by default	Eliminate insecure defaults and unnecessary services	Reduces vulnerabilities introduced during installation	Factory-state security assessment
Secure communications	Support authenticated and protected communication	Reduces reliance on trusted network location	Certificate and communication-security testing
Secure controls	Preserve essential functions under malicious or abnormal inputs	Connects cybersecurity properties to operational resilience	Documented control-system robustness testing
Strong authentication	Restrict unauthorised access through suitable authentication and roles	Reduces account and credential misuse	Authentication and privilege-enforcement demonstration
Threat modelling	Document credible compromise pathways and design mitigations	Improves transparency of product security assumptions	Manufacturer threat model and mitigation mapping
Vulnerability management	Maintain supported products and address vulnerabilities	Reduces exposure over the service life	Support commitments, disclosure procedures and component information
Upgrade and patch tooling	Permit controlled, verifiable updates	Enables safer lifecycle maintenance	Tested update, rollback and version-verification procedures

Source: Secure by Demand, pp. 3–4 — CISA and International Partners — January 2025.

The procurement requirements are particularly consequential because they influence security outcomes at several stages of equipment ownership. Strong authentication reduces opportunities for unauthorised entry; secure configuration management limits the risk of untracked operational changes; logging supports the investigation of abnormal activity; open standards facilitate integration and replacement; and robust maintenance provisions reduce the likelihood that an asset becomes permanently dependent upon unsupported software.

A manufacturer that offers these properties only through expensive optional components may impose continuing security costs upon operators. Accordingly, procurement evaluations should distinguish security features included in the baseline product from capabilities that require additional licences, external services or proprietary infrastructure.

The secure-by-default requirement is especially important. A device should not expose unnecessary administration services or rely upon known default credentials simply because the purchaser has not purchased an additional security package. The design objective is to minimise the number of corrective actions required before the product can be operated safely within its intended environment.

From Procurement Guidance to Enforceable Contractual Requirements

General statements of cybersecurity capability have limited value unless translated into requirements that can be demonstrated during procurement and commissioning. A supplier’s declaration that a product supports secure communications does not establish which communications are protected, which algorithms or certificate mechanisms are available, how keys are managed or what occurs when an authentication mechanism fails.

Similarly, a product may advertise event logging while failing to record the configuration changes most consequential for industrial incident investigations. A backup function may exist but require proprietary cloud services or unavailable supplier credentials during restoration.

Procurement specifications should therefore define security outcomes in terms of observable behaviour and operational independence.

For authenticated configuration management, the purchaser should establish whether unauthorised individuals can modify engineering logic, whether approved changes are attributable and whether the equipment can be restored from a trusted baseline.

For logging, the supplier should document which events are recorded, how those events are protected, how timestamps are managed and whether the records can be exported to systems operated by the infrastructure owner.

For software support, contractual documentation should establish the support period, the process for handling discovered vulnerabilities, the conditions under which security updates are supplied and the responsibilities associated with end-of-support transitions.

For recovery, the operator should determine whether essential restoration activities can be performed without continuous connectivity to manufacturer infrastructure.

These requirements are not purely technical. They affect the distribution of operational authority, the cost of ownership and the ability of the infrastructure operator to act independently during an incident.

Recommended Security Clauses for Industrial Procurement

Contractual subject	Minimum requirement to specify	Acceptance evidence	Principal procurement risk
Supported lifetime	Documented security maintenance and end-of-support policy	Binding support documentation	Equipment becomes unsupported prematurely
Vulnerability disclosure	Defined reporting, triage and remediation process	Published policy and contractual escalation terms	Slow response to consequential weaknesses
Configuration ownership	Operator access to necessary configuration data and restoration tools	Demonstrated backup and restoration	Excessive supplier dependence
Access management	Supported individual identities and appropriate privilege separation	Role and negative-access tests	Persistent shared or excessive privileges
Audit evidence	Exportable records of security and engineering activity	Representative logs	Inability to investigate changes
Secure defaults	Unnecessary interfaces disabled and no universal default credentials	Factory acceptance security review	Insecure deployment baseline
Updates	Authenticated updates and documented rollback procedures	Controlled update exercise	Unrecoverable or incompatible changes
Communications security	Supported authenticated and integrity-protected communications	Protocol and certificate tests	Unprotected management and configuration traffic
Component transparency	Hardware and software component information where applicable	Supplier documentation and SBOM/HBOM availability	Unidentified component vulnerabilities
Incident support	Defined supplier responsibilities during compromise	Incident support schedule and escalation procedure	Delayed technical assistance
Exit and migration	Practical export of configurations and essential operational data	Demonstrated migration procedure	Vendor lock-in
Operational validation	Security changes compatible with defined engineering requirements	Factory and site acceptance evidence	Cybersecurity improvement undermines operations

The requirements should be adjusted to the device class. A small field instrument cannot necessarily implement the same logging, identity and cryptographic capabilities as an engineering server. A safety-critical controller may require a substantially different validation process from a building-management gateway.

The essential distinction is between justified technical limitations and avoidable product-design deficiencies. Procurement authorities should require suppliers to explain limitations and the compensating architecture they necessitate, rather than accepting generic declarations of incompatibility.

Modernisation Should Proceed Through Defined Technical Pathways

The transition from legacy OT to more secure industrial infrastructure need not occur through complete replacement of entire installations. In many environments, meaningful improvements can be achieved by upgrading the components that govern communication, configuration and maintenance access while preserving the mechanical equipment and control functions that remain operationally suitable.

The viability of such an approach depends upon whether the existing architecture permits the introduction of secure intermediary components without unacceptable timing, compatibility or safety consequences.

An industrial protocol gateway may provide modern authentication at the boundary of an older system while translating communications into a form supported by the legacy controller. A new supervisory server may replace an unsupported operating environment while continuing to communicate with existing field equipment. A secure remote-access platform may remove permanent vendor connectivity without requiring immediate modification of controller firmware. A monitoring architecture may add visibility through passive observation rather than intrusive changes to the industrial devices.

However, these approaches introduce additional components and dependencies. Their benefits must therefore be assessed alongside the consequences of intermediary failure, the integrity of protocol translation and the continuing security limitations of the equipment behind the protective boundary.

The September 2026 initial public draft of NIST SP 800-82 Revision 4 provides relevant evidence of the direction of industrial security guidance. NIST identifies expanded treatment of asset management, network monitoring, system-management protection and Zero Trust principles, as well as broader coverage of water systems, food and agriculture, freight rail, maritime operations, building automation and industrial internet-of-things convergence.

As of 17 October 2026, however, Revision 4 remains a public draft, with comments due on 30 November 2026. Its proposed additions are relevant to emerging practice but should not be described as the final replacement for Revision 3.

NIST SP 800-82 Revision 4, Guide to Operational Technology Security — Initial Public Draft — September 2026

Technology Improvement Pathways and Engineering Trade-Offs

Modernisation pathway	Principal benefit	Legacy equipment retained	New dependency introduced	Conditions supporting adoption
Secure remote-access gateway	Better identity and session governance	Controllers and existing engineering tools	Gateway and access-management infrastructure	Remote maintenance is a significant exposure
Protocol-aware security gateway	Greater control of industrial communications	Existing controller protocol and field devices	Translation and inspection component	Protocol behaviour is well understood and testable
Supervisory workstation replacement	Reduced exposure from unsupported computing platforms	Underlying industrial controllers	Compatibility with existing applications and drivers	Engineering applications can be migrated safely
Segmentation redesign	Reduced lateral movement	Most existing control equipment	Additional network policy and administration	Dependencies are sufficiently documented
Passive telemetry deployment	Improved observation and investigation	Existing devices and control logic	Monitoring infrastructure	Nonintrusive collection can be engineered
Data diode	Strong directional separation for selected data flows	Source systems and production controllers	One-way transfer infrastructure	Legitimate data requirements are genuinely unidirectional
Controller firmware modernisation	Improved native security where supported	Existing controller hardware	New firmware behaviour and maintenance process	Vendor qualification and testing are available
Modular controller replacement	Removal of selected legacy weaknesses	Mechanical equipment and compatible peripherals	New controller integration	Interfaces and control logic can be validated
Complete control-system replacement	Broader architectural renewal	Potentially limited legacy components	Large commissioning and integration programme	Structural vulnerabilities cannot be adequately compensated
Local identity integration	Improved user and service accountability	Compatible existing systems	Identity infrastructure	Failure behaviour is compatible with operational requirements

The table describes technical options rather than a universally preferred sequence. Modernisation decisions require verified engineering costs, maintenance constraints, process dependencies and recovery requirements.

Protocol Gateways and Data Diodes Require Precise Architectural Justification

Protocol gateways can be useful where older equipment cannot support modern communication security but remains operationally necessary. They may provide controlled interfaces through which newer systems interact with legacy controllers, potentially allowing authentication and filtering at a point where those functions would otherwise be unavailable.

Nevertheless, the gateway’s ability to enforce meaningful policy depends upon the protocol and the depth of application understanding.

A gateway that permits a connection after authentication may provide little protection against unauthorised commands carried within that connection. A protocol-aware gateway may be able to distinguish communication functions but still lack the process context required to determine whether a technically valid command is operationally appropriate.

The practical requirement is therefore to specify exactly which operations the gateway can identify and restrict, and to validate that its failure or malfunction will not create an unacceptable operational hazard.

Data diodes present a different engineering proposition. Their purpose is to enforce a one-way communication relationship, potentially allowing operational data to leave a protected environment while preventing communications in the opposite direction through the protected connection.

This can be valuable for industrial monitoring, reporting and analytics applications where information export is necessary but inbound communication is not.

However, a data diode is not a substitute for complete architectural analysis. If the process requires bidirectional command exchange, a strictly unidirectional link may be unsuitable. If alternative communication paths remain active, the directional protection of one link may not establish effective system-wide isolation. If the receiving analytics environment can influence the source through another administrative relationship, the intended separation may be compromised indirectly.

The appropriate use of a diode is therefore determined by the actual information flow and the consequences of reverse communication, rather than by the assumption that unidirectional technology is intrinsically suitable for every critical industrial environment.

Modern Identity Infrastructure and the Risk of New Common-Mode Dependencies

Integrating industrial access with modern identity systems can improve accountability, reduce shared credentials and enable more consistent revocation of supplier permissions. It also introduces the possibility that failure or compromise of the identity infrastructure may affect several industrial systems simultaneously.

This common-mode dependency is especially important when multiple facilities rely upon the same authentication service, cloud identity provider or centrally administered access policy.

The consequences depend on the distinction between the continuing operation of an already-running physical process and the ability to initiate new maintenance or administrative sessions.

A properly designed industrial environment may continue local control during an identity-service outage while temporarily restricting nonessential remote maintenance. In other cases, operators may require emergency intervention during the outage, creating a need for controlled alternative access arrangements.

The appropriate design must therefore distinguish operational autonomy from administrative connectivity.

A modern identity service should not become a necessary condition for every local controller operation unless the engineering design explicitly requires and validates that dependency. Conversely, emergency access should not be implemented through undocumented permanent credentials that undermine the access controls applied during normal operation.

The central requirement is to preserve a verifiable relationship between identity assurance and process continuity.

Phased Equipment Replacement Should Be Based on Irreducible Residual Risk

The strongest justification for accelerated replacement arises when an essential industrial function remains exposed to a consequential compromise pathway that cannot be adequately constrained through available compensating controls.

This may occur where equipment requires unrestricted remote access for routine support, cannot be isolated from less trusted networks, lacks recoverable configuration information, depends on unsupported engineering tools or cannot provide sufficient evidence to establish whether its operating logic has been altered.

Replacement may also become necessary where an older system prevents the implementation of security controls required by the applicable regulatory framework or where the consequences of losing the associated physical function exceed the organisation’s defined risk tolerance.

The economic assessment should compare the complete costs and consequences of alternative strategies rather than focusing exclusively on equipment purchase prices.

Continued operation with compensating controls may involve gateway procurement, monitoring, specialist maintenance, recurring testing, vendor support and an enduring residual exposure. Replacement may involve capital expenditure, engineering redesign, commissioning, temporary disruption and the possibility of introducing new technical defects.

The more defensible comparison is therefore between the total lifecycle cost and expected operational assurance of each option, subject to separately defined safety and service-continuity requirements.

It would be inappropriate to assign universal monetary values to these alternatives without installation-specific cost, failure and consequence data.

Modernisation Decision Criteria

Condition	Continued compensation potentially defensible	Accelerated replacement potentially justified
External access	All necessary access can be strongly governed	Uncontrolled access remains necessary
Network separation	Essential processes can be effectively isolated	Required connectivity prevents meaningful containment
Configuration integrity	Trusted state can be established and monitored	Configuration changes cannot be adequately detected or verified
Recovery	Restoration is technically feasible and tested	Trusted recovery cannot be demonstrated
Supplier support	Necessary tools, components and expertise remain available	Critical supplier support has ended without viable alternatives
Process safety	Protective independence remains demonstrable	Existing design prevents adequate safety assurance
Maintenance disruption	Security controls can be introduced during acceptable windows	Continued operation requires unacceptable recurring intervention
Lifecycle economics	Compensation remains sustainable over the planning horizon	Long-term compensation costs and residual consequences become disproportionate
Regulatory obligations	Existing architecture can meet applicable requirements	Compliance requires capabilities unavailable in the installed system

These conditions should be interpreted through documented engineering assessment and applicable regulatory requirements, not as automatic legal thresholds.

Artificial Intelligence and Industrial Analytics: Authority Must Remain Bounded by Independently Enforced Constraints

The integration of artificial intelligence into operational environments creates a distinct governance problem because analytical systems may process industrial information and generate recommendations that influence physical operations.

At the lowest level of authority, an AI system may analyse historical measurements and provide informational reports without any connection capable of changing industrial equipment. At a higher level, it may generate maintenance recommendations or suggested parameter adjustments for review by authorised personnel. More intrusive architectures may allow automated systems to modify setpoints, schedule equipment operations or interact with engineering applications.

The security consequences differ substantially across these arrangements.

The principal question is not whether artificial intelligence can identify useful operating patterns. It is whether the system possesses direct or indirect authority to influence the physical process and whether that authority remains constrained when the model produces an incorrect recommendation, its inputs are manipulated, or the surrounding computing environment is compromised.

A system that produces analytical recommendations for human approval has a different risk profile from one that can independently transmit commands to controllers. Human approval, however, is only meaningful if the reviewer receives sufficient information to evaluate the proposal and if the technical architecture prevents the analytical system from bypassing the approval process.

The same principle applies to automatically generated maintenance instructions. A model may assist technicians in interpreting logs or identifying likely faults, but it should not acquire access to controller programming interfaces merely because it can prepare a proposed configuration change.

The NSA’s October 2026 announcement specifically identifies the additional exposure created by integrating advanced intelligent capabilities into operational systems. That observation supports a conservative approach to AI authority in safety- and mission-critical environments.

NSA Releases Zero Trust Guidance for Protecting Operational Technology Systems — NSA — October 2026

Proposed Governance Model for AI-Enabled OT

AI integration category	Permitted operational role	Control authority	Required governance
Historical analysis	Analyse archived industrial measurements	None	Data integrity, access limits and output validation
Operational monitoring	Identify unusual operating conditions	None	Defined alert thresholds and human review
Predictive maintenance	Recommend inspections or equipment servicing	None	Engineering verification and maintenance approval
Decision support	Recommend operating changes	No independent execution authority	Responsible operator review and approved procedures
Engineering assistance	Prepare proposed configuration changes	No direct deployment rights	Independent technical review and controlled change management
Bounded automation	Execute narrowly defined approved functions	Limited, explicitly engineered authority	Validated operating envelope and independent safeguards
Autonomous process optimisation	Modify operating conditions within a defined architecture	Potentially consequential control authority	Formal safety analysis, testing and independent enforcement
Safety-critical autonomous control	Directly influence protective or high-consequence functions	Highest consequence	Separate regulatory, engineering and safety assurance

The categories constitute an analytical classification, not a certification system established by the cited guidance.

For safety-critical applications, the most important design requirement is that protective limits should not depend exclusively upon the correctness or continued availability of the AI model. Independent engineering safeguards, validated control constraints and established operating procedures should continue to govern hazardous physical conditions.

Where the analytical system relies upon cloud infrastructure, external model providers or shared enterprise services, the operator must also evaluate whether those dependencies introduce remote control pathways, sensitive-data exposure or availability risks.

An AI model that is technically restricted to observational data should not be able to obtain write privileges through an associated automation service, administrative token or maintenance platform. The entire integration pathway must therefore be assessed, including indirect authority.

Supplier Accountability and the Security Economics of Industrial Ownership

The Secure-by-Demand framework also challenges a longstanding feature of industrial technology markets: the purchaser may bear much of the continuing cost of securing a product even though the manufacturer controls many of the design decisions that determine its security capabilities.

A manufacturer decides which authentication mechanisms are available, whether logging is included in the baseline product, whether secure update mechanisms exist, how long vulnerabilities will be addressed and whether owners can independently restore their equipment.

Where these properties are inadequate, the operator must compensate through additional systems and procedures, often under severe maintenance and availability constraints.

The January 2025 joint guidance explicitly identifies this imbalance and encourages purchasers to use their procurement decisions to create stronger incentives for manufacturers to provide secure products.

Secure by Demand: Priority Considerations for Operational Technology Owners and Operators when Selecting Digital Products — CISA and International Partners — January 2025

This creates a strategic opportunity for large public purchasers, defence organisations and operators of essential services. Where purchasers establish consistent minimum expectations, suppliers have stronger commercial reasons to incorporate cybersecurity into baseline product design rather than treat it as an optional integration service.

However, procurement policies must also account for industrial market structure and equipment availability. Excessively rigid requirements may exclude viable suppliers or delay necessary replacement where no product fully satisfies the desired security profile. This concern is particularly important for specialised industrial devices and smaller operators with limited purchasing power.

A defensible procurement policy should therefore distinguish mandatory protective outcomes from preferred implementation methods, establish justified exceptions and require transparent evidence of residual risk where products cannot satisfy all desired requirements.

The objective is to progressively improve the industrial equipment market without jeopardising the continuity of essential services during the transition.

International and European Procurement Implications

The January 2025 Secure-by-Demand document is notable for its multinational participation. Contributions from European and other allied cybersecurity authorities demonstrate a shared interest in strengthening the security properties of industrial products and reducing dependence upon insecure defaults.

Nevertheless, the document expressly clarifies that the European Commission’s contribution does not constitute an interpretation of European Union law, does not bind the Commission and should not be treated as a statement that every element of the multinational guidance reflects binding Union requirements.

This distinction matters because European procurement and product-security obligations must be assessed through the applicable legal instruments rather than inferred from the participation of European institutions in technical guidance.

For industrial operators, the practical opportunity is to align procurement specifications with internationally recognised cybersecurity objectives while separately establishing the legal obligations applicable to each product, sector and jurisdiction.

The European Union’s Cyber Resilience Act introduces horizontal cybersecurity requirements for products with digital elements within its defined scope, with obligations and application dates determined by the regulation. Its relationship with specialised industrial products and other sectoral rules must therefore be evaluated according to the particular product and legal provisions.

Regulation (EU) 2024/2847 on Horizontal Cybersecurity Requirements for Products with Digital Elements — European Parliament and Council — October 2024

The broader strategic implication for Italy, France, Germany and the United Kingdom is that industrial cybersecurity procurement should become a coordinated engineering, security and contractual function. Operators should not rely exclusively upon product certification or manufacturer declarations, but should require evidence that the purchased equipment can support the security and operational outcomes expected within the intended installation.

Chapter 5 — Key Judgments

The strongest long-term contribution to industrial Zero Trust will come from purchasing and engineering equipment whose security properties are intrinsic to its design, sufficiently documented for independent assessment and sustainable throughout the product’s operational life.

The twelve Secure-by-Demand considerations provide a documented basis for improving procurement requirements, including authenticated configuration management, baseline logging, secure communications, operator ownership, support commitments and the elimination of insecure defaults.

Modernisation should proceed through technically justified pathways rather than a general presumption that complete replacement is always necessary. Gateways, protocol mediation, monitoring, identity integration and modular upgrades can reduce important exposures, but each introduces dependencies that require engineering assessment.

Equipment replacement becomes strategically necessary where an essential process cannot be adequately protected, independently monitored or reliably restored using the available architecture. The decisive criterion is the residual risk to the physical function, not the chronological age of the equipment alone.

The integration of artificial intelligence creates additional requirements concerning the separation between observation, recommendation and control authority. For high-consequence industrial operations, automated actions must remain bounded by approved engineering conditions and independently enforceable safeguards.

There is high confidence that secure-by-design procurement can reduce future dependence upon compensating controls. There is moderate confidence in the comparative benefits of particular modernisation pathways until installation-specific testing and lifecycle analysis establish their operational performance and economic consequences.

What Would Change the Chapter 5 Assessment

The assessment would change if manufacturers demonstrated reliable and interoperable security capabilities across a substantially broader range of industrial products, allowing operators to modernise authentication, configuration management and logging without extensive redesign of existing facilities.

Conversely, persistent supplier dependence, inadequate software support commitments, incompatible update mechanisms or the inability to establish trustworthy restoration processes would strengthen the case for more demanding procurement conditions and earlier equipment replacement.

The remaining decision-relevant uncertainty concerns the relationship between security improvement, implementation cost, production disruption and residual physical risk. These variables must be measured through actual procurement, commissioning and operational evidence rather than estimated through generic cybersecurity maturity scores.

Pillar II — Integrated Strategic Assessment

The three chapters establish a continuous relationship between the architecture of industrial trust, the compensating protection of existing equipment and the procurement decisions that determine future exposure.

Zero Trust provides the conceptual mechanism for eliminating unrestricted authority based on network location or previously established trust. Compensating controls provide the practical means of applying that mechanism around equipment unable to support it directly. Secure-by-Demand procurement provides the longer-term route through which industrial systems can progressively acquire stronger native authentication, trustworthy configuration management, improved monitoring and independent recovery capabilities.

The central strategic distinction is between demonstrating that a control exists and demonstrating that a physical process remains protected when an adversary compromises an otherwise trusted component.

This distinction must govern future regulation, infrastructure investment and national security assurance. An operator may complete an extensive cybersecurity implementation programme while retaining unacceptable exposure if permitted access paths still allow unauthorised control of critical equipment. Equally, an ageing installation may achieve meaningful improvements in resilience without immediately replacing all legacy controllers if its essential processes can be isolated, its access relationships constrained and its recovery independently verified.

The evidence supports a consequence-based transition in which the effectiveness of each intervention is assessed against the actual physical functions it protects. The next stage of analysis must convert these architectural and industrial requirements into a measurable programme of government oversight, operator implementation, regulatory prioritisation and strategic intelligence collection.

---

PILLAR III — GOVERNMENT IMPLEMENTATION, REGULATORY ASSURANCE AND STRATEGIC INTELLIGENCE

Chapter 6. Implementation Roadmap, Risk Prioritisation and Governance

Principal Strategic Judgment: National Zero Trust Implementation Must Be Governed by Demonstrable Industrial Resilience Rather Than Cybersecurity Compliance Alone

The transition towards Zero Trust in critical operational technology requires a fundamental change in the way governments, regulators and infrastructure operators define successful cybersecurity implementation. The central question is no longer whether an organisation has adopted a sufficient number of security technologies, completed a predetermined percentage of technical activities or achieved conformity with an abstract maturity model. It is whether the organisation can demonstrate, through defensible engineering evidence, that compromise of an identity, workstation, supplier connection or supporting digital service will not automatically produce unauthorised control over consequential physical processes.

This distinction becomes particularly important when implementation programmes concern industrial estates that cannot tolerate extensive modification, possess limited maintenance windows, depend upon discontinued equipment or lack the financial capacity to replace whole control architectures. In such circumstances, an implementation programme centred principally on deploying technical products may exhaust available resources without addressing the most dangerous operational dependencies. Conversely, a programme that begins by establishing control ownership, understanding the consequences of compromise, identifying critical access paths and validating the behaviour of existing protective arrangements may produce substantial improvements before major replacement expenditure becomes necessary.

The joint CISA, Department of War, Department of Energy, FBI and Department of State guidance published on 29 April 2026 provides a suitable institutional foundation. Its structure follows the six functions of the NIST Cybersecurity Framework 2.0—Govern, Identify, Protect, Detect, Respond and Recover—and explicitly requires Zero Trust implementation to accommodate industrial availability, safety and operational constraints. The guidance also recognises the importance of multidisciplinary governance, risk-informed exceptions, supply-chain considerations and recovery from incidents affecting physical processes.

Adapting Zero Trust Principles to Operational Technology — CISA, Department of War, Department of Energy, FBI and Department of State — April 2026

For a national implementation programme, these six functions should not be treated as six consecutive projects, each completed before the next begins. They constitute interdependent management capabilities. The ability to identify a high-consequence asset informs the decision to restrict access to it; access restrictions require appropriate monitoring and exception procedures; effective monitoring must support operational response; and recovery arrangements must remain feasible under the architecture produced by the security programme.

A programme that completes its inventory before developing any access restrictions could leave an exposed facility unnecessarily vulnerable. A programme that installs restrictive access controls without first establishing emergency maintenance requirements could impair operational resilience. Implementation therefore requires parallel activity governed by consequence-based priorities, with engineering dependencies determining which changes must precede others.

The corresponding requirement for government oversight is to distinguish three levels of evidence: documentation showing that a control has been specified, implementation evidence showing that it has been installed and configured, and operational assurance demonstrating that it performs its intended function under relevant conditions. These levels must not be combined into a single percentage that obscures the difference between technical deployment and actual protection.

The Institutional Baseline: Government Oversight Is Itself an Implementation Constraint

Recent United States government audits provide unusually direct evidence that the difficulties of securing operational technology extend into institutional capacity, asset accountability and regulatory coordination.

The Government Accountability Office’s report of 7 March 2024, Cybersecurity: Improvements Needed in Addressing Risks to Operational Technology, examined CISA’s support for industrial control-system cybersecurity and its cooperation with seven selected federal agencies. GAO reviewed 13 CISA OT cybersecurity products and services, consulted 13 selected nonfederal entities and evaluated interagency coordination.

The findings were not uniformly negative. Twelve of the 13 selected nonfederal entities identified positive experiences with CISA’s OT products and services. Nevertheless, GAO also documented workforce and coordination difficulties. At the time of its review, CISA officials reported that a threat-hunting and incident-response service had four federal employees and five contractor personnel, a staffing arrangement they considered insufficient to respond to major incidents affecting multiple OT locations simultaneously.

This figure describes a particular service at the time examined; it must not be interpreted as the total number of CISA personnel engaged in operational technology cybersecurity.

GAO further found that CISA and its selected partner agencies had not fully addressed the five collaboration practices examined, including common outcomes, accountability, organisational understanding, responsibility allocation and written agreements. These findings are directly relevant to the design of a national Zero Trust programme because infrastructure resilience cannot be achieved solely through requirements placed upon individual operators if the institutions responsible for guidance, technical assistance, coordination and incident response lack clearly established responsibilities.

Cybersecurity: Improvements Needed in Addressing Risks to Operational Technology, GAO-24-106576 — U.S. Government Accountability Office — March 2024

The institutional problem remained relevant in 2026. GAO’s 28 September report on cybersecurity regulatory harmonisation examined views expressed by six industry representatives from energy, financial services and healthcare and public health. Participants identified examples of overlapping or conflicting regulatory obligations, particularly in incident reporting, and described the potential diversion of resources towards multiple compliance processes.

The selected panel cannot establish the prevalence of regulatory duplication across the entire national infrastructure economy. It does, however, document a recognised governance concern: imposing additional cybersecurity requirements without coordinating definitions, reporting channels and evidence expectations can generate administrative burdens that do not necessarily improve industrial protection.

Cybersecurity Regulations: Industry Panelists Identify Duplication and Conflicts and Ways to Address Them, GAO-26-109197 — U.S. Government Accountability Office — September 2026

The consequence for Zero Trust implementation is significant. Government should avoid establishing a new, independent compliance structure whenever an existing sectoral regime can incorporate the necessary technical and operational evidence. The more defensible approach is to define common assurance outcomes and permit competent sector regulators to collect the evidence through existing supervisory arrangements, supplemented where necessary by dedicated industrial cybersecurity assessments.

An Audited Quantitative Baseline: Federal Networked-Device Inventory Performance in September 2026

The strongest recently published quantitative evidence relevant to government implementation concerns inventory completeness rather than the deployment of Zero Trust controls themselves.

On 30 September 2026, GAO reported on the implementation of federal networked-device requirements across 22 civilian agencies covered by the Chief Financial Officers Act. As of September 2026, 15 agencies had established a networked-device inventory, 11 were maintaining their inventories and 10 had included all required information for each device. Only seven agencies had satisfied all three requirements.

These are unusually valuable indicators because they distinguish the creation of an inventory from the more demanding tasks of maintaining it and recording sufficient information. The population includes networked Internet of Things and operational technology devices within the scope of the review; it is not a census of all industrial controllers operated by government or private infrastructure entities.

The reported figures nevertheless demonstrate that even centrally governed federal institutions can encounter significant difficulties maintaining complete information about their networked equipment.

Internet of Things: OMB Action Needed to Ensure Agencies Secure Their Networked Devices, GAO-26-108937 — U.S. Government Accountability Office — September 2026

Table 6.1 — Federal Networked-Device Inventory Implementation

Audited requirement	Agencies satisfying requirement	Total agencies reviewed	Calculated share	Interpretation
Established an inventory	15	22	68.2%	Initial inventory exists
Maintained an inventory	11	22	50.0%	Inventory maintenance requirement satisfied
Included all required information	10	22	45.5%	Required asset information recorded
Satisfied all three requirements	7	22	31.8%	Complete compliance with the three assessed inventory requirements

Shares calculated from GAO’s published counts, rounded to one decimal place. The percentages refer to 22 reviewed federal agencies, not the proportion of devices inventoried or the national prevalence of secure OT equipment.

The 31.8% result is especially consequential for programme design. It illustrates that administrative evidence of inventory creation can substantially overstate the maturity of the underlying asset-management process. A regulator that asks whether an operator has an inventory may obtain an affirmative answer without knowing whether the inventory is current, complete or operationally useful.

For a high-consequence industrial environment, this limitation is greater still. An inventory can satisfy conventional device-recording requirements while failing to identify the physical function an asset supports, which maintenance workstation can reprogram it, what network connections are necessary and whether a safe operating alternative exists following loss of the device.

The policy implication is that infrastructure regulators should establish a progression from basic inventory existence to verified operational dependency coverage. Reporting should distinguish assets merely discovered through network tools from assets whose critical functions, permitted communications, support arrangements and recovery requirements have been validated by responsible engineers.

The same GAO report recommended that the Office of Management and Budget issue updated guidance for networked IoT and OT devices and provide oversight of implementation. As of the report’s publication, that recommendation remained open. This establishes a concrete government action point, rather than a hypothetical need for better asset governance.

A Consequence-Based Implementation Model for Ageing Industrial Estates

A national Zero Trust implementation programme should begin by classifying industrial functions according to the consequences that would follow from their loss, manipulation or prolonged unavailability. This classification must be independent of the apparent technological sophistication or age of individual components.

A recently installed controller supporting an essential safety-related process may deserve more stringent assurance than an older, isolated device whose failure would have limited local effects. Conversely, a legacy controller that remains internet-accessible and can change a high-consequence physical condition may require urgent intervention even if it has operated without incident for many years.

The key variables are the severity of credible consequences, the practical reachability of the relevant functions, the authority available following compromise, the effectiveness of existing safeguards and the feasibility of recovery.

These variables should be evaluated separately before producing an overall decision. An organisation should not be permitted to conceal a severe unresolved hazard by averaging it with favourable results elsewhere in the facility.

An effective programme would establish an individual protection and modernisation decision for each high-consequence process, supported by a documented chain connecting identified assets, communication dependencies, credible compromise pathways, existing safeguards, proposed interventions and validation outcomes.

Table 6.2 — Consequence-Based Priority Classes

Priority class	Defining condition	Required management response	Acceptable basis for deferral
Critical intervention	Credible cyber pathway to severe physical consequences with ineffective safeguards	Immediate senior escalation and technically safe interim restrictions	Only documented safety constraints with explicit alternative protection
High priority	Material consequence and exploitable or insufficiently governed access	Time-bound remediation plan with accountable owner	Validated compensating controls and formal residual-risk acceptance
Elevated	Consequential asset with uncertain dependencies or incomplete control assurance	Accelerated discovery and controlled validation	Demonstrated containment pending further investigation
Managed	Documented exposure with effective tested controls	Scheduled improvement and periodic reassessment	Current evidence that safeguards remain effective
Modernisation candidate	Structural security limitations make long-term protection unsustainable	Capital programme and replacement planning	Temporary compensation within a defined expiry period
Monitoring priority	Limited immediate consequence but potentially important dependency	Maintain visibility and verify material changes	Evidence that classification remains accurate

This classification is an analytical governance instrument, not an official NSA or CISA risk scale. The classes require locally defined consequence thresholds and must be applied consistently across the population being assessed.

The distinction between high-priority intervention and modernisation candidacy is particularly useful. A facility may require an immediate restriction on remote access while replacement of the underlying controller remains a multiyear engineering project. Treating these actions as one project can delay urgently needed protections until capital investment becomes available.

The First Thirty Days: Establishing Authority, Critical Exposure and Immediate Containment

The initial thirty-day period should be understood as an executive mobilisation phase, not a commitment to complete comprehensive Zero Trust transformation. Its purpose is to establish accountable decision-making and reduce the most obvious consequential exposure without destabilising operating systems.

The programme should designate a senior executive sponsor with responsibility for the protection of essential physical functions, identify the engineers authorised to approve changes and establish a formal mechanism for resolving disagreements between cybersecurity, production and safety requirements. These arrangements should be documented because ambiguous authority can become particularly dangerous during emergency maintenance or an active incident.

The same phase should identify facilities and processes whose interruption would create the greatest service, safety or national security consequences. That selection can draw upon existing business continuity assessments, safety studies, sectoral criticality classifications and engineering documentation, supplemented by targeted verification.

Operators should then establish a register of known external maintenance pathways, privileged engineering access, directly exposed management interfaces and critical vendor dependencies. The immediate objective is to determine whether any account or connection possesses access that is plainly inconsistent with its legitimate operational purpose.

Where a dangerous access path is identified, the operator should introduce a technically safe restriction rather than wait for completion of the full programme. Such intervention must nevertheless be approved through the applicable operational process, particularly when connectivity is required for emergency maintenance.

The first thirty days should also establish the reporting format for residual-risk exceptions. Each exception should identify the relevant physical function, the control that cannot yet be implemented, the reason for the limitation, the temporary safeguards, the responsible executive and the date at which continued acceptance must be reconsidered.

A generic statement that a device is too old to secure should not constitute an acceptable risk exception. The exception must explain what exposure remains and why the proposed interim arrangement is tolerable.

Table 6.3 — Initial Thirty-Day Implementation Commitments

Deliverable	Accountable authority	Minimum evidence	Completion criterion
Programme mandate	Executive sponsor	Approved scope and responsibilities	Authority to coordinate OT, IT and safety decisions established
Critical-function shortlist	Operations executive	Consequence-based selection record	High-consequence functions identified for initial assessment
Remote-access exposure register	OT security lead and engineering owner	Connections, providers, purposes and permissions	Uncontrolled known external paths identified
Privileged engineering access review	OT engineering manager	User, workstation and controller access records	Excessive privileges escalated or restricted
Immediate risk-exception register	Risk executive	Exposure, consequence, safeguards and expiry	Every material deferred intervention has accountable acceptance
Incident escalation arrangement	Operations and incident-response leadership	Contact and decision-authority record	Technical and operational responsibilities established
Initial recovery dependency assessment	Engineering and continuity teams	Available configurations, tools and supplier contacts	Critical recovery limitations identified
Government reporting baseline	Regulator or designated programme office	Consistent data definitions	Operators can report comparable implementation status

The proposed thirty-day period is a policy planning interval rather than an official requirement established by the NSA’s activity framework. Facilities facing an immediate, confirmed high-consequence exposure should act sooner, subject to safe execution.

Days Thirty-One to Ninety: Converting Initial Protection into Verified Operational Boundaries

The second phase should concentrate on converting preliminary asset knowledge into enforceable and testable restrictions. Its distinguishing characteristic is the movement from identifying the existence of access relationships to demonstrating that they are limited to authorised functions.

The operator should reconcile network observations with engineering records and confirm the communications necessary for the selected high-consequence processes. Particular attention should be given to connections that cross operational zones, access to engineering workstations, shared services and routes through which external suppliers can reach production equipment.

This phase should also establish a controlled process for approving privileged maintenance. Where feasible, the process should associate each session with a named person, approved work order, designated destination, permitted operation and limited duration. The objective is not to increase the number of administrative approvals but to make the authority exercised through each connection explicit and reviewable.

Segmentation improvements should then be introduced according to verified dependencies. It is essential that the relevant communications matrix be confirmed before restrictive network rules are applied. Changes should be staged, reversible where technically feasible and subject to observation for unintended effects.

A meaningful result at the ninety-day point would be a documented set of high-consequence processes for which the operator can identify the principal ingress paths, demonstrate the restrictions applied to those paths and explain how necessary local operations continue if the relevant access-management infrastructure fails.

This level of assurance may remain incomplete for older or poorly documented estates. The programme should report the uncertainty openly rather than describe an untested architecture as fully implemented.

Days Ninety-One to One Hundred Eighty: Demonstrating Compromise Containment and Recoverability

The third phase should move from control deployment into operational validation. At this stage, the relevant question is whether the controls perform as intended when selected assumptions of trust are deliberately removed under controlled test conditions.

A representative exercise may examine whether an approved test account can access an unapproved controller, whether an engineering workstation can communicate outside its designated zone, whether remote maintenance permissions expire as intended or whether an identity-service failure affects necessary local operations.

For particularly sensitive systems, validation may require a representative test environment, simulation or carefully bounded test that does not send potentially disruptive commands to live equipment. The evidentiary limitation of such testing must be recorded: a successful laboratory demonstration does not establish identical behaviour in every operating facility.

The same period should establish restoration evidence for critical configurations and supporting services. Operators should verify that essential recovery files remain available, that the necessary engineering tools can be used and that restoration does not depend upon inaccessible supplier systems or credentials.

The output should be a structured assurance package describing each tested scenario, its engineering assumptions, the expected protective behaviour, the observed result, any deviations and the residual consequences. This package should become the principal source of evidence for management and regulatory assessment.

Table 6.4 — Consolidated 30/90/180-Day Implementation Roadmap

Period	Programme objective	Principal deliverables	Validation requirement	Main decision at period end
Days 1–30	Establish authority and reduce urgent exposure	Governance charter, critical-function register, privileged-access review, exception register	Verify urgent restrictions do not interrupt essential operations	Which exposures require immediate escalation?
Days 31–90	Establish controlled industrial boundaries	Dependency maps, approved access policies, segmented pathways, engineering permissions	Confirm permitted and denied access behaviour	Which functions have demonstrably bounded access?
Days 91–180	Verify containment and recovery	Controlled exercises, configuration integrity evidence, restoration tests, corrective plans	Test compromise scenarios and safe recovery conditions	Which residual risks require capital modernisation?
Months 6–12	Institutionalise assurance	Repeatable evidence collection, supplier governance, procurement rules	Periodic review of exceptions and controls	Which protections can become normal operating requirements?
Years 2–3	Modernise consequential dependencies	Replacement or upgrade of priority systems, improved recovery independence	Commissioning and operational assurance	Which structural vulnerabilities remain unacceptable?
Years 4–5	Sustain and renew	Lifecycle management, renewed architecture and supplier obligations	Independent periodic assurance and change-triggered review	Is protection keeping pace with technology and operational change?

These intervals are proposed sequencing assumptions. They should be adjusted for asset criticality, maintenance opportunities, regulatory requirements and available engineering capacity.

Multiyear Modernisation: Engineering Programmes Must Be Sequenced Around Industrial Replacement Opportunities

Beyond the initial 180 days, the programme should shift from correcting immediately addressable weaknesses towards removing structural dependencies that cannot be sustainably protected. This stage requires integration with capital expenditure planning, industrial maintenance programmes, supplier contracts and the long-term renewal of infrastructure assets.

A central limitation of short cybersecurity programmes is that they are frequently funded independently of industrial equipment renewal. Security teams may receive resources to purchase monitoring and access-management products while the replacement of controllers, engineering workstations and associated applications remains governed by a separate capital process. The result can be a growing collection of intermediary protections surrounding equipment whose underlying limitations remain unresolved.

A more effective model incorporates cybersecurity requirements into scheduled industrial refurbishment, safety-system upgrades, digital transformation projects and equipment obsolescence programmes. Where a planned shutdown already requires significant engineering activity, the opportunity to replace unsupported controllers or introduce modern communication interfaces may be substantially more attractive than undertaking a separate interruption solely for cybersecurity purposes.

This does not imply that operators should defer urgent protections until major refurbishment occurs. Rather, interim controls should be explicitly connected to the future engineering programme that is expected to eliminate the underlying weakness.

Each significant compensating arrangement should therefore possess a documented lifecycle status. Some controls may remain appropriate indefinitely because they provide valuable defence-in-depth even around modern equipment. Others are temporary measures whose effectiveness, supportability or operational complexity will deteriorate over time. These should be assigned review dates, replacement dependencies and capital-planning responsibilities.

A five-year programme must also recognise that not every industrial system will be replaced within the planning horizon. The objective is to establish an evidence-based distinction between equipment that can remain safely protected, equipment requiring planned renewal and equipment for which continued operation under existing conditions creates unacceptable residual consequences.

Table 6.5 — Five-Year Capital and Operational Modernisation Programme

Planning horizon	Engineering investment focus	Cybersecurity outcome	Capital decision	Principal programme dependency
Year 1	Critical access and recovery infrastructure	Restrict immediate exposure and establish defensible assurance	Fund controls with near-term protective value	Reliable process and dependency information
Year 2	Unsupported engineering environments and shared services	Reduce concentrated administrative authority	Replace or isolate high-risk support platforms	Application and vendor compatibility
Year 3	Controllers and gateways with irreducible weaknesses	Remove high-consequence legacy exposure	Coordinate modular upgrades with planned shutdowns	Commissioning resources and operating windows
Year 4	Interoperability, configuration integrity and industrial telemetry	Improve lifecycle security and operator independence	Consolidate modernised architectures	Secure procurement and supplier performance
Year 5	Remaining systemic dependencies and renewal cycle	Establish sustainable protection and future replacement planning	Integrate cyber requirements into ordinary capital renewal	Audited residual-risk evidence

The five-year horizon is an analytical planning convention, not a prediction that all industrial modernisation can be completed within five years. Major infrastructure programmes may require longer implementation, particularly where replacement interacts with safety certification, grid operation, transport signalling or continuous industrial production.

Government Decision Rights and the Required Separation of Responsibilities

A national implementation programme requires a governance structure capable of resolving disagreements among cybersecurity specialists, infrastructure engineers, financial authorities, regulators and executive management. Without that structure, even technically sound measures may fail because responsibility for approving changes or accepting residual risk remains unclear.

At the operator level, the governing board or designated senior accountable executive should own the organisation’s aggregate risk exposure and capital response. The chief information security officer or equivalent cybersecurity executive should be responsible for identifying digital threats, evaluating protective mechanisms and reporting their effectiveness. OT engineering management should retain authority over the technical conditions necessary for safe and reliable process operation. Functional-safety specialists should determine whether proposed modifications affect established safety requirements.

Procurement and supplier management must then convert these technical requirements into enforceable contractual provisions, while operations management coordinates implementation within actual maintenance and production constraints.

At the government level, sector regulators should determine the evidence needed to establish compliance with applicable obligations, whereas national cybersecurity authorities should support common technical guidance, threat information and incident coordination within their mandates. Defence and national security authorities may require additional arrangements for designated systems and mission-critical industrial dependencies.

A critical principle is that responsibility for cybersecurity investment must not be confused with authority to approve a change affecting a physical process. A cybersecurity executive may identify an unacceptable risk, but the method of intervention must still pass the appropriate engineering and safety review.

Table 6.6 — Governance and Decision-Authority Matrix

Decision	Accountable authority	Required participants	Evidence for approval	Escalation condition
Approve OT cyber risk tolerance	Board or designated executive	Operations, cyber, safety and risk leadership	Consequence assessment and accepted exposure	Potential severe safety or essential-service consequence
Prioritise critical assets	Operations executive	Engineering, cyber and continuity teams	Process criticality and dependency records	Disagreement over consequence classification
Restrict supplier access	OT access owner	Cybersecurity and maintenance management	Approved task and access policy	Restriction prevents essential maintenance
Approve segmentation changes	OT engineering authority	Network security and system integrator	Validated communication dependencies	Risk to control or protective functions
Authorise controller configuration change	Responsible engineering authority	Maintenance and safety specialists as applicable	Approved change package and test evidence	Material change to operating or safety conditions
Accept temporary security exceptions	Senior risk owner	Engineering, cyber and safety	Residual-risk statement and compensating evidence	Risk exceeds approved tolerance
Approve equipment replacement	Capital investment authority	Engineering, finance, procurement and cyber	Lifecycle business case and implementation plan	Irreducible high-consequence vulnerability
Authorise emergency access	Designated operational authority	Incident command and technical specialists	Emergency procedure and contemporaneous record	Essential operations cannot be maintained
Report material incidents	Legally responsible operator	Legal, operations, cyber and regulatory teams	Validated incident facts and applicable reporting rules	Statutory reporting threshold is met
Certify restoration to service	Responsible operations/engineering authority	Safety, cyber and maintenance teams	Trusted configuration and operating verification	Residual uncertainty affecting physical safety

This model is a proposed accountability framework. Statutory duties, delegated authorities and formally approved safety responsibilities take precedence over generic organisational titles.

Regulatory Oversight: From Documentary Compliance to Operational Assurance

The effectiveness of national Zero Trust policy depends substantially upon how regulators assess implementation.

Traditional compliance processes often rely on written policies, control inventories, periodic audits and declarations that required technical measures have been deployed. These remain necessary, but they can fail to identify whether a compromise could reach consequential industrial functions.

An operator may produce evidence that privileged-access management exists without demonstrating that all relevant vendor paths pass through it. An inventory may list every identified controller without documenting the controllers’ physical consequences. A recovery policy may be formally approved despite the absence of a successful restoration exercise.

An effective regulatory model should distinguish documentary conformity from tested operational effectiveness.

For the highest-consequence installations, regulators should require evidence that control boundaries correspond to actual communications, that access permissions match documented operational responsibilities and that the organisation can maintain or restore essential functions following relevant failures.

This should not require regulators to conduct intrusive cybersecurity testing against live industrial systems. Rather, operators should be permitted to demonstrate assurance using approved engineering test environments, witnessed commissioning evidence, controlled exercises and other methods appropriate to the installation.

Regulatory requirements should also be proportionate to the operator’s resources and physical consequences. A small water utility cannot reasonably be expected to maintain the same internal cybersecurity organisation as a major electricity transmission operator, although both may need to demonstrate basic access accountability, asset knowledge and credible recovery capability.

The importance of this distinction is reinforced by GAO’s May 2026 testimony concerning water and wastewater cybersecurity. GAO reported that the United States water sector encompasses close to 170,000 water and wastewater systems, while operators exhibit widely differing cybersecurity capabilities, staffing and financial resources. It also identified limitations in EPA’s legal authority to require certain cybersecurity risk assessments, distinguishing the technical need for protection from the powers available to enforce it.

Critical Infrastructure Protection: Actions Needed to Address Persistent Cybersecurity Threats to the Water and Wastewater Sector, GAO-26-109159 — U.S. Government Accountability Office — May 2026

The figure describes the scale of the sector, not the number of insecure or compromised systems. Its policy significance lies in the challenge of developing effective national oversight across a highly diverse operator population.

Sector-Specific Regulatory Implementation Considerations

Sector	Principal implementation constraint	Appropriate regulatory emphasis	Required technical evidence	Potential government support
Electricity transmission	System reliability, protection and interconnection dependencies	Consequence-based cyber-physical assurance	Protection independence, configuration control and recovery	Sector coordination and specialised testing
Electricity distribution	Dispersed substations and varied operator resources	Access governance and restoration readiness	Remote asset coverage and controlled maintenance	Common guidance and utility cooperation
Water and wastewater	Fragmented ownership and constrained budgets	Essential protective practices and practical technical assistance	External access controls, process ownership and recovery	Grants, regional support and shared services
Rail transport	Signalling integrity and safety lifecycle	Controlled engineering changes and tested separation	Safety compatibility and system configuration assurance	Coordination with transport safety authorities
Ports and maritime facilities	Diverse systems and multiple commercial operators	Interdependency and supplier-access governance	Terminal control dependencies and external service access	Port-level coordination and common exercises
Food and agriculture	Distributed equipment and seasonal operating patterns	Risk-based access and essential-service continuity	Remote maintenance and process recovery	Sector-specific tools and supplier engagement
Hospitals	Continuous clinical activity and facility dependencies	Backup power and essential facility-function assurance	Engineering resilience and emergency operation	Health-sector coordination and technical assistance
Government facilities	Shared management systems and mission-dependent operations	Common services, access control and mission criticality	Facility dependency and networked-device inventories	Central procurement and shared assurance
Defence production	Sensitive processes and mission-delivery dependencies	Supplier security and verified production integrity	Engineering access, configuration integrity and recovery	Defence-specific oversight and contractual requirements

The table identifies areas for regulatory emphasis, not a statement that identical obligations already exist across these sectors.

European Regulatory Implications and the Need for Comparable Assurance

For the European Union, the implementation challenge must be addressed through the applicable cybersecurity and critical-entity resilience frameworks rather than direct adoption of United States defence requirements as binding law.

Article 21 of Directive (EU) 2022/2555, commonly known as NIS2, establishes cybersecurity risk-management measures for entities within its scope. These include risk analysis, incident handling, continuity and disaster recovery, supply-chain security, secure acquisition and maintenance, effectiveness assessment, access-control policies, asset management and authentication measures where appropriate.

The significance for Zero Trust is that many relevant management outcomes are already recognised within the legal framework, even though the Directive does not prescribe one universal industrial Zero Trust architecture.

Directive (EU) 2022/2555, Article 21 — European Parliament and Council — December 2022

The policy priority is therefore not necessarily to create an entirely new set of regulatory obligations labelled Zero Trust. It is to ensure that existing cybersecurity duties are interpreted and assessed through evidence appropriate to industrial operations.

Italy, France and Germany must implement relevant European requirements through their respective domestic legal and institutional arrangements. The United Kingdom requires separate assessment under its own regulatory system. Differences in national implementation and sector supervision matter, and the same technical practice cannot automatically be assigned an identical legal status in all four countries.

Across these jurisdictions, common assurance terminology would nevertheless improve comparability. Regulators could seek compatible definitions of verified external-access control, operational asset coverage, tested recovery, time-bound exceptions and validated industrial network boundaries, while allowing the actual engineering implementation to reflect local requirements.

This approach would reduce the risk that operators must produce multiple incompatible cybersecurity assessments for essentially the same protective outcomes.

Measuring Outcomes: Why Control Completion Rates Are Not Enough

A national programme should produce indicators that allow policymakers to distinguish implementation progress from genuine changes in exposure.

The most useful indicators combine coverage, effectiveness, operational compatibility and recoverability. Each requires a precise definition of the population measured and the evidence needed to treat a control as valid.

For example, reporting that 90% of industrial assets are inventoried may be misleading if the remaining 10% includes the highest-consequence controllers. Reporting that 100% of remote access uses multifactor authentication may be misleading if unrecorded vendor connections remain outside the measured population.

A sound indicator must therefore identify both the numerator and denominator, the criticality of excluded assets and the confidence associated with the underlying inventory.

Table 6.7 — Proposed National OT Zero Trust Performance Indicators

Indicator	Measurement definition	Principal evidence	Interpretation limitation
Critical asset inventory coverage	Verified critical assets / estimated total critical assets	Reconciled inventory and engineering records	Denominator may be incomplete
Process dependency completeness	Critical processes with validated dependency maps / assessed critical processes	Engineering-approved maps	Does not prove dependency resilience
Controlled external access coverage	Known external access paths under approved governance / all discovered external paths	Gateway and access review	Undiscovered paths remain outside denominator
Privileged identity accountability	Privileged activity attributable to approved individual or service identities / assessed privileged activity	Identity and session records	Shared application credentials may reduce attribution
Verified segmentation coverage	Critical zones with successful boundary tests / zones selected for testing	Approved validation reports	Results apply to tested paths and conditions
Configuration integrity coverage	Critical controllers with trusted, verifiable configuration baselines / assessed critical controllers	Engineering repositories and comparisons	Snapshot integrity may not be continuously assured
Recovery validation rate	Critical functions successfully restored in approved exercises / functions scheduled for testing	Exercise records	Test fidelity varies
Unresolved critical exceptions	Count of accepted high-consequence exceptions beyond approved review date	Risk-exception register	Count alone ignores severity
Time to revoke supplier access	Elapsed time from valid revocation decision to effective denial	Session and access-control logs	Depends on system availability and test conditions
Containment effectiveness	Tested scenarios in which prohibited access was prevented / completed relevant scenarios	Negative-access tests	Scenario coverage must be disclosed
Security-induced operational disruption	Documented process disturbances caused by security changes	Change and incident records	Underreporting may distort comparisons
Independent recovery capability	Critical functions restorable without unavailable supplier dependencies / assessed functions	Restoration exercises	Independence may vary by failure scenario

These indicators should not be combined into an unweighted national Zero Trust score. Doing so would conceal the differing significance of the protected processes and permit favourable results in lower-consequence environments to compensate numerically for serious unresolved exposure elsewhere.

A more defensible supervisory dashboard would report implementation coverage alongside explicit unresolved high-consequence exceptions, preserving the distinction between progress and unacceptable residual risk.

Residual Risk Acceptance and the Threshold for Accelerated Modernisation

A central difficulty in industrial cybersecurity governance concerns determining when compensating controls are no longer sufficient.

The decision should be driven by the consequences of plausible compromise, the effectiveness of available protective measures and the organisation’s ability to restore the affected process, rather than by a fixed equipment age.

Accelerated modernisation becomes particularly important when the operator cannot credibly restrict privileged access, when unavoidable communications permit unacceptable lateral movement, when a critical controller’s configuration cannot be verified or when recovery depends on unsupported tools that may be unavailable during an incident.

The presence of an independent safety function may reduce particular physical consequences, but it does not automatically eliminate the need for control-system modernisation. The relationship between the compromised system and the protective function must be demonstrated through engineering evidence.

Similarly, the absence of a documented incident does not establish that the remaining risk is acceptable. It may reflect limited attacker interest, effective existing controls or inadequate monitoring. Risk acceptance must therefore be based on the available engineering evidence and credible exposure pathways rather than incident history alone.

Table 6.8 — Escalation Conditions for Mandatory Executive Review

Condition	Why it matters	Required decision
Critical equipment is directly accessible from untrusted networks	Exposes consequential functions without adequate boundary protection	Immediate safe restriction or approved exceptional operation
Supplier access cannot be revoked or limited	Operator lacks effective authority over external intervention	Redesign access arrangement or escalate replacement
Controller integrity cannot be established after compromise	Safe continued operation may be uncertain	Determine necessary isolation, investigation or restoration
No credible recovery method exists	Incident may produce prolonged operational consequences	Accelerate recovery investment or system modernisation
Safety-related communications depend on an unvalidated security component	Protective behaviour may be affected by cybersecurity failure	Require engineering and safety review
Repeated testing demonstrates segmentation bypass	Intended containment is ineffective	Correct architecture and reassess residual exposure
Manufacturer support is unavailable for a critical exploitable weakness	Long-term vulnerability correction may be impossible	Consider restrictive compensation and accelerated replacement
Critical exception persists beyond approved expiry	Governance has failed to resolve known exposure	Escalate to senior accountable authority
AI or analytical service acquires unapproved control authority	New indirect pathway to physical manipulation	Suspend unauthorised capability and redesign permissions

Chapter 6 — Key Judgments

The implementation of Zero Trust in ageing operational technology should be governed through a programme that distinguishes immediate exposure reduction, medium-term assurance and long-term removal of structural vulnerabilities. The initial 30/90/180-day sequence provides a practical planning framework, but engineering consequences and actual maintenance opportunities must determine implementation timing.

The strongest institutional evidence indicates that asset accountability, government coordination and regulatory consistency remain significant challenges. GAO’s September 2026 inventory audit found that only seven of 22 reviewed civilian federal agencies had fully satisfied all three assessed networked-device inventory requirements. This is a directly documented implementation gap, although it is not a measure of national OT Zero Trust maturity.

The most useful national performance indicators are those that establish whether critical access paths are governed, boundaries perform as intended, recovery is feasible and unresolved high-consequence vulnerabilities are subject to accountable decisions.

There is high confidence that consequence-based governance and operational validation provide a more defensible basis for national oversight than product deployment counts alone. There is moderate confidence in the proposed implementation intervals, which must be adapted to the operating characteristics and engineering resources of individual facilities.

What Would Change the Chapter 6 Assessment

The assessment would change if representative implementation programmes demonstrated that a different sequence produces substantially stronger containment and recovery outcomes without increasing operational disruption. Comparable data on engineering costs, maintenance opportunities, control effectiveness and time to restore operations would permit more precise regulatory guidance.

The principal unresolved requirement is a national evidence architecture capable of connecting industrial asset exposure, implementation maturity and the observed consequences of compromise. That requirement forms the subject of the final chapter.

Chapter 7. Evidence Architecture, Analytical Methods and Priority Intelligence Questions

Principal Strategic Judgment: Governments Cannot Regulate the Effectiveness of OT Zero Trust Without Measuring Exposure, Physical Consequences and Verified Control Performance Separately

The principal intelligence deficiency confronting governments responsible for protecting operational technology is not the absence of cybersecurity frameworks or technical recommendations. It is the limited availability of comparable evidence demonstrating how vulnerabilities, access relationships, installed protective controls and physical-process dependencies combine to determine actual infrastructure risk. Until these elements can be measured consistently, government authorities will remain better equipped to describe what operators should implement than to establish whether those interventions materially reduce the consequences of a successful compromise.

This distinction is fundamental to the development of a national assurance regime. A regulator may know that a substantial number of organisations have adopted multifactor authentication, established network segmentation policies or introduced formal cyber risk-management procedures. Such information describes implementation activity. It does not independently establish whether attackers can still reach high-consequence controllers, whether privileged maintenance channels permit unauthorised configuration changes, whether protective systems remain independent, or whether an operator can restore an essential service following compromise of its engineering environment.

The evidentiary challenge is particularly severe for ageing industrial technology because conventional cybersecurity datasets provide an incomplete representation of the relevant physical environment. Vulnerability databases may identify weaknesses affecting particular products, but they do not establish how those products are configured, which processes they control, whether they are reachable through an exploitable pathway or what independent safeguards limit the consequences of compromise. Incident reporting may document disruption but omit the actual controller configuration, supplier relationship or engineering dependency that permitted the event. Asset inventories may record device ownership while excluding information about operational authority and process consequences.

The April 2026 interagency guidance provides an appropriate methodological starting point because it explicitly links asset identification, risk assessment, threat modelling, cyber-physical consequences, detection, response and recovery. Its organisation around the NIST Cybersecurity Framework 2.0 is relevant because it treats cybersecurity as a continuous risk-management process rather than a finite list of installation activities.

Adapting Zero Trust Principles to Operational Technology, Sections Identify, Detect, Respond and Recover — CISA and Partner Agencies — April 2026

The corresponding government intelligence requirement is to construct an evidence system that connects four questions: which essential physical functions are exposed, how a hostile actor might acquire authority over them, which safeguards prevent unacceptable consequences, and whether those safeguards have been validated under relevant operating conditions.

The answer must remain sensitive to differences between sectors, equipment generations, national legal frameworks and the circumstances under which operational data can safely be collected.

Establishing a Hierarchy of Primary Evidence

A rigorous national assessment should distinguish authoritative technical standards, government threat intelligence, incident investigations, manufacturer evidence, operator records and analytical inference.

These categories answer different questions and should not be treated as interchangeable.

NIST publications establish architectural principles, control considerations and recognised risk-management approaches. CISA and partner advisories provide authoritative statements concerning observed threats, relevant vulnerabilities and recommended defensive measures. GAO audits establish findings concerning the implementation and oversight of government programmes within the populations examined. Manufacturer documentation may establish the capabilities and support conditions declared for specific equipment, although those claims may require independent testing. Operator records supply installation-specific facts that public guidance cannot establish, including actual controller configuration, process dependencies and maintenance arrangements.

The evidentiary problem becomes significant when material from one category is used to support a conclusion belonging to another.

A technical standard recommending a particular security practice does not establish that the practice has been deployed. A manufacturer’s declaration that a controller supports authenticated communications does not establish that authentication has been enabled in the operating facility. An incident report describing compromise of a particular device population does not establish the national prevalence of that vulnerability.

A decision-grade assessment must preserve these distinctions at every stage.

Table 7.1 — Primary Evidence Architecture for National OT Assurance

Evidence class	Primary institution or holder	Principal analytical use	Necessary validation	Main limitation
NSA cybersecurity information sheets	NSA	Defence-related threat and protection priorities	Confirm actual recommendations and document version	Does not establish universal civilian implementation
CISA interagency OT guidance	CISA and partner agencies	Practical OT Zero Trust considerations	Identify relevant provisions and technical scope	Guidance does not demonstrate field effectiveness
NIST SP 800-207	NIST	Zero Trust architecture and logical policy model	Translate architecture to actual resources	Not an installation-specific engineering design
NIST SP 800-82	NIST	OT security and operational constraints	Apply appropriate final or draft version	General guidance requires local adaptation
ISA/IEC 62443	Standards bodies and applicable certification authorities	Industrial cybersecurity lifecycle and requirements	Confirm edition, adopted part and assessment scope	Compliance evidence varies by component and system
CISA/DOE sector guidance	Competent sector agencies	Sector-specific defensive expectations	Verify sector and applicability	May not represent binding requirements
Government audits	GAO and national audit institutions	Implementation gaps and programme performance	Check audited population and reference period	Findings may not generalise beyond audited cases
Manufacturer technical records	Equipment vendors	Product functions, support and vulnerabilities	Verify installed version and actual configuration	Manufacturer claims are not independent field tests
Operator asset records	Infrastructure owners	Equipment population and installed dependencies	Reconcile with engineering and physical evidence	May be incomplete or outdated
Engineering change records	Operators and system integrators	Configuration history and technical authority	Compare with trusted baselines	Informal changes may be absent
Incident investigations	Competent authorities and affected operators	Observed attack paths and actual consequences	Establish sequence and causal evidence	Reporting may omit sensitive technical detail
Operational validation reports	Operators, laboratories and assessors	Demonstrated performance of controls	Review test coverage and independence	Results apply to tested conditions

The hierarchy should distinguish documentary authority from empirical reliability. A government-issued document may be authoritative concerning official policy but insufficient to establish that a security technology performs as intended in a particular installation. Conversely, an operator’s controlled engineering test may provide strong evidence about one deployment without supporting a national-level generalisation.

A Current Government Evidence Gap: Inventory Compliance Does Not Establish Operational Security

The September 2026 GAO findings concerning federal networked-device inventories have implications beyond the numerical results presented in Chapter 6. They demonstrate the importance of distinguishing the existence of a reporting system from the completeness and usefulness of the underlying information.

GAO found that only seven of 22 reviewed civilian federal agencies had fully satisfied the three assessed inventory requirements, despite federal instructions to identify and maintain information about networked devices. The report further identified gaps in updated central guidance and oversight.

Internet of Things: OMB Action Needed to Ensure Agencies Secure Their Networked Devices, GAO-26-108937 — September 2026

The methodological lesson is that government reporting systems should not assume that assets absent from a database do not exist.

Unknown equipment must be treated as an uncertainty in the denominator, not as a secure or irrelevant portion of the installed estate.

This has substantial consequences for quantitative assessments. If an operator has identified 900 devices and placed 850 under a particular access-management programme, it might report 94.4% coverage. That value would describe coverage of the known inventory only. If additional assets remain undiscovered, the percentage could overstate actual coverage. More importantly, if the unidentified or unprotected equipment includes high-consequence controllers, the percentage could provide a misleading impression of operational resilience.

National measurement therefore requires explicit disclosure of inventory completeness and the methods used to establish it.

Developing a National Operational Technology Exposure Census

A national OT exposure census should not attempt to collect every technical detail of every industrial device into one central repository. Such an approach could create administrative burdens, sensitive-information concentrations and data-quality problems without necessarily improving risk understanding.

Instead, governments should establish a common set of essential variables that competent sector authorities can collect according to their mandates and the sensitivity of the relevant installations.

The census should distinguish the number of operators, facilities, critical physical functions, significant control systems and consequential remote-access pathways. These are separate units of analysis and must not be combined without careful definition.

A single operator may control numerous facilities. A facility may depend on several control systems. A control system may contain hundreds of devices. Multiple devices may support one critical physical function, while one shared workstation or communication gateway may influence several functions.

Counts at one level cannot be substituted for counts at another.

The census should also distinguish equipment that is merely old from equipment that is unsupported, incapable of necessary security functions, actually exposed through relevant access paths or responsible for particularly consequential operations.

Table 7.2 — Minimum National Exposure Dataset

Variable	Unit of analysis	Recommended classification	Purpose
Operator identity and sector	Operator	Sector and regulatory jurisdiction	Establish reporting coverage
Facility classification	Facility	Essential-service and consequence category	Establish operational significance
Critical physical function	Function	Service delivered and consequence of interruption	Link cybersecurity to public outcomes
Control-system type	System	PLC, DCS, SCADA, BAS, safety-related or other	Identify architecture
Device population	Device	Verified count by applicable class	Establish equipment denominator
Support status	Device or system	Supported, limited support, unsupported, unknown	Identify lifecycle exposure
Native authentication capability	Device or interface	Available and enabled, available but disabled, unavailable, unknown	Assess access-control limitations
Logging capability	Device or system	Relevant events recorded, limited records, unavailable, unknown	Assess investigative visibility
External access	Pathway	Managed, unmanaged, prohibited, unknown	Assess intrusion opportunity
Supplier dependency	Product or service	Operator-controlled, shared, supplier-controlled	Assess third-party influence
Configuration integrity	Critical asset	Verified baseline, incomplete baseline, unknown	Assess manipulation detection
Recovery status	Critical function	Tested, documented only, unavailable, unknown	Assess recoverability
Independent safeguards	Physical process	Verified, partially verified, unknown	Assess consequence limitation
Last assurance test	Control boundary	Date, scope and result	Establish evidence currency
Residual-risk exception	Exposure	Owner, expiry and consequence classification	Establish accountability

The collection of these variables should be proportional to the sensitivity and consequence of the installation. Detailed architecture drawings, administrator credentials and complete controller configuration files should not be routinely transferred to broadly accessible national databases merely to demonstrate compliance.

A more defensible system would permit operators to retain sensitive engineering evidence while reporting standardised results and making detailed records available to authorised assessors under appropriate controls.

Mapping Cyber Dependencies to Physical Consequences

Cyber dependency analysis must establish which digital components are necessary for the operation, supervision, protection and recovery of each essential physical function.

The method begins with the physical process rather than the network topology.

For a critical water-treatment function, the relevant analytical object might be the ability to maintain a required treatment condition. The assessment would identify controllers, instruments, operating stations, communications services, power supplies, engineering applications and protective functions necessary for maintaining that condition.

For an electrical facility, the relevant object might be the ability to preserve a defined operational capability while maintaining required protection behaviour. The assessment would then identify the supervisory, control and protection dependencies associated with that function.

The critical distinction is between components whose loss affects observation, components whose loss affects ordinary control and components whose compromise could alter safety-related behaviour.

This method permits the same digital asset to be evaluated differently depending on the physical functions it supports.

It also allows the analyst to identify shared dependencies that may create common-mode exposure. If several critical processes require the same engineering server for restoration, that server becomes important even if it does not normally participate in live control. If multiple facilities depend upon a common remote-access service, compromise of that service may create access opportunities across otherwise separate operational environments.

A dependency map should therefore record both normal-operation relationships and relationships that become relevant during maintenance, emergency intervention or recovery.

Table 7.3 — Cyber-Physical Dependency Analysis

Dependency relationship	Principal question	Required evidence	Consequence of omission
Controller to physical process	What condition can the controller influence?	Engineering design and verified logic	Misclassification of physical consequence
Controller to field devices	Which measurements and actions are affected?	Wiring, instrumentation and system records	Incomplete manipulation assessment
Operator station to controller	Which operating commands are available?	Application permissions and functional tests	Excessive authority goes unnoticed
Engineering workstation to controller	Which configuration changes are possible?	Engineering tools and access records	Programming attack path omitted
Controller to safety functions	What protective independence exists?	Safety design and validation records	Incorrect assumption of consequence containment
Industrial system to identity service	What access fails if identity infrastructure is unavailable?	Authentication design and resilience tests	Unrecognised common-mode dependency
Facility to external supplier	Which support functions depend on vendor systems?	Contracts and maintenance records	Recovery or access dependency overlooked
Control system to backup power	What occurs during power or transfer failure?	Electrical engineering documentation	Underestimated service interruption
Controller to recovery repository	Can a trusted configuration be restored?	Backup inventory and restoration results	False assurance of recoverability
OT to analytical services	Can observation pathways become control pathways?	Interface architecture and permission testing	Indirect control authority overlooked

The resulting dependency map provides the foundation for assessing attack paths and evaluating the effect of proposed controls.

Attack-Path Analysis Under Zero Trust Assumptions

Conventional vulnerability assessments often concentrate on whether a particular system possesses a known exploitable weakness. For industrial Zero Trust, the relevant analytical question is broader: what sequence of access relationships would allow an adversary to move from an initial compromised component to an action capable of producing an unacceptable physical consequence?

The analysis should identify the initial access opportunity, the identity or privilege involved, the communications pathways available, the industrial capability that could be exercised and the safeguards intended to interrupt the sequence.

Crucially, the assessment should not assume that the first compromised identity or device will always be outside the industrial network. The starting condition may instead involve a compromised maintenance workstation, legitimate supplier credentials, a malicious update or an authorised insider exceeding their permitted role.

The purpose is to establish whether security boundaries remain effective after the loss of one previously trusted component.

A mature assessment should also examine whether legitimate applications can be used in unintended ways. Denying unauthorised network connections does not necessarily prevent misuse of an authorised engineering tool. Restricting access to one controller does not necessarily prevent harmful actions if the permitted user retains broad programming authority over that controller.

Consequently, the unit of protection should be the industrial capability as well as the network path.

Table 7.4 — Representative Attack-Path Assurance Cases

Initial compromise assumption	Potential progression	Intended protective boundary	Validation objective
Supplier account compromised	Attempted access to unrelated controllers	Destination-specific remote-access policy	Demonstrate denial outside approved task
Engineering workstation compromised	Attempted reachability across production zones	Segmentation and engineering access restrictions	Demonstrate containment to authorised resources
Enterprise identity compromised	Attempted authentication into OT	Separate access decisions and privilege restrictions	Demonstrate enterprise compromise does not confer OT authority
Historian compromised	Attempted use of data path for control	Restricted industrial data interface	Demonstrate absence of unauthorised command capability
Monitoring system compromised	Attempted interference with process communications	Monitoring independence	Demonstrate industrial control continues safely
Remote-access gateway unavailable	Loss of supplier maintenance capability	Emergency operating and maintenance procedures	Demonstrate necessary intervention remains feasible
Controller configuration altered	Persistence of unauthorised logic	Configuration-integrity and recovery processes	Demonstrate detection and restoration
Cloud analytics service compromised	Attempted expansion into OT management	Mediated data transfer and limited service identity	Demonstrate containment of external compromise
Shared supplier update mechanism compromised	Attempted introduction of untrusted software	Update validation and engineering change control	Demonstrate unauthorised change prevention

These are defensive assurance scenarios. The appropriate execution method must be approved by the responsible engineers and should avoid unnecessary attempts to manipulate live safety-critical equipment.

Distinguishing Prevention, Containment, Detection and Recovery Outcomes

One of the most important requirements for programme evaluation is to avoid treating different cybersecurity outcomes as equivalent.

Prevention concerns whether the attacker can perform the prohibited action at all. Containment concerns whether a compromise remains limited to a defined portion of the environment. Detection concerns whether the organisation identifies relevant activity in sufficient time and with adequate accuracy. Recovery concerns whether a trusted and operationally acceptable state can be restored.

An organisation may perform well in one dimension and poorly in another.

A monitoring system may detect unauthorised programming but lack the ability to prevent it. A network boundary may stop lateral movement while providing limited information about what occurred within the compromised zone. A robust recovery process may restore equipment after compromise but require a lengthy shutdown.

The evaluation of national investment programmes should therefore record these outcomes separately.

Table 7.5 — Operational Assurance Evidence by Security Outcome

Outcome	Measurable result	Required test evidence	Principal limitation
Prevention	Prohibited action was denied	Controlled access test	Only tested actions are covered
Containment	Compromise remained within intended boundary	Representative compromise scenario	Untested paths may remain
Detection	Relevant activity produced a validated alert	Event and monitoring correlation	Alert accuracy and coverage vary
Investigation	Necessary activity and configuration history reconstructed	Log and engineering-record review	Legacy devices may provide incomplete evidence
Response	Responsible personnel acted within approved operational procedures	Exercise record	Exercise conditions may be simplified
Recovery	Trusted function restored under accepted conditions	Restoration test	Physical and digital conditions may differ from real incidents
Continuity	Essential service remained within defined operating requirements	Operational evidence	Outcome depends on the tested scenario
Safety preservation	Protective functions performed as designed	Engineering and safety validation	Cannot be inferred from cybersecurity tests alone

The distinction between cybersecurity containment and physical-process continuity is especially consequential. An organisation may successfully isolate a compromised network while interrupting the service the network supports. Such an intervention may be justified if continued operation presents unacceptable hazards, but it should not be represented as uninterrupted resilience.

Establishing an Evidence-Based Cost-Benefit Method

Comparisons between compensating controls and equipment replacement should incorporate more than initial capital expenditure.

A defensible analysis would examine the cost of implementation, engineering testing, maintenance, training, operational downtime, supplier support, expected remaining service life and future replacement requirements. It should also consider the costs and consequences associated with potential compromise, while acknowledging the uncertainty involved in estimating their likelihood.

Expected-loss calculations can be useful where defensible incident probabilities and consequence distributions exist. In many industrial environments, however, reliable probability estimates are unavailable, particularly for rare but severe cyber-physical events.

Under these conditions, fabricated numerical probabilities would create an appearance of precision unsupported by evidence.

A better approach is to compare feasible options under a set of documented consequences and operational constraints. This might include whether the option can prevent unauthorised programming, whether it preserves essential communications, whether it introduces new common-mode dependencies and whether trusted recovery remains achievable.

Financial comparisons can then be developed using actual investment costs, documented maintenance expenditure and bounded operational disruption scenarios, keeping uncertain cyber-event consequences separate from known project costs.

Table 7.6 — Compensating Controls Versus Replacement: Analytical Comparison Framework

Assessment dimension	Required input	Suitable method	Principal uncertainty
Acquisition expenditure	Supplier quotations and project estimates	Lifecycle cost comparison	Procurement price variation
Engineering integration	Scope and staffing estimates	Project cost and schedule analysis	Undiscovered dependencies
Production interruption	Planned maintenance and shutdown requirements	Documented outage scenarios	Actual commissioning duration
Vulnerability reduction	Verified weaknesses and protective controls	Attack-path comparison	Untested bypasses
Operational compatibility	Timing, functionality and safety requirements	Approved engineering testing	Differences between test and production
Supportability	Manufacturer commitments and spare availability	Lifecycle support assessment	Supplier continuity
Recovery capability	Tools, configurations and test results	Restoration exercises	Incident-specific conditions
Residual cyber exposure	Remaining feasible compromise paths	Structured consequence analysis	Threat evolution and incomplete visibility
Physical consequence	Engineering and continuity assessments	Consequence mapping	Rare or compound failures
Long-term adaptability	Interoperability and upgrade options	Scenario-based architecture review	Future standards and product support

The analysis should identify options that are technically unacceptable before comparing their financial attractiveness. An inexpensive measure that creates an unacceptable safety hazard is not an economically superior alternative.

Programme Evaluation: Establishing Whether National Guidance Actually Changes Outcomes

Governments seeking to evaluate the effectiveness of Zero Trust guidance should distinguish three questions.

The first concerns adoption: whether operators have implemented the recommended practices.

The second concerns performance: whether those practices produce the intended access restrictions, containment and recovery outcomes.

The third concerns impact: whether implementation reduces the probability or severity of consequential incidents.

Adoption is the easiest to measure through operator reporting, but it is also the weakest evidence of actual protection. Performance requires controlled tests and reliable technical records. Impact requires incident data, exposure information and analysis capable of distinguishing the effects of the programme from other developments.

For example, a reduction in reported incidents after deployment of segmentation may be consistent with improved security, but it may also reflect changes in attacker activity, reporting practices or the monitored population. Conversely, an increase in detected incidents may reflect improved visibility rather than deteriorating protection.

A credible evaluation must account for these possibilities.

Where enough comparable operators exist, regulators could establish matched cohorts based on sector, facility scale, operational complexity and initial cybersecurity characteristics. They could then compare changes in documented access exposure, containment-test results and recovery performance over time.

Such comparisons would not necessarily establish causality, particularly if participation is voluntary and better-resourced organisations are more likely to implement controls early. They could nevertheless provide stronger evidence than simple national adoption percentages.

Where controlled comparisons are infeasible, longitudinal evaluation within individual operators may still identify measurable improvements, provided the assessment preserves changes in asset population, system architecture and test coverage.

Table 7.7 — National Programme Evaluation Design

Evaluation question	Preferred evidence	Analytical approach	Qualification
Are controls being adopted?	Operator implementation records	Coverage analysis	Deployment is not effectiveness
Do controls restrict intended access?	Negative-access test results	Control-performance evaluation	Results limited to tested pathways
Are critical dependencies better understood?	Validated asset and process records	Longitudinal completeness assessment	Inventory growth may initially reveal more risk
Is incident detection improving?	Detection and investigation records	Consistent incident-case analysis	Changes in monitoring alter observed counts
Is containment becoming faster?	Timestamped exercise and incident records	Comparable scenario analysis	Scenarios may differ in difficulty
Is recovery becoming more reliable?	Restoration exercises	Repeated operational testing	Tests may not capture all real-world constraints
Is regulatory burden proportionate?	Compliance effort and duplicate reporting data	Administrative cost analysis	Operator costs vary
Are suppliers improving product security?	Procurement tests and contractual evidence	Longitudinal procurement assessment	Supplier claims require verification
Is residual exposure declining?	Consequence-based attack-path assessments	Repeatable risk comparison	Threat landscape and asset population change
Are essential services more resilient?	Verified operational incident outcomes	Multiyear sector analysis	Rare severe incidents limit statistical inference

A government programme should report the maturity of its evidence system alongside the results. An apparent improvement derived from incomplete data should not receive the same confidence as an improvement supported by repeatable testing and stable population definitions.

The Role of Government Audits and Independent Assurance

Government audit institutions provide an essential independent perspective because they can examine the performance of national programmes rather than simply their policy objectives.

The March 2024 GAO investigation into CISA’s OT support activities demonstrated that technical assistance programmes require workforce planning, service-performance measures and effective interagency collaboration. The September 2026 inventory audit demonstrated that formal requirements do not necessarily produce complete implementation. The September 2026 regulatory harmonisation report documented concerns about duplicated and conflicting reporting expectations.

Taken together, these findings support an important analytical conclusion: a Zero Trust programme can fail at the institutional level even when its technical recommendations are defensible.

Cybersecurity: Improvements Needed in Addressing Risks to Operational Technology — GAO — March 2024

Internet of Things: OMB Action Needed to Ensure Agencies Secure Their Networked Devices — GAO — September 2026

Cybersecurity Regulations: Industry Panelists Identify Duplication and Conflicts and Ways to Address Them — GAO — September 2026

Independent assurance should therefore address both operator implementation and the effectiveness of the government institutions responsible for supporting it.

For operators, independent assessment should examine whether reported security outcomes are supported by engineering evidence. For governments, independent assessment should examine whether national programmes have realistic funding, competent technical personnel, consistent definitions and procedures for addressing weaknesses identified through oversight.

Such arrangements would reduce the risk that compliance becomes a substitute for protection.

Priority Intelligence Requirements for National Security Authorities and Critical Infrastructure Regulators

The final intelligence agenda should concentrate on questions whose answers could materially alter government guidance, intervention priorities, financial incentives or regulatory expectations.

The following ten questions are ranked according to their contribution to decisions about immediate exposure, control effectiveness, physical consequences and sustainable modernisation. This is an analytical priority ordering rather than an official NSA intelligence requirements list.

Table 7.8 — Ten Priority National Intelligence Questions

Priority	Intelligence requirement	Decisive evidence	Government decision enabled
1	Which high-consequence physical functions remain accessible through inadequately governed digital pathways?	Validated access and process dependency maps	Immediate intervention and oversight
2	How completely are operators implementing the NSA’s 26 high-impact activities, and which are operationally effective?	Verified activity catalogue, operator evidence and test results	Guidance refinement and programme prioritisation
3	Which compensating controls reliably prevent compromise from crossing industrial process boundaries?	Comparable containment exercises	Minimum assurance expectations
4	How much uncontrolled authority remains within vendor and contractor access arrangements?	Supplier session records and access testing	Procurement and remote-access regulation
5	What proportion of critical legacy systems cannot be securely maintained or independently recovered?	Support records and restoration exercises	Accelerated modernisation funding
6	Which security changes introduce unacceptable process disruption or safety dependencies?	Engineering validation and change-related incident evidence	Safe implementation standards
7	How effectively do monitoring and response arrangements distinguish cyber compromise from ordinary industrial faults?	Incident investigations and correlated operational telemetry	Detection and response investment
8	What barriers prevent operators from purchasing equipment with necessary native security functions?	Tender outcomes, supplier capabilities and lifecycle costs	Secure-by-Demand incentives
9	How rapidly can operators contain and recover from defined compromise scenarios?	Comparable timed exercises and real incidents	National resilience indicators
10	Which regulatory, financial and workforce constraints prevent implementation, particularly among smaller essential-service operators?	Audits, operator surveys and cost evidence	Proportionate regulation and technical assistance

Intelligence Requirement 1: Identifying High-Consequence Digital Exposure

The highest-priority question concerns the actual relationship between untrusted digital access and consequential physical functions.

An answer requires more than scanning publicly accessible services. It requires identifying which reachable systems can influence critical processes, whether their access permissions permit meaningful intervention and whether independent safeguards limit the consequences of compromise.

The relevant information should be collected through authorised operator assessments, verified system architecture and engineering analysis. Government should prioritise aggregated exposure findings and intervention needs rather than routinely assembling detailed exploitation pathways in broadly accessible national repositories.

The decision enabled by this intelligence is immediate prioritisation. Where credible access to a high-consequence function is insufficiently governed, protective intervention may be justified independently of the asset’s chronological age.

Intelligence Requirement 2: Measuring the NSA Activity Framework Against Actual Outcomes

The NSA’s selection of 26 high-impact activities from a broader 84-activity framework warrants a dedicated implementation study.

The necessary first step is to obtain and validate the complete primary activity catalogue, including its exact titles, definitions and any associated implementation guidance. The October 2026 official announcement supports the existence and strategic purpose of the guidance, but does not provide sufficient accessible detail here to reconstruct an authoritative item-by-item matrix.

NSA Releases Zero Trust Guidance for Protecting Operational Technology Systems — NSA — October 2026

The second step is to distinguish activity completion from verified protective effect. Operators should identify which activities are implemented, which remain partially implemented, which cannot be applied to existing technology and which have been validated through representative operational evidence.

The third step is to determine whether implementation outcomes differ materially according to equipment age, sector, facility complexity and organisational resources.

Such analysis would permit government authorities to determine whether the selected activities provide an appropriate minimum implementation pathway for civilian operators, or whether particular sectors require additional measures.

Intelligence Requirement 3: Establishing the Effectiveness of Compensating Controls

The third requirement concerns the practical effectiveness of protections deployed around equipment that cannot support modern security mechanisms directly.

The government should seek evidence from controlled implementation studies comparing relevant architectures across representative industrial environments. The purpose would not be to declare one commercial technology universally superior, but to establish which combinations of segmentation, controlled maintenance access, gateway enforcement and monitoring produce demonstrable containment under specified conditions.

The decisive information is whether a compromised component can exercise authority beyond its intended operational scope.

Where results differ, analysts should investigate the characteristics explaining the difference, including protocol capabilities, network architecture, access-management design and the presence of undocumented communication paths.

The resulting evidence could inform sector-specific technical guidance and procurement specifications.

Intelligence Requirement 4: Quantifying Supplier Access and Privilege Exposure

Supplier access remains one of the most important relationships between industrial operators and external organisations.

The government should determine how many consequential maintenance pathways are persistent rather than temporary, how often broad privileges are granted, whether individual supplier identities can be established and whether access can be revoked independently by the operator.

Data collection should also identify cases in which emergency maintenance requirements make conventional access restrictions impractical.

The decisive analytical distinction is between a supplier relationship that is contractually authorised and a particular industrial action that is operationally permitted. Effective governance must establish both.

The resulting intelligence would support procurement requirements, vendor oversight and the development of practical remote-access reference architectures.

Intelligence Requirement 5: Determining When Equipment Replacement Becomes Necessary

The fifth requirement addresses the boundary between sustainable compensation and unavoidable modernisation.

Governments need evidence showing which legacy systems cannot be adequately protected because of unsupported software, insecure configuration interfaces, non-recoverable engineering environments or unavoidable access relationships.

The relevant decision should not depend exclusively upon the availability of security patches. The ability to establish a trusted configuration, maintain essential protective functions and recover without unavailable supplier infrastructure may be equally consequential.

A credible assessment would compare the costs and effectiveness of feasible compensating controls with the full lifecycle cost of replacement, subject to physical safety and service continuity requirements.

This intelligence could support targeted financial incentives and prevent indiscriminate equipment replacement programmes.

Intelligence Requirement 6: Evaluating the Safety Consequences of Security Changes

A national Zero Trust programme must also establish which proposed security controls introduce new operational dependencies.

The necessary evidence includes engineering change records, compatibility testing, commissioning results and documented security-related disruptions.

This requirement is particularly important because an increase in security controls does not automatically imply a reduction in overall cyber-physical risk.

A gateway that introduces a new single point of failure, an identity service that prevents necessary emergency intervention or a monitoring system that interferes with industrial communications may reduce one exposure while creating another.

Government guidance should therefore incorporate evidence of operational compatibility and require proportionate validation before deployment into sensitive systems.

Intelligence Requirement 7: Assessing Detection and Investigation Capability

The seventh question concerns the ability of operators to recognise and reconstruct consequential cyber activity.

The relevant intelligence should establish which devices produce usable audit evidence, which activities can be observed through surrounding systems and whether investigators can correlate digital changes with physical-process behaviour.

Particular attention should be given to the distinction between malicious activity, accidental engineering changes and mechanical faults.

A mature monitoring programme should be evaluated according to the accuracy and timeliness of these distinctions, not simply the volume of collected telemetry.

The government decision enabled is the prioritisation of monitoring investments and the development of common forensic expectations suitable for legacy equipment.

Intelligence Requirement 8: Identifying Secure Procurement Market Failures

The eighth requirement concerns whether the industrial equipment market supplies the capabilities operators need.

Evidence should be gathered from procurement exercises, manufacturer declarations, acceptance testing, contract performance and operator experience.

The analysis should determine whether strong authentication, secure configuration management, logging, supported updates and recovery independence are available in baseline products or require additional proprietary components.

Where requirements cannot be met, the reason should be identified. It may arise from genuine technical constraints, inadequate market incentives, limited supplier competition or insufficiently precise purchasing specifications.

This information would permit governments to target procurement guidance and incentives towards the product characteristics most likely to reduce future industrial cybersecurity debt.

Intelligence Requirement 9: Measuring Incident Containment and Recovery

The ninth requirement concerns a genuinely operational measure of resilience: how rapidly and reliably essential services can be contained and restored following defined compromise scenarios.

The evidence should distinguish the time required to detect an incident, establish its operational scope, restrict the compromised access, verify the integrity of affected systems and restore trusted operation.

A single combined recovery-time metric may conceal important differences.

An incident may be detected quickly but require extended engineering investigation. A compromised workstation may be isolated immediately while the operator remains unable to establish whether controller logic has changed. A restored digital system may still require physical commissioning before normal operations resume.

Government assessment should therefore retain these intervals separately and relate them to the particular physical service.

Intelligence Requirement 10: Identifying the Barriers That Determine National Adoption

The final requirement concerns the institutional and economic constraints that determine whether technically sound guidance can be implemented at scale.

Relevant evidence includes workforce availability, operator budgets, supplier dependency, regulatory duplication, maintenance windows, technical assistance capacity and access to qualified industrial cybersecurity expertise.

The importance of this requirement is supported by GAO’s findings concerning CISA’s OT service capacity and the practical constraints facing water and wastewater operators.

Cybersecurity: Improvements Needed in Addressing Risks to Operational Technology — GAO — March 2024

Critical Infrastructure Protection: Actions Needed to Address Persistent Cybersecurity Threats to the Water and Wastewater Sector — GAO — May 2026

The policy consequence is that uniform technical expectations may require differentiated implementation support. Smaller operators may need shared assessment services, technical assistance or coordinated procurement, whereas large infrastructure organisations may be capable of maintaining their own assurance programmes.

Such differentiation should concern the route to achieving protection, not the acceptance of avoidable high-consequence exposure.

A Government Research Programme for 2027–2031

The ten intelligence requirements should be incorporated into a multiyear research and assurance programme with defined responsibilities and periodic public reporting at an appropriate level of aggregation.

The first stage should establish common definitions, source provenance and reporting populations. Without this foundation, apparently precise comparisons between sectors may be statistically misleading.

The second stage should develop representative implementation studies, concentrating on architectures used across ageing industrial estates. These studies should test containment, maintenance access, logging and recovery under controlled conditions.

The third stage should connect these results to regulatory oversight and capital planning, identifying which controls consistently demonstrate protective value and which structural weaknesses require replacement.

A fourth stage should evaluate whether the programme reduces the consequences of real incidents and improves service restoration. This is the most difficult stage because severe industrial cyber incidents are comparatively rare and incident populations may not be statistically comparable.

Table 7.9 — Proposed National Research and Assurance Programme

Period	Research objective	Principal evidence product	Government application
2027	Establish comparable exposure definitions and baseline coverage	National OT exposure methodology and sector baselines	Prioritise critical gaps
2028	Validate major protective architectures	Controlled access, containment and recovery studies	Refine technical guidance
2029	Measure procurement and supplier improvements	Secure product capability and lifecycle evidence	Strengthen purchasing requirements
2030	Compare sector implementation effectiveness	Audited operator maturity and assurance results	Adjust regulatory expectations and incentives
2031	Evaluate infrastructure resilience outcomes	Longitudinal programme assessment	Determine next-generation investment priorities

This is a recommended research schedule, not an announced government programme or forecast of completed outcomes.

European and Allied Intelligence Cooperation

The technical similarities between United States and European industrial environments create opportunities for cooperation in evidence collection and assurance, particularly where the same manufacturers supply equipment across multiple jurisdictions.

However, national security information, critical infrastructure configurations and commercially sensitive engineering records may be subject to different disclosure restrictions. Cooperation should therefore concentrate initially on common technical definitions, anonymised results, product-security evidence and lessons derived from controlled testing.

The European NIS2 framework provides a relevant institutional foundation for cybersecurity risk management and supervisory cooperation among covered entities, but legal obligations must be determined according to the applicable Union and national provisions.

Directive (EU) 2022/2555 — European Parliament and Council — December 2022

Italy, France, Germany and the United Kingdom could contribute distinct industrial and regulatory experience to a shared evidence programme, provided their national systems are not treated as legally interchangeable. Common equipment-assurance methods would be particularly valuable where industrial suppliers operate across borders and where multinational infrastructure operators face multiple supervisory regimes.

The principal advantage of such cooperation would be to reduce duplicated engineering effort while improving the comparability of security outcomes.

Confidence Assessment and Remaining Data Limitations

The evidence supports a high-confidence conclusion that meaningful OT Zero Trust assurance requires more than inventory creation, access-control deployment and formal policy adoption. It requires reliable relationships between identified physical functions, permitted operational authority, tested protective boundaries and recoverability.

There is also high confidence that current government oversight faces substantial implementation challenges. GAO’s findings concerning federal inventory completeness, OT workforce capacity and regulatory coordination provide concrete evidence of institutional limitations within the populations examined.

There is moderate confidence that a common national assurance framework could materially improve regulatory consistency and investment targeting. The mechanism is clear: comparable definitions and validated outcomes would enable authorities to distinguish protective effectiveness from nominal compliance. The scale of improvement remains uncertain because representative national implementation studies have not been established through the evidence examined here.

There is limited confidence in claims assigning universal numerical effectiveness to specific compensating controls or estimating nationwide proportions of unprotected industrial controllers. Such estimates require defined populations, reliable sampling and reproducible validation data.

The same limitation applies to claims concerning the additional success rates of AI-assisted industrial attacks. Official guidance recognises the threat, but available evidence does not justify assigning one universal numerical increase in the probability of successful physical-process manipulation.

Chapter 7 — Key Judgments

The principal intelligence requirement for national OT protection is the establishment of a comparable, consequence-based evidence architecture capable of connecting access exposure, industrial dependencies, control effectiveness and recovery outcomes.

Primary government publications and technical standards establish credible security principles, but they do not independently demonstrate how effectively those principles have been implemented across the national installed base.

The most valuable near-term research would establish the completeness of high-consequence asset and dependency inventories, identify unmanaged privileged pathways and validate the ability of existing protective controls to contain compromise.

The most valuable medium-term research would compare the effectiveness of compensating controls across representative industrial architectures and establish which structural vulnerabilities justify accelerated replacement.

The most consequential long-term question is whether these interventions demonstrably reduce the physical and service-delivery consequences of cyber incidents.

Final Net Assessment — The Strategic Requirement for 2027–2031

The implementation of Zero Trust across ageing operational technology should be treated as a national infrastructure resilience programme rather than a conventional cybersecurity upgrade.

Its success depends upon the ability to govern authority over physical processes, establish reliable boundaries around equipment that cannot protect itself, verify the effectiveness of those boundaries and progressively replace systems whose vulnerabilities cannot be reduced to an acceptable level.

The institutional evidence available in October 2026 demonstrates that governments and operators face substantial difficulties even in foundational activities such as maintaining complete device inventories, coordinating specialised cybersecurity assistance and harmonising regulatory expectations. These difficulties cannot be resolved solely by issuing additional technical guidance.

The NSA’s October 2026 intervention and the CISA interagency framework provide an important basis for action, but the next requirement is empirical: converting security principles into repeatable demonstrations of containment, safe operation and recovery.

For cabinet-level decision makers, three consequences follow.

First, immediate investment should address the access paths and dependencies capable of producing the most serious physical consequences, irrespective of whether the underlying equipment is scheduled for replacement.

Second, regulatory assessment should distinguish implementation from effectiveness, requiring evidence that critical functions remain protected under representative compromise conditions.

Third, long-term industrial procurement and capital planning should remove structural cybersecurity weaknesses, rather than perpetually financing compensating systems around unsupported equipment.

The resulting policy objective is not a theoretically perfect industrial network. It is an infrastructure estate in which digital compromise does not automatically translate into unacceptable physical authority, essential protective functions remain dependable, and operators retain a demonstrable capacity to recover trusted control of the services upon which national security and public welfare depend.

This is the decisive standard against which Zero Trust implementation should be judged through 2031.

---

Copyright of debuglies.com – Even partial reproduction of the contents is not permitted without prior authorization Reproduction reserved