Isolated, VLAN, security zone: the words are not interchangeable

In most architecture reviews we attend, four words are used as though they meant the same thing: isolated, segregated, VLAN, security zone. They do not, and the confusion goes well beyond vocabulary: it produces networks that everyone believes are protected and that are not.

The method article in this series is about the reference that settles words like these: where a definition should be sourced, how to write one that survives a reviewer, and how to make every other document cite it instead of restating it. This one is that method applied to the four words an industrial network is described with — and to the mechanisms underneath them.

Worth twenty minutes of precision.

One sentence carries the rest of this article: security does not come from the logical split, it comes from what decides at the border. A site can run a dozen tidy VLANs and have no border anywhere. The sections that follow are what that sentence costs in practice — the mechanisms a VLAN really offers, and what a zone boundary has to contain before it counts as one.

Isolated: the air gap

A network physically cut off from every other. No cable, no route, no path. In theory unreachable from outside.

Two things to say about it. First, it genuinely is the strongest control when it is real. Second, it is almost never real, and it is increasingly incompatible with what plants are asked to do: remote support, predictive maintenance, MES integration, energy reporting. An architecture that depends on an air gap is an architecture that will be quietly breached by the business itself, one exception at a time.

Why air gaps decay, and what crosses them, is the subject of a separate article.

VLAN: a logical split, and nothing more

The most consequential misunderstanding sits here, so a little technical detail is worth it.

Start with what is actually being relied on. The tag is four bytes inserted into the Ethernet frame just after the source address: two bytes marking the frame as tagged, three bits of priority, one drop-eligible bit, and twelve bits of VLAN identifier, which is where the ceiling of 4 094 usable VLANs comes from. Those twelve bits say which VLAN the frame claims to belong to. They do not say who put them there, whether the sender was entitled to that VLAN, or what the frame may do once it arrives. No field in the tag carries a permission, because the mechanism was never designed to express one.

A VLAN separates broadcast domains. It is an organisational tool: it keeps traffic tidy, limits broadcast noise, and lets you group devices logically regardless of where they are physically plugged in. All of that is useful.

What it does not do is stop anything. Traffic between two VLANs is routed, and routing without filtering is simply connectivity with extra steps. If the router or layer-3 switch between VLAN A and VLAN B forwards everything, you have not segmented, you have relabelled.

Three specific weaknesses to know about:

• A VLAN carries no policy. It has no concept of allowed or denied. The policy lives wherever routing happens, and if nobody wrote one, the default is permissive.
• Trunk and native VLAN misconfiguration. A misconfigured trunk port, or an unchanged default native VLAN, lets frames reach places the diagram says they cannot.
• A compromised device is inside the VLAN. Everything in the same VLAN is reachable at layer 2 with no filtering at all. If your production cell is one flat VLAN, one compromised HMI reaches every controller in it.

The sentence worth remembering: a VLAN is a label, not a control.

Security zone: a perimeter with a policy

A security zone groups systems that share the same security requirements, and defines a controlled boundary around them. Communication with other zones passes through a conduit where the policy is enforced, typically an industrial firewall filtering by source, destination, protocol and, ideally, by industrial function code.

This is the model of IEC 62443, and its value is that it forces two questions that VLANs never force:

• What is this zone’s required security level, and does it match the consequence of losing it? A cell making a sterile product and a cell packing cardboard do not need the same protection, and pretending they do wastes money on one and under-protects the other.
• What exactly must cross this boundary, and why? That list, written down, is the security policy. If nobody can produce it, the firewall rules are archaeology rather than design.

Four properties separate a zone model that works from a diagram with rounded rectangles on it.

• A point where a decision is taken, on every conduit. An industrial firewall, a virtual firewall, or at minimum a layer-3 switch whose access lists are genuinely maintained, tested and version-controlled. The distinction is not in the hardware. It is in whether a decision is taken, and recorded.
• Deny by default. Anything not explicitly permitted is blocked. This is the requirement that forces the flow matrix to exist, which is why it is the part everyone postpones.
• Rules that understand the protocol. Permitting Modbus/TCP on port 502 says almost nothing. Reading a register and writing a configuration travel on the same port, under the same permission, and only the function code tells them apart.
• Asymmetry taken seriously. Telemetry going up and instructions coming down are not the same traffic, do not carry the same consequence, and have no business sharing a rule.

The test that settles it

One question exposes the difference immediately, and it is worth asking in any architecture review:

If a machine in this zone is compromised tomorrow, what can it reach in the next zone, and what, specifically, enforces that limit?

If the answer names a firewall and a rule set someone can display, you have zones. If the answer is “it is a different VLAN”, you have labels. If the answer is “it should not be able to”, nobody has tested it.

A longer form of the same question, worth writing into an audit brief: from a compromised asset, which critical equipment can I reach, using which protocols, and at what point is that attempt inspected, authorised and recorded? If the answer is everything, with no control and no trace, the network is not segmented. It is flat, with several addressing plans, which produces a reassuring diagram and an unchanged attack surface.

From here the article moves from the concept to the mechanism: what the VLAN actually does when you lean on it, and what a boundary has to contain before it counts as one.

Two ways a frame ends up where it should not

Both are old, both are documented, and both are still found in plants, because the conditions they need are ordinary industrial conditions rather than mistakes.

Switch spoofing. A port still willing to negotiate its own mode can be talked into becoming a trunk. Something plugged into it announces itself as a switch, the port agrees, and what was an access port now carries every VLAN the trunk is entitled to carry. Automatic trunk negotiation is not part of the IEEE standard; it is a convenience certain switch families add, and where it exists it is usually enabled out of the box. That last detail is what makes it worth checking on your own equipment rather than assuming either way.

Double tagging. The more interesting one, because nothing has to be misconfigured for it to work. It uses a rule the standard requires.

Two consequences deserve more attention than they usually get in an industrial setting.

The first is that the path is one way. The outer tag is removed and never replaced, so nothing in the target VLAN can answer back along it. In an office network that is a serious limitation: you cannot read anything. In an OT network it is a much smaller one, because a great deal of what matters can be done without reading. An instruction to a controller does not need an answer to take effect.

The second is the precondition. Both techniques require physical access to a port, or a foothold on a machine already inside. In an office that precondition does real work. In a plant it does much less: cabinets stand on the production floor, field switches have free ports, contractors arrive with laptops and connect them where the work is. The assumption that a port is hard to reach is an office assumption that travelled to the shop floor without being re-examined.

The four port settings, and the one that is not the same as “no”

Most managed switches offer four settings for a given port on a given VLAN. Three of them are well understood. The fourth is routinely treated as decoration.

The distinction between the last two is the one worth carrying away. No means the port is not in the VLAN. Forbidden means it may not be put in it. On a switch where nothing registers VLANs automatically the two behave identically, which is why the difference is so rarely noticed. The moment a dynamic registration protocol is running anywhere in the estate, and the multiple registration protocols are standard rather than exotic, they diverge: a port set to no can be joined to the VLAN by a declaration arriving over the wire, and a port set to forbidden cannot. Of the four, it is the only setting that is a refusal rather than a description.

It costs nothing to set, and it outlives the engineer who set it. That is a rare combination in a network.

The chain that has to agree

A tag is only honoured by equipment that has been told the VLAN exists. That sounds obvious until the path crosses more than two switches.

The failure is quiet in a particular way. Both ends of the path are right, and the person who configured them can prove it. The device that drops the frame sits in between, was often installed by somebody else and years earlier, and is frequently a switch added to reach one more cabinet rather than as part of any architecture. Nothing records a dropped frame as an error. Troubleshooting starts at the ends and works inwards, which is exactly the wrong direction.

The practical rule is short: the VLAN must be declared on every switch along the path, and carried on every port that links one switch to the next. A VLAN plan that is complete on the two switches you drew is not a VLAN plan.

Untagged on the default VLAN: convenience with a bill attached

There is a pattern that works, is easy to maintain and is very common: putting the ports that face unmanaged equipment untagged on the default VLAN. Unmanaged switches cannot handle tags, so this lets them be dropped into the network with no configuration at all, and a great many industrial estates contain unmanaged switches nobody is going to replace this year.

Two costs come with it, and both are better named than discovered.

• The default VLAN is where everything else lands. A new port, a device reset to factory settings, an unconfigured replacement: they all arrive there. Anything sensitive sharing that VLAN shares it with every accident.
• Untagged traffic mixed with tagged traffic misbehaves in ways that look like network problems. Frames handled by a device that was not expecting them are dropped, or delivered somewhere unintended. What reaches the control room is intermittent latency and communication that works most of the time, which is the hardest kind of fault to get anyone to fund.

And as the previous section showed, a default VLAN shared between a trunk and ordinary access ports is precisely the condition double tagging needs.

None of that makes the pattern wrong. It makes it a deliberate choice, applied to traffic whose exposure somebody has thought about, rather than a default that arrived with the equipment.

The flow matrix is the deliverable

A filtering policy is not written rule by rule. It is written as a grid: every zone against every other zone, each cell holding either a permitted flow or a refusal somebody accepted. Written that way, an empty cell is a decision. Written rule by rule, an empty cell is an oversight that nobody can tell apart from a decision.

One cell is doing most of the work. Permitting Modbus/TCP 502 between supervision and the field permits everything the protocol can do, writing registers included. Permitting function codes 1 to 4 permits reading coils, discrete inputs, holding registers and input registers, and nothing else. The write codes, single and multiple coils and single and multiple registers, are simply absent; and the vendor-specific codes used to download a program sit outside the publicly documented codes altogether, so a rule that names function codes excludes them by construction.

Whether your equipment can express a rule at that level is one of the very few product questions in this whole discussion that actually decides an architecture.

Diode or gateway: two different guarantees

Unidirectional gateways appear in most good-practice lists, sometimes under a phrase that quietly covers two very different objects. Confusing them leads to overestimating what has been bought.

A data diode has no return path in the hardware. The property does not depend on a configuration being right, on firmware being current, or on anybody maintaining anything. It holds because there is no physical means of sending anything back. That is the strongest guarantee available in a network, and it is narrow: it suits a data historian and outbound telemetry, and it suits nothing that needs a conversation.

A bidirectional secure gateway permits a conversation under strict application-level control. It is far more useful, since remote access and application exchanges both need an acknowledgement, and its guarantee is software. Software has an attack surface. Not a large one in a well-built product, but not zero either, and not independent of maintenance.

Both are legitimate. The mistake is to spend a diode's budget and describe a gateway's capability, or the reverse. In a sound architecture a diode protects one or two particularly sensitive conduits. It does not replace the filtering policy on all the others.

Two failure modes we see constantly

Zones drawn by geography instead of by requirement. Zones defined as “building A”, “building B” feel natural and mean nothing in security terms. Zones are defined by shared security requirement, which often puts two machines in different buildings in the same zone, and two machines side by side in different ones.

The any-any rule that stayed. An industrial firewall installed with a permissive rule during commissioning, because the flows were not documented and the line had to start. The rule is never tightened, because tightening it now risks stopping production and nobody can say which flows are legitimate. A firewall with an any-any rule is a cable with a maintenance contract.

A bigger firewall will not get you out of that second one. The traffic baseline will: two weeks of passive capture tells you what actually talks to what, and turns rule-writing from a gamble into a transcription.

Where to start

Few sites can be rebuilt in one go, and the order matters more than the ambition. This sequence extracts the most risk reduction from a constant effort, and keeps the risk to production low while it does it.

1. Inventory, passively. You do not segment what you do not know. Passive capture through a mirror port or a tap carries no risk to the process, and almost always reveals flows nobody knew about. Two or three weeks is usually enough to catch the weekly and monthly patterns.
2. Define the zones on function and consequence, not on the VLANs you already have. It is common for one VLAN to contain three distinct zones once criticality is the criterion. Starting from the existing plan guarantees you inherit decisions taken for entirely different reasons.
3. Take the trust boundaries first. The link to the management network, vendor remote access, remote maintenance. Here the ratio of effort to risk avoided is most favourable, and usually where the flows are already best documented.
4. Run in observation before you block. Most industrial firewalls will log without enforcing. A few weeks in that mode removes nearly all the unpleasant surprises at the moment of switching to deny by default, and it is the difference between a controlled cutover and an unplanned stop.
5. Keep it alive. The filtering policy is a living deliverable: versioned, reviewed at every process change, tested. A matrix frozen three years ago describes a network that no longer exists.

The VLAN is still worth having

None of this condemns the mechanism. A VLAN organises, it structures an addressing plan, and it is a convenient precondition for zones: without it there is often no boundary on which to apply a policy at all.

What it describes is an intention. What constrains anything is the set of rules applied on the conduits, and the discipline with which they are maintained.

A VLAN tells you where a frame claims to belong. A zone tells you what it is allowed to do once it gets there. The split is not the control; the border is.

References

• IEC 62443-3-2:2020, Security risk assessment for system design: zones, conduits and security levels. webstore.iec.ch
• IEEE 802.1Q, Bridges and Bridged Networks: VLAN tag format, native VLAN handling and registrar administrative control. standards.ieee.org
• Modbus Organization, MODBUS Application Protocol Specification (public, user-defined and reserved function codes). modbus.org
• BSI, Industrial Control System Security: Top 10 threats and countermeasures 2022 (BSI-CS 005E, v1.5). allianz-fuer-cybersicherheit.de