Zero Trust Architecture - from concept to implementation in IT and OT environments

In December 2020, SolarWinds disclosed that an update to the Orion platform contained a backdoor installed by an APT group linked to Russian intelligence. The SUNBURST malware operated within the networks of over 18,000 organizations - including US government agencies, technology companies, and critical infrastructure operators. Firewalls, IDS systems, and VPNs were of no help because the attackers were already inside, moving laterally between systems with the privileges of trusted software.

This incident confirmed what John Kindervag described in 2010 and what NIST formalized in SP 800-207 in 2020: the security model based on network perimeters is fundamentally flawed. Not because firewalls don’t work - but because they assume something that cannot be guaranteed: that everything inside the network is trustworthy.

In this article, we break down Zero Trust Architecture into its component parts - from the seven NIST principles, through the CISA maturity model, to specific implementation challenges in OT environments where protocols like Modbus and PROFINET do not support authentication.

Source: Gartner (2024), DoD CIO (2025)

What is Zero Trust Architecture

Zero Trust is not a product or technology - it is a security model that eliminates implicit trust from network architecture. Every access - regardless of whether it originates from inside or outside the network - must be authenticated, authorized, and continuously validated.

NIST SP 800-207 defines ZTA architecture across two planes: control plane and data plane. This separation is fundamental - access decisions are made in a different layer than the actual data flow.

Control Plane - the brain of the architecture

The control plane consists of three logical components that collaborate on every access request:

Policy Engine (PE) - the brain of the system. It receives an access request and makes a decision (grant/deny/revoke) based on a trust algorithm - an algorithm that weighs multiple signals simultaneously:

Signal source	Example	Impact on decision
User identity	MFA confirmed, account active, role	Who is requesting access?
Device posture	EDR active, OS current, disk encrypted	Is the device trustworthy?
Location and context	IP, geolocation, time of day, network	Is the context normal?
Behavior	Anomalies vs baseline (e.g., impossible travel)	Is the behavior suspicious?
Threat intelligence	Known malicious IPs, IOCs, active campaigns	Is the environment safe?
Organization policies	Access rules per resource, data classification	What is allowed and what is not?

Policy Administrator (PA) - the translator. It receives the PE’s decision and configures enforcement mechanisms: generates session tokens, defines connection parameters (IP, port, key), opens or closes the communication channel.

Policy Enforcement Point (PEP) - the guard on the data plane. It physically blocks or allows traffic. The PEP is the only component that “touches” data - it can be an agent on a device, a network gateway, a reverse proxy, or a firewall.

Data Plane - the data flow

The data plane is the plane where actual communication between the user/device and the resource takes place. The PEP operates at the boundary of the data plane - allowing only traffic authorized by the control plane.

How an access request works - step by step

User/device → PEP [blocks by default]
                         ↓
                    PA (forwards request to PE)
                         ↓
                    PE [trust algorithm]:
                    ├── Check identity (IdP/MFA)
                    ├── Check device posture (EDR/MDM)
                    ├── Check context (location, time, network)
                    ├── Check threat intelligence
                    ├── Check access policies
                    └── Calculate risk score
                         ↓
                    Decision: GRANT (risk score < threshold)
                         ↓
                    PA → configures PEP (open channel, session X, timeout Y)
                         ↓
                    PEP [allows] → Resource
                         ↓
                    [Continuous validation - PE monitors session]
                    If risk score increases → PA → PEP [terminate session]

Control mechanisms implemented by ZTA components

Each component implements specific control mechanisms:

Component	Control mechanism	How it works
PE	Continuous authentication	Identity verification not only at login, but throughout the entire session
PE	Risk-based access	Decision depends on context, not just password and role
PE	Adaptive policies	Different requirements for the same resource depending on risk (e.g., office vs cafe)
PA	Session binding	Session tied to a specific device and identity - token cannot be transferred
PA	Just-in-time access	Privileges granted for the duration of a task, automatically expire
PEP	Default deny	Every connection blocked by default until PE issues a decision
PEP	Microsegmentation	Granular policies per workload/device/protocol
PEP	Protocol-aware filtering	In OT: allow Modbus Read, block Modbus Write from unauthorized sources

In practice, PE, PA, and PEP can be implemented as separate systems (e.g., SIEM/SOAR as PE, NAC as PA, firewall as PEP) or as an integrated platform (SASE/SSE, Microsoft Entra + Defender + Intune).

Seven principles of NIST SP 800-207

NIST formulated seven fundamental principles on which every Zero Trust implementation is based:

#	Principle	Practical implication
1	All data sources and computing services are resources	Not just servers - also printers, IP cameras, PLC controllers, IoT sensors
2	All communication is secured regardless of network location	Traffic within the corporate network requires the same encryption as traffic from the internet
3	Access to resources is granted on a per-session basis	Each connection requires separate authorization - no permanent “trusted” tunnels
4	Access is determined by dynamic policy	Decision considers identity, device state, location, time of day, behavior
5	The organization monitors the integrity and security posture of all assets	Continuous diagnostics, not a one-time audit - CDM (Continuous Diagnostics and Mitigation)
6	Authentication and authorization are dynamic and strictly enforced	MFA at login is not enough - validation continues throughout the session
7	The organization collects maximum information about the state of assets and communication	Telemetry from networks, endpoints, applications, and identity feeds the decision model

Three NIST deployment models

NIST describes three reference deployment models that differ in how the PEP is implemented:

Agent model (Device Agent/Gateway) - agent software on each device works with a resource gateway. Best control granularity, but requires the ability to install an agent - which in OT environments can be impossible.

Enclave Gateway model - protects groups of related resources behind a shared gateway. Equivalent to the zones and conduits concept from IEC 62443 - fits well with OT network segmentation.

Resource Portal model - a single access point for multiple resources, acting as a reverse proxy. Used in remote access to ICS systems scenarios, where service technicians connect through a central gateway.

CISA Zero Trust Maturity Model v2.0

In April 2023, CISA published the updated Zero Trust Maturity Model (ZTMM v2.0), which defines five pillars and four maturity levels. This model is mandatory for US federal agencies (OMB M-22-09), but serves as a practical roadmap for any organization.

Five pillars and four levels

Pillar	Traditional	Initial	Advanced	Optimal
Identity	Passwords, local accounts	MFA, central IdP	Continuous verification, session risk analysis	Phishing-resistant MFA, just-in-time access, full automation
Devices	No inventory	Basic MDM, antivirus	EDR/XDR, compliance check before access	Continuous posture validation, real-time isolation of compromised devices
Networks	Flat network, perimeter firewall	IT/OT macrosegmentation	Microsegmentation, east-west encryption	Dynamic segmentation, adaptive policies based on behavior
Applications	No inventory, no testing	Basic vulnerability scanning	DAST/SAST in CI/CD, WAF	Continuous testing, runtime protection, service mesh with mTLS
Data	No classification	Basic classification, perimeter DLP	Automatic classification, encryption at-rest and in-transit	Rights management (DRM), real-time access audit, tokenization

Three cross-cutting capabilities

In addition to the five pillars, CISA defines three capabilities that span every pillar:

1. Visibility and analytics - telemetry from every pillar feeds a shared decision model (SIEM/SOAR/XDR)
2. Automation and orchestration - policies enforced automatically, without manual intervention
3. Governance - policies, procedures, roles, and responsibilities defined and measured

Zero Trust in OT environments - specifics and challenges

Zero Trust principles were created in the context of IT environments, where every device has an operating system capable of running an agent, and communication protocols support encryption and authentication. OT environments are a different world.

Why OT is harder

Challenge	Description	Impact on Zero Trust
No authentication in protocols	Modbus, S7comm, EtherNet/IP have no auth mechanisms	Cannot verify identity at the protocol level
15-25 year lifecycle	PLC controllers, RTUs, DCS operate for decades without updates	No ability to install agents, no TLS support
Real-time requirements	Delays >10ms can cause process failures	Inline inspection and encryption can disrupt determinism
No agents	Many Level 0-1 devices lack computational resources for an agent	Forces network-centric rather than agent-based approach
Availability > confidentiality	Priority: the process must run, even at the cost of security	ZT mechanisms cannot block critical communication

DoD Zero Trust for OT (November 2025)

In November 2025, the Pentagon published the first comprehensive guide for implementing Zero Trust in OT environments - “Zero Trust for Operational Technology Activities and Outcomes.” The document defines:

• 105 ZT activities divided across 7 pillars (users, devices, applications & workloads, data, networks & environments, automation & orchestration, visibility & analytics)
• 84 target level activities - minimum required from every DoD component
• 21 advanced level activities - for systems with the highest risk level

Key DoD requirement: the Purdue model, IEC 62443, and UFC 4-010-06 remain authoritative frameworks for classifying OT systems. Zero Trust is a layer on top, not a replacement - it strengthens control at the zone boundaries that Purdue defines.

Purdue 2.0 - adapting the model to Zero Trust

The classic Purdue model assumes hierarchical segmentation (Level 0-5) with control at level boundaries. Purdue 2.0 preserves this hierarchy but adds:

• Microsegmentation within levels - not just boundaries between Level 2 (supervision) and Level 1 (control), but granular policies within each level
• Lateral movement control - restricting east-west communication between devices at the same level
• Cloud and XIoT integration - IIoT sensors, edge computing gateways, and cloud connections incorporated into the security model
• Compensating controls for devices without auth - protocol-aware allowlisting, unidirectional gateways, anomaly detection

CISA Microsegmentation Guidance (July 2025)

In July 2025, CISA published the guide “Journey to Zero Trust: Microsegmentation,” which identifies microsegmentation as the foundation of Zero Trust Architecture - including in OT environments. Key recommendations:

• Start with macrosegmentation (separating IT from OT networks), then move to microsegmentation within the OT zone
• Segment at the business function level (cell/area zones from IEC 62443), not just VLANs
• Use protocol-aware enforcement - filtering by protocol function codes, e.g., allowing Modbus Read (FC 03/04) while blocking Write (FC 05/06/16) from unauthorized sources

We describe the detailed approach to segmentation in a separate article: OT network segmentation.

Where Zero Trust doesn’t work - limitations and compensations

ZTA is not a universal solution. There are environments and scenarios where full implementation of Zero Trust principles is impossible or dangerous. The CISO must know where to apply ZTA, where to adapt, and where to compensate with other controls.

Safety Instrumented Systems (SIS)

Safety Instrumented Systems (SIS) - systems performing process safety functions (ESD, F&G, SIL 2+) - have an overriding requirement: they must always work. Adding inline ZTA mechanisms (encryption, per-session authentication) introduces:

• Latency - additional milliseconds can exceed the timing requirements of safety loops
• Single point of failure - failure of a ZTA component (e.g., PE unavailable) can prevent safety communication
• Certification complexity - changes in the SIS communication path require SIL revalidation

Recommendation: SIS should be physically isolated from the ZTA-covered network. Compensating controls: unidirectional gateway (data diode), hardcoded ACL on a dedicated firewall, passive anomaly monitoring (OT NDR in tap mode).

Legacy OT without authentication

PLC controllers and RTUs at Purdue Levels 0-1 (e.g., Modbus RTU, older S7-300) do not support any authentication or encryption mechanisms. You cannot install an agent on a controller with 64 KB of memory.

Recommendation: Enclave Gateway model - the PEP wraps a group of legacy devices, implementing control at the enclave boundary:

Control	How to implement without an agent
Authentication	At the enclave gateway (PEP), not on the end device
Authorization	Protocol-aware allowlisting: allow specific function codes from specific IPs
Monitoring	Passive NDR (Nozomi, Claroty) in tap mode - zero impact on latency
Encryption	IPSec tunnel between enclave gateways, not end-to-end to PLC

Real-time communication and determinism

Protocols with determinism requirements (PROFINET IRT, EtherCAT, Time-Sensitive Networking) do not tolerate additional delays. Inline inspection or per-packet encryption will disrupt the communication cycle.

Recommendation: Do not deploy inline ZTA on the real-time path. Instead: microsegmentation at the switch level (VLAN + ACL), passive monitoring, access control to the management network (not to the real-time network).

Fail-open vs fail-closed

The key question: what happens when the Policy Engine is unavailable?

Strategy	When to use	Risk
Fail-closed	IT networks, access to sensitive data	Availability - users cannot work
Fail-open	Safety-critical processes where lack of communication = threat to life	Security - potentially unauthorized access
Cached decision	Compromise - the last known PE decision remains valid for a defined period (e.g., 5 min)	Depends on cache TTL and risk change

Costs and organizational barriers

ZTA requires not just technology but a change in organizational culture. The most common barriers:

• Inventory - you cannot define policies for assets you don’t know about. Organizations with incomplete inventories must complete them before ZTA deployment
• User resistance - MFA, access restrictions, device compliance checks. Requires communication and buy-in from management
• Integration costs - ZTA connects multiple systems (IdP + EDR + NAC + SIEM + firewalls). Integration requires time and expertise
• Lack of skills - SANS 2025: only 14% of OT organizations feel fully prepared for new threats

Zero Trust technology stack - mapping to pillars

Zero Trust Architecture is not a single tool but an ecosystem of technologies. The table below maps solution categories to CISA ZTMM pillars:

Technology category	CISA pillar	Function in ZT architecture
IAM / IdP (Entra ID, Okta)	Identity	Central authentication point, SSO, conditional access policies
MFA / phishing-resistant auth (FIDO2, passkeys)	Identity	Eliminating the credential theft vector
PAM (CyberArk, Delinea)	Identity	Privileged account management, session recording, JIT access
EDR/XDR (CrowdStrike, Microsoft Defender)	Devices	Continuous posture validation, threat detection, isolation
MDM/UEM (Intune, Jamf)	Devices	Compliance check before access, configuration enforcement
Microsegmentation (Illumio, Guardicore, Zero Networks)	Networks	Granular east-west policies, limiting lateral movement
ZTNA (Zscaler Private Access, Cloudflare Access)	Networks	Replaces VPN - per-session access, no network exposure
SASE/SSE (Zscaler, Palo Alto Prisma, Netskope)	Networks + Applications	Consolidation of SWG, CASB, ZTNA, FWaaS into one platform
CASB (Netskope, Microsoft Defender for Cloud Apps)	Applications + Data	SaaS access control, shadow IT discovery, DLP
DLP / data classification (Purview, Forcepoint)	Data	Automatic classification, exfiltration blocking
SIEM/SOAR (Sentinel, Splunk, Chronicle)	Visibility	Telemetry correlation, automated incident response
OT NDR (Nozomi, Claroty, Dragos)	Networks (OT)	Passive OT protocol monitoring, agentless anomaly detection

Advanced detection mechanisms in ZTA architecture

Attackers adapt to ZTA. Session token theft, AiTM (Adversary-in-the-Middle) attacks, and MFA fatigue compromise are techniques for bypassing Zero Trust mechanisms. A mature architecture must account for these vectors.

UEBA - user behavioral analytics

User and Entity Behavior Analytics (UEBA) is a key component of the trust algorithm in the Policy Engine. UEBA builds a profile of normal behavior for each user and device, then assigns a risk score based on deviations:

Behavioral anomaly	Risk score impact	ZTA action
Login at unusual time	Low-medium	Step-up authentication (additional MFA)
Impossible travel (Warsaw → Singapore in 30 min)	High	Session block, SOC alert
Massive file download above baseline	Medium-high	Access restriction, DLP alert
New device used for privileged account	High	Require re-authentication + device enrollment
Lateral movement pattern (sequential access to many systems)	Critical	Immediate isolation, IR playbook

Defense against token theft and AiTM

AiTM (Adversary-in-the-Middle) attacks intercept session tokens after successful MFA - thereby bypassing authentication. In 2025, this vector became one of the primary methods of account compromise despite MFA.

Compensating controls:

• Token binding - tying the session token to a specific device (IP, device fingerprint). A token intercepted on another device is rejected
• Continuous Access Evaluation (CAE) - Microsoft Entra ID allows immediate token revocation (without waiting for TTL expiration) upon detecting anomalies
• Phishing-resistant MFA - FIDO2/passkeys do not send secrets over the network, so an AiTM proxy has nothing to intercept
• Compliant Network check - access only from the corporate network or via ZTNA (even with a valid token, an attempt from an unknown network is blocked)

AI in ZTA defense (2025+)

AI-powered SIEM and SOAR strengthen ZTA through:

• Automatic correlation of signals from multiple pillars (identity + device + network + data)
• Predictive risk analysis (identifying compromise before it materializes)
• Autonomous response (device isolation, token revocation, session termination without human intervention)

Case studies - lessons from deployments

Google BeyondCorp - 10+ years of experience

Google BeyondCorp is the oldest and most extensively documented ZTA deployment. Key lessons:

• No VPN - 130,000+ Google employees access resources without VPN, through BeyondCorp proxy verifying identity and device posture
• Long tail problem - migrating 80% of resources was relatively quick, but the last 20% required disproportionately more effort (specific applications, legacy systems, edge cases)
• Iterative approach - Google has been publishing BeyondCorp papers since 2014 and continues to iterate; ZTA is not a project with an end date
• Device Trust - Google requires the device to be managed and have a current trust certificate before the Policy Engine even considers the access request

DoD - Zero Trust at national scale

The US Department of Defense is deploying ZTA across all systems - classified and unclassified:

• 91 Target Level activities - minimum required from every DoD component by end of FY2027
• 61 Advanced Level activities - for highest-risk systems, by FY2032
• Navy pilot result - during testing with Microsoft Security, Navy personnel achieved 100% success across 91 Target Level activities
• Strategy 2.0 - the Pentagon plans to publish an updated ZT strategy in early 2026

Implementation roadmap - from quick wins to full architecture

Implementing Zero Trust is a multi-year project. The roadmap below describes three phases, from actions that can be taken within weeks to architecture transformation spanning 2-3 years.

Phase 1: Foundations (0-6 months)

Goal: eliminate the most common entry vectors without revolutionizing infrastructure.

• Enforce MFA on all accounts with remote and privileged access - phishing-resistant (FIDO2/passkeys) where possible
• Asset inventory - you cannot protect what you cannot see; a complete ICS asset inventory is the starting point for OT environments
• IT/OT macrosegmentation - if it doesn’t exist, a firewall at the IT-OT boundary with a DMZ is priority number one
• Deploy central IdP - consolidate identity management (Entra ID, Okta) with conditional access policies
• Disable inactive accounts - review and deactivate accounts unused for >90 days

Phase 2: Expanding controls (6-18 months)

Goal: transition from macrosegmentation to microsegmentation, deploy continuous monitoring.

• IT network microsegmentation - east-west policies at the workload and application level
• EDR/XDR on all IT endpoints and OT engineering workstations (Level 2-3)
• ZTNA instead of VPN for remote access - verify user and device before each connection
• PAM for privileged accounts - session recording, password rotation, just-in-time elevation
• OT NDR - passive monitoring in the OT network with no process impact; anomaly detection in industrial protocols
• Data classification and DLP deployment at the IT/OT zone boundary

Phase 3: Optimization and automation (18-36 months)

Goal: dynamic policies, automated response, continuous improvement.

• Microsegmentation in OT - granular policies at the cell/area zone level from IEC 62443
• Orchestration automation - SOAR playbooks responding to incidents without manual intervention
• Continuous validation - breach and attack simulation (BAS), regular red team penetration tests
• Threat intelligence integration - feeding the Policy Engine with current OT threat data
• Zero Trust at the OT application layer - mTLS for new protocols (OPC UA), protocol-aware allowlisting for legacy

Checklist: assessing your organization’s Zero Trust readiness

The list below allows you to assess where your organization is on the implementation journey. Every unchecked item is a potential attack vector that Zero Trust is designed to eliminate:

Identity

• Central IdP (Entra ID, Okta) for all users
• MFA on all accounts with remote access
• Phishing-resistant MFA (FIDO2/passkeys) for privileged accounts
• Automatic deactivation of inactive accounts (>90 days)
• Just-in-time access for administrative operations

Devices

• Complete inventory of IT and OT devices with current metadata
• EDR/XDR on workstations and servers
• Device compliance check before granting access
• BYOD policy with corporate data separation

Networks

• IT/OT macrosegmentation with DMZ
• IT network microsegmentation (east-west)
• Internal traffic encryption (mTLS, IPsec)
• ZTNA instead of classic VPN for remote access
• Microsegmentation in OT at the cell/area zone level

Applications and data

• Application inventory and classification (sanctioned vs shadow IT)
• WAF and DAST/SAST in the CI/CD pipeline
• Data classification and DLP policies
• Data encryption at-rest and in-transit

Visibility

• Central SIEM/XDR platform collecting logs from IT and OT
• OT NDR monitoring industrial protocols
• Automated alerts and SOAR playbooks
• Regular penetration tests and BAS

How to start

Zero Trust is not a one-time project but a shift in security philosophy. SolarWinds, Colonial Pipeline, FrostyGoop - each of these incidents confirmed that the perimeter model does not protect organizations against a determined adversary. Organizations that approach Zero Trust in phases - starting with identity and segmentation, and ending with automation and continuous validation - achieve measurable results without decision paralysis.

If your organization manages OT infrastructure, it is worth starting with an assessment of the current state of segmentation and access control. SEQRED performs IEC 62443 compliance audits, security architecture design, and microsegmentation deployments in industrial environments. We help transition from the perimeter model to Zero Trust without disrupting production processes - schedule a free initial consultation, during which we will assess your starting point.

Additional materials on remote work security and the Defense in Depth model in DCS systems can be found in our related articles.

Sources

• NIST SP 800-207 - Zero Trust Architecture (2020)
• CISA Zero Trust Maturity Model v2.0 (2023)
• CISA - Journey to Zero Trust: Microsegmentation Guidance (2025)
• DoD Zero Trust for Operational Technology Activities and Outcomes (2025)
• Gartner: 63% of Organizations Have Implemented Zero-Trust Strategy (2024)
• Gartner Predicts 10% of Large Enterprises Will Have Mature Zero-Trust Program by 2026 (2023)
• IBM Cost of a Data Breach Report 2025
• NIST SP 800-207A - Zero Trust Architecture Model for Cloud-Native Applications (2023)