How to Set Up a Managed Switch VLAN for OT
A VLAN lets one physical switch carry several logically separate networks, which is how a controls engineer keeps control traffic, instrument traffic, and any business or camera traffic apart on shared switch hardware. This how-to walks through planning the VLAN scheme, assigning ports, configuring the trunk between switches, and proving the isolation actually holds. It is conceptual rather than vendor-specific: the menu names differ by switch, but the sequence and the verification are the same everywhere.
Set up a managed switch VLAN for OT in one line: To set up a managed switch VLAN for OT, first plan a VLAN ID for each traffic class, then create those VLANs on the switch, assign each device port as an access port in its VLAN, and configure the inter-switch links as trunk ports carrying the required VLANs. Finally verify isolation by confirming devices in different VLANs cannot reach each other except through the router or firewall you intend, which is the whole point of segmenting.
Plan the VLAN Scheme First
A VLAN scheme is a design decision made before you touch the switch. Decide which traffic classes must be separated - typically control and I/O, instrumentation, engineering access, and any non-control traffic such as cameras or business systems - and assign each a VLAN ID and an IP subnet. Keeping one VLAN per traffic class and one subnet per VLAN is the clean pattern, because it makes the segmentation visible in the addressing and simple to reason about. The rationale for this separation is covered in the reference on the OT VLAN.
Reserve VLAN 1, the default VLAN most switches ship with, for nothing operational. Devices left in the default VLAN because no one assigned them are a classic source of accidental cross-traffic, so plan to move every real device into a purpose-built VLAN and leave the default empty. Document the ID-to-purpose mapping and the subnet for each VLAN in the site network drawing, because a VLAN scheme that lives only in one engineer's head is unmaintainable and dangerous during a fault.
Decide up front how the VLANs will communicate where they must. VLANs are isolated by default, so any required traffic between them - an engineering workstation reaching a controller, or SCADA polling an instrument VLAN - has to pass through a router or firewall that you control and can log. Planning those inter-VLAN paths deliberately, rather than discovering them by breaking things, is what turns VLANs into real network segmentation instead of just cosmetic grouping.
Create VLANs and Assign Access Ports
On the switch, create each VLAN from your plan by its ID, giving it a descriptive name so the configuration reads clearly months later. Creating the VLAN just tells the switch the VLAN exists; it carries no traffic until you assign ports to it. Work from your documented ID-to-purpose map so the VLAN numbers on the switch match the drawing exactly, because a mismatch between the design and the running configuration is how segmentation quietly breaks.
Assign each device-facing port as an access port belonging to a single VLAN - the VLAN of whatever is plugged into it. An access port carries untagged traffic for exactly one VLAN, which is right for an end device like a PLC, RTU, instrument, or workstation that has no concept of VLAN tags. The distinction between access ports for end devices and trunk ports for switch-to-switch links is fundamental and is detailed in the guide to a trunk port versus access port.
Move devices out of the default VLAN as you assign ports, and account for every port. An unassigned port sitting in the default VLAN is an open door: plug anything into it and that device lands in the default VLAN with whatever else was left there. Disable unused ports entirely or park them in an unused, isolated VLAN so a stray connection cannot bridge into an operational network, a hardening step that pairs with the broader switch-hardening procedure.
Configure the Trunk Between Switches
Where two switches connect and must both carry the same VLANs, the link between them is a trunk port, not an access port. A trunk tags each frame with its VLAN ID so the receiving switch knows which VLAN the frame belongs to, allowing many VLANs to share one physical inter-switch cable while staying logically separate. Configure the trunk to carry only the VLANs that genuinely need to cross that link, because a trunk that blindly carries all VLANs spreads every VLAN everywhere and undermines the isolation you built.
Set the native VLAN of the trunk deliberately and avoid leaving it as the default, since untagged frames on a trunk fall into the native VLAN and a careless native-VLAN setting can leak traffic between segments. Prune the VLAN list on each trunk to the minimum, so a VLAN that only exists on two switches does not propagate across the whole plant. This pruning is part of keeping the segmentation tight rather than nominal.
Match the trunk configuration on both ends. A link configured as a trunk on one switch and an access port on the other, or trunks carrying mismatched VLAN lists, produces confusing partial connectivity where some VLANs work and others do not. Confirm both ends agree on trunk mode, the allowed VLAN list, and the native VLAN, because trunk mismatches are among the most common and most frustrating VLAN faults to diagnose after the fact.
Verifying the Result
The verification that matters is isolation: prove that a device in one VLAN cannot reach a device in another VLAN except through the router or firewall you intended. From a device in the control VLAN, confirm you cannot reach a device in the business or camera VLAN directly, and from the instrument VLAN confirm you can reach only what the design permits. Isolation that exists on the configuration screen but fails this reachability test is not real, and this test is the heart of the separate procedure for verifying network segmentation with a test plan.
Confirm the intended paths work as well as the blocked ones. A VLAN scheme that isolates perfectly but also blocks the SCADA server from polling the instrument VLAN has broken the plant, so verify that every legitimate flow - engineering access, SCADA polling, time sync - still passes through its intended router or firewall path. Segmentation is correct only when the wanted traffic flows and the unwanted traffic does not, both proven by test.
Check the switch's VLAN and port tables against your plan. Every access port should show its intended VLAN, every trunk should show the intended allowed list and native VLAN, and no operational device should remain in the default VLAN. A configuration that matches the documented design, combined with passing reachability tests, is what lets you sign off the VLAN setup with confidence rather than hope.
Common Mistakes
The most common mistake is leaving devices in the default VLAN. Ports that were never assigned, or devices dropped in during a hurry, sit in VLAN 1 and can reach each other across the isolation you thought you built. Move every operational device into a purpose-built VLAN and leave the default empty, disabling or isolating unused ports.
A second mistake is trunking all VLANs everywhere. A trunk configured to carry every VLAN spreads all of them across every switch, so a segment that should exist on only two switches ends up reachable plant-wide, quietly defeating the point of segmenting. Prune each trunk to the minimum VLAN list it actually needs.
The third is verifying only that the wanted traffic flows and never testing that the unwanted traffic is blocked. A VLAN setup can look successful because SCADA still works, while cross-VLAN reachability you never checked leaves the isolation broken. Always test both directions: the intended paths pass, and the forbidden paths fail, before declaring the segmentation done.
Frequently Asked Questions
What is the difference between an access port and a trunk port on an OT switch?
An access port carries untagged traffic for exactly one VLAN and is used for end devices like PLCs, RTUs, and workstations that know nothing about VLAN tags. A trunk port tags each frame with its VLAN ID and carries multiple VLANs over one physical link, which is used for switch-to-switch connections. Assigning the wrong type - a trunk where you needed an access port or the reverse - produces confusing partial connectivity.
Why should I not use the default VLAN for OT devices?
Because unassigned ports and unconfigured devices land in the default VLAN automatically, so anything left there can reach anything else left there, including a device someone plugs into a forgotten open port. Leaving the default VLAN empty and moving every operational device into a purpose-built VLAN removes that accidental bridge, and disabling or isolating unused ports stops a stray connection from bridging into an operational network.
How do I know my OT VLANs are actually isolated?
Test reachability, not just the configuration screen. From a device in one VLAN, confirm you cannot directly reach devices in the VLANs that should be separated, and confirm the legitimate flows still pass through the router or firewall you intended. Segmentation is real only when the forbidden paths fail and the intended paths work, both proven by test, because a configuration that looks isolated can still leak through a mis-set trunk or native VLAN.
Automation services
Need help turning this into a working system?
Merobix integrates SCADA, programs Allen-Bradley and Siemens PLCs, and designs and fabricates industrial control panels.
Meeting requests are reviewed before confirmation.