How to Secure OT Networks Without Opening Inbound Firewall Ports

TL;DR

Every inbound firewall port opened to an OT network is an attack vector. In 2025, 82% of verified OT intrusions began through VNC connections exposed to the internet, 65% of OT environments had insecure remote access conditions, and 75% of all OT attacks originated as IT breaches that crossed into operational technology through open conduits. IEC 62443 mandates zone-and-conduit segmentation with strict control over inter-zone communication – yet the standard architecture for remote OT access still requires opening inbound ports for VPN concentrators, jump servers, or remote desktop gateways.

There is an alternative. Reverse-access architecture eliminates inbound ports entirely by having the OT-side component initiate all connections outbound. The firewall remains in permanent deny-all for inbound traffic. No open ports means no discoverable attack surface – nothing to scan, nothing to exploit, nothing to target with DDoS. This article provides the technical architecture, implementation steps, compliance mapping, and real-world scenarios for securing OT networks with zero inbound exposure.

The Inbound Port Problem in OT Security

Opening an inbound firewall port to an OT network does three things, all of them dangerous.

It creates a discoverable target. Internet scanning tools like Shodan, Censys, and ZoomEye continuously index every open port on the internet. An inbound port on an OT firewall – whether for a VPN, jump server, or SCADA web interface – is discoverable within hours of being opened. In 2025, Claroty reviewed over 200 OT attacks and found that attackers overwhelmingly used freely available tools (UltraVNC, TightVNC, Metasploit, modbus-cli) to exploit internet-facing OT services. The attacks were not sophisticated. They did not need to be – the ports were open.

It violates the zone-and-conduit model. IEC 62443 Part 3-3 defines security zones and conduits as the foundational architecture for OT protection. The standard explicitly requires that all inter-zone communication be controlled, and that conduits enforce the security requirements of the highest-sensitivity zone they connect to. An inbound port from the internet directly into an OT zone bypasses this model entirely – it creates an uncontrolled conduit from the lowest-trust zone (internet) to the highest-sensitivity zone (control systems).

It exposes systems that cannot defend themselves. OT devices – PLCs, RTUs, HMIs, SCADA servers – were designed for reliability and real-time performance, not for adversarial security. They run legacy operating systems, use unencrypted protocols (Modbus/TCP, DNP3, OPC-DA), and often cannot be patched without production downtime. Exposing these systems to internet-originating traffic, even through a firewall, puts them in a threat environment they were never built to survive.

The Numbers Behind the Risk

Statistic	Source
82% of verified OT intrusions in 2025 used VNC as the initial access vector	Claroty, 2026
65% of OT environments had insecure remote access conditions	Dragos OT Cybersecurity Report, 2025
75% of OT attacks originate as IT breaches that cross into OT	Zero Networks / Industry data, 2025
45% of organizations with OT had SSH communicating to publicly routable addresses	Dragos, 2025
Ransomware groups targeting OT rose 60% year-over-year	Dragos, 2025
OT ransomware attacks spiked 87% YoY in manufacturing	Dragos, 2025
Manufacturing accounts for 42% of OT attack detections	Trellix, 2025
Average OT vulnerability patching time: 180 days (vs. 30 days for IT)	Trellix, 2025
50%+ of organizations reported at least one ICS/OT security incident	SANS Institute, 2025
820,000 IoT/OT hacking attempts per day globally	DeepStrike / Industry data, 2025

How Reverse-Access Architecture Eliminates Inbound Ports

The Traditional Remote Access Model (Inbound)

In a conventional OT remote access setup, the architecture requires an inbound connection path:

A VPN concentrator or jump server sits in the OT DMZ (IDMZ)
The firewall opens an inbound port (typically TCP 443, 3389, or 22) to this device
Remote users (engineers, vendors, operators) connect inbound through this port
After authentication, the session is proxied or tunneled into the OT network

The problem: the VPN concentrator, jump server, or remote desktop gateway is internet-facing. It has a public IP address. It listens on an open port. It is discoverable and targetable. Every CVE in the VPN software, every misconfigured access rule, every brute-forced credential becomes a direct path into OT.

This is not hypothetical. The Colonial Pipeline attack (2021) originated through a compromised VPN credential. The Oldsmar water treatment facility attack (2021) exploited an internet-facing TeamViewer connection. The 2025 Claroty report found that the vast majority of OT compromises used exactly this pattern – internet-exposed remote access tools with weak or stolen credentials.

The Reverse-Access Model (Outbound-Only)

Reverse-access architecture inverts the connection flow:

A lightweight connector is deployed inside the OT network (or in the IDMZ)
The connector initiates an outbound-only connection to an access gateway
The firewall permits only outbound traffic from the connector – zero inbound ports are opened
Remote users authenticate to the access gateway, which routes their session through the existing outbound tunnel
The OT network has no listening services, no open ports, and no public IP address

The critical security property: the firewall is in permanent deny-all for all inbound traffic. There is nothing to scan, nothing to probe, nothing to brute-force. The OT network is invisible to the internet.

Architecture Comparison

Property	Traditional (Inbound)	Reverse-Access (Outbound-Only)
Firewall inbound ports	1+ open (VPN, RDP, SSH)	Zero – permanent deny-all
Internet-discoverable services	Yes (VPN concentrator, jump server)	None – invisible to scanning
Attack surface for DDoS	VPN/gateway is targetable	No target exists
VPN CVE exposure	Direct – exploit reaches OT network	Eliminated – no VPN in the path
Credential brute-force risk	VPN login page is internet-facing	Authentication occurs at gateway, not at OT boundary
IEC 62443 conduit compliance	Conduit opens from low-trust to high-trust zone	Conduit initiated from high-trust zone outward
Shodan/Censys visibility	OT gateway appears in scan results	Nothing to index
Lateral movement after compromise	Attacker enters network with VPN-level access	Session is application-specific, microsegmented

Real-World Scenario: Water Utility Remote Access

The Problem

A municipal water utility needs to provide remote access for three use cases: on-call engineers monitoring SCADA systems after hours, a PLC vendor performing quarterly firmware updates on treatment plant controllers, and the state environmental agency accessing compliance reporting dashboards.

Traditional approach: The utility opens TCP 443 for a VPN concentrator in the IDMZ. All three user groups connect through the VPN, which grants network-level access to the SCADA zone. The PLC vendor’s session uses the same VPN tunnel as the engineer’s monitoring session. Firewall rules attempt to restrict lateral movement, but the VPN provides Layer 3 connectivity to the zone – any device reachable on the network is potentially accessible.

Reverse-access approach: The utility deploys a connector inside the IDMZ that initiates an outbound connection to a Zero Trust access gateway. The firewall remains in deny-all for inbound traffic. Each user group receives a separate, application-specific access policy:

On-call engineers receive access to the SCADA HMI web interface only – no network-level access, no PLC programming ports, no database connectivity.
PLC vendor receives time-bounded access (4-hour window) to the specific PLC programming interface only, with session recording enabled. Access automatically expires and cannot be renewed without re-approval.
Environmental agency receives read-only access to the compliance reporting dashboard – no access to SCADA, no access to PLCs, no access to any other system.

No inbound ports are opened. No VPN is deployed. Each user sees only the specific application they are authorized to access. The firewall’s deny-all state is never modified.

Case Study: Manufacturing Plant IT/OT Convergence

Background

A multinational manufacturer operates 12 production facilities with Siemens S7 PLCs, Rockwell Allen-Bradley controllers, and Wonderware InTouch HMI systems. The IT team needs to collect production data for ERP integration (SAP). Maintenance vendors need quarterly access for PLC programming. The corporate SOC needs to ingest OT security logs into Splunk.

Before: Open Inbound Ports

The plant network had the following inbound paths:

TCP 443: Cisco AnyConnect VPN for remote engineering access
TCP 3389: RDP jump server for vendor PLC programming
TCP 502: Modbus/TCP exposed through a NAT rule for a third-party analytics tool
TCP 5900: VNC to HMI stations for remote troubleshooting

A penetration test revealed that the VPN concentrator was running firmware with three known CVEs. The Modbus port was discoverable on Shodan. The VNC sessions used default credentials. The RDP jump server had not been patched in 14 months.

After: Reverse-Access Architecture

The plant eliminated all inbound firewall ports and deployed reverse-access connectors in the IDMZ:

ERP integration: An outbound OPC-UA Secure connection pushes production data from the historian to a relay in the IDMZ. SAP reads from the relay. No IT system has any inbound path to OT.
Vendor PLC programming: Vendors authenticate at the access gateway, which routes their session through the outbound connector to the specific PLC programming interface. Sessions are recorded, time-bounded, and require approval. Identity-based access controls verify vendor identity, device posture, and authorization before granting access.
SOC log ingestion: OT security logs are pushed outbound from the IDMZ to Splunk via syslog-over-TLS. The SOC has no inbound path to OT.
Remote troubleshooting: Engineers authenticate at the gateway and receive application-level access to specific HMI web interfaces – no VNC, no RDP, no network-level connectivity.

Result: Shodan scan of the plant’s IP range returns zero results. The firewall audit shows deny-all for all inbound rules. The penetration test finds no externally exploitable services.

IEC 62443 Compliance Mapping

Reverse-access architecture maps directly to IEC 62443 requirements. Here is how each foundational requirement is addressed:

IEC 62443 Requirement	How Reverse-Access Addresses It
FR1 – Identification & Authentication	All users authenticate at the access gateway before any connection to OT resources is established. MFA is enforced. Device posture is verified.
FR2 – Use Control	Per-user, per-application access policies enforce least privilege. Vendor access is time-bounded. No user receives network-level access.
FR3 – System Integrity	No inbound traffic reaches OT systems, preventing unauthorized command injection. Session recording captures all actions for integrity verification.
FR4 – Data Confidentiality	All sessions are encrypted end-to-end (TLS 1.3 / AES-256). No unencrypted protocols traverse the internet.
FR5 – Restricted Data Flow	Data flows only through explicitly defined outbound conduits. No inbound data flow is permitted. Microsegmentation isolates application tiers.
FR6 – Timely Response to Events	All access events are logged in immutable audit trails. SIEM integration enables real-time alerting on policy violations.
FR7 – Resource Availability	No inbound attack surface means no DDoS vector against OT. Reverse-access architecture maintains availability by eliminating the most common disruption path.

Security Level Alignment

IEC 62443 Security Level	Inbound Port Architecture	Reverse-Access Architecture
SL1 (Casual violation)	Meets with basic VPN + MFA	Exceeds – no ports to probe
SL2 (Simple intentional)	Requires hardened VPN + segmentation	Meets natively – no inbound exposure
SL3 (Sophisticated intentional)	Fails – VPN is an exploitable conduit	Meets – no inbound conduit exists
SL4 (State-sponsored)	Fails – nation-state can exploit any internet-facing service	Approaches – infrastructure is invisible to reconnaissance

Implementation Checklist

Pre-Deployment Assessment

[ ] Inventory all current inbound firewall rules to OT zones (ports, protocols, source IPs, purpose)
[ ] Document every remote access pathway (VPN, RDP, VNC, TeamViewer, vendor portals)
[ ] Map all data flows that cross the IT/OT boundary (historian, ERP, SIEM, analytics)
[ ] Identify all external users who access OT systems (vendors, contractors, remote engineers)
[ ] Classify each access requirement by Purdue level, application, protocol, and frequency
[ ] Assess current IEC 62443 security level target for each zone

Architecture Design

[ ] Deploy reverse-access connectors in the IDMZ – one per zone or per application group
[ ] Configure connectors to initiate outbound-only connections to the access gateway
[ ] Set firewall to deny-all for inbound traffic to OT zones – no exceptions
[ ] Define per-user, per-application access policies at the gateway
[ ] Configure time-bounded access for vendor sessions with automatic expiration
[ ] Enable session recording for all OT access sessions
[ ] Implement MFA with phishing-resistant methods (FIDO2 or hardware tokens)
[ ] Configure identity-based segmentation to prevent lateral movement within OT zones

Data Flow Reconfiguration

[ ] Convert historian-to-ERP data flow from inbound (IT pulls from OT) to outbound (OT pushes to IDMZ relay)
[ ] Configure OT security log export as outbound syslog-over-TLS to SIEM
[ ] Replace any Modbus/TCP or DNP3 connections that traverse the internet with protocol-aware secure tunnels
[ ] Verify that no OT device initiates connections to external IP addresses outside defined outbound paths

Validation

[ ] Run external vulnerability scan (Shodan, Censys, Nmap) against all plant IP ranges – verify zero results
[ ] Conduct penetration test specifically targeting OT remote access paths
[ ] Verify firewall deny-all state with stateful inspection – confirm no inbound connections are established
[ ] Test vendor access workflow: authentication, authorization, session recording, time expiration
[ ] Validate audit trail completeness against IEC 62443 FR6 requirements
[ ] Document architecture for compliance examination readiness

Common Objections and Technical Responses

“Our SCADA vendor requires inbound access for support”

The vendor does not need inbound network access. They need application-level access to the specific SCADA interface or PLC programming environment. Reverse-access architecture provides this through outbound-initiated tunnels. The vendor authenticates at the gateway and receives a session to the specific application – with recording, time limits, and least-privilege controls. No inbound port is required.

“We need real-time data for our ERP/MES integration”

Real-time data flows can be implemented as outbound pushes from the OT historian to an IDMZ relay using OPC-UA Secure or MQTT with TLS. The ERP/MES system reads from the relay – never from the OT network directly. This maintains data freshness while preserving the deny-all inbound posture. The IDMZ relay pattern is the architecture explicitly recommended by IEC 62443 and the Purdue Reference Model for IT/OT data exchange.

“Our jump server has been running for years without incident”

The absence of a known incident does not indicate security. Claroty’s 2025 research found that OT environments take an average of 180 days to patch vulnerabilities – and that the majority of attacks use freely available tools against known weaknesses. An internet-facing jump server with 14-month-old patches is not “incident-free” – it is “not yet compromised.”

“Opening one port with IP whitelisting is low risk”

IP whitelisting provides minimal protection. Source IP addresses can be spoofed in many attack scenarios, cloud-hosted attacker infrastructure uses IP ranges that overlap with legitimate vendors, and IP-restricted ports are still discoverable by scanning tools. The only way to eliminate the risk from an inbound port is to eliminate the inbound port.

“Our insurance requires VPN for remote access”

Cyber insurance policies are evolving. Many insurers now recognize that ZTNA with reverse-access provides stronger security than VPN – and some are beginning to offer premium reductions for organizations that eliminate internet-facing VPN infrastructure. Present the insurer with the architectural comparison and IEC 62443 mapping from this article. The conversation is about risk posture, not about specific technology requirements.

Who Needs Zero-Inbound OT Access – and Why

This architecture is not theoretical or limited to high-security government facilities. Every organization with networked OT systems faces the inbound port risk – and the industries below face it most acutely.

Manufacturing. Manufacturing accounts for 42% of all OT attack detections (Trellix, 2025) and has been the top ransomware target for four consecutive years. Production lines running legacy PLCs cannot tolerate the patching cadence required to secure internet-facing services. Eliminating inbound ports removes the attack vector entirely.

Water and Wastewater. Water utilities are disproportionately targeted by hacktivists and nation-state actors. The 2021 Oldsmar attack and multiple 2025 incidents against US and European water facilities demonstrate that internet-exposed remote access (VNC, TeamViewer) is the primary entry point. Small water utilities with limited security staff benefit most from architecture that requires no active inbound threat management.

Energy and Utilities. Energy infrastructure faces coordinated campaigns from nation-state actors (ELECTRUM, Sandworm) and hacktivists. IEC 62443 SL3/SL4 requirements for energy facilities demand the strictest possible conduit controls. Reverse-access architecture achieves SL3 compliance natively by eliminating inbound conduits from external zones.

Transportation. Ranked as the most targeted OT sector in the first half of 2025 (Nozomi Networks). Traffic control systems, rail signaling, port operations, and airport infrastructure all depend on SCADA and PLC systems that are increasingly network-connected – and increasingly targeted.

Healthcare. Medical device networks (IoMT) share many characteristics with industrial OT: legacy operating systems, proprietary protocols, and devices that cannot be patched during operation. The average cost of an IoMT breach reaches $10 million. Microsegmentation combined with reverse-access provides the defense-in-depth required for medical environments where device availability is directly linked to patient safety.

Oil and Gas. Pipeline operations, refinery control systems, and offshore platform automation depend on remote access for distributed operations across geographically remote sites. The Colonial Pipeline attack demonstrated the catastrophic impact of a compromised remote access pathway in this sector.

Deployment Roadmap

Phase 1: Vendor Access (Weeks 1–4)

Start by replacing VPN-based vendor access – the highest-risk, most audited pathway. Deploy the reverse-access connector in the IDMZ. Configure vendor-specific application policies with time-bounded sessions and recording. Close the corresponding inbound firewall port.

Phase 2: Remote Engineering Access (Weeks 5–10)

Extend to remote engineers and on-call operators. Map each engineer’s access requirements to specific applications (HMI, historian, engineering workstation). Replace VNC and RDP with application-level access through the gateway. Close remaining inbound remote access ports.

Phase 3: IT/OT Data Integration (Weeks 11–16)

Reconfigure data flows that currently require inbound paths. Convert historian-to-ERP from pull (inbound) to push (outbound via IDMZ relay). Configure outbound syslog for SOC integration. Validate that all data exchange operates through outbound-initiated conduits.

Phase 4: Full Deny-All and Validation (Weeks 17–20)

Set all OT zone firewalls to deny-all for inbound traffic with no exceptions. Run external scans to verify zero discoverable services. Conduct penetration testing against the new architecture. Document the configuration for IEC 62443 compliance audit. Establish ongoing monitoring for any unauthorized inbound rule additions.

Conclusion

Every inbound firewall port opened to an OT network is an architectural decision to accept risk. In 2025, OT attackers do not need sophisticated techniques – they need an open port, a default credential, and a freely available tool. Eighty-two percent of verified OT intrusions followed exactly this pattern.

Reverse-access architecture eliminates this entire attack category. By inverting the connection flow – OT initiates outbound, users connect at the gateway – the firewall stays in permanent deny-all. The OT network has no internet presence. There is nothing to discover, nothing to exploit, and nothing to disrupt.

This is not a theoretical improvement. It is the architectural realization of what IEC 62443 has always required: controlled conduits between zones, with security enforced at the level of the highest-sensitivity zone. The zone-and-conduit model was never intended to include an open port from the internet into a control system network. Reverse-access architecture closes that gap – permanently.