Ask anyone who’s run a factory for more than ten years what’s changed, and connectivity comes up before anything else. Lines that used to sit on their own cable runs now push data to a dashboard in head office. Vendors log in from wherever they are instead of getting on a plane. Sensors talk to cloud platforms. All of it is genuine improvement, and all of it is a new door.
What’s behind those doors is the awkward bit. PLCs, HMIs, SCADA servers, DCS environments, RTUs, engineering workstations, safety systems. A lot of it was specified when “security” meant a padlock and a network that physically didn’t touch anything else. One infected engineering laptop, or one remote-access rule somebody wrote in a hurry three years ago, can reach the lot.
IEC 62443 compliance is the industry’s answer to that. The standard is a series of international documents written specifically for Industrial Automation and Control Systems, and it’s deliberately broader than most OT cybersecurity frameworks. It covers risk assessment, network architecture, organisational process, system requirements, how products get built, and the unglamorous business of keeping all of it current. Nobody wrote it so you’d buy an industrial firewall. They wrote it so you’d end up with a plant network that’s segmented, sized to actual risk, and watched by someone.
The standard isn’t a checklist
It’s a family of documents, and they don’t all speak to the same reader:
| Standard | Who it’s for |
|---|---|
| IEC 62443-2-1:2024 | Security programmes for asset owners |
| IEC 62443-2-4:2023 | Requirements for IACS service providers |
| IEC 62443-3-2:2020 | OT risk assessment and system design |
| IEC 62443-3-3:2013 | System requirements and security levels |
| IEC 62443-4-1:2018 | Secure product development lifecycle |
| IEC 62443-4-2:2019 | Technical requirements for IACS components |
There’s one assumption in the 2024 revision that quietly shapes everything downstream: industrial systems are expected to run for twenty years or more. Which means legacy operating systems, firmware nobody supports, and in a few cases hardware whose manufacturer no longer exists. You cannot patch and reboot a line that’s halfway through a batch. Sometimes you can’t patch it at all, ever.
So OT cybersecurity ends up being a negotiation between four things pulling in different directions: security, availability, safety, and production continuity. Any recommendation that only respects the first one gets ignored by the plant, and rightly so.
Zones and conduits
Sketch out a typical factory network. ERP talks to the historian, historian to SCADA, SCADA to the HMIs, HMIs to the PLCs, PLCs to the machines. Now imagine all of that on one flat network with nothing in between. An attacker who gets a foothold anywhere has a route to everywhere, and that’s not a hypothetical. It’s how most published OT incidents actually unfolded.
The standard’s answer is industrial network segmentation, built on two ideas.
A zone groups assets that need the same level of protection. In practice it usually layers out something like this:
- Enterprise: ERP, corporate users, business applications
- Industrial DMZ: jump servers, historians, remote-access gateways, shared IT/OT services
- Operations: SCADA and manufacturing operations
- Control: HMIs and engineering workstations
- Cell/area: PLCs, RTUs, controllers
Sites with real process hazard usually pull the safety-instrumented systems out into a zone of their own, and that’s a good instinct.
A conduit is the controlled path between zones. Instead of enterprise IT reaching a PLC directly, traffic goes through a firewall, into the industrial DMZ, through another firewall, and only then onto the OT network. Every hop is somewhere you get to ask whether the traffic is necessary.
The rule underneath it is short enough to remember: only what a process genuinely needs should cross a zone boundary. Firewalls, VLANs, routing and access control are how you enforce that. They aren’t the decision. The decision comes first, and it’s usually a conversation with process engineering rather than with IT.
Why SL 4 shouldn’t be your answer
Different parts of a plant carry different risk, so the standard defines four IEC 62443 security levels, graded by the kind of adversary you’re up against.
SL 1 is the accidental stuff. An operator who clicks something they shouldn’t have, with no ill intent whatsoever.
SL 2 covers deliberate attacks using simple means. Low resources, generic skills, not much motivation.
SL 3 is a step change: sophisticated methods, moderate resources, and real IACS-specific knowledge. Someone who knows what Modbus is and why your historian matters.
SL 4 assumes sophisticated methods, extended resources, deep expertise and high motivation. Nation-state territory, more or less.
The temptation, particularly when a board is nervous, is to write SL 4 across the whole site. Resist it. Levels are meant to fall out of an OT risk assessment, not out of anxiety, and over-specifying burns budget and operational flexibility you’ll want somewhere else.
Three abbreviations do most of the work here. SL-T is the target, meaning what the zone needs. SL-C is capability, or what the kit can technically deliver. SL-A is achieved: what you actually ended up with once it was installed and configured by real people on a real schedule.
The gap between the last two is where most programmes quietly come apart. A device rated for SL 3 does not hand the zone SL 3. Architecture, configuration, policy, staffing and daily process decide that, and none of them come in the box.
The seven foundational requirements
Everything technical rolls up into seven headings.
FR 1, identification and authentication control. Who is this? Unique accounts instead of the shared login taped to the monitor, MFA where it’s workable, certificates, decent credential hygiene, and authentication for devices and processes as well as people.
FR 2, use control. Fine, we know who they are. What are they allowed to do? An operator monitors. An engineer changes authorised control configurations. A vendor touches their own equipment and nothing else. Least privilege, applied honestly rather than on paper.
FR 3, system integrity. Protection against unauthorised change: secure configuration, malware protection, vulnerability management, application control, patching where it’s possible, intrusion prevention, integrity monitoring.
FR 4, data confidentiality. Encryption, protected credentials, secure VPNs, protected admin channels, applied where the information actually warrants it rather than everywhere by reflex.
FR 5, restricted data flow. Zones and conduits stated as a requirement. Traffic between zones takes controlled paths, and lateral movement gets expensive.
FR 6, timely response to events. You have to be able to notice. Central logging, OT-aware monitoring, IDS/IPS, SIEM integration, alerting, and an incident-response process somebody has actually rehearsed rather than filed.
FR 7, resource availability. Redundant paths, configuration backups, tested recovery, DoS protection, resilient design. This weighs more in OT than in IT, because an outage isn’t a slow service. It’s a stopped physical process, and occasionally a damaged one.
What this looks like on an actual site
Take a mid-sized plant: 60 PLCs, 25 HMIs, 8 engineering workstations, 2 SCADA servers, a historian, 120 industrial IoT devices. That’s north of 200 assets, every one of which has to be known before it can be defended.
Which is exactly why this work doesn’t start with a purchase order.
Find the assets first. Record IP and MAC, manufacturer, model, firmware or software version, protocol, physical and logical location, owner, and how badly the process suffers without it. It’s tedious and it’s non-negotiable. You can’t protect what nobody wrote down.
Then map how they talk. HMI to PLC, engineering workstation to PLC, PLC to SCADA, SCADA to historian, historian into the DMZ, DMZ to enterprise IT, remote engineer through a gateway to one named asset. This baseline is what lets you segment without stopping production, because it separates the flows that are real from the ones people assume exist.
Then assess the risk. IEC 62443-3-2 lays out the approach. For each zone: what’s the threat, what weakness could be exploited, how likely is that, and what happens if it works. In an industrial setting “what happens” spans a wide range: shutdown, equipment damage, quality failures, safety incidents, environmental release, IP loss, regulatory trouble, straightforward financial loss.
That’s the analysis that gives you an SL-T you can defend in a meeting.
Segmenting the network
Once you know the assets and the risks, the architecture more or less writes itself. A common shape: enterprise IT, industrial firewall, industrial DMZ, second firewall, SCADA and operations, segmentation firewall, control systems, then the PLCs and field equipment.
The precise layout depends on your processes and traffic. There’s no universal diagram, and the boxes at each tier aren’t interchangeable either. Throughput, environmental rating and port count all shift as you move down toward the cell level, which we go into properly in our guide to sizing the rugged firewall to the plant. What matters for IEC 62443 compliance is that systems with different security requirements stop sharing a broadcast domain and an implicit trust relationship.
Protocols and remote access
Standard firewall policy runs on source IP, destination IP and port. That’s thin context for a network carrying Modbus TCP, EtherNet/IP, PROFINET, DNP3, OPC, BACnet or IEC 60870-5-104, where a perfectly permitted connection can still carry an instruction nobody authorised. If your platform supports industrial protocol inspection, turn it on. It moves you from “allowed to talk” to “allowed to say this.” We’ve written separately about what an industrial firewall for OT security has to do that an enterprise box doesn’t.
Secure remote access deserves its own attention, because it’s where a disproportionate number of real incidents begin. The weak version is a vendor laptop, a VPN, and the run of the OT network. The strong version puts MFA in front, terminates the session on a gateway or jump server in the DMZ, and grants one authorised system for a stated purpose and a defined window. Identity, target, reason, duration. Constrain all four or you’ve constrained none.
When you simply can’t patch
This comes up in every single OT engagement, and there’s no tidy answer.
If a vulnerable system can’t be patched or replaced without stopping production, you fall back on compensating controls: isolation, microsegmentation, tight firewall policy, intrusion prevention, application allowlisting, virtual patching, protocol inspection, closer monitoring, restricted remote access.
None of that fixes the vulnerability. It shrinks the set of places the vulnerability can be reached from, which, until the next planned shutdown, is usually the only honest objective available.
Monitoring, and IEC 62443 compliance evidence for audits
Plants don’t hold still. New PLCs go in, firmware gets updated, a vendor needs access, a line expands, policy drifts. IEC 62443 compliance established once and never revisited is a photograph of a factory that doesn’t exist anymore.
Ongoing visibility should cover failed and unauthorised access attempts, devices appearing that nobody added, unusual communication, configuration changes, firewall violations, malware indicators, exploitation attempts.
Documentation carries just as much weight, because compliance gets demonstrated with evidence, not with assurances. Expect to keep the asset inventory, network diagrams, zone and conduit definitions, risk assessments, security level decisions, firewall policies, access records, remote-access procedures, vulnerability and patch history, backup procedures, incident-response plans, and change management records. Auditors ask for the boring ones.
“But we bought a certified product”
This is the single most common misreading of the standard, and it comes up constantly.
IEC 62443 addresses four groups: asset owners, system integrators, service providers, product manufacturers. Certification of a component tells you something about that component. Nothing more. A device can satisfy every applicable product requirement and still sit in an architecture that’s wide open on three sides.
A certified box is not IEC 62443 compliance, and a firewall is not a programme. Getting there takes the combination: people, process, architecture, technology, documentation, and someone actually watching.
A roadmap that survives contact with reality
| Stage | Activity | Output |
|---|---|---|
| 1. Discover | Identify OT assets | Asset inventory |
| 2. Map | Understand communication | Traffic baseline |
| 3. Assess | Perform OT risk assessment | Risk register |
| 4. Classify | Determine security requirements | SL-T per zone |
| 5. Design | Define zones and conduits | Security architecture |
| 6. Protect | Deploy controls | Segmented OT environment |
| 7. Monitor | Detect security events | OT visibility |
| 8. Document | Maintain evidence | Audit readiness |
| 9. Improve | Review risks and controls | Continuous improvement |
Discover, assess, design, implement, validate, monitor. In that order. The failure mode, and it’s a common one, is buy, install, assume.
How Vays Infotech works with plants on this
Doing it well needs people who understand cybersecurity and industrial network architecture, which is a narrower overlap than it sounds. Our work tends to fall into four areas.
Assess. OT asset discovery, network assessment, IT/OT architecture review, communication analysis, gap assessment, risk identification. Establishing what’s genuinely there before anyone recommends anything.
Architect. Designing the target state: zones and conduits, an industrial DMZ, IT/OT segmentation, secure remote access, network resilience, and controls placed where they’re useful rather than where they fit.
Protect. Implementing what the risk assessment justified: industrial and next-generation firewalls, industrial network segmentation, intrusion prevention, protocol visibility, secure VPN and ZTNA, access control, endpoint protection where the hardware can carry it.
Monitor and maintain. Firewall policy review, security updates, vulnerability remediation, configuration review, network monitoring, change management, documentation, and support as the plant changes underneath you.
The aim was never another appliance in the rack. It’s moving a flat, largely unwatched industrial network toward one that’s segmented, risk-based and observable.
From compliance to resilience
The real value of the standard is the questions it forces, most of which plants have never formally answered. What OT assets do we have? Which ones matter? What happens if they’re compromised? Which systems genuinely need to talk to each other? Where should the network be divided? What security level does each zone need? Who gets access, and for how long? How are the unpatchable systems protected? Would we even detect an attack? How fast could we recover?
Answer those properly and compliance stops being the point. What you’ve built by then is an operation that can take a hit and keep making product.
If you’re looking at an IEC 62443 compliance readiness assessment, an OT segmentation project, or a wider industrial cybersecurity refresh, Vays Infotech can review what you’re running today and put together a roadmap that fits how the plant actually works.
