If the Vendor VPN Lands on the PLC Subnet, You Don't Have a DMZ
Designing SCADA remote access against IEC 62443-3-3 SR 5.2 and SR 1.13, testing the denied paths at commissioning, and the port and timeout numbers that break it.
The VPN comes up and the PLC answers a ping
That one line decides whether your remote access design works. If ping 10.20.30.11 returns from the vendor's laptop, that laptop is already a control network device. Whether there is a firewall in the path or not.
IEC 62443-3-2 asks you to break this up into zones and conduits. In Purdue terms that is Level 3.5 — a DMZ between the enterprise (Level 4/5) and the control network (Level 0–2), with traffic terminating there instead of passing through. NIST SP 800-82 Rev 3 (2023) says the same thing: no flow should traverse directly between the business network and the control network.
None of this is an argument against remote support. When a line is down and the vendor engineer is two hours away, remote access is the answer. The point is only that it should stop once, at a boundary you chose.
A path that holds up looks like this:
- User authenticates to a VPN or zero-trust access service.
- The connection lands inside the industrial DMZ and nowhere else.
- From there the user opens a jump host, remote desktop gateway, or vendor support VM.
- Only approved protocols cross from the DMZ toward the control zone.
- Session logs, file transfers, and working time are retained.
Without step 3, the rest is decoration.
What the standard actually requires
"We follow security standards" carries no weight in an audit. IEC 62443-3-3 (System security requirements and security levels) states its remote-access requirements by clause number. These are the ones you can point a firewall rule at.
| Clause | Requirement | Effect on the design |
|---|---|---|
| SR 1.13 | Monitor and control all access via untrusted networks | The VPN must terminate inside the DMZ |
| SR 1.13 RE(1) | Explicit access request approval | No standing vendor tunnel; there has to be a request and an approval |
| SR 2.6 | Terminate a remote session automatically after configurable inactivity, or manually by the user who started it | This value has to match the firewall idle timeout — see below |
| SR 2.8 | Auditable events | Who, when, what. A login log alone does not satisfy it |
| SR 5.1 | Network segmentation | The clause your Level 3.5 DMZ exists under |
| SR 5.2 | Zone boundary protection, deny all / permit by exception | An any-any rule violates this outright |
FR 5 (Restricted Data Flow) is the foundational requirement that groups the SR 5.x family. If you map each firewall rule to one of these numbers while you are writing it, the next audit is short.
You will see documents that cite an SL (security level) alongside each clause. SL assignment depends on the risk assessment for that specific zone, so it is not fixed the way the clause numbers are. Better to leave out an SL number you have not verified than to publish one.
Separate engineering access from operator access
The HMI runtime, the SCADA server, the historian, and the engineering workstation do not need the same exposure.
| Access target | Typical purpose | Safer pattern |
|---|---|---|
| HMI client | Observe screens during a support call | Read-only support client or mirrored session |
| SCADA server | Service restart, log review, patch check | Jump host, named accounts, admin elevation only when needed |
| PLC engineering workstation | Online diagnostics, controlled downloads | Time-bound access, change ticket, local site approval |
| Historian or reporting server | Query data, check collectors | DMZ-facing reporting interface or restricted database proxy |
| Vendor package controller | Vendor diagnostic tool | Dedicated support VM with firewall rules only to that machine |
Do not let "vendor VPN" become a generic route to every device. A packaging OEM, a drive specialist, and an MES engineer need different machines and different ports.
A rule nobody can explain is a rule nobody can delete
allow-any-vendor survives forever, because nobody knows what breaks if it goes. OEM_A_support_vm_to_filler_plc_tcp_44818_ticket_2317 can be challenged months later.
For each rule, record at least:
- Source zone and named source host or group.
- Destination host, subnet, or service.
- Protocol and port, not
TCP any. - Business owner and technical owner.
- Whether the rule is permanent, scheduled, or emergency-only.
- The test method used at commissioning.
- The IEC 62443-3-3 clause it maps to.
Learn the port numbers. Ask a vendor and the answer is usually "just open everything."
| Purpose | Port |
|---|---|
| RDP | TCP 3389 |
OPC UA (opc.tcp) | TCP 4840 |
| Modbus TCP | TCP 502 |
| EtherNet/IP explicit messaging (CIP Class 3) | TCP 44818 |
| EtherNet/IP implicit I/O (Class 1) | UDP 2222 |
EtherNet/IP ListIdentity browse | UDP 44818, broadcast |
| OPC Classic / DCOM | TCP 135 plus dynamic 49152–65535 |
| Microsoft SQL Server | TCP 1433 |
The last two rows are what keep breaking segmented designs. Broadcasts do not route, and a 16384-port dynamic range is not something you can reasonably permit across a boundary.
Use jump hosts as tools, not as junk drawers
A jump host should be boring. The tools support needs, and nothing else. Once it becomes the shared desktop where everyone leaves installers, passwords, screenshots, and old project files, it stops being a control point and becomes the exposure.
- Named accounts per person or per vendor company, not a shared
vendorlogin (SR 1.1). - MFA before reaching the jump host.
- No saved PLC, SCADA, database, or domain passwords in browsers or tool profiles.
- Clipboard and drive redirection limited by policy.
- File transfer through a scanned drop folder, not drag-and-drop onto the control server.
- Session recording, or at minimum login and command logs, for privileged work (SR 2.8).
- A snapshot restore or rebuild procedure after major vendor work.
The jump host is where remote access policy becomes real. If it is unmanaged, the network diagram is only a drawing.
Testing only the happy path is not testing the boundary
Asking "can the vendor connect?" at commissioning proves the allowed path and nothing else. What SR 5.2 requires is the denied side. If you never test what should be blocked, you do not know the deny rules are actually in force.
- The VPN user reaches the jump host but cannot ping the PLC subnet directly.
- The jump host reaches the required HMI or PLC engineering port.
- File shares unrelated to the support task do not open.
- A time-bound account cannot log on outside its approved window.
- DNS names used by the tools resolve from the DMZ.
- A large project upload or trend export completes without a silent timeout.
- Firewall logs show the intended rule hit, not a broad fallback rule.
A short packet capture at the DMZ firewall beats guessing. Check source NAT, destination NAT, port translation, and asymmetric routing before blaming the SCADA application.
Common failure modes
Remote access failures are usually network design problems wearing an application costume.
The tool connects but the browse list is empty. EtherNet/IP browse sends ListIdentity as a UDP 44818 broadcast. Broadcasts do not cross a router, so the moment you segment, browse comes back empty — every time. The connection itself is fine over TCP 44818, which is exactly why it looks like "it connects but there's nothing in the list." The fix is not opening the firewall, it is typing the IP address in. Crossing zones, explicit IP configuration always beats discovery.
The OPC UA client cannot latch onto an endpoint. The discovery services in OPC UA Part 4 §5.4 (GetEndpoints) return the server's own EndpointDescription.endpointUrl verbatim, and that URL carries the server's internal hostname or private IP. Behind NAT the client connects once, reads the returned address, dials it, and fails. Register the externally reachable hostname as an alternate endpoint URL on the server. If the hostname in the connection URL does not match the certificate's subjectAltName, you get Bad_CertificateHostNameInvalid instead. Neither is a firewall problem.
RDP works but the PLC software will not go online. Either the license server route is missing, or the USB license dongle is not mapped into the session, or the broadcast discovery above is not crossing the zone. It is one of those three.
It only works with the firewall opened wide. Take a packet capture while it works, then keep only the flows you actually saw. An any-any rule left in place after the outage bites at the next incident, not at the next audit.
A large project upload stalls silently near 90%. This is where the hours go. The cause is usually two timeouts that do not agree. The Windows TCP keepalive default is 7200 s (2 hours), while a firewall's TCP session idle timeout is commonly 3600 s. If the upload goes quiet for more than an hour waiting on the far side, the firewall drops the session first. Neither end logs an error; it just stops. Raise the idle timeout on that rule or shorten the keepalive so they match. The SR 2.6 session termination value belongs in the same conversation — set it separately and your security policy will kill uploads.
The vendor says the VPN is slow. Start with MTU. A 1500 bytes Ethernet MTU minus IPsec tunnel overhead means you need TCP MSS clamped to roughly 1350 bytes, or large packets fragment or get dropped. The symptom is "ping works but file transfer hangs." Latency and packet loss come after that. Heavy engineering tools run better on a support VM near the control network than on a remote laptop.
The plant loses visibility during support. Remote sessions consume historian, HMI, and PLC communication capacity. Watch controller connection counts, SCADA client license counts, and historian collector queues while the vendor is working.
The operating rules are part of the design
- Name a local plant contact before enabling vendor access.
- Separate accounts per person or per vendor company.
- Close emergency access after the incident. The explicit approval in SR 1.13 RE(1) includes taking it back.
- Keep a list of approved tools and versions on the support VM.
- Record separately what was changed, what was only observed, and what still needs follow-up.
- Review remote access rules after projects, shutdowns, and vendor upgrades.
One last check. During the last outage, did somebody say "just open it up for now"? If so, the approved path does not really work, and the design is not finished.