Note: All observations in this article describe systemic patterns encountered across multiple integration projects and environments. No specific system, client, or facility is identified. The purpose is to highlight industry-wide problems, not to expose any single organisation.
The Gap Between the Standard and the Site
IEC 62443 is a comprehensive framework. It covers security management systems, secure product development lifecycles, system integration requirements, and component-level security. In the right hands, it maps a path from a completely unsecured plant to a defensible, zone-segmented, authenticated industrial environment.
I’ve never seen it fully implemented in a live integration project.
That’s not an exaggeration for effect. That’s what commissioning industrial systems in the real world looks like. The standard sits in a PDF somewhere. The site has a production deadline and the integrator has a fixed-price contract. The two rarely meet.
What I’ve Actually Seen
1. Default Credentials Everywhere
The first thing you learn on a real commission is that nobody changes default credentials. Factory-set username and password on the PLC web server. Factory defaults on the managed switch embedded in the control cabinet. HMI running Windows 7 with Administrator / Administrator.
This isn’t isolated laziness. It’s a structural problem. The engineer who integrates the Siemens S7-1500 is not the same person who defined the network security policy — because there often is no network security policy. There’s a machine specification and a handover date.
I’ve reached web interfaces on devices in production networks within seconds of connecting a laptop to the cabinet switch. No authentication required. Direct access to I/O configuration, network parameters, and in some cases, PLC program uploads. From a physical standpoint, the attacker just needs to open the cabinet door — many of which are keyed identically across an entire plant, or left unlocked during production.
Standard (IEC 62443-4-2 CR 1.1):
"The device shall support the ability to authenticate human users."
Reality:
HTTP interface on port 80, no authentication, full configuration access.
2. Flat Networks with Industrial Protocols
Profinet, EtherNet/IP, and Modbus TCP were designed for deterministic real-time communication, not for security. Profinet has no native authentication mechanism — a device that speaks the protocol correctly is trusted by the network. Modbus TCP has no concept of authentication at all. Any device on the network can send function codes.
In practice, I’ve regularly found OT networks structured as follows:
[Office network (IT)]
|
[Unmanaged switch in cabinet]
|
[All PLCs, HMIs, SCADA servers, historian,
remote access modem — all on same subnet]
No VLAN segmentation. No firewall between zones. The historian logging production data sits on the same broadcast domain as the safety controller. The engineer’s laptop plugged into the cabinet port is on the same network as the SCADA server.
The recommended architecture from IEC 62443-3-3 is a zone-and-conduit model where communication between security zones passes through a defined conduit with inspection. What I’ve found in the field is a flat /24 with 60 devices and no ACLs.
3. Remote Access: The Hole Nobody Talks About
This is the one that concerns me most.
Industrial OT systems almost universally have remote access enabled for vendor support. When a Beckhoff module faults at 3 AM on a Sunday, someone needs to get in. The vendor’s support engineer needs visibility. This is understood and accepted.
What’s not acceptable is the way this remote access is typically implemented:
- TeamViewer or AnyDesk installed on the SCADA server, often with a fixed password or unattended access enabled
- Consumer 4G routers placed in the cabinet by a subcontractor, providing a persistent back-channel that bypasses the plant’s IT infrastructure entirely — and bypasses any firewall, any logging, any visibility
- Vendor VPN clients pre-configured on machines, credentials shared between the vendor’s entire support team, never rotated, documented in a shared spreadsheet
- RDP enabled on Windows HMIs with port 3389 open to the office network (or in some cases, to the internet via port-forwarding on the router described above)
I’ve been on sites where I could identify two or three separate, independent paths to remote access on the same machine — none of them logged, none of them monitored, none of them approved by anyone at the plant level.
The conversation about security with a production site goes like this: “We can’t restrict that — if the machine breaks, we need the vendor to be able to get in immediately.” The unstated assumption is that the vendor’s access channel is inherently trustworthy. It isn’t.
4. USB as the Universal Integration Bus
Patching OT systems is difficult. The machines run Windows XP Embedded, Windows 7, or Windows 10 LTSC. They’re not connected to WSUS. They can’t access Windows Update — the network policy, if one exists, blocks it.
So how does software get onto these machines? USB drives.
Technicians carry USB drives between projects, between sites, between clients. The drive that carried a PLC project file to a steel plant last week is the same drive that’s being plugged into the HMI at a food processing facility today. Nobody scans them. There’s often no policy against it — the USB port is the only way to load a project.
USB-based malware — Stuxnet being the most famous example — exploits exactly this vector. Stuxnet propagated primarily through USB drives because the air-gapped centrifuge controllers it targeted had no other data path. The vector that compromised Iranian nuclear infrastructure is still the default integration method on new commissions in 2025.
5. The Contractor Problem
On large industrial projects, the main integrator coordinates subcontractors: electricians, mechanical engineers, instrument technicians, network engineers (sometimes), and PLC programmers. Each contractor works within their scope. Security sits in nobody’s scope.
The electrician wires the cabinet. The PLC programmer writes the logic. The network subcontractor — if one exists — connects the switches. The site automation engineer does final commissioning and signs off. At no point does anyone ask: who has access to this system now? What credentials exist? What is the attack surface?
I’ve seen commissions handed over with:
- No documentation of network topology
- No list of device credentials
- No record of what software was installed on SCADA machines
- Remote access tools active that the client didn’t know about
- Default passwords that the commissioning engineer set “temporarily” and never changed
The client signs the handover form and takes operational responsibility for a system they have no visibility into.
6. The Pressure Dynamic
The security problems above don’t happen because engineers are careless. They happen because of a specific commercial and schedule pressure that is endemic to industrial integration projects.
Fixed-price contracts incentivise speed. Every day a machine isn’t running is lost production. Security work — segmenting networks, changing credentials, documenting access, configuring firewalls — takes time and doesn’t produce visible output. It doesn’t make the conveyor move faster. From the project manager’s perspective, it’s scope creep.
The result is a predictable pattern: security tasks are the first thing deferred when a project runs late. “We’ll harden it after FAT.” “We’ll change the passwords before final handover.” “We’ll set up the VPN properly on the next maintenance window.” These deferred tasks accumulate into a permanent security debt that nobody in the organisation has budget or schedule to pay.
What the Standards Actually Require
For reference — this is what good OT security practice looks like, per IEC 62443 and NIST SP 800-82:
Zone and Conduit Architecture (IEC 62443-3-3):
- Separate zones by criticality: Safety (SIL), Control, Supervisory, DMZ, Enterprise
- All inter-zone traffic through a defined conduit — typically a firewall or data diode
- No direct connectivity between enterprise and control zones
Authentication (IEC 62443-4-2):
- Unique credentials per device and per user
- No default passwords in production
- Privileged account management with time-limited access
Remote Access (IEC 62443-2-4):
- Vendor remote access via organisation-controlled VPN, not vendor-supplied tools
- Session logging and recording
- Time-limited access grants — vendor cannot access without explicit approval per session
Asset Inventory:
- Complete inventory of all devices, firmware versions, network addresses, and credentials
- Documented at handover; maintained operationally
Patch Management:
- Defined process for OT system patching — even if infrequent, even if via USB with pre-scanned media
- Firmware update testing in a replica environment before production deployment
Why This Matters More Than IT Security Failures
A data breach in an IT environment is serious. Data is exfiltrated, customers are affected, regulatory fines follow. The system continues operating.
A successful attack on an unsegmented OT network can stop physical production. It can activate or deactivate actuators. In environments with hazardous processes — gas, chemicals, high-voltage, high-temperature — it can create conditions that harm people.
The 2021 Oldsmar water treatment attack is the clearest recent example. An attacker — via TeamViewer, the same tool described above — remotely adjusted sodium hydroxide levels to potentially dangerous concentrations. A vigilant operator caught it. The gap between that incident and a public health disaster was one operator watching one screen at the right moment.
Norsk Hydro (2019). Colonial Pipeline (2021). The Triton/TRISIS malware targeting safety instrumented systems. These are not exotic, nation-state-only attack scenarios. They’re the consequence of the same conditions I described above, at scale, against motivated adversaries.
The Path Forward
I’m not writing this to be cynical about the industry. The engineers I’ve worked with are competent and professional. The problem is structural, not personal. Here’s what actually moves the needle:
Security as procurement requirement: Customers need to specify IEC 62443 security levels in the contract before integration begins. Not as a checkbox, but as a testable acceptance criterion. If the integrator can’t demonstrate zone segmentation and credential management at FAT, they don’t pass FAT.
Security scope in project budgets: Remote access infrastructure, firewall configuration, and credential management need to be line items in the project budget. If they’re not budgeted, they won’t happen.
OT security specialists on integration projects: Someone whose job responsibility includes security — not as a secondary duty of the PLC programmer — needs to be present on every large commission. This is starting to happen in nuclear, defence, and critical infrastructure. It needs to become standard for any industrial automation project.
Vendor access management platforms: Tools like Claroty, Armis, and Dragos provide network visibility and vendor access management designed for OT environments. They’re not cheap, but they’re far cheaper than the incident they prevent.
The gap between what IEC 62443 describes and what I’ve seen in the field is not inevitable. It’s a consequence of economic incentives that security professionals — and the clients who hire them — have the ability to change.
The first step is acknowledging that the problem exists.