Zero trust is the security model that removes implicit trust from the network and verifies every access on its own merits. Instead of trusting whatever is inside the perimeter, it asks every request to prove it should be allowed. In identity-rich IT, this is powerful and increasingly standard.
Applying zero trust to OT is harder. Many OT systems have no identity, speak protocols with no authentication, and cannot tolerate the overhead that zero trust mechanisms add. This article looks at what translates, what breaks down, and how reachability reduction provides a pragmatic path to the same goal.
01Key takeaways
- 01
Zero trust removes implicit network trust and verifies every access instead of trusting location.
- 02
Its core ideas, least privilege, microsegmentation and continuous verification, are valuable in OT.
- 03
It breaks down where OT systems lack identity, use unauthenticated protocols, or cannot tolerate added overhead.
- 04
The spirit of zero trust, never assume reachability is safe, maps directly onto reducing reachability.
- 05
A pragmatic OT zero-trust step is to remove standing access and make connectivity explicit and minimal.
02Zero trust basics
Zero trust replaces the old model of a trusted internal network behind a hard perimeter with one where no actor or system is trusted by default. Every access request is authenticated, authorized and verified against policy, regardless of where it comes from.
NIST describes zero trust architecture around principles like least privilege, per-request access decisions and continuous verification. The aim is to ensure that being on the network is not, by itself, permission to do anything.
Zero trust's core claim: location is not authorization. Every access must earn its allowance.
03Why OT challenges the model
Zero trust assumes a world of strong identity and the ability to verify every request. OT often provides neither, which is where the model strains.
- Many devices have no concept of user identity to authenticate.
- Industrial protocols frequently lack authentication and encryption entirely.
- Real-time constraints leave no room for the overhead of per-request verification.
- Legacy systems cannot run agents or modern security software.
- Availability requirements make aggressive blocking risky.
04What translates, and what does not
Rather than treating zero trust as all-or-nothing, it helps to separate the principles that survive the move to OT from the mechanisms that often do not.
- Translates well
- Least privilege, microsegmentation, removing implicit trust between zones, and verifying access at controlled boundaries rather than trusting the network.
- Translates poorly
- Per-device identity on legacy controllers, agent-based enforcement, and continuous per-request authentication on real-time protocols.
The lesson is to pursue zero trust outcomes through the means OT allows, often at the network and boundary level, rather than forcing IT mechanisms onto devices that cannot support them.
05Reachability reduction as a pragmatic zero-trust step
If a device cannot verify who is talking to it, the next best thing is to strictly limit what can talk to it at all, and when. This is zero trust expressed through reachability: never assume a path should be open just because it exists.
Removing standing access embodies the zero-trust default of denying by default. An AIRGAPNET controlled connectivity pattern can keep OT segments disconnected by default and open a path only for an explicitly approved, time-bound purpose, so connectivity is never implicit and always justified, even when the device itself cannot enforce that.
It is not a full zero-trust architecture, but it delivers the most important part of the intent: nothing is reachable simply because it happens to be on the network.
06Closing thought
Zero trust is a strong idea that does not transplant cleanly into OT. Taken literally, with per-device identity and continuous verification everywhere, it collides with legacy protocols, real-time limits and devices that cannot participate.
Taken as intent, never trust the network, always justify access, it fits OT well. Pursue it where OT allows, lean on segmentation and least access, and use reachability reduction to deny by default. Zero trust in OT is less about new agents on old devices and more about refusing to assume any path is safe.
FAQFrequently asked questions
What is zero trust?
Zero trust is a security model that removes implicit trust from the network and verifies every access on its own merits. Instead of trusting whatever is inside a perimeter, it requires each request to be authenticated, authorized and checked against policy.
Why is zero trust hard to apply in OT?
Many OT devices have no user identity, industrial protocols often lack authentication, real-time constraints leave no room for per-request verification overhead, legacy systems cannot run agents, and strict availability requirements make aggressive blocking risky.
What parts of zero trust work in OT?
Least privilege, microsegmentation, removing implicit trust between zones, and verifying access at controlled boundaries translate well. Per-device identity on legacy controllers, agent-based enforcement and continuous per-request authentication often do not.
How does reducing reachability relate to zero trust?
If a device cannot verify who is talking to it, the next best thing is to strictly limit what can reach it and when. Removing standing access and making connectivity explicit and time-bound embodies the zero-trust default of denying by default.
Can you achieve full zero trust in OT?
Rarely in the literal IT sense, because many devices cannot participate. But the intent, never trust the network and always justify access, is achievable through segmentation, least access and reachability reduction at the network and boundary level.
SRCSources of record
Never trust the path
Deny by default where devices cannot verify for themselves.
Express zero-trust intent in OT by removing standing access: keep segments disconnected by default and open a path only for an explicit, time-bound, approved purpose.