Zero trust for OT: a practical, phased roadmap

Zero trust for OT is an operationally adapted security model that continuously verifies identity, context and device posture while preserving safety and availability. It never assumes trust based on network location alone, and it does not treat industrial control systems like office laptops.

Three priorities matter more than any others when you start:

• Build a comprehensive, authoritative asset inventory before touching a single firewall rule.
• Design network segmentation using zones and conduits, not flat VLANs dressed up as security boundaries.
• Introduce identity and access controls suited to OT, including just-in-time and just-enough access (JITA/JEA), rather than porting enterprise identity policy wholesale.

Table of Contents

• Why does OT need zero trust now?
• What are the core zero trust controls for OT?
• How should you sequence a zero trust rollout?
• Where does zero trust risk breaking OT operations?
• How do you secure vendor and remote access to OT?
• Which standards and guidance should you follow?
• How does PODTECH deliver OT zero trust projects?
• What supply chain risks does zero trust for OT address?
• How does continuous monitoring work in OT under zero trust?
• How should incident response change under OT zero trust?
• Can zero trust work with legacy OT systems and protocols?
• How is data protected within an OT zero trust framework?
• What risk assessment approach fits OT zero trust?
• How do you prepare OT personnel for zero trust adoption?
• Zero trust for OT: practical roadmap, not a product
• Start your OT zero trust programme with PODTECH
• Sources

Why does OT need zero trust now?

Most OT incidents don’t start in OT. They start in the IT network, where an attacker gains a foothold and then walks across an implicit trust relationship into the control environment. Dragos data and IEC 62443 mapping consistently point to IT to OT paths as the principal attack vector, often with attackers sitting inside the network for months before anyone notices.

Perimeter firewalls and the classic Purdue model assume that once you’re inside a layer, you’re broadly trusted. That assumption is the problem, not a feature.

• Perimeter defence fails once an attacker or compromised vendor credential is already inside.
• Purdue layers describe traffic flow, not identity or intent, so they don’t stop lateral movement within a layer.
• A breach in OT is not just a data problem. It can mean unsafe process states, halted production or physical damage.

What are the core zero trust controls for OT?

Adapting zero trust to OT means rebuilding four things: what you know you have, how you segment it, who gets access and how enforcement behaves when something breaks.

1. Asset inventory and tagging. An OT asset register must be authoritative, meaning it reflects every PLC, RTU, HMI and sensor, not just what’s convenient to scan. Passive network discovery plus engineering walk-downs typically closes the gap that active scanning alone leaves.
2. Zones and conduits. IEC 62443 groups assets by consequence and risk into zones, then documents every permitted flow between them as a conduit, complete with protocol, direction and justification. This conduit documentation is the artefact auditors and incident responders actually use.
3. PEP/PDP/PIP architecture. NIST SP 800-207 defines the policy enforcement point, policy decision point and policy information point that make up a zero trust architecture. In OT, the PDP is usually split: an enterprise PDP for policy authoring, and a local PDP at the plant that caches decisions and keeps enforcing them if the link to the enterprise goes down.
4. Microsegmentation and JITA/JEA. Industrial firewalls with deep packet inspection for protocols like Modbus or DNP3 enforce segmentation at the conduit level. Just-in-time, just-enough access limits standing privilege, but it needs fail-safes so an emergency response never gets stuck waiting on an access request.

The trade-off across all four is granularity versus latency. Finer segmentation means more policy decisions, and every OT deployment has a threshold, sometimes milliseconds, beyond which added checks are riskier than the threat they mitigate.

How should you sequence a zero trust rollout?

A phased, mission-focused rollout beats a big-bang deployment every time in OT, largely because it lets you validate safety before scaling anything.

1. Assess. Inventory assets, classify them by function and safety consequence, and use that consequence analysis to assign zones. SEI’s mission-focused assessment approach weighs mission context, system attributes, threat environment and dependencies before any control is chosen.
2. Pilot. Design conduits for a single contained cell or line, then deploy a local PDP and PEP there only.
3. Validate. Run safety testing against the pilot, confirm rollback procedures work, and monitor for false positives that could interrupt legitimate control traffic.
4. Scale. Extend the validated pattern zone by zone, tracking metrics as you go.

Track these at every stage:

• Availability and uptime against baseline, not just security events blocked.
• Policy rule usage, to catch conduits that are too permissive or too restrictive.
• Incident containment time, comparing pre and post segmentation.
• Operator friction reports, since a control nobody can work around safely gets bypassed.

Where does zero trust risk breaking OT operations?

Strict IT-style enforcement, applied without adaptation, is where zero trust for OT projects go wrong. A policy engine that blocks or delays a control command because of an expired certificate or a lagging identity check isn’t a security win. It’s a safety incident waiting to happen.

• Real-time control loops cannot tolerate the authentication latency that’s routine in enterprise IT.
• A PDP outage should never mean fail-closed plant stoppage; it should mean falling back to the last known-good local policy.
• Legacy PLCs and RTUs often can’t run modern agents, support modern cryptography, or generate the logs a PEP expects.

Local PDP caching with well-tested failover is the pattern that keeps recurring across DoD zero trust guidance and independent case studies alike: enforce locally, sync when you can, and never let a network hiccup become a plant stoppage.

How do you secure vendor and remote access to OT?

Third-party maintenance access is where most OT compromises actually enter, and it’s also where the strongest zero trust wins are available fastest.

• Route every vendor session through a jump host in the industrial DMZ, never a direct routable path into the control network.
• Issue short-lived, scoped credentials tied to a specific work order, with an operator approving the session before it opens.
• Record vendor sessions for audit and post-incident review, and terminate access automatically when the maintenance window closes.
• Enforce all of this through documented conduits, so a vendor gateway can never quietly become a permanent backdoor.

A 2025 case study on ZT-OT architecture found this pattern works well for securing remote access and BYOD scenarios in a water treatment system, though it also flagged that legacy devices without security support still need the compensating controls covered above.

Which standards and guidance should you follow?

You don’t need to invent an OT zero trust framework from scratch. Four documents cover almost everything a programme needs.

• CISA’s joint guidance on adapting zero trust to OT sets out priority activities: asset visibility, supply chain risk management and OT-adapted identity and access management.
• NIST SP 800-207 defines the PEP/PDP/PIP architecture that every OT-specific design should map back to.
• IEC 62443 provides the zones-and-conduits engineering model that turns segmentation from a network diagram into an auditable security artefact.
• DoD’s zero trust OT guidance, published in late 2025, lists 105 specific zero-trust activities and capability outcomes for high-assurance mission-critical environments, useful even outside defence contexts as a checklist of maturity.

Treat these as a stack, not a menu. CISA tells you what to prioritise, NIST tells you how the architecture fits together, IEC 62443 tells you how to engineer the segmentation, and DoD’s outcomes list tells you how far a high-assurance programme should ultimately go.

How does PODTECH deliver OT zero trust projects?

Engagement runs through dedicated teams, staff augmentation or managed services depending on how deeply an OT team wants day-to-day involvement.

• Delivery is phased against a mission-focused assessment, not a generic checklist.
• Engagement models flex from embedded staff augmentation to fully managed programmes.
• Case work spans safety-critical AI deployment, including the LifeSafety.ai construction safety platform, and automated compliance reporting through ReportZero.

What supply chain risks does zero trust for OT address?

OT environments inherit risk not only from their own devices and users, but from every vendor, integrator, software update, remote support workflow and maintenance dependency attached to them. Zero trust helps reduce that exposure by shrinking implicit trust across the supply chain.

• Vendor credentials are treated as high-risk by default, not as permanently trusted because the supplier is approved.
• Software and firmware updates can be validated through controlled paths, with approval, provenance checks and constrained deployment windows.
• Third-party tools are isolated to defined conduits, reducing the blast radius if a supplier environment is compromised.
• Access decisions can incorporate context, such as maintenance schedule, device posture, location and approved work order.

This matters because many of the most damaging OT intrusions exploit trusted relationships rather than technical novelty. A zero trust model does not eliminate supplier risk, but it does make that risk visible, bounded and auditable.

How does continuous monitoring work in OT under zero trust?

Continuous monitoring in OT is not the same as aggressive endpoint telemetry in enterprise IT. In industrial environments, monitoring has to respect deterministic systems, fragile devices and process safety constraints.

• Passive network monitoring is usually the starting point, because it provides visibility without disrupting control traffic.
• Baseline normal communications between zones, conduits, protocols and assets so deviations can be detected quickly.
• Correlate identity, device and network context rather than relying on any single signal.
• Feed monitoring outputs into local enforcement where appropriate, but only after validation that automated action will not create unsafe states.

In practice, continuous monitoring under zero trust means building a live picture of who is talking to what, through which conduit, under what conditions, and whether that behaviour matches the approved operating model.

How should incident response change under OT zero trust?

Incident response in OT zero trust becomes more precise, but also more dependent on preparation. The goal is not simply to detect compromise. It is to contain it without destabilising operations.

• Containment should be conduit-aware, so responders can isolate a path or zone without taking down unrelated process functions.
• Playbooks should distinguish safety systems from production systems, because the response options are not the same.
• Session recording and access logs improve forensics, especially for remote vendor activity.
• Rollback and failover procedures must be tested in advance, not invented during an event.

Zero trust does not replace OT incident response discipline. It strengthens it by making trust relationships explicit and by giving responders clearer enforcement points to work with.

Can zero trust work with legacy OT systems and protocols?

Yes, but not by pretending legacy OT can suddenly behave like modern cloud-native infrastructure. The practical answer is to apply zero trust principles around legacy systems, not blindly inside them.

• Use segmentation and protocol-aware gateways to control access to devices that cannot authenticate strongly themselves.
• Apply read-only replicas, historians or proxies where direct interrogation would be unsafe.
• Wrap unsupported assets with monitoring and policy controls at the network and session layer.
• Prioritise consequence over purity; a compensating control that preserves safety is better than a theoretically elegant control that risks downtime.

Legacy compatibility is one of the main reasons OT zero trust must be phased. You are often working with equipment that was never designed for modern identity, telemetry or cryptographic controls.

How is data protected within an OT zero trust framework?

Data protection in OT is broader than confidentiality alone. It includes integrity of commands, reliability of telemetry, provenance of engineering changes and controlled movement of operational data into enterprise systems.

• Protect command integrity so only authorised systems and users can issue control actions.
• Constrain data flows between zones and document why each conduit exists.
• Apply encryption where feasible, but only where it does not undermine device compatibility or timing requirements.
• Separate operational data consumers, such as historians, analytics platforms and remote dashboards, from direct control paths.

In OT, the most important data protection question is often not “is this secret?” but “if this data is altered, delayed or replayed, what happens to the process?”

What risk assessment approach fits OT zero trust?

The best fit is a mission-focused, consequence-led assessment rather than a generic control-gap exercise. OT security decisions should start with what the system does, what failure would mean and which dependencies matter most.

• Map critical functions and safety consequences before selecting controls.
• Identify dependencies across IT, OT and third parties, especially remote access and update paths.
• Assess threat realism, including likely attacker paths from enterprise networks into plant environments.
• Rank controls by operational value and implementation risk, not by how familiar they are to enterprise teams.

This approach keeps the programme grounded in operational reality. It also helps explain to plant leadership why some controls should move quickly while others need careful piloting.

How do you prepare OT personnel for zero trust adoption?

OT zero trust succeeds or fails with operators, engineers and maintainers. If the people running the process see controls as unpredictable obstacles, they will route around them. Preparation is therefore as much operational as technical.

• Train teams on the purpose of zones, conduits and access controls in operational language, not abstract security jargon.
• Rehearse emergency access procedures so JITA/JEA does not become a bottleneck during urgent maintenance.
• Include operators in pilot validation, because they will spot workflow friction before dashboards do.
• Build trust through predictability, clear rollback plans and visible support from engineering and leadership.

The cultural shift is simple to state but hard to implement: access becomes explicit, temporary and justified, while safety and uptime remain non-negotiable.

Zero trust for OT: practical roadmap, not a product

Zero trust for OT is not a box you buy and switch on. It is a design and operating model that has to be adapted to industrial reality. The practical roadmap is consistent across sectors:

1. Establish authoritative visibility of assets, communications and dependencies.
2. Engineer segmentation through zones and conduits, not cosmetic network separation.
3. Apply OT-suitable identity and access controls, especially for vendors and remote maintenance.
4. Enforce locally with resilient policy architecture so safety is not dependent on a distant control plane.
5. Scale only after validation proves the controls preserve availability and operator usability.

The organisations that do this well are not the ones that move fastest. They are the ones that sequence correctly, validate relentlessly and treat safety as the first design constraint rather than the last exception.

Start your OT zero trust programme with PODTECH

PODTECH helps organisations design and deliver OT security programmes that respect the realities of industrial operations. That means phased implementation, mission-focused assessment, resilient local enforcement and measurable outcomes tied to uptime, safety and containment.

• Assess your current OT trust boundaries and identify the highest-risk IT-to-OT paths.
• Build an authoritative asset and conduit model before enforcement changes begin.
• Pilot zero trust controls in a contained environment with rollback and safety validation built in.
• Scale with the right delivery model, from dedicated teams to managed services.

If you’re planning an OT zero trust programme and need a roadmap that works in live industrial environments, PODTECH can help you move from concept to controlled execution.

Sources

• CISA: Adapting Zero Trust Principles to Operational Technology
• NIST SP 800-207: Zero Trust Architecture
• SEI: Implementing Zero Trust in Operational Technology
• DoD CIO: Zero Trust Operational Technology Activities and Outcomes
• HICSS 2025: Compensating controls and zero trust patterns for OT
• OT network segmentation, zones and conduits reference