Everyone knows they should "use VLANs." Far fewer can answer how many, which, why, and where the boundaries go. Segmentation isn't a feature you enable — it's a design you reason about from trust and blast-radius. This is how to draw the zones before you configure a single one.
Segmentation exists to contain blast radius: when — not if — a device is compromised, how far can the attacker reach? A flat network answers "everywhere." Good segmentation answers "the one zone that device was in." The design question is therefore not "which VLANs does the vendor support" but "what are my trust zones, and what is allowed to cross between them?" Every VLAN, VRF, firewall rule, and 802.1X policy is just the implementation of that answer.
The method is three steps: enumerate trust zones by who/what lives there and how much you trust it; define the inter-zone policy as default-deny with explicit, minimal allows; and choose the enforcement layer for each boundary (VLAN + ACL, VRF, firewall, or host isolation). This post is the design; the implementations are the VLAN, ACL, port-security, and 802.1X posts, and it leads naturally into zero-trust.
01
List every category of device by how much you trust it and how sensitive it is. The zones fall out of that grid — don't start from a VLAN count, start from trust.
A zone is a set of devices that share a trust level and a purpose. The canonical business set: guests (untrusted, internet-only), staff/corporate (trusted users), servers/PMS (sensitive data — cards, records), CCTV/IoT (weak, rarely-patched, dangerous if compromised), VoIP (needs QoS + isolation), OT/BMS (building/industrial systems — never on the office network), and a management zone for the network devices themselves. Not every site has all of these, and some split further — but naming them by trust is what tells you where the walls go.
Two device categories belong in different zones if the answer to "should a compromise of one be able to reach the other?" is no. A guest laptop reaching the CCTV recorder: no → separate zones. Two reception PCs reaching each other: fine → same zone. IoT reaching the internet but nothing internal: its own zone with an internet-only policy. Apply that single question across your device inventory and the zone map draws itself — no guesswork about "how many VLANs."
02
The policy is a matrix: by default nothing crosses zone boundaries, and you add the few flows that must. If you can't name why a flow exists, it doesn't.
Draw the zones down one axis and across the other; every cell is a policy. Start every cell at deny, then open the handful that the business genuinely needs: staff → PMS (booking), staff → CCTV (viewing), VoIP → PBX, everything → internet (except CCTV/OT). The discipline is that each allow is specific (source zone, destination host/port) and justified. A rule you can't explain is a rule an attacker will use.
| From → To | Policy |
|---|---|
| Guest → anything internal | Deny (internet only) |
| Staff → PMS/servers | Allow specific ports (app, print) |
| Staff → CCTV | Allow viewing port only |
| CCTV/IoT → internet | Deny (remote view via VPN) |
| Any → Management zone | Deny except the admin host |
| OT/BMS ↔ office | Deny both ways |
03
Not every boundary is enforced the same way. Match the mechanism to the boundary — VLAN+ACL for most, a firewall for the high-stakes ones, host isolation within a shared zone.
| Boundary need | Enforce with |
|---|---|
| Separate broadcast domains + basic inter-zone filtering | VLAN + SVI ACL |
| Stateful, logged, high-stakes (guest↔servers, DMZ) | Firewall / zone-based |
| Full routing/table isolation (multi-tenant) | VRF |
| Device-to-device within one zone (guests) | Client isolation / horizon |
| Who's allowed on a port at all | 802.1X / MAB |
| Rogue-DHCP / ARP spoofing inside a zone | DHCP snooping + DAI |
The classic failure: VLANs are configured, everyone feels segmented, and inter-VLAN routing on the core happily forwards everything between them because no ACL was applied. A VLAN is a broadcast-domain boundary, not a security boundary — the security boundary is the policy at the routing/firewall point. Likewise, isolating zones but leaving guest-to-guest traffic open inside the guest VLAN (no client isolation) leaves the whole guest population exposed to one another. Prove each boundary by testing from the wrong side: from guest Wi-Fi, can you reach the PMS? If yes, it's decoration.
04
A segmentation design nobody can read gets eroded in six months. Encode the zone into the address plan and the names so the intent survives staff turnover.
Make the third octet the VLAN/zone so an address tells you its zone at a glance (10.10.20.x = VLAN 20 = guest), keep a one-line-per-zone table in the runbook, and name interfaces and firewall objects after zones (GUEST-IN, PMS-SRV) not numbers. Segmentation is only as good as the next engineer's ability to understand it without you — the design document and a legible address plan are part of the architecture, not an afterthought.
Takeaways
NOCTIS designs and implements segmentation across Crete — trust zones, a default-deny policy, and the right enforcement at each boundary — with proof, from the wrong side, that the walls actually hold.
Book a Discovery Call →