Why ZTNA in OT Isn’t Just Like IT: Unpacking the Network Perimeter for Industrial Environments

Zero Trust Network Access (ZTNA) has become a staple acronym in IT security, serving as both a buzzword and a practical architecture guiding countless deployment projects worldwide. However, a worrying trend has emerged in the context of Operational Technology (OT): many organizations and vendors are attempting to lift-and-shift IT-origin ZTNA blueprints into environments they fundamentally don't fit. This post explores the distinct challenges of applying ZTNA in OT domains, illustrates why “just do what we do in IT” leads to dangerous gaps, and underscores the nuanced architectural and operational differences necessary for true OT security.

ZTNA: A Brief Technical Context

ZTNA emerged as a response to the inadequacy of traditional network perimeter-based security in the era of cloud computing, mobile workforces, and advanced threat actors. The fundamental premise: “Never trust, always verify.” Under ZTNA, network location doesn’t confer trust. Instead, authentication, authorization, least-privilege access, and continuous verification are required every time an entity wants to access another.

In IT, ZTNA solutions are typically instantiated via brokers (for example, a cloud gateway or on-prem appliance) that authenticate users and devices, often integrating with directory services and identity providers, to grant access to protected IT assets.

ZTNA’s Original Habitat: The IT Domain

The first large-scale ZTNA deployments occurred in standard corporate IT environments—think knowledge workers accessing databases or CRM systems from various devices and locations. Devices are relatively homogeneous and modern. Applications typically use standard protocols (HTTP(S), RDP, SSH, etc.) and can integrate natively with identity solutions (like SAML, OAuth). IT’s evolutionary tradition of replacing infrastructure every half-decade further accelerated adoption.

What Makes OT Distinct?

Operational Technology (OT)—the umbrella term for industrial devices and networks controlling everything from manufacturing robots to power substations—poses realities that ZTNA-for-IT simply doesn’t address. OT environments are built for safety, determinism, and longevity. Many assets were never designed with any kind of remote or even local modern security in mind.

• Longevity: PLCs, RTUs, sensors, and actuators can be expected to run for decades (not 3-5 years).

• Heterogeneity: A single plant may contain assets from dozens of vendors, with proprietary and legacy protocols, and no built-in identity mechanisms.

• Deterministic Operation: Predictability is paramount—emergent behaviors from untested network components can cause outages or safety failures.

• Separation from IT: Air gaps, proprietary networks, and the control loop's intolerance for millisecond latency are real, even critical, constraints.

Network Architecture: Different DNA

In IT, a ZTNA broker is typically interposed between users (clients) and services (applications or endpoints). All access is funneled through policy enforcement points, often cloud-managed, that understand user identity and device security posture.

In OT, the notion of an “application” is not so clean: control protocol traffic spans multiple layers (field, control, supervisory), often using custom or ancient protocols. Machines may “talk” to each other peer-to-peer, not via a well-bounded, user-authenticated application gateway. The ZTNA “broker” concept thus becomes muddy or even inapplicable without significant re-architecture. Furthermore, the blast radius of a poorly placed enforcement point in an OT network could induce downtime or process instability.

Historical Note: From Purdue Model to ZTNA

Since the late 1990s, OT networks have been organized according to variants of the Purdue Enterprise Reference Architecture model. This stratifies the environment into levels (from corporate business at Level 5 down to field devices at Level 0), separated—ideally—by firewalls or data diodes. Moving lateral traffic control down the stack (to L2 and L1) is not trivial and can even be infeasible when OT protocols lack session-level identifiers, making granular policy enforcement a near-impossibility for legacy assets.

IT/OT Collaboration: Beyond Turf Wars

Too often, ZTNA initiatives are led solely by IT teams whose priorities (confidentiality, cloud enablement, user-centricity) are not congruent with OT imperatives (availability, integrity, deterministic latency, safety). In most successful projects, a cross-disciplinary team is formed, mapping where ZTNA principles are achievable and where compensating controls (such as strict fixed-function firewalls or application layer proxies) must stand in.

One recurring gap: IT-driven ZTNA products expect asset identity be asserted by the endpoint (machine certificates, device posture checks, etc). Yet, many OT assets either cannot be patched to participate in such frameworks or do not even possess sufficient compute capabilities for agent installation. Identity may therefore have to be inferred instead—by MAC address, port, network locality, or other weak signals—raising the bar for secure implementation.

Secure Connectivity Deployment: Architecture, Testing, Reality Checks

Whereas IT ZTNA can be software-deployed to cloud or endpoint with limited disruption, OT rollouts require painstaking risk assessment and staged validation. Critical considerations include:

• Latency and Jitter: Many ZTNA brokers (especially those relying on cloud detours or heavy inspection) introduce variable latency, which can be catastrophic for time-sensitive industrial protocols.

• Protocol Non-Support: Many industrial protocols (Modbus, DNP3, Profinet) are not natively supported for deep packet inspection or identity assertion in most ZTNA solutions.

• Fail-Safe Principles: In OT, the default state on broker/process failure must be safe for the physical process (stop, not let through, not prompt for user interaction).

• Change Control: Many plants have monthly or even quarterly maintenance windows. Pushing an agent update, enforcing new inspection logic, or modifying topology can trigger unexpected faults.

Example: Attempting to enforce user-initiated sessions only (as ZTNA mandates) breaks plant-floor M2M (machine to machine) traffic that runs autonomously and constantly. Retroactively redesigning all plant control traffic to “call out” via a broker can be more dangerous (and costly) than the risk you’re aiming to reduce.

Where ZTNA in OT Does Work

This is not to say ZTNA has no role in OT. It shines in the following scenarios:

• Remote Access: Technician and vendor access can be strictly brokered, providing a single audit/control point and reducing VPN sprawl.

• Selective Asset Segmentation: Where assets are modern, support secure identity and communications, and are already “IT-friendly” (Windows servers, HMIs, historian databases).

• High-Security DMZs: Between Level 3/Level 4, brokering connections to corporate IT from plant OT benefits from applying ZTNA logic—though these are often isolated exceptions, not the main pattern.

Even where possible, ZTNA must be treated as one component of a multi-layered security model—not a panacea, but a targeted tool.

Practical Steps for Industrial ZTNA Adoption

1. Asset Inventory: Know every asset, protocol, expected data flow, ownership, and risk profile before drawing up ZTNA blueprints.

2. Protocol and Identity Mapping: Understand what device identity is achievable. Avoid “agent or nothing” solutions.

3. Engage Operations Teams: Test in lab environments. Validate any change that might affect latency, protocol compatibility, or deterministic operation.

4. Compensating Controls: Where ZTNA is not viable, strengthen firewalls, deploy protocol-aware proxies, or reinforce monitoring capabilities.

5. Continuous Review: Revisit your architecture regularly. As assets are upgraded, ZTNA applicability expands—don’t architect for the future at the expense of today’s safety.

Conclusion

Borrowing IT security doctrine blindly for OT environments is an invitation to fragile, unsafe, and ultimately insecure deployments. ZTNA can add real value as a guardrail for remote access and modern OT/IT integration, but only by respecting the unique constraints and operational realities of industrial environments. Collaboration between IT, OT, and network engineering—guided by pragmatic, not dogmatic, approaches—remains essential.

Summary: ZTNA in OT is not a software checkbox to be ticked, but a careful, often partial, architectural effort demanding cross-disciplinary rigor, staged adoption, and a nuanced understanding of industrial risk.