TLDR
Zero Trust has become the mandated architecture for critical infrastructure, but vendor promises rarely match operational reality. Most implementations fail not from bad technology, but from vendors oversimplifying the unique constraints of critical systems: legacy equipment that can’t be replaced, operational technology that predates modern security models, and safety requirements that override security assumptions. Here’s what actually works when you can’t afford to get it wrong.
When Federal Mandates Meet 15-Year-Old SCADA
After the Colonial Pipeline ransomware attack in May 2021, President Biden issued an Executive Order mandating that federal agencies modernize cybersecurity standards, with explicit focus on operational technology that runs critical infrastructure. By January 2022, the Office of Management and Budget formalized this with M-22-09, requiring federal agencies to meet specific Zero Trust cybersecurity standards by the end of fiscal year 2024.[1]
Here’s the problem. When vendors demonstrate Zero Trust, they’re showing cloud-native microservices with modern API gateways. Your environment: ICS and SCADA control systems designed to be in production for years if not decades, running legacy operating systems, unpatched and vulnerable to cyberattacks.[1] You can’t just upgrade a substation controller. Taking systems offline for security updates could darken homes or disrupt water treatment.
A 2023 survey found that 88% of OT cybersecurity leaders in critical infrastructure have taken steps to adopt Zero Trust, but only 58% found paths that don’t require equipment overhaul.[2] That means 42% are still facing that daunting prospect.
The architecture is sound. The implementation assumptions vendors make are often fantasy.
What Vendors Promise (And Why It Sounds So Good)
The Zero Trust pitch follows a familiar script. The goal is to prevent unauthorized access to data and services and make access control enforcement as granular as possible, shifting from a location-centric model to a data-centric approach for fine-grained security controls. The core tenets sound unassailable: never trust, always verify. Micro-segmentation prevents lateral movement. Continuous authentication validates every access request. All sensitive data gets encrypted in transit and at rest.[3]
These aren’t wrong. They’re genuinely valuable security improvements over perimeter-based defenses that assume internal network traffic is trustworthy.
The problem surfaces in implementation assumptions. NIST’s Zero Trust Architecture guidance acknowledges that building ZTA from scratch is rarely viable for federal agencies or any organization with an existing network, but notes there may be times when an organization builds new infrastructure where ZTA might be possible.[4] That’s the disconnect. Vendors demonstrate Zero Trust on greenfield deployments with modern authentication protocols, API-first architectures, and cloud-native services.
Your environment looks different. Critical infrastructure operators provide vital services like electricity generation and water treatment that rely on supervisory control and data acquisition (SCADA) systems using supervisory computers to communicate with field assets.[5] These systems don’t have modern authentication. They can’t tolerate the latency of continuous verification. Many use proprietary protocols that predate the security model vendors are selling.
Most Zero Trust products were designed for IT environments, then marketed to OT with new slides but not new architectures. The demo works beautifully when everything supports OAuth and can be containerized. When half your infrastructure predates those concepts, the demo becomes fantasy.
Technical Reality in Critical Infrastructure
The Legacy Problem
Legacy devices often lack essential security features, such as encryption, authentication protocols, and regular security updates.[6] Additionally, the long lifecycles of these devices make it challenging or impractical to implement timely security patches and updates. Critical infrastructure runs on equipment designed for 20-30 year lifecycles. You can’t just upgrade a substation controller or a gas pipeline SCADA system. Replacement isn’t a security project—it’s a capital expenditure requiring years and regulatory approval.
The Availability Constraint
Implementing Zero Trust security measures, such as continuous monitoring and micro-segmentation, may impact the availability and performance of ICS components, which are often designed for real-time responsiveness.[7] A hospital can’t take patient monitoring systems offline for security updates during operating hours. A water treatment facility can’t pause operations for network segmentation. Organizations facing encryption challenges might consider layering third-party encryption solutions. However, this practice could disrupt availability and performance due to processing overhead—a reduction that would likely be unacceptable in many industrial environments because it could negatively affect the safety of an industrial process.[5]
The Authentication Challenge
Many OT devices have been around for a long time and were designed for single-user operation. Allowing multiple users might require shared account authentication, which precludes the important cybersecurity concepts of nonrepudiation and least privilege. Shared accounts are in some ways the antithesis of zero trust.[5] Modern Zero Trust assumes identity-based access control, but how do you authenticate a 15-year-old PLC with a hardcoded password and no concept of user identity? You can’t put multi-factor authentication on a temperature sensor.
The practical answer involves proxies, gateways, and compensating controls—which reintroduces exactly the trust boundaries Zero Trust is supposed to eliminate.
The Monitoring Overhead
The enterprise should collect data about asset security posture, network traffic and access requests, process that data, and use any insight gained to improve policy creation and enforcement.[4] Continuous verification generates massive telemetry. Critical infrastructure environments are already data-rich. Most organizations lack the Security Operations Center capacity to act on this data. Adding Zero Trust monitoring without additional analysis capability just creates noise.
The Real Cost
Vendor quotes focus on licensing. Actual cost lives in integration engineering, process changes, and operational overhead. Ongoing operational costs including vendor support, infrastructure scaling, and policy management may increase during the first 12-18 months. Organizations face these increases as they optimize configurations and expand Zero Trust coverage.[8] The tools are often the smallest line item compared to what it takes to make them work in your environment.
What Actually Works (From People Who’ve Done This)
Start with Asset Inventory and Criticality
Critical infrastructure needs a complete inventory before implementing Zero Trust Architecture. You can’t implement Zero Trust without knowing what you’re protecting and what can tolerate security controls. Map your environment by criticality and capability. Lower level ICS systems and devices like IEDs, PLCs, and sensors lack granular access control capabilities on the device itself and instead rely on perimeter, gateway, and front end protections.[9]
Implement in Phases Based on Technical Capability
The recommended phased model starts with identifying critical assets, establishing visibility and risk assessment, implementing OT-IT network segmentation to limit risk and minimize attack surface, then applying Zero Trust policies.[10] Begin with the newest, most capable systems. Prove the architecture works before expanding. Organizations may find that legacy systems and facilities may not be feasibly updatable to Zero Trust Architecture. These entities will need to account for any residual risks from such facilities if they deem Zero Trust controls are necessary for risk mitigation.[9]
Accept Hybrid Architecture as Permanent State
Critical infrastructure will never be pure Zero Trust. For most enterprise architectures, organizations will need to combine multiple microsegmentation capabilities, potentially through a combination of preexisting capabilities and one or more vendor products, applying each where appropriate to align with identified use cases, needs, and objectives.[11] Network segmentation isn’t failure—it’s a necessary control layer for systems that can’t support identity-based access.
Invest in Engineering, Not Just Tools
The bottleneck is rarely the technology. You need people who understand both Zero Trust principles and your specific operational environment. Deploy iteratively based on lessons learned from pilot deployments, provide user training and raise awareness, and create comprehensive change management plans to address organizational and cultural changes.[12] Budget should favor integration and operations over licensing costs.
Trust the Process, Not the Pitch
Critical infrastructure needs Zero Trust architecture, but getting there requires honest assessment of your technical constraints—not vendor promises that ignore operational reality. The organizations succeeding at this treat it as a 3-5 year architecture evolution, not a 12-month product deployment.[2] They’re spending 70% of budget on integration engineering and only 30% on licenses. They’re proving the model on their newest systems before touching anything connected to physical processes.
That’s the unglamorous path. It’s also the one that actually protects critical systems when you can’t afford downtime and can’t replace a 20-year-old SCADA network because a vendor’s demo looked good.
References
[1] Delinea. (2021). “Zero Trust for ICS / SCADA Systems | How Does it Work?” https://delinea.com/blog/zero-trust-for-ics-scada-systems
[2] Xage Security. (2023). “Securing Critical Infrastructure: The Journey to Zero Trust.” https://xage.com/securing-critical-infrastructure-the-journey-to-zero-trust/
[3] Department of Defense. (2022). “Zero Trust Reference Architecture Version 2.0.” https://dodcio.defense.gov/Portals/0/Documents/Library/(U)ZT_RA_v2.0(U)_Sep22.pdf
[4] Rose, S. et al. (2020). “NIST Special Publication 800-207: Zero Trust Architecture.” National Institute of Standards and Technology. https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-207.pdf
[5] Carnegie Mellon University Software Engineering Institute. “IT, OT, and ZT: Implementing Zero Trust in Industrial Control Systems.” https://insights.sei.cmu.edu/blog/it-ot-and-zt-implementing-zero-trust-in-industrial-control-systems/
[6] Veridify. (2025). “Zero Trust for OT Security – Overcoming Legacy Device Security Gaps and Technical Debt.” https://www.veridify.com/zero-trust-for-ot-security-overcoming-legacy-device-security-gaps-and-technical-debt/
[7] Veridify. (2025). “Zero Trust: Reinforcing Security in Industrial Control Systems.” https://www.veridify.com/zero-trust-reinforcing-security-in-industrial-control-systems/
[8] Axis Intelligence. (2025). “Zero Trust Implementation Cost Calculator 2025: Enterprise Budget Planning Tools.” https://axis-intelligence.com/zero-trust-implementation-cost-calculator-2025/
[9] North American Electric Reliability Corporation (NERC). (2023). “White Paper – Zero Trust Security for Electric Operations.” https://www.nerc.com/comm/RSTC_Reliability_Guidelines/White_Paper_Zero_Trust_For_Electric_OT.pdf
[10] Palo Alto Networks. (2025). “Securing Critical Infrastructure with Zero Trust – Perspectives.” https://www.paloaltonetworks.com/perspectives/zero-trust-for-critical-infrastructure/
[11] Industrial Cyber. (2025). “CISA releases ‘Journey to Zero Trust’ series, guides federal agencies on microsegmentation to boost adoption.” https://industrialcyber.co/zero-trust/cisa-releases-journey-to-zero-trust-series-guides-federal-agencies-on-microsegmentation-to-boost-adoption/
[12] Amazon Web Services. “Phased approach to Zero Trust – AWS Prescriptive Guidance.” https://docs.aws.amazon.com/prescriptive-guidance/latest/strategy-zero-trust-architecture/phased-migration.html