Cyber Strategy
Cyber Secure
Cyber Operations
Cyber Response
Cyber ResilienceA zero-trust target state for asset owners who need remote operations and vendor support without opening a path into the control network
Every asset owner eventually receives the same two requests in the same week. Operations want to supervise a site from a central room, and a vendor wants to dial in to look at a faulted PLC. Both are reasonable. Both are also, in most plants, answered with a VPN account and a jump host that nobody has reviewed since the day it was installed.
The question is no longer whether to allow remote access. It is whether the path you build can still be defended once a credential is phished, a vendor laptop is compromised, or an engineer makes a bad change at 2 a.m. Here in CS4 form DTS solution we are designing a target state that answers that question in architecture rather than in policy: one broker enclave in L 3.5 , three control gates in front of every session, and a design in which no route exists between the enterprise network and the control network.
3.5 OT DMZ where every remote session starts and stops | 3 Control gates; a session that fails one never opens | 2 Factors: authenticator app plus email OTP | 0 Routed paths between Level 4 and Level 3 |
Why the conventional pattern leaves gaps
A VPN into the plant network followed by a jump host is the most common remote access design in industrial sites, and it solves connectivity. It does not solve identity, privilege, accountability or containment. Once the tunnel is up, the user is trusted by network location, and everything the jump host can reach is reachable by whoever holds the credential.
In most industrial remote access designs, the weaknesses cluster into the same six control gaps. Each one maps to a specific control and a specific place where that control is enforced, which matters because an assessor, or an attacker, will test the enforcement point and not the policy document.
Control gap in a typical estate | Target-state control | Enforcement point |
|---|---|---|
No OT-owned identity, MFA or single broker | Read-only domain controller, OT MFA service and one PAM gateway pair in the Level 3.5 OT DMZ, brokering every application | OT domain controller, PAM gateway |
Standing privileges, no just-in-time | Per-session entitlement with work order, reason, window and named supervisor approval; hard expiry with no action required | PAM entitlement workflow |
No session recording or audit trail | Screen, keystroke and command capture to write-once storage, retained to policy and forwarded to the SOC | Session recording store |
No vendor approval workflow | Vendor engineers land on a non-persistent desktop, then pass the same three gates; identity re-certified per maintenance campaign | ZTNA, virtual desktop, PAM approval |
Inconsistent firewall policy across sites | One rule intent: one permit inbound to the PAM, one permit outbound for OTP mail, default deny logged | IT / OT boundary firewall |
Implicit trust after the first hop | Session broken at the PAM; credential injected; one hardened jump server per control process in its own VLAN; no east-west path; no desktop | PAM, jump servers, Level 3 firewall |
Table 1: Six control gaps, the control that closes each one, and where it is enforced
The design principle: broker the session, never route it
The central idea is simple. Instead of extending a network into the plant, place a dedicated broker enclave in the OT DMZ at Level 3.5 and make it the only place where remote sessions start and stop. It sits between the enterprise network at Level 4 and the operations network at Level 3, and it is administered by OT security, not by the IT team that runs the corporate estate.
The inbound session terminates on the PAM gateway. The gateway then opens a second, separate session to a hardened jump server at Level 3. At no point does an IP route exist from Level 4 to Level 3. The user never holds a network path to the plant, only a session that the broker is willing to keep alive.
Six design decisions follow this principle. Together they determine whether architecture is genuinely zero trust or simply a longer chain of trusted hops.
- The broker tier lives in the OT DMZ. A dedicated enclave at Level 3.5, between the IT / OT boundary firewall and the Level 3 boundary firewall, holds the PAM gateway pair, the credential vault, session recording and the OT MFA service. It carries nothing else.
- Identity is owned by OT. A read-only domain controller for the OT forest, also in the OT DMZ, is bound to the PAM over LDAPS. A phished IT credential is not a principal in that directory, so it fails before any policy is evaluated.
- The session is broken, never routed. The inbound TLS session ends on PAM, which opens a second session to the jump server that owns the approved application. Nothing is routed between Level 4 and Level 3.
- Applications are published, not exposed. The operator receives a console, a remote application or a shell. Never a desktop and never raw RDP. An unpublished protocol has no path at all, which is stronger than a denied one.
- Access is just-in-time and just-enough. A request names the application, the work order, the reason and the window, and a supervisor approves it. The entitlement expires on its own. Standing OT access does not exist.
- Credentials stay in the vault and every session is recorded. Target passwords are injected by the PAM and rotated on close, so the operator never sees one. Screen, keystrokes and commands go to write-once storage and to the SOC.
Three gates, and a session that fails anyone never opens
The PAM is best understood as three separate control gates rather than one product feature. Each gate fails closed, which means a failure produces no session instead of a degraded one.
GATE 1 Before authentication Fails closed: no login page is served • Source IP and hostname allow-list, evaluated before the login page • Device posture: OS build, patch level, anti-malware, disk encryption, domain join • Machine certificate or managed-device attestation • Geo, time-of-shift and rate fencing; TLS 443 to one published URL only | GATE 2 Authentication and authorization Fails closed: no entitlement is granted • Authentication against the OT domain, never the corporate directory • MFA by authenticator app; email OTP fallback issued from the OT DMZ; • Just-in-time request: application, work order, reason, window, supervisor approval • Posture re-check after login; published applications only, no desktop | GATE 3 During and after the session Fails closed: the session is terminated • Credential injected from the vault, never displayed, rotated when the window closes • Screen, keystroke and command recording to write-once storage, forwarded to the SOC • Clipboard, drive redirection, USB and local printing disabled; files only via a scanned patch relay • Idle timeout and hard expiry; no east-west path between jump-server VLANs |
Table 2: The three gates a remote session must pass
The distinction between gates matters operationally. Gate 1 stops unmanaged devices and unexpected sources before a login page is even served. Gate 2 decides who the person is and what they may do, using an identity that OT owns. Gate 3 limits what the person can do while connected and guarantees evidence afterwards.
Two scenarios the design must handle
1 · An IT-side operator on a managed workstation
The operator authenticates twice, once to the corporate estate and once to the OT domain and holds neither the OT credential nor a route to it.
- Opens the published PAM URL over TLS 443; source and hostname are on the allow-list.
- Passes the device posture challenge: patch level, anti-malware, disk encryption, managed device.
- Authenticates against the OT forest over LDAPS with MFA by authenticator app.
- Raises a just-in-time request; a supervisor approves a time-boxed window and only entitled applications are shown.
- The PAM requests the target credential from the vault and injects it into the jump server. The operator never sees it.
- The session is re-originated from the PAM to the Level 3 jump server, with copy, paste and file transfer disabled.
- Screen, keystrokes and commands stream to the recording store and the SOC.
A zero-trust target state for asset owners who need remote operations and vendor support without opening a path into the control network
Every asset owner eventually receives the same two requests in the same week. Operations want to supervise a site from a central room, and a vendor wants to dial in to look at a faulted PLC. Both are reasonable. Both are also, in most plants, answered with a VPN account and a jump host that nobody has reviewed since the day it was installed.
The question is no longer whether to allow remote access. It is whether the path you build can still be defended once a credential is phished, a vendor laptop is compromised, or an engineer makes a bad change at 2 a.m. Here in CS4 form DTS solution we are designing a target state that answers that question in architecture rather than in policy: one broker enclave in L 3.5 , three control gates in front of every session, and a design in which no route exists between the enterprise network and the control network.
3.5 OT DMZ where every remote session starts and stops | 3 Control gates; a session that fails one never opens | 2 Factors: authenticator app plus email OTP | 0 Routed paths between Level 4 and Level 3 |
Why the conventional pattern leaves gaps
A VPN into the plant network followed by a jump host is the most common remote access design in industrial sites, and it solves connectivity. It does not solve identity, privilege, accountability or containment. Once the tunnel is up, the user is trusted by network location, and everything the jump host can reach is reachable by whoever holds the credential.
In most industrial remote access designs, the weaknesses cluster into the same six control gaps. Each one maps to a specific control and a specific place where that control is enforced, which matters because an assessor, or an attacker, will test the enforcement point and not the policy document.
Control gap in a typical estate | Target-state control | Enforcement point |
|---|---|---|
No OT-owned identity, MFA or single broker | Read-only domain controller, OT MFA service and one PAM gateway pair in the Level 3.5 OT DMZ, brokering every application | OT domain controller, PAM gateway |
Standing privileges, no just-in-time | Per-session entitlement with work order, reason, window and named supervisor approval; hard expiry with no action required | PAM entitlement workflow |
No session recording or audit trail | Screen, keystroke and command capture to write-once storage, retained to policy and forwarded to the SOC | Session recording store |
No vendor approval workflow | Vendor engineers land on a non-persistent desktop, then pass the same three gates; identity re-certified per maintenance campaign | ZTNA, virtual desktop, PAM approval |
Inconsistent firewall policy across sites | One rule intent: one permit inbound to the PAM, one permit outbound for OTP mail, default deny logged | IT / OT boundary firewall |
Implicit trust after the first hop | Session broken at the PAM; credential injected; one hardened jump server per control process in its own VLAN; no east-west path; no desktop | PAM, jump servers, Level 3 firewall |
Table 1: Six control gaps, the control that closes each one, and where it is enforced
The design principle: broker the session, never route it
The central idea is simple. Instead of extending a network into the plant, place a dedicated broker enclave in the OT DMZ at Level 3.5 and make it the only place where remote sessions start and stop. It sits between the enterprise network at Level 4 and the operations network at Level 3, and it is administered by OT security, not by the IT team that runs the corporate estate.
The inbound session terminates on the PAM gateway. The gateway then opens a second, separate session to a hardened jump server at Level 3. At no point does an IP route exist from Level 4 to Level 3. The user never holds a network path to the plant, only a session that the broker is willing to keep alive.
Six design decisions follow this principle. Together they determine whether architecture is genuinely zero trust or simply a longer chain of trusted hops.
- The broker tier lives in the OT DMZ. A dedicated enclave at Level 3.5, between the IT / OT boundary firewall and the Level 3 boundary firewall, holds the PAM gateway pair, the credential vault, session recording and the OT MFA service. It carries nothing else.
- Identity is owned by OT. A read-only domain controller for the OT forest, also in the OT DMZ, is bound to the PAM over LDAPS. A phished IT credential is not a principal in that directory, so it fails before any policy is evaluated.
- The session is broken, never routed. The inbound TLS session ends on PAM, which opens a second session to the jump server that owns the approved application. Nothing is routed between Level 4 and Level 3.
- Applications are published, not exposed. The operator receives a console, a remote application or a shell. Never a desktop and never raw RDP. An unpublished protocol has no path at all, which is stronger than a denied one.
- Access is just-in-time and just-enough. A request names the application, the work order, the reason and the window, and a supervisor approves it. The entitlement expires on its own. Standing OT access does not exist.
- Credentials stay in the vault and every session is recorded. Target passwords are injected by the PAM and rotated on close, so the operator never sees one. Screen, keystrokes and commands go to write-once storage and to the SOC.
Three gates, and a session that fails anyone never opens
The PAM is best understood as three separate control gates rather than one product feature. Each gate fails closed, which means a failure produces no session instead of a degraded one.
GATE 1
Before authentication
Fails closed: no login page is served
• Source IP and hostname allow-list, evaluated before the login page
• Device posture: OS build, patch level, anti-malware, disk encryption, domain join
• Machine certificate or managed-device attestation
• Geo, time-of-shift and rate fencing; TLS 443 to one published URL only
GATE 2
Authentication and authorization
Fails closed: no entitlement is granted
• Authentication against the OT domain, never the corporate directory
• MFA by authenticator app; email OTP fallback issued from the OT DMZ;
• Just-in-time request: application, work order, reason, window, supervisor approval
• Posture re-check after login; published applications only, no desktop
GATE 3
During and after the session
Fails closed: the session is terminated
• Credential injected from the vault, never displayed, rotated when the window closes
• Screen, keystroke and command recording to write-once storage, forwarded to the SOC
• Clipboard, drive redirection, USB and local printing disabled; files only via a scanned patch relay
• Idle timeout and hard expiry; no east-west path between jump-server VLANs
Table 2: The three gates a remote session must pass
The distinction between gates matters operationally. Gate 1 stops unmanaged devices and unexpected sources before a login page is even served. Gate 2 decides who the person is and what they may do, using an identity that OT owns. Gate 3 limits what the person can do while connected and guarantees evidence afterwards.
Two scenarios the design must handle
1 · An IT-side operator on a managed workstation
The operator authenticates twice, once to the corporate estate and once to the OT domain and holds neither the OT credential nor a route to it.
- Opens the published PAM URL over TLS 443; source and hostname are on the allow-list.
- Passes the device posture challenge: patch level, anti-malware, disk encryption, managed device.
- Authenticates against the OT forest over LDAPS with MFA by authenticator app.
- Raises a just-in-time request; a supervisor approves a time-boxed window and only entitled applications are shown.
- The PAM requests the target credential from the vault and injects it into the jump server. The operator never sees it.
- The session is re-originated from the PAM to the Level 3 jump server, with copy, paste and file transfer disabled.
- Screen, keystrokes and commands stream to the recording store and the SOC.
2 · A third-party OEM engineer on an unmanaged endpoint
Here access is brokered three times: onto a corporate desktop using VPN, through the PAM at Level 3.5, then onto a hardened jump server at Level 3. The vendor endpoint never speaks to an OT asset, and no VPN tunnel into OT is offered.
- The vendor reaches the ZTNA portal with endpoint posture and MFA from an agreed source range.
- They land on a non-persistent corporate desktop with clipboard, drive redirection, USB and printing disabled.
- From that desktop only, TLS 443 passes through the IT egress and the IT / OT boundary firewall to the PAM.
- The just-in-time request names the application, work order, reason and window; the OT supervisor approves it.
- Authorization runs against the OT domain controller and the OTP service. The vendor’s own IT account is rejected.
- A vault-injected credential opens one published application on one jump server: no desktop, no lateral path.
- When the window expires the session is terminated, the target credential is rotated, and the recording is retained for supervisor and SOC review.
Blocked by the platform, not by policy
Inside an approved session the user cannot: see, type or store a credential; open raw RDP or SSH from the workstation into OT; transfer a file except through the scanned relay; authenticate to OT with an IT domain account; reach any host other than the published target; copy, paste, map a drive, mount USB or print; hold access before approval or after expiry; or reach the safety system or any Level 1 / 0 device.
That list is deliberate. Technical controls that depend on a user choosing to follow a rule are not controls. These restrictions are properties of the architecture, which is what allows an assessor to test them.
Aligning to IEC 62443-3-3
The target state can be mapped to the seven foundational requirements of IEC 62443-3-3, with a target security level of SL-T 3 for the remote access conduit. The mapping is useful because it turns an architecture discussion into a conversation about evidence.
Requirement | Foundational requirement | How the target state addresses it |
|---|---|---|
FR 1 | Identification and authentication | OT-owned directory plus MFA |
FR 2 | Use control | Just-in-time entitlement with supervisor approval |
FR 3 | System integrity | Device posture checks and a hardened, golden-image jump server |
FR 4 | Data confidentiality | TLS on every hop; credentials injected from the vault |
FR 5 | Restricted data flow | No Level 4 to Level 3 route; one permit per boundary |
FR 6 | Timely response to events | Write-once recording forwarded to the SOC |
FR 7 | Resource availability | HA firewall pairs and a separate enclave, so remote access cannot starve operations |
Table 3: Foundational requirements and the corresponding target-state control
What this architecture does not replace Safety instrumented systems sit outside the remote access scope entirely: no remote access, ever. Local control and protection functions must never depend on the broker being available. Remote monitoring, diagnostics, engineering access and remote control carry different risk, so each should be a separate entitlement authorized on its own merits, and the architecture supports the process safety assessment rather than substituting for it. |
From reference design to a working site
Reference architectures fail when they stay on paper. We recommend five decisions and a pilot, in this order, before any broad rollout.
- Confirm. Zone definitions and the OT DMZ boundaries are signed off jointly by OT and IT, and a change authority is named.
- Select. The PAM platform is evaluated against the three gates and demonstrated in a proof of concept rather than described in a datasheet.
- Design. VLAN plan, firewall rule bases, the OT read-only domain controller build, the vault and the rotation policy.
- Pilot. One control process , one vendor and one full maintenance window, with failure tests witnessed.
- Roll out. Per-control process onboarding follows, then the legacy remote access paths are decommissioned and proven closed.
The last step is the one most often skipped. A new brokered path that coexists with the old VPN and the old vendor modem has not reduced risk, it has added a path. Closure of the legacy routes should be tested and evidenced.
The takeaway
Remote access is neither inherently safe nor inherently unacceptable. Its risk is set by the architecture that carries it, the privileges it grants and the evidence it leaves behind. Zero trust in OT is not a product to buy. It is a decision to stop trusting network location and to make every session earn its entitlement, one gate at a time.
The goal is neither open connectivity nor blanket disconnection. It is remote access that is controlled, accountable and designed around safety, availability and integrity. |
How CS4 works with your environment
CS4 , the OT/ICS Cybersecurity Division of DTS Solution, supports asset owners across the full path from design through to a proven-closed legacy estate:
✓ Remote access design review against the six control gaps and IEC 62443-3-3
✓ Purdue-based architecture design, including zones, conduits, the broker enclave and firewall rule intent
✓ PAM platform evaluation against the three gates, with a demonstrated proof of concept
✓ Pilot planning and witnessed failure testing for one control process and one vendor
✓ Decommissioning plans for legacy VPN, jump host and vendor modem paths
2 A third-party OEM engineer on an unmanaged endpoint
Here access is brokered three times: onto a corporate desktop using VPN, through the PAM at Level 3.5, then onto a hardened jump server at Level 3. The vendor endpoint never speaks to an OT asset, and no VPN tunnel into OT is offered.
- The vendor reaches the ZTNA portal with endpoint posture and MFA from an agreed source range.
- They land on a non-persistent corporate desktop with clipboard, drive redirection, USB and printing disabled.
- From that desktop only, TLS 443 passes through the IT egress and the IT / OT boundary firewall to the PAM.
- The just-in-time request names the application, work order, reason and window; the OT supervisor approves it.
- Authorization runs against the OT domain controller and the OTP service. The vendor’s own IT account is rejected.
- A vault-injected credential opens one published application on one jump server: no desktop, no lateral path.
- When the window expires the session is terminated, the target credential is rotated, and the recording is retained for supervisor and SOC review.
Blocked by the platform, not by policy Inside an approved session the user cannot: see, type or store a credential; open raw RDP or SSH from the workstation into OT; transfer a file except through the scanned relay; authenticate to OT with an IT domain account; reach any host other than the published target; copy, paste, map a drive, mount USB or print; hold access before approval or after expiry; or reach the safety system or any Level 1 / 0 device. |
That list is deliberate. Technical controls that depend on a user choosing to follow a rule are not controls. These restrictions are properties of the architecture, which is what allows an assessor to test them.
Aligning to IEC 62443-3-3
The target state can be mapped to the seven foundational requirements of IEC 62443-3-3, with a target security level of SL-T 3 for the remote access conduit. The mapping is useful because it turns an architecture discussion into a conversation about evidence.
Requirement | Foundational requirement | How the target state addresses it |
|---|---|---|
FR 1 | Identification and authentication | OT-owned directory plus MFA |
FR 2 | Use control | Just-in-time entitlement with supervisor approval |
FR 3 | System integrity | Device posture checks and a hardened, golden-image jump server |
FR 4 | Data confidentiality | TLS on every hop; credentials injected from the vault |
FR 5 | Restricted data flow | No Level 4 to Level 3 route; one permit per boundary |
FR 6 | Timely response to events | Write-once recording forwarded to the SOC |
FR 7 | Resource availability | HA firewall pairs and a separate enclave, so remote access cannot starve operations |
Table 3: Foundational requirements and the corresponding target-state control
What this architecture does not replace Safety instrumented systems sit outside the remote access scope entirely: no remote access, ever. Local control and protection functions must never depend on the broker being available. Remote monitoring, diagnostics, engineering access and remote control carry different risk, so each should be a separate entitlement authorized on its own merits, and the architecture supports the process safety assessment rather than substituting for it. |
From reference design to a working site
Reference architectures fail when they stay on paper. We recommend five decisions and a pilot, in this order, before any broad rollout.
- Confirm. Zone definitions and the OT DMZ boundaries are signed off jointly by OT and IT, and a change authority is named.
- Select. The PAM platform is evaluated against the three gates and demonstrated in a proof of concept rather than described in a datasheet.
- Design. VLAN plan, firewall rule bases, the OT read-only domain controller build, the vault and the rotation policy.
- Pilot. One control process , one vendor and one full maintenance window, with failure tests witnessed.
- Roll out. Per-control process onboarding follows, then the legacy remote access paths are decommissioned and proven closed.
The last step is the one most often skipped. A new brokered path that coexists with the old VPN and the old vendor modem has not reduced risk, it has added a path. Closure of the legacy routes should be tested and evidenced.
The takeaway
Remote access is neither inherently safe nor inherently unacceptable. Its risk is set by the architecture that carries it, the privileges it grants and the evidence it leaves behind. Zero trust in OT is not a product to buy. It is a decision to stop trusting network location and to make every session earn its entitlement, one gate at a time.
The goal is neither open connectivity nor blanket disconnection. It is remote access that is controlled, accountable and designed around safety, availability and integrity. |
How CS4 works with your environment
CS4 , the OT/ICS Cybersecurity Division of DTS Solution, supports asset owners across the full path from design through to a proven-closed legacy estate:
✓ Remote access design review against the six control gaps and IEC 62443-3-3
✓ Purdue-based architecture design, including zones, conduits, the broker enclave and firewall rule intent
✓ PAM platform evaluation against the three gates, with a demonstrated proof of concept
✓ Pilot planning and witnessed failure testing for one control process and one vendor
✓ Decommissioning plans for legacy VPN, jump host and vendor modem paths
Dubai