Part of the Protect Playbook ← Return to Protect Hub

ZTNA and iDMZ—The Gold Standard for OT Remote Access

Requirement: This module addresses the secure brokering of remote OEM access to onboard OT environments, satisfying IACS UR E26 requirements for authenticated conduits.

In the maritime world, enabling remote access to critical Operational Technology (OT) networks is essential for maintenance. However, directly exposing these systems to the internet is an unacceptable risk.

The Challenge: Legacy Security Flaws

The VPN Problem

Grants full Layer 3 access. Once connected, a remote user can “see” and scan your entire OT subnet, increasing lateral movement risk.

The Jump Host Problem

Requires constant OS patching. It creates a large, persistent attack surface sitting directly adjacent to your PLC network.

The Solution: Move to Zero Trust. Access is granted to the application itself (e.g., just the HMI), not the entire network segment.

The Solution: ZTNA in the iDMZ

An iDMZ (Industrial DMZ) acts as a neutral buffer zone. Critically, it serves as the secure environment for the ZTNA Gateway.

ZTNA and iDMZ architecture for maritime OT

Fig 2.1: ZTNA Gateway Architecture for Multi-Vendor OT Environments.

ZTNA Connection Flow

1 Remote Request:

The engineer requests access via a ZTNA client. No ports are open on the ship yet.

2 Identity & Posture Check:

The Broker verifies MFA and ensures the laptop is corporate-owned and virus-free.

3 Outbound App-Tunnel:

The Gateway in the iDMZ opens a secure outbound tunnel. The engineer connects only to the authorized OT application.

Firewall and Policy Configuration

Component Source Destination Service Action
Gateway Uplink iDMZ WAN HTTPS (443) PERMIT
OT Access iDMZ OT Zone App Specific PERMIT
Default Deny iDMZ (All) OT Zone ANY DENY
Protocol Verification Steps
OEM Documentation Review

Consult vendor manuals to identify primary communication ports (e.g., Modbus/502). Never use “ANY” as a source or service for vendor access.

Operational Traffic Analysis (Baselining)

Use a packet analyzer to identify background “keep-alive” heartbeats or watchdog timers. These secondary signals ensure system stability and can cause session timeouts or false alarms if blocked by strict firewall rules.

Pro-Tip: Always baseline for at least 24–48 hours. Some OT polling cycles or diagnostic heartbeats only occur once a day or during specific events, such as a pump start or engine maneuver.

The Advantages of ZTNA 2.0 in the iDMZ

By integrating ZTNA 2.0 into the iDMZ, you achieve the ultimate security controls for your fleet, moving beyond “connect-and-forget” security models:

Continuous Trust Verification

Access is not just granted once; the ZTNA system continuously verifies the user’s identity and device health throughout the entire session.

Minimal Attack Surface

The ZTNA Gateway is a hardened, purpose-built appliance. This drastically reduces the patching burden and exposure compared to a general-purpose Windows/Linux server.

Granular Control

Policies are enforced based on identity and application. It allows you to safely manage multi-vendor access to disparate OT systems without complex firewall rules.

Implementing the iDMZ with a modern ZTNA solution is the most effective way to enable necessary remote access while maintaining the absolute security and integrity of a vessel’s critical operational systems.

Remote Access Secured

Ready to Secure Local Identities?

Establishing ZTNA satisfies the “how” of connectivity. Now, ensure the credentials used for access are governed by robust Password Policies.

Continue to Password Policies →
Scroll to Top