Most organizations approach IT-to-OT connectivity as a single problem and deploy a single solution: a VPN for remote access, an MFT platform for file transfer, or a firewall for perimeter control. Each addresses one dimension of the connectivity challenge while leaving the others exposed.

A VPN provides remote access to OT systems – but does nothing to secure automated file transfers between ERP and MES, and provides no lateral movement controls once a user is inside the network. An MFT platform secures file exchange – but has no control over interactive application sessions or network segmentation. A next-generation firewall enforces perimeter rules – but cannot provide application-level access controls or manage the content of files crossing the IT/OT boundary.

The result is a patchwork of point solutions with policy gaps between them. In 2025, 75% of OT attacks originated as IT breaches that crossed into operational technology – exploiting exactly these gaps. Ransomware groups targeting OT rose 60% year-over-year. And 65% of OT environments had insecure remote access conditions, most at the IT/OT convergence boundary.

The January 2026 CISA/NCSC-UK joint guidance on OT connectivity calls for a layered approach that addresses data flows, access controls, and network segmentation as integrated – not independent – security domains. The DoD’s November 2025 Zero Trust for OT guidance defines 105 mandatory activities across identity, access, data, and network pillars. Neither framework is satisfiable by a single-layer solution.

This article introduces a three-layer model for IT to OT secure connectivity that addresses all three dimensions – secure data exchange, secure application access, and network segmentation – as a unified architecture. For security architects designing or upgrading IT/OT connectivity, this framework maps directly to IEC 62443, the Purdue Model’s zone-and-conduit requirements, and the 2026 government guidance.

The Three Layers Defined

IT-to-OT connectivity serves three distinct functions. Each function has different protocols, different threat models, and different security requirements. Treating them as a single problem guarantees that at least one function is either insecure or broken.

Layer 1: Secure Data Exchange

What it covers: Automated and manual file transfers between IT and OT environments – historian replication to ERP, patch distribution from IT to OT endpoints, configuration backups from PLCs to central repositories, compliance report exports, and ad-hoc file sharing between engineering teams.

Protocols involved: SFTP, FTPS, HTTPS, OPC-UA, MQTT, SMB, SCP, and proprietary file transfer protocols.

Why it needs its own layer: Files crossing the IT/OT boundary carry two risks simultaneously: they may contain malware that compromises OT systems, and they may contain sensitive operational data that should not leave the OT environment without controls. A secure data exchange layer must scan inbound files (AV, CDR/content disarm, DLP), encrypt files at rest and in transit (AES-256), enforce policy-based controls on file type, size, source, and destination, provide complete audit trails for every file movement, and support automated server-to-server transfers without human intervention.

What happens without it: Organizations fall back to USB drives, unencrypted email attachments, or direct SMB shares between IT and OT networks. The NCSC-UK’s 2025 guidance on Privileged Access Workstations in OT specifically warns against unauditable USB transfers and recommends that all file transfers to OT environments be “audited, authenticated, automated and inspected.” The 2025 Cl0p ransomware campaign exploited MFT platforms (Cleo, CrushFTP) to compromise organizations across the IT/OT boundary – demonstrating that even purpose-built file transfer solutions can become attack vectors if not properly hardened.

Layer 2: Secure Application Access

What it covers: Interactive human sessions between IT users and OT applications – remote engineers accessing SCADA HMIs, vendor technicians programming PLCs, operators viewing historian dashboards, and IT administrators managing OT infrastructure.

Protocols involved: RDP, SSH, VNC, HTTPS, proprietary PLC programming protocols (Siemens TIA Portal, Rockwell Studio 5000), Modbus/TCP for direct device interaction, and TN3270 for legacy mainframe access.

Why it needs its own layer: Application access requires real-time, bidirectional interaction – fundamentally different from file transfer. The security requirements are also different: identity-based, per-application access policies (not network-level access), multi-factor authentication with device posture verification, session recording with keystroke and screen capture for audit, time-bounded access with automatic expiration for vendor sessions, and zero inbound ports on the OT network – all connections initiated outbound from OT.

What happens without it: Organizations use VPNs that grant network-level access to the entire OT zone after a single authentication. In 2025, Claroty found that 82% of verified OT intrusions used internet-facing remote access tools (VNC, RDP via VPN) as the initial vector. Compromised credentials provided full network access, enabling lateral movement to SCADA servers, historians, and PLCs. The vendor who needed access to one PLC had the same network-level connectivity as a plant engineer with access to everything.

Layer 3: Network Segmentation

What it covers: East-west traffic controls within and between OT zones – preventing lateral movement after any breach, isolating safety systems from process control, separating vendor access zones from engineering zones, and enforcing communication policies between applications at the same Purdue level.

Technologies involved: Microsegmentation, identity-based firewalls, VLANs with inter-VLAN filtering, software-defined networking, and protocol-aware filtering for OT-specific protocols.

Why it needs its own layer: Layers 1 and 2 control north-south traffic – who and what crosses the IT/OT boundary. Layer 3 controls what happens after the boundary is crossed. Without east-west controls, a compromised session or a malicious file that passes through Layers 1 and 2 has unrestricted movement within the OT network. The SolarWinds breach demonstrated this pattern at scale – the initial compromise crossed a trust boundary, and then lateral movement through unsegmented networks enabled access to the most sensitive systems.

Network segmentation must isolate each zone within the Purdue hierarchy (Level 2 control systems isolated from Level 3 manufacturing operations), enforce identity-based communication policies between workloads (application A can communicate with application B but not C), restrict protocol usage per zone (Modbus/TCP allowed in Level 1–2 only; no IT protocols in control zones), and contain any breach to the smallest possible blast radius.

What happens without it: A compromised HMI at Level 2 can scan and reach every PLC, RTU, and safety controller on the same flat network. A former DHS official found that the average industrial network has 11 undocumented connections to IT systems. Without segmentation, each of those connections is a potential lateral movement path.

How the Three Layers Work Together

Each layer addresses a different connectivity function, but the layers are not independent – they reinforce each other. Here is how the three layers interact at each critical IT/OT boundary.

At the IDMZ (Purdue Level 3.5)

Layer	Function at the IDMZ	What It Prevents
Layer 1: Data Exchange	Historian replication from OT to IDMZ relay; patch staging from IT to IDMZ; file scanning (AV/CDR) before release to OT	Malware delivery via infected files; uncontrolled data exfiltration from OT
Layer 2: Application Access	Identity-verified, per-application access to SCADA HMI and PLC interfaces via outbound-only brokered connections	Unauthorized interactive access; credential-based network penetration
Layer 3: Segmentation	IDMZ microsegmented into functional zones (historian relay, patch server, access gateway) – each isolated from the others	Compromise of one IDMZ component spreading to others; pivoting from historian to access gateway

During Vendor Maintenance Sessions

Layer	Function During Vendor Access	What It Prevents
Layer 1	Vendor uploads firmware file → scanned in IDMZ (AV + CDR) → released to target PLC only after policy validation	Malicious firmware delivery; supply chain compromise via infected updates
Layer 2	Vendor authenticates at access gateway → receives application-level access to specific PLC programming interface only → session recorded, time-bounded to 4-hour window	Vendor accessing any system beyond their scope; unrecorded sessions; persistent access after maintenance ends
Layer 3	Vendor’s session is microsegmented – the PLC they are programming cannot reach other PLCs, SCADA servers, or safety systems during the session	Lateral movement from a compromised vendor session to other OT assets

During a Ransomware Attempt Crossing from IT

Layer	Defense Function	Outcome
Layer 1	Ransomware-laden file is caught by CDR scanning in the IDMZ before reaching OT	File never enters OT network – blocked at Layer 1
Layer 2	Even if file bypasses scanning, application access controls prevent the compromised IT session from interacting with OT systems (access requires separate authentication + device posture)	Attacker cannot establish interactive session to OT – blocked at Layer 2
Layer 3	Even if attacker reaches one OT system, microsegmentation prevents propagation to adjacent systems, historians, or safety controllers	Blast radius contained to single compromised asset – blocked at Layer 3

Architecture Comparison: Single-Layer vs. Three-Layer

Capability	VPN Only	MFT Only	Firewall Only	Three-Layer Integrated
Secure file transfer with scanning	No	Yes	No	Yes
Identity-based application access	No	No	No	Yes
Per-application access (not network)	No	No	No	Yes
East-west segmentation	No	No	Partial (perimeter only)	Yes
Session recording	No	No	No	Yes
Outbound-only OT connections	No	Possible	No	Yes
Zero inbound ports on OT	No	Possible	No	Yes
Vendor time-bounded access	Manual	No	No	Automatic
File content inspection (CDR/AV)	No	Yes	Partial	Yes
Compliance audit trail	Partial	Partial	Partial	Complete (all 3 layers)

Implementation Guide: Building the Three Layers

Step 1: Map All IT-to-OT Connectivity (Before You Build Anything)

Before deploying any technology, document every connection type crossing the IT/OT boundary:

Data flows: What files move between IT and OT? In which direction? How often? Via which protocol? Which ones are automated (server-to-server) and which are manual (human-initiated)? Which carry operational data outbound and which deliver patches/updates inbound?

Application sessions: Who accesses OT systems interactively? How many internal engineers, external vendors, and IT administrators? Which applications do they access? Which protocols? How often? Are sessions recorded? Is access time-bounded?

Network paths: Which network segments are connected across the IT/OT boundary? Are there undocumented connections (shadow IT)? Which segments communicate with each other within OT? Is any east-west traffic controlled?

This mapping reveals which of the three layers is most deficient in the current architecture – and where to start.

Step 2: Deploy Layer 1 – Secure Data Exchange (Weeks 1–8)

Start with data exchange because file-based attacks are the most common cross-boundary threat vector:

• Deploy a secure data exchange platform in the IDMZ that brokers all file transfers between IT and OT
• Configure inbound scanning: antivirus, content disarm and reconstruction (CDR), and DLP
• Implement outbound controls: data classification enforcement, encryption, and audit
• Replace direct SMB/FTP shares between IT and OT with brokered transfers through the IDMZ
• Eliminate USB-based transfers by providing secure, audited alternatives
• Verify: no file crosses the IT/OT boundary without scanning, encryption, and audit

For organizations in regulated sectors like banking, secure data exchange must also enforce regulatory controls – PCI DSS file handling requirements, DORA incident reporting for file-based incidents, and retention policies for audit trails.

Step 3: Deploy Layer 2 – Secure Application Access (Weeks 9–18)

Replace VPN-based remote access with identity-verified, application-level access:

• Deploy an access gateway in the IDMZ or DMZ that brokers all interactive sessions
• Configure outbound-only connections from OT to the gateway – zero inbound ports on OT firewalls
• Define per-user, per-application access policies (each user sees only the specific application they need)
• Implement MFA with device posture verification (FIDO2 keys or authenticator apps)
• Enable session recording for all cross-boundary sessions (engineering, vendor, administrative)
• Configure time-bounded access for vendors with automatic expiration
• Migrate application by application: start with the highest-risk remote access paths (vendor PLC programming, SCADA administration)

For government and federal environments, Layer 2 must integrate with PIV/CAC smartcard infrastructure and support on-premises deployment for classified or air-gapped networks.

Step 4: Deploy Layer 3 – Network Segmentation (Weeks 19–28)

Add east-west controls to prevent lateral movement within OT:

• Segment Level 3 (manufacturing operations) from Level 2 (control systems) with enforced policies
• Isolate safety systems (SIS) from process control systems in separate microsegments
• Deploy identity-based segmentation that controls workload-to-workload communication
• Implement protocol whitelisting at Level 1/0 boundaries (only Modbus, EtherNet/IP, PROFINET – no IT protocols)
• Microsegment the IDMZ itself – historian relay, patch server, and access gateway in separate segments
• Validate: run an internal penetration test specifically targeting lateral movement from one OT zone to another

Step 5: Validate the Integrated Architecture (Weeks 29–32)

Test all three layers working together:

• [ ] Attempt to send a malicious file from IT to OT – verify Layer 1 blocks it
• [ ] Attempt to access an OT application without proper authentication – verify Layer 2 denies it
• [ ] Attempt lateral movement from a compromised OT asset – verify Layer 3 contains it
• [ ] Run an external scan (Shodan/Censys) against OT IP ranges – verify zero discoverable services
• [ ] Verify complete audit trail coverage: every file transfer (Layer 1), every application session (Layer 2), every inter-zone communication attempt (Layer 3)
• [ ] Validate compliance mapping against IEC 62443, NIST SP 800-82, and applicable sector requirements

IEC 62443 Mapping: Three Layers to Seven Foundational Requirements

IEC 62443 FR	Primary Layer	How Addressed
FR1 – Identification & Authentication	Layer 2	Per-session MFA for all application access; per-transfer authentication for data exchange
FR2 – Use Control	Layer 2 + Layer 3	Per-application access policies (Layer 2); workload communication policies (Layer 3)
FR3 – System Integrity	Layer 1	File scanning (AV/CDR) prevents malicious content from reaching OT; change management for PLC updates
FR4 – Data Confidentiality	Layer 1	AES-256 encryption for files at rest and in transit; DLP enforcement on outbound data
FR5 – Restricted Data Flow	All Three Layers	Outbound-only file transfer (L1); outbound-only application access (L2); east-west policy enforcement (L3)
FR6 – Timely Response	All Three Layers	Immutable audit trails from file transfers, application sessions, and segmentation events
FR7 – Resource Availability	Layer 2 + Layer 3	Zero inbound ports eliminate DDoS surface (L2); segmentation contains incidents (L3)

Who Needs the Three-Layer Approach

If your organization only secures file transfer (MFT deployed, but remote access is VPN-based and no microsegmentation exists): You have Layer 1 but lack Layers 2 and 3. Remote access is your biggest vulnerability – the 82% of OT intrusions via remote access tools in 2025 exploited exactly this gap.

If your organization only secures remote access (ZTNA deployed, but files still cross via USB/email and OT networks are flat): You have Layer 2 but lack Layers 1 and 3. File-based attacks and lateral movement are your exposure.

If your organization only has firewall segmentation (perimeter firewalls between IT and OT, but no application-level controls or file scanning): You have partial Layer 3 but lack Layers 1 and 2. The firewall controls which traffic crosses the boundary, but does not inspect file content or enforce per-user application access.

If your organization needs all three: Most industrial organizations with converged IT/OT environments need all three layers. The question is which to deploy first – and the answer depends on which gap is largest in the current architecture.

Common Mistakes

Deploying Layers 1 and 2 but skipping Layer 3. Data exchange and application access secure the north-south boundary. Without east-west segmentation, any compromise that crosses the boundary – whether through a zero-day that evades scanning or a compromised insider session – has unrestricted lateral movement within OT.

Deploying three separate products from three separate vendors with no policy integration. The three layers must share a common policy framework. If the data exchange platform allows a file transfer that the network segmentation should have blocked, or if the application access layer permits a session to a system that segmentation has isolated, the layers conflict rather than reinforce. Unified platforms that deliver multiple layers from a single policy engine eliminate this integration risk.

Treating Layer 1 as “just FTP with encryption.” Secure data exchange is not simply encrypted file transfer. It requires content inspection (scanning for malware, verifying file integrity), policy enforcement (file type restrictions, size limits, source/destination controls), workflow automation (pre/post-transfer actions), and complete audit trails. An SFTP server with TLS is not a secure data exchange platform.

Applying Layers 1 and 2 at the boundary but not within OT. Inter-zone file transfers within OT (between Level 3 engineering workstations and Level 2 PLCs, for example) also need Layer 1 controls. Internal application access between OT zones needs Layer 2 identity verification. The three-layer model applies at every trust boundary – not just at the IT/OT perimeter.

Conclusion

IT-to-OT connectivity is not one problem – it is three. File transfer, application access, and network segmentation operate on different protocols, serve different functions, and face different threats. A single-layer solution – whether VPN, MFT, or firewall – addresses one function while leaving the other two exposed.

The three-layer approach provides comprehensive, defense-in-depth coverage across the entire IT to OT secure connectivity stack. Layer 1 secures data in motion between environments. Layer 2 secures interactive human sessions across the boundary. Layer 3 prevents lateral movement within the OT environment after any breach. Together, they satisfy IEC 62443’s foundational requirements, the CISA/NCSC-UK 2026 layered defense principles, and the DoD’s 105 mandatory Zero Trust activities for OT.

For security architects, the deployment sequence is determined by the current gap analysis: start with whichever layer is most deficient, but plan from the outset for all three. An MFT deployment without ZTNA leaves remote access exposed. A ZTNA deployment without segmentation leaves lateral movement unchecked. A segmentation deployment without data exchange controls allows malicious files through. The goal is not three separate tools – it is a single, integrated architecture that enforces consistent policy across all three dimensions of IT-to-OT connectivity.