Putting cameras, door access and sensors on one network without breaking it
A camera with a default password on the same network as your accounts system is a route in that no password policy covers.
IoT network segmentation means putting cameras, door controllers and sensors on their own network segment with explicit rules about what they may reach. Without it, a device shipped with a default password sits alongside your file server, and the power budget of the switch becomes a problem nobody planned for.
Key takeaways
- Devices belong on their own segment with rules, not on the same flat network as staff computers.
- Switch power budget matters as much as port count, and is the failure that appears last.
- Most device traffic should never reach the internet at all, and should be stopped from trying.
- Default credentials and firmware updates need a named owner or they are nobody's job.
- Segmentation is cheap during a fit-out and disruptive afterwards, so it belongs in the cabling design.
Why a flat network stops working once devices arrive
A small office network is usually flat: everything plugs in, everything can reach everything, and that simplicity is genuinely an advantage while the only things plugged in are computers and a printer.
Connected devices break the assumption behind it. A camera is a small computer running a web server, often with a default password, frequently with firmware that was last updated by the manufacturer some time ago, and typically installed by whoever was fitting the cameras rather than by anyone thinking about network security. Put twenty of them on the flat network and you have added twenty machines that nobody patches and nobody logs into, each of which can reach your file server.
That is the actual risk, and it is worth stating plainly because it is not the risk people imagine. The concern is rarely that somebody watches your camera feed. It is that a device with a weak interface becomes the foothold, and from the flat network everything else is reachable. Multi-factor authentication on your email does nothing about it, because the attacker is already inside the network rather than signing in to anything.
Scale makes it worse rather than better in one specific way. A device estate grows by accretion: cameras with the fit-out, access control at the lease renewal, a leak sensor after a flood, a temperature logger because a client asked. Each addition is small enough that nobody revisits the network design, so the flat network quietly accumulates machines nobody owns. By the time it is worth fixing, nobody can say with confidence what is on it.
What segmentation actually means in a small office
Segmentation sounds like enterprise vocabulary and gets dismissed on that basis. In practice, for an office of twenty or two hundred people, it means a handful of separate networks on the same physical switches, with a firewall deciding what may pass between them.
A workable arrangement is four: staff devices, connected devices, guests, and anything handling payments. The devices segment is the one this piece is about. The rule for it is restrictive by default, because device traffic is predictable in a way that human traffic is not. A camera needs to reach its recorder. A door controller needs to reach its controller software. A sensor needs to reach its gateway. Almost nothing on that segment has any business reaching a file server, and most of it has no business reaching the internet either.
Writing that rule down is the work. Once written it rarely changes, which is the opposite of the staff network, and it is why this is a design task rather than an ongoing burden.
A question worth asking of any proposed segmentation is what it does when the firewall is unavailable. Separation that depends on a single device means that device is now a single point of failure for the cameras as well as the office. For most small offices that trade-off is acceptable and simply needs to be known. Where it is not, the recorder sits on the device segment so that recording continues regardless of what the rest of the network is doing, which is a design decision rather than an accident.
- Devices may reach their own recorder, controller or gateway, and nothing else inside the building.
- Devices may not initiate connections to the staff segment at all.
- Internet access is denied by default and allowed only for the specific devices that genuinely need it.
- Management interfaces are reachable only from a named administrative machine or network.
- Everything that is allowed is allowed explicitly, so the list itself is the documentation.
Power budget, which is the failure nobody plans for
Most cameras and door readers take their power from the network cable, which is convenient and removes a socket from every mounting position. It also introduces a limit that does not exist on an ordinary switch: the total power the switch can supply across all its ports.
The common mistake is choosing a switch on port count. Twenty-four ports looks like enough for twenty cameras with room to spare, and it is, until the power budget is reached. What happens then is not a clean failure. Devices reboot in a loop, or the last few installed never come up reliably, or everything works until a hot afternoon when the switch reduces output. It is diagnosed as a camera fault because that is what it looks like.
The fix is arithmetic done before buying: add the draw of every device, allow headroom for the ones that draw more when their heater or motor runs, and check the switch's total budget rather than its per-port figure. Higher-power devices such as pan-tilt cameras and some access hardware need the higher power standards, and the switch has to support them rather than merely having spare ports.
Two details catch people out beyond the arithmetic. Cable length reduces delivered power, so a device at the far end of a long run receives less than the specification suggests. And some switches reserve power per port once a device negotiates for it, meaning the budget is consumed by what devices asked for rather than what they currently draw. Both argue for headroom rather than for calculating to the last watt.
Cable it at fit-out, because retrofitting is the expensive path
Every device on this list wants a cable. Wireless cameras exist and they are a compromise on both reliability and power, because something still has to supply the power.
That makes device placement a cabling decision, and cabling decisions are made during the fit-out when ceilings are open and containment is going in. A camera point added after the ceiling closes means lifting tiles, running surface trunking or accepting a worse position, and it costs several times what the same point costs during the first fix. We make the same argument generally on the structured cabling page.
The practical advice is to over-provide rather than to predict precisely. Pull cable to the positions you might plausibly want a device, terminate them, and leave them unused. An unused outlet costs very little at first fix and removes a decision from the future, which is worth more than it sounds in a building you will occupy for years.
One more thing worth settling at first fix is where the recorder and any controller will physically live, because they need a secure, ventilated position with power rather than a shelf in a corridor cupboard. A recorder that anyone can reach and unplug is a weak point in a system installed to improve security, and moving it later means moving cable.
Credentials and firmware, which need an owner
Two jobs are routinely nobody's. The first is changing default credentials and recording what they were changed to, with the record kept somewhere that survives the installer leaving. The second is firmware, which for devices is a genuine problem rather than a formality, because device manufacturers publish updates irregularly and nothing prompts anyone to apply them.
Neither job is hard and both are invisible until they matter. Assign them. In an office with managed support that is part of the arrangement, which is one of the things the managed IT support page covers. In an office without one, it needs a named person and a date in the calendar rather than an intention.
Device interfaces also deserve the same scepticism as any other web application. Where a device ships its own web interface, it is worth checking it against the OWASP Top Ten, because a surprising number of them fail on basics that were solved in ordinary software years ago.
There is a disposal question too, which is unglamorous and routinely missed. A camera or reader removed from a wall still holds configuration, and often credentials, for the network it was on. Devices leaving the building should be reset, and the record of what was installed should be updated when something is taken out rather than only when something is added. An inventory that only ever grows is not an inventory.
What this looks like on real sites
The pattern recurs across very different buildings. A cold store runs temperature sensors whose readings are a compliance record, and the segment has to be reliable without being reachable, which we covered in cold chain temperature monitoring. A gym runs door access during unstaffed hours, where the question of what the door does on power loss matters more than anything about the network, covered in gym access control.
The device segment is also where the network and the rest of the office meet most awkwardly, because the people specifying cameras are rarely the people who run the network. That gap is where most of these problems originate: a security contractor quotes a camera system, nobody asks what it needs from the network, and the switch, the segment and the rules are discovered afterwards. Involving whoever runs the network in the camera conversation costs an hour and prevents most of this. What each internet provider can deliver, and what the firewall can then do with it, is covered on the network and Wi-Fi page, where du and e& line options are set out.
An industrial site is a different discipline again, because control systems have requirements that office security practice actively breaks, which is the subject of SCADA and OT security. The common thread is that the devices are only as good as the network under them, and the network is decided before the devices arrive.
If you are planning an installation, the connected devices page sets out what the work covers, and the segmentation itself is configured on the same firewall that carries the rest of your security rules.
If some of the devices cannot be cabled, the radio choice is its own decision and is set out in choosing between Wi-Fi, LoRaWAN and Thread.
Frequently asked questions
It separates them from staff, which is something, but it is the wrong segment. Guest networks are designed to let anything reach the internet and nothing reach inside, which is close to the opposite of what a camera needs: it usually has to reach a recorder inside the building and should not reach the internet at all. Give devices their own segment with their own rule.
Usually not a new one, but it has to be a managed switch rather than an unmanaged box, because segmentation is configured on it. Many offices already have managed switches and have never used the capability. Where the existing switch is unmanaged, replacing it is a modest cost compared with recabling and is the natural moment to check the power budget too.
Add up the draw of every powered device including the ones you plan to add, allow headroom for devices that draw more when a heater or motor runs, and compare it against the switch's total power budget rather than its per-port rating. The budget is the number that runs out, and it runs out in a way that looks like faulty cameras.
Sometimes, if the system genuinely uses a vendor cloud for remote viewing or storage. Often it is a default rather than a requirement. Ask what specifically needs to be reached and why, then allow that and nothing else. A blanket permission for a whole segment to reach the internet is the thing worth refusing.
Less than people expect if the cabling is sound, because it is mostly configuration rather than physical work. The devices keep their cables and their positions; what changes is which segment each port belongs to and what the firewall allows. The awkward part is usually discovering what currently talks to what, which is an argument for documenting it as you go.
Somebody named, with a date in the calendar. Device manufacturers publish updates irregularly and nothing prompts you, so an intention to keep things current reliably becomes nothing at all. Under a managed support arrangement it is part of the service. Without one, it needs a person rather than a policy.
Written by Srinivasan Ramachandran, Founder, Listonics · Published Oct 11, 2026 · Last reviewed October 11, 2026 · 2,079 words
