Executive summary. Operational technology (OT) and industrial control systems (ICS/SCADA) are now prominent ransomware targets, with remote access serving as a primary attack vector. Recent research shows that 58% of direct ransomware incidents in 2023 were linked to remote access vulnerabilities, and the number of ransomware groups targeting industrial organizations reached 80 in 2024, a 60% increase from the prior year. AppGate positions its Zero Trust Network Access (ZTNA) platform with an OT-ready architecture that integrates with jump servers and SCADA zones, aiming to supersede broad VPN access by implementing identity- and policy-driven controls based on frameworks such as IEC 62443, NERC CIP, and TSA pipeline directives.
1. Remote Access to ICS/SCADA: From Convenience to Primary Attack Vector
Ransomware and targeted attacks against OT environments have increased significantly. Dragos' 2025 OT/ICS Cybersecurity Report notes an increase in ransomware groups targeting industrial organizations to 80 in 2024, up from 50 in 2023. Manufacturing comprised more than half of observed victims. The report also notes 25% of ransomware incidents led to a full OT site shutdown, while 75% resulted in at least some operational disruption.
Remote access is central to this trend:
- At-Bay's 2024 InsurSec report found that 58% of direct ransomware incidents in 2023 were linked to remote access vulnerabilities. Self-managed Cisco and Citrix VPNs carried 11× higher ransomware risk than cloud-managed VPNs or environments without VPNs.
- Attackers increasingly target exposed remote services, moving beyond phishing. Dragos reports adversaries combine known vulnerabilities, weak remote access configurations, and exposed OT assets to reach ICS networks.
- In many industrial incidents, compromised VPN credentials or remote desktop access provide the initial entry, allowing lateral movement to engineering workstations, historians, or SCADA servers.
For ICS and SCADA, this risk is pronounced. Traditional remote access often provides:
- Persistent, network-level connectivity to entire OT segments
- Coarse controls based on IP ranges or static firewall rules
- Limited visibility into which assets or functions a remote engineer accesses
As OT networks converge with IT and cloud systems, broad network exposure combined with minimal governance amplifies the impact of a breach.
2. Why Zero Trust Network Access Is Moving into OT Networks
Zero trust architecture (ZTA) assumes no user or device is trusted by default, regardless of network location. NIST's SP 800-207 defines zero trust as approaches enabling accurate, per-request access decisions in environments where the network may be compromised. In practice, ZTNA enforces least-privilege, identity-centric access to specific applications or services instead of broad network reachability.
Recent adoption trends include:
- Okta's 2023 State of Zero Trust report found the percentage of organizations with a zero-trust initiative rose from 24% in 2021 to 61% in 2023.
- Gartner reported in April 2024 that 63% of surveyed organizations had fully or partially implemented a zero-trust strategy by late 2023.
Most early ZTNA implementations focused on IT applications-not on programmable logic controllers (PLCs), remote terminal units (RTUs), human-machine interfaces (HMIs), or SCADA servers.
OT security requirements complicate direct use of IT-centric ZTNA models:
- Many controllers and legacy SCADA systems cannot run agents and use proprietary or legacy protocols
- OT networks operate continuously with tight change and scanning restrictions
- Availability and safety outweigh confidentiality; new controls must not disrupt deterministic traffic or time-critical control loops
Industry standards such as IEC 62443 emphasize zones, conduits, and role-based security responsibilities for asset owners, integrators, and product suppliers. The IEC 62443 series includes IEC 62443-3-3 for system security, IEC 62443-4-1 for secure product development, IEC 62443-4-2 for technical requirements, and IEC 62443-2-3 for patch management. These documents stress least privilege, segmentation, and managed remote access-key zero-trust principles-without prescribing specific architectures.
As remote access attacks escalate, ZTNA designed for OT conditions now represents a strategic necessity rather than an optional enhancement.
3. Inside AppGate's OT-Ready ZTNA Architecture
AppGate's ZTNA platform, established as a software-defined perimeter solution, now features "OT-ready" architecture and mappings to NERC CIP and TSA pipeline directives, tailoring ZTNA for ICS/SCADA and critical infrastructure.
3.1 Direct-Routed ZTNA and Cloaked Infrastructure
AppGate employs a direct-routed ZTNA model. Instead of routing traffic through a multi-tenant cloud, the platform creates mutual-TLS tunnels directly between user devices and gateways near protected resources, either on-premises or in the cloud. A 2025 TSA pipeline solution brief describes this approach as reducing latency and bandwidth demands while enforcing granular access controls for critical OT systems.
Key enforcement mechanisms:
- Single Packet Authorization (SPA): Infrastructure is invisible until a valid SPA packet is received, blocking unauthenticated port scanning and service enumeration.
- Dynamic micro-firewalls: AppGate's 2024 overview describes "dynamic micro-firewalls" that instantiate per-session firewalls, combining per-user and per-resource entitlements to keep assets hidden.
- Context-aware policies: Access decisions are based on user identity, device status, time, location, and other attributes. Policies can restrict by role, shift, or operational state.
- Comprehensive logging: Gateways log each access event and can forward them to SIEM or SOAR platforms for centralized monitoring.
For ICS/SCADA, this reduces the attack surface: remote users see only explicitly sanctioned host:port combinations predefined in their entitlements, never generic network-level visibility into OT subnets.
3.2 OT-Ready Access: Jump Servers and SCADA Zones
AppGate's NERC CIP-focused materials address typical OT topologies in utilities and critical infrastructure. The OT-ready architecture integrates ZTNA with jump servers, engineering workstations, and SCADA zones, without needing wholesale network redesign or inline appliances.
Key aspects relevant to ICS/SCADA:
- ZTNA gateways are positioned in DMZs or at the OT/IT boundary (e.g., Purdue Level 3.5) to mediate lower-level control network access
- Supports scenarios where engineers connect to a jump host, with ZTNA controlling which SCADA servers or PLC ports can be reached
- Outbound-only connectors on port 443 from OT segments, minimizing the need for inbound firewall rules while enforcing strict egress control
This design matches IEC 62443's zones-and-conduits model, in which conduits provide managed communication paths between security zones of different levels.
3.3 Adaptive, Identity-Centric Access for Field and Vendor Users
AppGate's ZTNA features are mapped to specific OT regulatory and operational requirements:
- The NERC CIP solution brief links ZTNA capabilities-multi-factor authentication (MFA), least privilege, session logging, vendor isolation-to CIP-003 (remote access), CIP-005 (electronic security perimeters), and related standards.
- A TSA pipeline directive brief aligns ZTNA with requirements for segmentation, access control, continuous monitoring, patch management, and incident response.
Standout OT-specific features include:
- "No network-level visibility"-systems remain hidden until access is granted based on identity and context, enforced through SPA and policy evaluation before session establishment.
- Secure, direct-routed remote access to OT assets without central backhauling; SPA, SSO/MFA, device checks, just-in-time access, and full session logging are standard controls.
- Unpatched systems can be isolated within ZTNA zones, restricting access to authorized users for remediation and blocking wider exploitation.
These capabilities operationalize zero-trust principles such as least privilege, continuous verification, and micro-segmentation in OT environments sensitive to strict change controls and limited protocol support.
4. Alignment with IEC 62443 and Other Governance Frameworks
AppGate's OT-oriented documentation references alignment with frameworks such as NIST CSF, NIST SP 800-82, ISA/IEC 62443, NERC CIP, and TSA pipeline directives.
Key points include:
- Zones and conduits: IEC 62443 requires segmentation into zones with appropriate security levels, connected via conduits enforcing specific controls. Identity-based session controls and micro-firewalls can serve as logical conduits.
- Remote access and service provider controls: IEC 62443-2-4:2023 defines security requirements for IACS service providers, including architecture, remote access, logging, malware protection, patch management, and backups. ZTNA supports compliance efforts for these controls in multi-tenant settings.
- Patch management and unpatched assets: IEC 62443-2-3 and 3-3 recognizes some OT systems may lack timely patches, requiring compensating controls. Isolating such systems within ZTNA zones addresses this need technically.
- Auditability and monitoring: ZTNA session logs and feeds to SIEM/SOAR tools aid evidence collection for audits, including NERC CIP's CMEP and critical infrastructure oversight.
No ZTNA platform independently provides full compliance with IEC 62443 or NERC CIP. Governance demands layered technical and organizational controls. Nevertheless, OT-aware ZTNA forms a central enforcement layer alongside traditional firewalls and intrusion detection.
5. Comparative View: VPN, Generic ZTNA and OT-Specific ZTNA
The following table compares three approaches to securing ICS/SCADA remote access.
| Dimension | Legacy VPN / Jump Server | Generic IT ZTNA | OT-Specific ZTNA (e.g., AppGate ZTNA, OT-focused SRA platforms) |
|---|---|---|---|
| Exposure of OT assets | Network-level OT access, broad address ranges, limited asset cloaking | Application-level for IT workloads; OT assets often out-of-scope or exposed via shared connectors | SPA and micro-firewalls cloak OT endpoints; users see only authorized hosts and ports |
| Granularity of access control | Static firewall rules, IP ranges, shared VPN profiles; enforcing least privilege per role is difficult | Per-app policies for IT protocols; limited OT protocol support | Identity-, device-, and time-aware policies map to OT roles, maintenance windows, and operational states; "segments of one" for critical assets |
| OT system compatibility | Compatible with IP devices, but may bypass IEC 62443 zoning | Suited for HTTP(S) and modern protocols; OT integration typically requires workarounds | Designs directly reference PLCs, SCADA, workstations, and DMZ jump hosts; built for IT/OT boundaries |
| Network segmentation | Relies on static DMZ boundaries; VPN tunnels may cross zones, expanding blast radius | Enables micro-segmentation mainly for IT; OT often remains segmented separately | North-south segmentation, integration with micro-segmentation platforms, enforces both IT and OT zoning models |
| Handling of unpatched assets | Often connects unpatched OT devices directly to remote users | Focused on IT asset patching; limited for legacy OT nodes | Can isolate vulnerable OT systems in dedicated ZTNA zones, tightly controlling access |
| Auditability and governance | VPN logs capture source IP and tunnel duration, not resource-level activity | Good IT visibility; limited OT session tracking | Detailed session logs, SIEM/SOAR integration; control mapping to NERC CIP and IEC 62443 |
Other OT remote access vendors use similar approaches. For example, Secomea describes its platform as "purpose-built for OT/ICS," supporting clientless access to PLCs, HMIs, SCADA, DCS, and RTUs, and states certification under IEC 62443-4-1 and compliance with 62443-4-2 and 62443-3-3. The general trend is a shift from generic VPNs to OT-aware, zero-trust designs for industrial access.
6. Deployment Considerations in Brownfield OT Environments
Implementing OT-focused ZTNA in existing plants or critical infrastructure demands careful planning.
Key considerations include:
- Placement and integration: ZTNA gateways are usually situated in DMZs or the Level 3.5 OT/IT boundary, mediating Level 3 and below access. Integration must not bypass established safety controls.
- Agentless access: Most PLCs, RTUs, and SCADA devices lack the capacity for agents. ZTNA focuses on securing jump servers, engineering workstations, and proxies that mediate access to field devices.
- Change control and testing: Modifying access pathways can have complex effects. Controlled pilots, dedicated testing environments, and cross-functional collaboration are needed.
- Performance and latency: Direct-routed ZTNA reduces detour overhead, but policy checks add latency. Time-sensitive control loops typically remain local; ZTNA governs supervision and maintenance.
- Incident response and isolation: ZTNA policies enable swift containment by restricting or revoking access for compromised accounts. This function must integrate with established OT response processes.
Adoption of OT-specific ZTNA is more than a VPN replacement-it requires a thorough review of access, segmentation, and governance practices across IT and OT domains.
7. Actionable Conclusions and Next Steps
Escalating ransomware activity, remote access as a primary breach vector, and rising regulatory demands are impelling industrial enterprises toward identity- and policy-driven OT access.
Current data indicates 58% of direct ransomware incidents stem from remote access vulnerabilities, 70% of recent ICS vulnerabilities are deep in control networks, and 39% threaten both loss of view and control. Over 60% of organizations report zero-trust initiatives in place, though OT remains underserved in these efforts.
Practical steps for manufacturing, utilities, pipeline, and transportation operators:
- Inventory remote access paths: Document all external access mechanisms-VPNs, jump servers, RDP tools, and vendor tunnels-and compare against ransomware incident data.
- Map zones, conduits, and identities: Organize OT segmentation following IEC 62443, mapping all identities to their specific resource requirements.
- Define zero-trust OT policies: Translate operational roles to least-privilege, time-bound policies enforced through ZTNA.
- Pilot OT ZTNA: Initiate deployment on a targeted use case, like a single SCADA maintenance environment, before expanding.
- Integrate with governance and patch management: Connect ZTNA controls to risk assessments, IEC 62443 programs, and patch-management, employing isolation policies where patching is impractical.
AppGate's OT-ready ZTNA represents one approach to moving industrial access from perimeter-centric VPNs to policy-driven control. The wider industrial cybersecurity direction favors identity- and context-based models layered with segmentation and anomaly detection.
Frequently Asked Questions
How does OT-focused ZTNA differ from traditional VPNs for ICS/SCADA?
Traditional VPNs extend user network presence into OT segments, often granting broad IP access once connected. OT-focused ZTNA authenticates users and devices, evaluates context, and exposes only specific OT services-such as a single engineering workstation or SCADA host-through encrypted tunnels. Infrastructure often remains hidden until SPA and policy validation, and all connections are logged with asset-level detail.
Can OT ZTNA be deployed without agents on PLCs and RTUs?
Yes. Most OT ZTNA solutions are agentless for field devices. Control is enforced at jump servers, engineering workstations, and ZTNA gateways on the OT/IT boundary. Policies determine which downstream OT assets can be accessed, through which ports and for what duration, avoiding field device modifications.
Does adopting ZTNA automatically deliver IEC 62443 compliance?
No. IEC 62443 involves roles, risk management, and technical controls beyond any single solution. ZTNA can support managed remote access, least privilege, segmentation, logging, and compensating controls, but asset owners and providers still need organizational security programs, risk assessments, and incident response plans.
What performance impact does ZTNA introduce to latency-sensitive industrial processes?
Properly designed ZTNA deployments maintain control loops and safety systems within local OT networks. ZTNA governs supervision, configuration, maintenance, and monitoring where additional latency from policy enforcement and encryption is usually acceptable. Direct-routed models avoid unnecessary detours that might hinder operational workflows.
Where does OT ZTNA fit alongside firewalls and anomaly-detection platforms?
OT ZTNA complements perimeter firewalls, intrusion detection, and monitoring systems. Firewalls enforce static boundaries; anomaly detection analyzes network and process behavior. ZTNA adds an identity-centric layer, regulating sessions and providing audit trails for governance and response.
