An unmanaged PoE switch is not a worse switch. It is a switch that cannot tell you anything. When a camera drops at three in the morning, the managed unit in the same rack can tell you which port lost PD detection, how many CRC errors accumulated on that cable before it went, and whether the link flapped eleven times in the last hour. The unmanaged unit tells you the port LED is off. That difference is worth more than every feature on the comparison sheet, and it is the only reason I specify managed hardware on projects where a truck roll costs more than the switch.
I learned this the expensive way. Years ago I signed off a 20-camera retail fit-out with an unmanaged 24-port unit because the budget was tight and the topology was flat — one switch, one NVR, nothing clever. Eight months later the site started losing cameras in groups of four or five at a time, always in the evening. No logs anywhere. I drove out three times: reseated cables, swapped cameras, replaced a power supply. The actual cause was a single water-damaged RJ45 on a pole that had been arcing intermittently, filling the switch's forwarding table with garbage and stalling the segment. A managed switch would have shown me the port's error counters in the first five minutes. Instead I spent three evenings and about the price of six managed switches finding it by hand.
What you are buying is evidence, not features
The datasheet comparison always leads with VLANs, QoS, link aggregation, ACLs. On a surveillance network of a dozen cameras, most of that goes unused. What actually gets used is the boring part: per-port counters, PoE status per port, LLDP neighbour discovery, and a log with timestamps.
That is what turns a vague complaint into a diagnosis. "Cameras keep dropping" is not a ticket anyone can act on. "Port 14 on the west switch has 4,312 CRC errors and dropped PD detection twice at 19:40" is a ticket with an owner. If you have ever argued with a contractor about whether a cable was faulty or a camera was faulty, you already know why this matters.
The second thing you buy is reach. On an unmanaged switch, the only way to power-cycle a frozen camera is to drive to the site, unplug the cable, count to ten and plug it back in. On a managed switch it is a click, or an automatic rule that does it for you. Multiply that by a few dozen cameras across a few sites and the switch pays for itself in one quarter.
The three failures an unmanaged switch cannot describe
Almost every surveillance outage I get called about falls into one of three buckets. The unmanaged switch is blind to all three.
A loop. Someone adds a small switch in a cabinet, or a cable gets patched back into the same unit. Without spanning tree, broadcast frames circulate until the segment saturates. Cameras do not go dark one at a time; they go dark in a cluster, and every port LED blinks like it is working fine. On a managed switch you see the log line and the port that is flapping. On an unmanaged one you see nothing at all, and the fault looks exactly like a dead switch.
A marginal PoE port. PD detection fails intermittently when the cable's loop resistance has crept up — water in a connector, a crushed pair, a bad punch-down. The camera reboots, comes back, reboots again next week. Per-port PoE status would show you the detection failures and the delivered current. Without it, the only evidence is the customer's memory of when it happened.
A dying cable. CRC and alignment errors climb for weeks before a link fails outright. On a managed port you can read the counters and replace the cable before the outage. Without counters, the first symptom is the outage, and the first hypothesis is always "the camera is broken" — which is why so many perfectly good cameras get replaced. If you have been through the power-up troubleshooting checklist, you know how much faster it goes when you can see the port's numbers.
Web-managed is not L2 managed, and the gap is bigger than the price
This is where most buyers get caught, because the box says "managed" and the price looks like a bargain. A web-managed switch gives you a browser UI for the essentials: per-port PoE on and off, VLANs, sometimes basic QoS, sometimes a crude loop detection. An L2 managed switch gives you that plus spanning tree with fast convergence, link aggregation, port mirroring, SNMP and syslog, ACLs, and usually a CLI.
The practical difference on a 30-camera site is convergence and observability. Rapid spanning tree reconverges in the region of a second or two; classic STP takes tens of seconds, which on a video network means a visible gap in recording and a burst of reconnects. And a web-managed unit that can toggle PoE ports but cannot send a syslog trap is still a switch you have to poll by hand at three in the morning.
| Capability | Unmanaged | Web-managed | L2 managed |
|---|---|---|---|
| Per-port PoE on/off and scheduling | No | Usually | Yes |
| Per-port error and PoE telemetry | No | Partial | Yes |
| Loop detection / spanning tree | No | Basic or none | RSTP / MSTP |
| SNMP traps and syslog | No | Rarely | Yes |
| Port mirroring for packet capture | No | Rarely | Yes |
| VLANs for camera / management separation | No | Yes | Yes |
| Remote firmware recovery (dual image) | No | No | Usually |
| Field-replaceable with zero configuration | Yes | Mostly | Needs a config restore |
The two features that actually earn their keep on a camera network
If I had to justify a managed switch on a surveillance project with only two features, it would be these.
Scheduled per-port PoE. Not for saving electricity — for recovery. A camera whose firmware locks up once a month can be power-cycled on a schedule, or on a ping check. This is the single most effective reliability measure on cheap camera hardware, and it is impossible on an unmanaged unit. I have kept eight-year-old cameras in service for years with a nightly 30-second PoE cycle and nothing else.
Port-level power reporting. Delivered watts per port tells you when a camera's IR array has degraded, when someone swapped a 12 W dome for a 25 W PTZ without telling anyone, and when a port is running at the edge of its class. On a 24-port unit, this is also how you discover that your "300 W budget" is actually being spent by 18 devices you thought were 8 W each.
Everything else — VLANs, ACLs, aggregation — is useful but optional at this scale. Buy the managed unit for these two, and treat the rest as a bonus.
What a managed switch costs you that nobody puts in the quote
Managed hardware is not free to own. It is free to buy and expensive to keep, if you are careless.
There is firmware debt: someone has to track vendor releases, decide which ones matter, and schedule a maintenance window. There is configuration drift: a switch replaced in a hurry with a factory-default config is now an unmanaged switch with a management port open to the network. There is lockout risk: I have locked myself out of a remote site by changing a management VLAN on a Friday afternoon, and I would rather not repeat it. And there is the classic one — a managed switch with a default password and a management IP reachable from the camera VLAN is a worse security posture than the dumb switch it replaced.
So the honest rule is this: a managed switch is worth it when someone will actually use the telemetry, and when the site has a documented config backup. If neither is true, you are paying for a browser login nobody opens, and an unmanaged unit with good surge protection is the better engineering decision.
The routine I run before a managed unit leaves the bench
Ten minutes here saves a site visit later. This is the sequence I use, in order, every time.
- Change the default credentials, then change them again if the first password was anything a search engine has ever seen. Write it in the site file, not on a sticker.
- Move management onto its own VLAN and restrict which subnets can reach it. A management interface visible from the camera VLAN is an open door with a nice view.
- Enable RSTP and mark every camera-facing port as an edge port. Leave one uplink as the only path back, and write down which port that is.
- Set the PoE schedule and the ping-based recovery rule. Thirty seconds off at 04:00, plus a reboot after three failed pings, covers most frozen-camera cases.
- Export the configuration and save it next to the port map, outside the switch. Include the firmware version in the filename.
- Log the firmware date in the site notes with a review reminder for twelve months out, so the switch does not quietly become an unpatched appliance nobody owns.
Do those six things and a managed switch earns its price. Skip them and you have bought a device that is more expensive to replace than the one it replaced, with the same amount of information coming out of it.
How I specify it by project size
| Project | What I specify | Why |
|---|---|---|
| Under 8 cameras, one cabinet, on site weekly | Unmanaged, with a decent power budget | Telemetry nobody reads adds no value; simplicity wins |
| 8–24 cameras, single building | Web-managed, per-port PoE scheduling | Scheduled reboots and PoE toggling cover most failures; VLAN separation if the network is shared |
| 24+ cameras, multi-building or remote | L2 managed with RSTP, SNMP, syslog | Loops and cable faults have to be diagnosable without a site visit |
| Outdoor or industrial cabinets | Managed industrial unit, wide temperature, dual DC input | The failure mode is usually power and heat, not features |
One caveat on port count: buy the managed switch you need plus four spare ports, not the one that fits exactly. The day someone adds a camera and there is no free port, the cheap fix is a small unmanaged switch daisy-chained in the cabinet — which is exactly how loops get created on networks that were designed properly.
If the runs are long or the site is spread out, the switch choice matters less than the topology. I would rather have an unmanaged switch and fibre between buildings than a managed switch with a 140 m copper span in the middle of it, and the long-run comparison is the place to start that decision.
Questions I get asked every week
Can I add management later by replacing one switch?
Yes, and that is often the right sequence. Keep the unmanaged units as edge devices, put a managed switch at the core, and you gain most of the visibility for a fraction of the cost. Just make sure the uplinks are documented before you start, or you will spend the first evening tracing cables by hand.
Does a managed switch improve PoE reliability?
Not the power delivery itself. It improves your ability to observe and recover, which is what actually determines uptime. A managed unit with a weak power supply is still a weak unit.
Is web-managed enough for a school or small factory?
For a single-building site with under two dozen cameras and someone on site during the day, usually yes. The moment the site is remote, or two people share the network, I move up to L2 managed for the logging alone.
What happens if the managed switch loses its config?
It boots to defaults: no VLANs, no PoE schedule, management on a default address. That is why a config backup saved outside the switch is not optional. I keep a text file per site with the config and the port map, and it has saved me more than once.
Do I need managed switches for a pure PoE lighting or access-point deployment?
The same logic applies, with a different weight. Lighting controllers rarely need a manual reboot, so scheduling matters less; access points benefit enormously, because a PoE bounce is the standard fix for a wedged radio.
How much does the difference actually cost?
On a 24-port PoE unit, the jump from unmanaged to web-managed is usually a modest percentage, and from web-managed to L2 managed is a larger one. Compare that against one after-hours callout, and the arithmetic is rarely close. The managed range and the plain PoE switch range sit side by side if you want to price the gap for a specific port count, and the industrial models are the ones I reach for when the cabinet is outdoors.
My rule after fifteen years of this: buy an unmanaged switch only when you are certain nobody will ever ask you what happened at 3 a.m. On every other project, the telemetry is the product. The switching is almost incidental.