Zero Trust for Operational Technology

From OT-Specific Compensating Controls to a Governed Enterprise Edge

The October 8, 2026 National Security Agency (NSA) guidance and the Department of Defense (DoD) Zero Trust for Operational Technology (OT) Activities and Outcomes document strengthen the case for OT-specific implementation rather than one-size-fits-all adoption of IT security controls.

Origins and evolution (2023–2026). Beginning in 2023, IGEL® engaged in technical discussions with U.S. government cybersecurity practitioners on the operational challenges of applying Zero Trust cyber defenses to OT. The central question was how to establish identity, access, segmentation, visibility, and resilient controls around long-lived production systems without interrupting operations or requiring wholesale replacement. Subsequent work on the IGEL Adaptive Secure Endpoint Platform™ (IASEP™) and its ecosystem has focused on addressing those barriers through a governed access and execution layer around existing OT investments.

Operational technology cannot simply inherit IT security practices. Long-lived assets, safety and uptime requirements, original equipment manufacturer (OEM) dependencies, intermittent connectivity, and systems that cannot run agents require a risk-based Zero Trust approach. Those early discussions prioritized asset visibility, segmentation, compensating controls, identity, monitoring, and change governance. The updated architecture extends that foundation: standardize the human and application access endpoint while preserving the underlying industrial process and validated OEM systems.

The IGEL Adaptive Secure Endpoint Platform™ offers a governed operating foundation spanning IT workspaces and selected OT access and workload classes. The immutable IGEL OS™ and IGEL Preventative Security Model® reduce endpoint persistence opportunities; IGEL Universal Management Suite™ (UMS™) governs enrolled devices, configuration, applications, and lifecycle; IGEL Managed Hypervisor™ (IMH™) enables centrally managed and secure virtual-machine workloads on IGEL OS™; and IGEL Managed Containers™ (IMC™) delivers container images to IGEL OS™. IGEL Trusted Macro Secure Enclave™ (TMSE) describes a trusted policy-extension architecture, while IGEL Management Interface™ (IMI™) provides an integration interface to complementary management systems, including policy-related integrations where implemented. External policy decision points and network infrastructure remain responsible for their respective authorization and enforcement functions.

The delivery model reflects an evolution from workspace delivery to IGEL IT for OT™, with three layers of contextual access (device, persona, and conditional context), explicit division of policy responsibilities across IGEL UMS™ and partner engines, and staged support for virtual machines, managed containers, local Linux apps, Progressive Web Apps (PWAs), enterprise browsers, and VDI/DaaS solutions. These patterns provide an approach to implementing and documenting OT Zero Trust controls while preserving the underlying industrial control systems.

The DoD Zero Trust for OT Activities and Outcomes document includes 105 activities (84 Target, 21 Advanced). The mapping in this article is illustrative, not an official compliance determination or a claim of NSA/DoD endorsement.

The OT Zero Trust problem: protect operations without disrupting them

OT comprises heterogeneous supervisory and operational endpoints, human-machine interfaces (HMIs), engineering stations, manufacturing execution system (MES) clients, historians, warehouse terminals, operator panels, and industrial control devices. Control-system availability, determinism, safety, validation, and original equipment manufacturer (OEM) supportability constrain patching, encryption, authentication, and agent deployment. The access endpoint is often the most practical point to standardize while leaving process controllers and validated applications intact.

Constraint	Zero Trust response	Acceptance evidence
Unpatchable or unsupported systems	Isolate, restrict pathways, virtualize selected access workloads, and document compensating controls	Asset owner approval, communication allowlist, recovery test
Shared or continuously visible HMIs	Persona-based session control, badge/PIN or multifactor authentication (MFA) where safe, session continuity	Operator workflow and fail-safe testing
Multiple OEM protocols and access methods	Broker browser, RDP, approved agents, and selected local runtimes	Peripheral, latency, licensing, and OEM qualification
Disconnected or highly available sites	Local policy behavior, bounded offline operations, change windows	Site-level failure and recovery exercises

The strategic shift is toward a defense-in-depth approach that strengthens security across OT environments. By combining a secure endpoint foundation with identity-based access controls, network segmentation, and centralized management, organizations can apply consistent security protections across HMIs, MES terminals, engineering workstations, and other critical OT systems while supporting operational continuity.  

This is a practical way to advance Zero Trust outcomes across factory floors without claiming to replace programmable logic controllers (PLCs), safety systems, OEM control systems, industrial segmentation, or specialized OT monitoring. 

Architectural model: control, execution, integration, and workload planes

Execution foundation: IGEL OS™, IGEL Preventative Security Model®, and IGEL Trusted Macro Secure Enclave™ (TMSE)

An immutable, read-only endpoint platform reduces an organization’s overall writable surface and supports a consistent known-good configuration. TMSE describes a trusted policy-extension architecture and boundary, not a claim that all silicon-to-cloud attestation capabilities are generally available. Trusted Platform Module (TPM) and measured-state evidence, workload isolation, and cryptographic binding to upstream policy decisions are potential extensions that require partner-specific engineering and validation.

IGEL UMS™ as endpoint governance and evidence source

IGEL UMS™ provides endpoint enrollment, device and configuration inventory, application assignment, profiles, updates, and lifecycle governance. Supported integrations can expose relevant device context to network access control (NAC) and external policy engines.

IGEL UMS™ does not independently replace enterprise NAC, policy decision points, or network enforcement infrastructure. Platforms such as Cisco Identity Services Engine (ISE), ForeScout, and associated network controls perform their respective authorization and enforcement functions according to the deployed integration. Device records and configuration data can contribute to governance evidence, subject to appropriate collection, retention, and validation.

IMH™, IMC™, and IMI™: managed workload and policy interfaces

Component	OT role	Design boundary
IMH™	Run selected legacy Windows or other supported VM workloads on IGEL-managed endpoints	Validate VM OS licensing, OEM support, drivers, I/O passthrough, timing, and current IGEL UMS™ orchestration features
IMC™	Deploy governed OCI-compatible Linux container workloads	Rootless Podman, hardware/OS prerequisites, and supported Compose subset; not a general PLC runtime
IMI™	Integration pattern for exchanging identity, device state, policy, and partner signals	API schema, attestation freshness, enforcement ownership, and availability of specific integration capabilities must be validated

Standardizing access to MES, WMS, HMI, and the wider factory floor

The practical modernization opportunity is interface convergence. Industrial OEMs increasingly offer MES, WMS, HMI, and supervisory applications through browser interfaces, vendor agents, and VDI/DaaS sessions. This reduces the need for a unique endpoint operating stack for every machine or production application. A common IGEL-managed access endpoint can present these heterogeneous applications while IGEL UMS™ standardizes configuration, application entitlement, and endpoint lifecycle across production, warehouse, engineering, and enterprise IT use cases. OEM-specific drivers, latency, safety, offline operation, and qualification still require per-use-case validation.

This is IT/OT convergence at the access and execution layer, not the displacement of PLCs, safety controllers, or OEM process-control systems. It allows OT to retain production applications while IT and OT jointly govern the endpoint boundary, identities, network permissions, and change controls.

Modern OT OEM offerings increasingly expose browser-based operator interfaces, remote display protocols, gateway agents, API integrations, and container-friendly components. This is an architectural opportunity, not a claim that all OEMs support one standard. A common IASEP™-managed access endpoint can support access to applications from vendors such as Siemens, Rockwell, Honeywell, Körber, and SAP through appropriate browser, agent, or remote-session delivery methods, subject to validation of the specific application, OEM requirements, and safety controls.

IGEL UMS™ is the central configuration, enrollment, and endpoint-context control point for devices running IGEL OS™. In an integrated comply-to-connect architecture, IGEL UMS™ can supply device identity, approved configuration, and assigned application context to external NAC and policy engines, such as Cisco ISE or ForeScout. The NAC infrastructure and network switches/firewalls, not IGEL UMS™ alone, make and enforce the relevant network admission and segmentation decisions. Likewise, secure remote access requires an integrated identity, gateway, broker, or Zero Trust Network Access (ZTNA) service with authorization, session control, and audit. This division of responsibility prevents the inaccurate claim that IGEL UMS™ independently replaces every NAC, privileged access management (PAM), or remote-access platform.

The desired default-deny pattern is to admit only approved, enrolled IGEL endpoints to designated access paths and to deploy only authorized, curated applications sourced from the IGEL App Portal™ and managed through IGEL UMS™. Unmanaged or unknown devices should be denied, quarantined, or routed to a separate onboarding workflow according to network policy. This can reduce shadow IT and unapproved software, but does not automatically discover or eliminate all unmanaged OT assets. Complete asset inventory requires complementary discovery and reconciliation with a configuration management database (CMDB), passive OT monitoring, and OEM asset records.

Microsegmentation can be applied at the device or workload-access level when supported by the external enforcement infrastructure and endpoint context; ISA/IEC 62443 zone-and-conduit segmentation provides the broader industrial design. Apply the least-disruptive boundary consistent with safety and availability. For example, an operator HMI may be authorized only to its designated MES gateway and plant services, while an engineering workstation requires time-bound, logged access to a specific controller zone. These policies must be tested against continuous display, shift change, and loss-of-connectivity scenarios.

Pattern	Example use	Zero Trust control opportunity
Secure Enterprise Browser	MES web UI, work instructions, dashboards, WMS, cloud SaaS	Identity, conditional access, session/data policy, limited local persistence
VDI / DaaS	Legacy Windows HMI or MES client, engineering app	Session isolation, authenticated broker, remote-host controls
Approved local agent / app	Scanner, badge, industrial peripheral, OEM client	Application allowlisting, signed distribution, device policy
IGEL Managed Hypervisor™ virtual machine	Legacy Windows application tied to a shop-floor workflow	Host isolation and managed recovery with qualified peripheral support
IGEL Managed Containers™	Run local service at the edge to process machine data, reduce network dependency	Container lifecycle, constrained permissions, network allowlists

A managed endpoint does not grant authority over all equipment on the floor. Programmable logic controllers (PLCs), safety instrumented systems, drives, and embedded controllers require separate controls, asset inventories, network segmentation, and process-owner authorization.

Policy integration and comply-to-connect

The target design separates the policy information point (IGEL UMS™ device and configuration state), policy decision point (enterprise identity and access management (IAM)/NAC/secure access service edge (SASE) or other designated engine), and policy enforcement points (network switch, firewall, ZTNA gateway, application, browser, and endpoint controls). A proposed extension of IMI™ could carry signed, fresh device-state evidence and challenge/response material, subject to partner-specific engineering and validation. A policy engine then decides whether a specific identity, endpoint, application, and OT zone may communicate.

Example flow: enroll endpoint in IGEL UMS™; assign device certificate and approved profile; verify operator identity and role; collect relevant posture; transmit evidence to an integrated NAC/policy engine; authorize only the necessary MES/HMI/WMS destination and protocols; continuously evaluate material changes; revoke or restrict access without creating unsafe process behavior. Emergency operating procedures and break-glass pathways require explicit design and audit.

A second insight from the multiyear effort is that Zero Trust outcomes can serve as a common control-and-evidence backbone for multi-framework governance. Controls such as asset identification, least privilege, segmentation, configuration integrity, monitoring, incident response, and lifecycle governance have corresponding objectives in ISA/IEC 62443, NIST SP 800-53, NIST CSF 2.0, and sector-specific regimes. Mapping one implemented control to multiple requirements reduces duplicate engineering and audit work, but does not make the frameworks interchangeable: each retains distinct scope, assurance, safety, documentation, and assessment requirements. This article therefore proposes a requirement-to-control-to-evidence crosswalk, with gaps and compensating measures explicitly recorded.

Zero Trust outcomes and multi-framework governance

DoD Zero Trust pillar	IASEP™ contribution	Complementary control / evidence
User / Identity	Persona-based application assignment and session access integration	IAM, MFA/PAM, privileged account logs
Device	IGEL UMS™ enrollment, IGEL OS™ configuration, and managed state	NAC posture decisions, inventory, attestation validation
Network / Environment	Policy context for comply-to-connect	Industrial firewalls, zones/conduits, ISE/ForeScout, data diodes
Applications / Workloads	Curated delivery, browser, VDI/DaaS, IMH™, IMC™	OEM hardening, allowlists, application identity, and runtime monitoring
Data	Reduce local storage and govern access pathways	Data loss prevention (DLP), browser controls, encryption, historian/data governance
Automation / Orchestration	IGEL UMS™ profiles, lifecycle, and APIs	Security orchestration, automation, and response (SOAR)/change control, safe rollback, and human approvals

Mapping basis: DoD Zero Trust for Operational Technology Activities and Outcomes; NSA October 2026 OT guidance; NIST SP 800-207, SP 800-82 Rev. 3 and SP 800-53; ISA/IEC 62443 zones/conduits and lifecycle requirements; NIST CSF 2.0. A controls workbook should record each authoritative requirement ID, required control, product contribution, external dependency, evidence of record, owner, status, and residual gap. No blanket certification or compliance claim follows from using IASEP™.

OT deployment reference architecture and decision gates

Logical access path: operator / engineer identity → endpoint managed within IASEP™ (IGEL OS™, TMSE, approved browser/RDP/agent and selected VM/container workloads) → access governed by external IAM/NAC/ZTNA controls → segmented industrial network → OEM MES/WMS/HMI applications or supervisory control and data acquisition (SCADA) systems → PLC/process domain.

Management and evidence: IGEL UMS™ governs endpoint enrollment, configuration, and policy, with integration through supported interfaces such as IMI™ where applicable. Relevant device records and security logs can support OT monitoring, SOC activities, and governance evidence where configured. Safety and process controls remain independent.

Pilot acceptance gates

1. Inventory and classify all target devices, OEM interfaces, zones, identities, and dependencies.
2. Establish a known-good endpoint and documented compensating controls.
3. Test NAC decisions, isolation, and revocation without unsafe downtime.
4. Qualify browser/RDP/agent and any VM/container input/output (I/O), latency, failover, and peripheral behavior.
5. Demonstrate change approval, rollback, recovery, and audit evidence.
6. Expand site by site with OT engineering sign-off and operating procedures.

Discussion questions for government and critical-industry stakeholders

• Which OT endpoints can be governed without touching controllers?
• Which systems cannot tolerate reauthentication or network disruption?
• Who approves compensating controls and risk acceptance?
• What authoritative source binds device state to user and workload access?
• Which OEM interfaces can be standardized today?
• What evidence proves compliance to connect and safe recovery?
• Which Target/Advanced Zero Trust outcomes remain dependent on external policy, segmentation, monitoring, or process controls?