Network segmentation for growing businesses

A network printer sits in a corridor. It was installed six years ago, its firmware has never been updated, its web interface still has the manufacturer's default password, and it is on the same network as the finance workstations, the file server and the switch that connects them. Nobody made a decision about that. It was plugged into the nearest port and it worked.

The business consequence is that the security of the accounts system is now partly determined by the firmware of a printer. Any device on a flat network can attempt to reach any other, so the weakest thing on the network sets the floor for everything else. That is rarely how a business would describe its own risk position, and it is very often an accurate description of it.

Segmentation is the control that changes this. It is not a product and it is not primarily a security purchase — it is a set of decisions about which groups of things are allowed to reach which other groups, enforced at the points where traffic crosses between them. This article is about making those decisions well. It is not a configuration guide, and it deliberately stops short of writing firewall rules.

Why flat networks persist

Flat networks are almost never chosen. They accrete. A business starts with one switch and a handful of devices, where separation would have been pointless overhead. It grows, and each new device is connected the way the previous one was, because that works and because segmenting retrospectively means understanding traffic that nobody has ever mapped.

By the time it matters, the network has cameras, door controllers, phones, printers, laptops, servers, a NAS, a hypervisor, and a handful of things nobody can identify, all able to reach one another. The absence of segmentation is not a decision anyone would defend; it is simply that no moment ever arrived when someone was asked to defend it.

The final row is worth more attention than it usually gets. Segmentation does not only reduce the damage; it reduces the cost and duration of the investigation, because the question of what an attacker could have reached has a documented answer rather than requiring a survey of everything.

A VLAN is not a security boundary

This is the correction that matters most, and the standard itself makes the point clearly if you read what it is for.

VLANs are defined in IEEE 802.1Q, currently the 2022 edition, whose title is IEEE Standard for Local and Metropolitan Area Networks — Bridges and Bridged Networks. Its stated scope is that it specifies how the Media Access Control Service is supported by bridged networks, the principles of operation of those networks, and the operation of MAC bridges and VLAN bridges, including management, protocols and algorithms.

That is a bridging standard. It describes how to divide a switched network into separate broadcast domains so that traffic is contained and addressing is manageable. It is not an access control standard and it does not claim to be one. A VLAN gives you a boundary; it does not tell you what may cross it.

Layer 2 separation, layer 3 reconnection

Devices in different VLANs cannot talk to each other directly. They talk through a layer 3 device — a router, a layer 3 switch, or a firewall — that has an interface in both. That routing is not optional, because a VLAN that cannot reach anything is not useful: the finance VLAN still needs the file server, the phones still need the PBX.

The security question is therefore not whether you have VLANs. It is what the routing point does. If it forwards everything between VLANs, you have divided the broadcast domains and changed nothing about reachability: an attacker on the camera VLAN can still reach the finance VLAN, one hop later. If it applies a policy about what may cross, you have segmentation.

There is also a case for layer 2 controls within a segment, particularly where the devices in it should never talk to each other at all. A set of cameras generally has no reason to communicate peer to peer, and preventing it inside the segment removes a lateral path even before the routing question arises.

Design the zones from the business, not the wiring

The failure mode in segmentation projects is starting from the equipment. Somebody counts the switches, decides on a number of VLANs, and then tries to fit the business into them. The more durable order is the reverse: establish which groups of things exist and what they legitimately need to reach, and let the network design follow.

Two axes cover almost everything. People are grouped by what their role requires — general staff, finance, engineering, contractors. Devices are grouped by what they are and how much they can be trusted to defend themselves — servers, endpoints, phones, printers, cameras, building systems. A device that cannot be patched and cannot run security software belongs in a group defined by that limitation rather than by which department bought it.

The right-hand column is the one to write first. It is easier to agree what something should never reach than to enumerate everything it might need, and starting there produces a default-deny posture without anyone having to argue for one in the abstract.

The zones that matter most and get built last

Three zones deliver most of the risk reduction and are consistently the last to be implemented, usually because they involve equipment owned by somebody other than IT.

The management network

Switch, firewall, hypervisor, storage array, out-of-band server management, camera recorder and PBX administration interfaces are the highest-value targets on any network, because reaching them means reaching everything they control. They are also frequently addressed on the same subnet as staff laptops, because that is where the addressing was convenient during installation.

If a compromised laptop can reach the firewall's administration page, no other segmentation matters — an attacker who takes the enforcement point owns the policy. A separate management zone, reachable only from a defined administrative path, is the single highest-value segment to build and often the cheapest, because the device count is small and the traffic patterns are simple.

Cameras, door controllers and building systems

This category is where segmentation most obviously pays, for reasons that have nothing to do with the devices' function. Cameras, access control panels, sensors and displays are frequently installed by a specialist contractor rather than by IT, run firmware that is updated rarely if ever, ship with well-known default credentials, and sometimes include a vendor remote support path that nobody in the business documented.

They are also, individually, low-value targets — which is exactly why they are useful to an attacker as an entry point on a flat network. The correct posture is that these devices reach their own controller or recorder and nothing else, including the internet, unless a specific and justified exception exists. Where the vendor requires remote access for support, that is a documented exception with a defined path, not an open outbound rule.

For businesses with genuine operational technology rather than building services, NIST publishes SP 800-82 Revision 3, Guide to Operational Technology (OT) Security, finalised in September 2023, which is the authoritative reference for that environment and goes well beyond what a general network design covers.

Guest access

Guest wireless is the zone most businesses do implement, and it is worth checking that it does what people assume. A guest network should reach the internet and nothing else — not internal resources, and ideally not other guest devices. It is common to find guest networks that are separated from the corporate network but still permit clients to see each other, and rather more common to find a guest network that was configured correctly at installation and has since been given an exception so that a visitor could print.

Where enforcement happens, and what the policy should look like

Every zone boundary needs a point where traffic crossing it is evaluated. In most growing businesses that is the firewall, sometimes a layer 3 switch for high-volume internal traffic, and increasingly both — a switch handling east-west volume with a firewall handling the boundaries that matter most.

The strategic decisions about that policy are architectural, and they are worth settling before anyone writes a rule. The detailed craft of rule-base design — ordering, object management, egress filtering, change control — is a separate subject.

1. 1

   Default deny, in both directions

   The base position between zones is that nothing is permitted, and each flow is added because someone identified a need. A policy that begins permissive and is tightened later is almost never tightened, because nobody can prove which of the existing flows are load-bearing.

2. 2

   Permit services, not subnets

   A rule allowing the staff zone to reach one server on one port is segmentation. A rule allowing the staff zone to reach the whole server subnet is a routed network with extra steps.

3. 3

   Be explicit about direction

   Most flows are asymmetric. Staff need to initiate connections to servers; servers rarely need to initiate connections to staff endpoints. Permitting the return path of an established session is not the same as permitting the reverse direction, and conflating them removes much of the value.

4. 4

   Log what is denied, not only what is permitted

   Denied traffic between zones is the clearest available signal that something is misconfigured, or that something is attempting to move laterally. A policy that denies silently gives you neither.

5. 5

   Record why each exception exists

   Every segmentation design accumulates exceptions. The ones with a documented reason and an owner can be reviewed. The ones without will survive forever, because nobody will risk removing a rule whose purpose is unknown.

East-west traffic is the part nobody watches

Traffic between the business and the internet is north-south, and it passes through a firewall that inspects and logs it. Traffic between two devices inside the network is east-west, and on a flat network it passes through a switch that does neither.

This asymmetry is the reason lateral movement is effective. An attacker who has reached one endpoint no longer needs to cross the perimeter to reach anything else, and the tooling watching the perimeter cannot see them do it. Segmentation is what forces east-west traffic through a point that can evaluate and record it — which is a monitoring benefit as much as a control, and one that is frequently undersold when the work is being justified.

The practical implication for design is that the boundaries worth creating are the ones that lateral movement would have to cross. A segmentation scheme that separates two groups who never communicate anyway is tidy and achieves little; one that sits between the endpoints and the servers is where the value is.

Branch offices, cloud and remote users

Segmentation designed for one site tends to be undone at the three places where the network extends beyond it.

Branch offices

A site-to-site link between offices frequently carries everything, which merges two networks and therefore two blast radii. If a compromise at a small branch can reach head office servers because the tunnel permits all traffic, the segmentation at each site is undermined by the link between them. Zones should extend across sites consistently — the branch's device zone is part of the same zone as head office's, subject to the same policy — rather than each site being one undifferentiated area that trusts the other.

Cloud environments

The same principles apply with different primitives. Cloud providers offer virtual networks, subnets and instance-level or group-level firewalls, and the enforcement point is generally distributed rather than a single appliance. Two differences are worth knowing.

The first is helpful: cloud network controls typically default to denying inbound traffic, so the default posture is closer to the one you want, and the risk is loosening it rather than forgetting to tighten it. The second is not: because rules are attached to resources rather than to a physical topology, a cloud environment can drift into a state where nobody can describe the effective policy without querying it. The discipline that keeps this manageable is defining the network structure as code alongside the workloads, so the intended policy is reviewable rather than discovered.

A connection between an on-premises network and a cloud environment is a zone boundary like any other, and deserves a policy rather than a route.

Remote users

A remote access design that terminates users into the server zone removes the segmentation for everyone connecting remotely, which in a hybrid business may be most of the workforce. Remote users belong in their own zone, subject to the same policy as their equivalent on-site group and generally to a narrower one. The topology and identity decisions behind that are covered in the secure remote access article rather than here.

The commercial argument: scope reduction

Segmentation is usually justified on risk, which is correct and is a difficult argument to win against a budget. There is a second argument that is easier to quantify, and businesses handling card payments should know it.

The PCI Security Standards Council is explicit that segmentation is optional rather than mandated. Its CTO has stated that network segmentation is not a PCI DSS requirement, but that the Council has always encouraged a strategy that minimises the systems that have access to cardholder data. The purpose of the guidance, in the Council's framing, is to reduce the number of systems requiring PCI DSS controls — by limiting where payment data resides across the network, an organisation can drastically reduce the number of systems to protect, which makes security efforts more focused and more manageable.

Read commercially, that is a cost lever rather than a compliance obligation. Every system in scope must be assessed, controlled and evidenced. Segmentation is the mechanism that determines how many systems that is. A business that does not segment is not non-compliant; it has chosen a larger and more expensive assessment.

A decision framework

Segmenting everything at once is how these projects stall. The following sequence produces value early and keeps each step small enough to be reversible.

1. 1

   Inventory what is connected

   Not a diagram — a list, including the things nobody claims. Anything you cannot identify is a finding in itself, and it belongs in the most restricted zone until somebody can say what it is.

2. 2

   Group by trustworthiness, not by department

   The question is whether a device can be patched, monitored and authenticated. A camera and a printer belong together despite having nothing else in common.

3. 3

   Write what each group must never reach

   Faster to agree than the permit list, and it establishes default-deny without an abstract argument about security posture.

4. 4

   Start with management, then devices, then guest

   Highest value, lowest disruption, fewest stakeholders. None of the three interferes with how staff work, which means they can be done without a change freeze.

5. 5

   Separate users from servers next

   This is the boundary lateral movement has to cross, and it is where most of the remaining value sits. It also needs the most care, because it touches everybody's daily work.

6. 6

   Test from the wrong side

   Attempt to reach each zone from a zone that should not be able to. Untested segmentation is a hypothesis, and this is the step that converts it into a control.

7. 7

   Review exceptions on a schedule

   Exceptions accumulate. A quarterly review with a named owner is what stops a segmented network reverting to a flat one over three years.

Common design mistakes

Two business scenarios

Composites of situations we see repeatedly; no client detail is included.

A professional services firm, one office, sixty staff

One subnet, one switch stack, everything reachable. The trigger was an insurance questionnaire asking what a compromised laptop could reach, for which the honest answer was everything including the firewall's administration interface.

The work was sequenced to avoid disruption. A management zone was created first and the switch, firewall, hypervisor and NAS administration interfaces were moved to it, reachable only from a defined administrative path — two days of work, no user impact, and it removed the worst finding. Printers and the camera recorder moved to a device zone permitted to reach only their own controllers. Guest wireless was rebuilt to reach the internet only, with client isolation. Users and servers were separated last, over a weekend, with a permit list built from a fortnight of flow logging rather than from guesswork.

A multi-site operation taking card payments

Three sites, a site-to-site link carrying everything, and payment terminals on the same network as general staff. The driver was cost rather than risk: every system that could reach the payment environment was in assessment scope, which made the annual assessment expensive and the remediation list long.

Isolating the payment environment behind a policy boundary reduced the number of systems in scope substantially, and the branch tunnels were narrowed from carrying everything to carrying the specific flows each site needed. The segmentation was then tested from outside the boundary and the test was repeated as part of the assessment cycle, because segmentation asserted but unverified would not have been accepted — and, more usefully, would not have been true for long.

Implementation checklist

• An inventory exists of everything connected, and anything unidentified sits in the most restricted zone until it is identified.
• Zones are defined by trust and function rather than by department or by which switch a device is plugged into.
• For each zone, what it must never reach is written down and agreed.
• Inter-zone policy is default-deny in both directions, with each permitted flow added deliberately.
• Permits name services on hosts rather than whole subnets.
• Direction is explicit: permitting a response is not the same as permitting the reverse flow.
• Management interfaces for switches, firewalls, hypervisors, storage, recorders and the PBX are in their own zone.
• Cameras, door controllers, printers and sensors reach their own controller and nothing else, with vendor remote access as a documented exception.
• Guest access reaches the internet only, with client isolation, and has no exceptions that were added and never removed.
• Denied inter-zone traffic is logged and somebody looks at it.
• Zones extend consistently across branch sites; site-to-site links carry permitted flows rather than everything.
• Cloud network policy is defined as code and reviewable, not discovered by querying the environment.
• Remote users land in their own zone with policy matching their equivalent on-site group.
• Every exception has a recorded reason and a named owner, reviewed on a schedule.
• The boundaries have been tested from the wrong side, and the test is repeated rather than performed once.

Frequently asked questions

Conclusion

Segmentation is the control that decides how much of a business is exposed when prevention fails, and prevention eventually fails. It is also one of the few security investments that is mostly configuration of equipment already owned rather than a purchase, which makes the usual obstacle organisational rather than financial: somebody has to decide what should reach what, and get the people who own those systems to agree.

The work that matters is not creating VLANs. It is writing down what each group of things must never reach, enforcing that at the points where traffic crosses, logging what gets denied, and then testing from the wrong side to confirm that the boundary is real. A network described as segmented but never tested from outside its own boundaries is a diagram, not a control.