Both a managed and an unmanaged industrial switch will move Ethernet frames between the devices plugged into them, and for a simple panel where you just need a few controllers to talk, either one works. The difference shows up the moment you want the network to do more than forward blindly: separate traffic into zones, survive a broken cable, block a rogue device, or tell you what is going on inside it. This page contrasts the plug-and-play unmanaged switch with the configurable managed switch, lays out the features the managed one adds, and explains why the moment a SCADA network needs segmentation or redundancy it is forced up to a managed switch.
Managed vs unmanaged switch in one line: An unmanaged switch is a plug-and-play device that forwards Ethernet traffic between its ports with no configuration and no options, while a managed switch adds a configuration layer that provides VLANs for segmentation, ring or spanning-tree redundancy, port security, quality-of-service prioritization, and diagnostics. An unmanaged switch is cheaper and simpler and is fine for a small, flat, non-redundant network, but any topology that needs to be segmented, made loop-safe, or made redundant has to use a managed switch, because those capabilities exist only in the managed device.
An unmanaged switch is deliberately featureless. You power it, plug in your devices, and it immediately begins learning which device is on which port and forwarding frames accordingly, with no setup, no address, no login, and no settings to get wrong. That simplicity is its whole value proposition: a plant technician can replace a dead one with a spare from the shelf and the network comes straight back up, because there is no configuration to restore and nothing to reconfigure. For a small, self-contained panel where a handful of devices sit on one flat network, an unmanaged switch does the job cleanly and cheaply.
The cost of that simplicity is that the switch has no idea what it is carrying and no way to make any decision beyond basic forwarding. It cannot separate traffic into groups, cannot prioritize time-critical control frames over bulk transfers, cannot block a device that should not be there, and cannot tell you a single thing about its own health or the links attached to it. It is a silent black box: frames go in and frames go out, and if something is wrong you learn about it from the symptoms on the connected devices rather than from the switch.
Crucially, an unmanaged switch has no loop protection. It does not run spanning tree, so if the network ever contains a loop, from a redundant cable or a wiring mistake, the unmanaged switch will happily forward the resulting broadcast storm at full speed with nothing to stop it. This single limitation is what draws the hard line around where unmanaged switches are safe to use: only in networks that are genuinely flat and have no redundant paths, because the instant you add a second path you have created the possibility of a storm the unmanaged switch cannot prevent.
A managed switch adds a control and configuration layer on top of the same forwarding hardware, and that layer is where its value lives. The headline feature is VLAN support, which lets the switch carve its ports into separate virtual networks so that, for instance, control devices and video cameras and vendor equipment ride the same physical switch yet cannot see one another. VLANs are the mechanism that turns a flat network into a segmented one, so any plan to segment an OT network on the switches themselves depends on managed switches to enforce those boundaries.
Redundancy is the second major capability. Managed switches run loop-prevention and ring-recovery protocols, from standard spanning tree to fast proprietary ring protocols, that allow the network to have redundant links which stay safely idle until a failure and then activate to heal the network in a fraction of a second. This is impossible on unmanaged switches because it requires the switches to talk to each other and agree on which link to block. Alongside redundancy, managed switches add port security features that can lock a port to a specific device and disable it if an unexpected one appears, quality-of-service that prioritizes control traffic ahead of bulk data, and IGMP snooping that keeps multicast from flooding every port.
The often-underrated feature is diagnostics. A managed switch has an address, a management interface, and a set of monitoring protocols, so it can report link status, port error counts, traffic levels, and its own temperature and power, and it can send alerts when something changes. On an unmanned site that visibility is what lets staff see a link degrading or a port erroring before it becomes an outage, and it lets a network monitoring or SCADA platform pull switch health into the same view as the process. The trade for all of this is that a managed switch must be configured, and that configuration must be backed up, because a replacement switch is useless until its VLANs, redundancy, and security settings are loaded back onto it.
The choice between the two is not really about preference; it is dictated by what the network topology has to do. As long as a SCADA network is flat, small, and has a single path to every device, an unmanaged switch is a defensible, economical choice, and many perfectly good panels use them. The jump to managed switches becomes mandatory the moment any of three needs appears: you want to segment traffic into zones, you want the network to survive a single link failure, or you need visibility into the network itself. Each of those needs maps to a feature that exists only on a managed switch.
Segmentation forces the jump because VLANs live on managed switches, so the widely recommended practice of separating control, business, and vendor traffic simply cannot be enforced at the switch layer without them. Redundancy forces the jump because a ring or any second path requires a loop-prevention protocol to be safe, and running that protocol is a managed-switch capability; putting a redundant link on unmanaged switches does not give you resilience, it gives you a broadcast storm waiting to happen. Multicast-heavy control protocols push in the same direction, because without the IGMP snooping that only managed switches provide, that multicast floods every port and can cause I/O timeouts. In each case the topology decision, not the budget, makes the call.
For a remote SCADA site feeding a cloud platform such as Merobix, the managed switch also earns its place by becoming a monitored asset rather than a blind spot. Because it can report its port states, error counters, redundancy status, and temperature over a management protocol, those values can be trended and alarmed right alongside the process data, so staff learn that a ring has gone from redundant to running on its last path, or that a port is racking up errors, before the site actually drops offline. An unmanaged switch offers none of that, so on a network that matters enough to monitor, the managed switch is usually the right answer as much for the visibility as for the VLANs and redundancy.
Yes, and it is common. A frequent pattern is managed switches forming the redundant, segmented backbone while small unmanaged switches sit at the very edge fanning out a few devices in a single panel. The caution is that the unmanaged switches must never create a loop or a redundant path of their own, because they cannot participate in the loop-prevention protocol the managed backbone relies on, and the segmentation you configured on the managed switches does not extend into an unmanaged switch, so everything behind one unmanaged switch shares whatever single VLAN it connects to.
Most managed switches will forward traffic straight out of the box in a default configuration, so in that narrow sense they work unconfigured, but you get none of the reason you bought a managed switch until you set it up. VLANs, redundancy, port security, and prioritization all require configuration, and that configuration must then be backed up so a failed switch can be replaced quickly. This is the real operational difference: an unmanaged switch needs no configuration and no backup, while a managed switch needs both, which is the price of its capabilities.
It depends entirely on what the site's network has to do rather than on how big it is. If the site is genuinely flat, has no redundant links, needs no segmentation, and nobody needs remote visibility into the network, an unmanaged switch is the sensible, cheaper choice. If the site needs any segmentation, any redundancy, or any switch-level diagnostics fed to a monitoring platform, a managed switch is required regardless of how few devices are involved, because those capabilities do not exist on the unmanaged unit at any price.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.