A VLAN is not an IEC 62443 segmentation strategy

“We have separated IT and OT. We use VLANs.”

That sounds good, and a VLAN can absolutely be part of a good solution. But it is not the question I would start with. I would first want to know:

What are we actually trying to protect?

Why is this machine in this zone? Which systems need to communicate with it? Which data really needs to move between them? Who can connect from outside? And what happens to operations if we block a connection during an incident?

That is where the real OT segmentation conversation starts. Not with VLAN 20 or VLAN 30. With risk.

A VLAN tells you where traffic can be separated. Not why.

A VLAN is a technical way to separate systems logically. That can be useful, and often it is necessary. But a VLAN does not automatically tell us:

• which critical function a system supports;
• what the consequences of failure or compromise could be;
• why particular systems belong together;
• which communication is genuinely required;
• which supplier needs access;
• whether a connection can safely be interrupted;
• how much protection a part of the environment needs.

Those are not configuration questions. They are risk and architecture questions. And that is where zones and conduits in IEC 62443 become useful.

Think about a building, not a switch

Imagine a large building. You can put walls everywhere, but more walls do not automatically make the building safer. First you want to understand:

• what happens in each room;
• which rooms matter most;
• who needs access;
• which doors are genuinely necessary;
• which doors should normally stay closed;
• what happens if a door is locked during an emergency.

Only then do you decide where walls, doors, locks and monitoring belong. The principle is similar in an industrial environment. A good design does not start with “how many VLANs should we create?” but with “which functions, risks and necessary connections do we have?”

Step 1: define what you are assessing

IEC 62443-3-2 starts by defining the System under Consideration. In plain language: which part of the real world are we talking about? It could be an entire plant, a production line, an energy installation, a water treatment facility, or a single machine or skid.

That boundary matters. If nobody is clear about what is inside and outside the assessment, it becomes difficult to have a useful conversation about zones, risk or protection later.

Step 2: understand the consequences

Then comes risk. Not only “can this system be hacked?”, but more importantly:

“What happens to the organisation if this system is no longer trustworthy or available?”

In OT, consequences often go beyond data. Think about downtime, lost production, quality problems, equipment damage, environmental impact, loss of process visibility and safety consequences.

Two technically similar systems can have completely different risk profiles. The architecture should reflect that difference.

Step 3: create zones you can explain

A zone is not simply another word for a VLAN or subnet. It is a logical grouping of assets that should be treated in a comparable way from a cybersecurity perspective. There should be a reason behind the grouping — because systems support the same critical function, have similar consequences if they fail, require comparable access, or need a comparable level of protection.

When someone looks at the architecture, the question “why are these systems together?” should have a sensible answer. Not: “because they were put on the same switch years ago.”

One grouping is not a matter of taste: safety-related systems belong in their own zone. 62443-3-2 treats them separately, and that is not a formality — a safety function that becomes dependent on an ordinary process connection is a different kind of risk from a stopped line.

Step 4: identify the required data flows

This is where many network diagrams become too shallow. There is a line between two boxes, perhaps even a firewall in between, but nobody can clearly explain why the line needs to exist.

That is why I want to understand the required data flows as well as the zones. For every important flow, I want to know:

• which system or zone initiates the communication;
• where the communication goes;
• which information or function is required;
• the direction of the data;
• why the communication is needed;
• when or how often it is required;
• what happens operationally if the flow becomes unavailable.

The difference looks small, but it is fundamental. Technical: `VLAN 30 can communicate with VLAN 40.` Operational: `Production Zone A sends process information to OT Operations so operators can monitor the process.`

The first tells us what is technically possible. The second tells us what is necessary.

A firewall rule tells you what is possible. A data flow tells you what is necessary.

Once you know that distinction, it becomes much easier to decide what should be allowed — and what is not actually needed.

Step 5: use conduits to control necessary communication

Zones almost never operate completely on their own. Monitoring, engineering, reporting and maintenance require communication between different parts of the environment. IEC 62443 uses the concept of conduits for this: the controlled communication between zones for which common security requirements apply.

A conduit is therefore not automatically one firewall, one cable, one VLAN or one protocol. Those technologies may be part of the implementation, but the question comes first: which communication needs to exist, and how do we want to control it?

Step 6: decide how much protection a zone needs

This is where 62443-3-3 comes in, and it is the step missing from most diagrams. Zones and conduits say what belongs together and what moves between them; they say nothing yet about how robust it has to be.

62443-3-3 describes system requirements grouped into seven foundational requirements — among them identification and authentication control, use control, system integrity, restricted data flow, timely response to events and resource availability. Security levels are attached to those requirements.

What makes that useful is that you can set a target security level (SL-T) per zone based on the risk from step 2, and then compare it with what the environment can actually do today. That gap is your work list, and it is considerably more concrete than “we should do something about segmentation”.

A zone holding a packaging line and a zone holding a safety function should not land on the same level. If they do, something has not been thought through — or protection has been added where it only buys complexity.

What might this look like?

There is no universal IEC 62443 network architecture. A factory, airport, ship, water utility and energy facility all have different processes and different risks. But a simplified drawing can make the principle visible.

The arrows between the zones are not decoration. They represent required data flows:

• DF-01 — process monitoring: production zones to OT Operations, and from there to the industrial DMZ;
• DF-02 — business reporting: industrial DMZ to Business IT;
• DF-03 — engineering and maintenance: OT Operations to an authorised production zone;
• DF-04 — supplier maintenance: external supplier via controlled remote access to an authorised OT target.

Not because IEC 62443 says every environment must contain these exact flows. But because every important connection should have a clear reason to exist.

Put the supplier on the drawing too

Remote access is not a footnote. A supplier may be essential for maintaining an installation, but remote access also creates a route from outside into the environment. That means “we use MFA on the VPN” is not the end of the conversation. I also want to know:

• which zone the supplier can reach;
• which systems are accessible;
• when access is possible;
• who approves it;
• how activity is monitored;
• how access can be revoked immediately;
• who we call when something goes wrong;
• what we do if the supplier itself is unavailable.

If a supplier can technically reach many systems because it was once convenient, a neat VLAN diagram tells us very little about the real risk. How that plays out in practice is covered in our article on the Dutch Cybersecurity Act, AI and OT.

A beautiful drawing can still describe a poor architecture

Architecture diagrams can look convincing: coloured boxes, firewalls, a DMZ, VLAN numbers, arrows. But I would put a few simple questions next to the drawing. Why does this zone exist? Why are these systems together? Which data needs to move between these zones, and why is that flow necessary? Which risk are we reducing? And what happens if we block the connection?

If nobody has a good answer, we mostly have a neat network diagram. Not yet a risk-driven security architecture.

Put your current OT diagram on the table

You do not need to wait for a large programme. Take your current architecture or network diagram and work through these questions:

1. Is it clear exactly what we are trying to protect?
2. Can we explain why systems are in the same zone?
3. Have IT and OT been deliberately separated, and do we understand the necessary communication between them?
4. Are safety-related functions in a zone of their own?
5. Have we explicitly identified the required data flows between zones?
6. For every important flow, can we explain who communicates with whom, which function is required and why?
7. Do we know the protection level we want per zone, and how far we are from it?
8. Is external and supplier access visible and controlled?
9. Do we know what happens operationally when a connection is lost?
10. Does communication exist that nobody can still explain a valid need for?

That final question can produce the most useful discussion. Legacy connectivity is not automatically required connectivity.

The objective is not as much segmentation as possible

More zones are not automatically better. More firewalls are not automatically better. More rules are not automatically better. Complexity can become a risk of its own.

The objective is to design an environment where you can explain what you are protecting, why assets belong together, which communication is necessary, what happens if that communication becomes unavailable, and which protection is appropriate for the risk.

A VLAN can be an excellent part of that. So can a firewall. So can a DMZ. But the technology follows the risk decision, not the other way around.

So when someone says “our OT is segmented, we have VLANs”, my next question is: “good. Can you explain why the zones and data flows were designed this way?” That is where the interesting conversation starts.

About the Quick Check

The CyberBusters Zones & Conduits Architecture Quick Check is a practical conversation tool. It is not an IEC 62443 certification, conformity assessment or replacement for a formal risk assessment.

IEC 62443-3-2 addresses, among other things, defining the System under Consideration, cybersecurity risk assessment, partitioning into zones and conduits, further risk analysis, and establishing and documenting appropriate security requirements. IEC 62443-3-3 describes the system requirements and their associated security levels.

From architecture to implementation

Zones, conduits and data flows are one part of the picture. The next step is bringing risk, security requirements, suppliers, governance and lifecycle together into an executable IEC 62443 programme. For a structured route through that, there is the PECB ISA/IEC 62443 Lead Implementer.

Further reading

• IEC 62443-3-2 — security risk assessment for system design
• IEC 62443-3-3 — system security requirements and security levels
• ISA — ISA/IEC 62443 series of standards
• CyberBusters — The rules are in force. But do you know what to do when something goes wrong?