Zero-Trust Network Segmentation Without the Enterprise Price Tag

Zero-Trust marketing assumes you have the Illumio budget. For an SMB without €120k of enterprise micro-segmentation tooling, the practical question is: how do we get 80% of the security value with €5k of mid-market gear and a quarter of focused work?

This article is the budget Zero-Trust playbook. East-west firewalling, identity-aware access policies, micro-segmentation patterns implemented with open-source and prosumer-tier gear. Aimed at the IT lead with a flat network, a tight budget, and a CISO asking when we go Zero-Trust.

What "Zero-Trust" actually means at the network layer

Stripped of marketing: never trust based on network location. Every connection is verified independently. The network is just transport; the trust decision lives in the identity and policy layer.

The three operational primitives:

1. Micro-segmentation. Workloads are isolated from each other by default. Communication requires explicit policy.
2. Identity-aware policy. "Can host A talk to host B" depends on the workload identities, not the IP addresses.
3. Continuous verification. A connection that was allowed yesterday is re-evaluated against current policy.

Enterprise platforms (Illumio, Guardicore, Cisco Tetration, ColorTokens) wrap these primitives in pretty dashboards with agent-based enforcement. The primitives themselves are not exclusive to enterprise gear.

The €5k stack

Add 0.5 weeks of engineering time for the initial design + 1-2 weeks for the rollout. Total project cost typically €5k-€8k including engineering.

The four-layer architecture

Layer 01: VLAN-based segmentation (the floor)

The starting point. Slice the LAN into purpose-based VLANs:

• Management VLAN (10) — switches, firewall, monitoring. IT-only.
• User VLAN (20) — employee laptops and desktops.
• Voice VLAN (30) — IP phones, video conferencing devices.
• Server VLAN (40) — on-prem servers, NAS, application backends.
• Printer VLAN (50) — multifunction devices, label printers.
• IoT VLAN (60) — building systems, cameras, badge readers.
• Guest VLAN (90) — visitor WiFi, isolated from everything.
• Quarantine VLAN (99) — un-authenticated or non-compliant devices.

Default inter-VLAN policy: deny all. Specific allow rules enable the business: User → Server on documented ports, User → Printer on print protocols, Voice → Voice gateway on SIP, etc.

This alone closes the largest hole in a flat-network estate. A compromised printer can no longer talk to the file server. A guest laptop cannot see internal services. The radius of impact from any single device compromise shrinks dramatically.

Layer 02: 802.1X for dynamic VLAN assignment

Static VLAN-per-port works for desks. Modern offices need dynamic — the same port might host a laptop or a printer or a phone at different times. 802.1X with RADIUS produces device-identity-aware VLAN assignment.

The flow:

1. Device plugs into a switch port. Port starts in "unauthorised" state.
2. Switch sends EAPOL request to the device.
3. Device responds with credentials (certificate, username+password, or MAC-based fallback).
4. Switch forwards to RADIUS server (FreeRADIUS).
5. RADIUS verifies credentials, returns Access-Accept with Tunnel-Private-Group-ID = VLAN.
6. Switch places port on the assigned VLAN. Device gets DHCP, starts working.

For laptops, the credential is a machine certificate issued by your CA at device-enrolment time. For printers and IoT, MAC-Authentication-Bypass (MAB) with explicit whitelist. For visitor laptops, captive portal puts them on the guest VLAN.

Result: device identity is enforced at network connection time, not just at application login time.

Layer 03: ZTNA for application access (the real Zero-Trust shift)

VLAN segmentation handles network-layer trust. ZTNA handles application-layer trust. The pattern: forget where the user is on the network; verify them per-application based on identity + device + context.

The budget options:

• Tailscale with Access Control Lists (ACLs). Free for under 100 users + 100 devices. WireGuard-based mesh. Identity-aware via SSO.
• Twingate with Resources policy. Free for small teams, paid tiers reasonable.
• Cloudflare Zero Trust (formerly Cloudflare Access). 50 users free; per-user beyond.
• NetBird: open-source self-hosted ZTNA on WireGuard. Free; you operate the coordination server.

Configure ZTNA so that internal apps (Jira, GitLab, internal dashboards, dev environments) are reachable only via the ZTNA overlay, not via direct LAN access. Even users sitting at their desks in the office connect to internal apps via the ZTNA tunnel.

The result: an attacker who lands a foothold on the office LAN cannot reach internal applications. They have to also compromise an authorised user identity + a compliant device.

Layer 04: Host-level micro-segmentation (the Linux superpower)

For workloads that need finer-grained policy than VLAN allows: host-level firewalls. The Linux netfilter framework + nftables produce per-host policy that no VLAN can match.

# /etc/nftables/server.nft on a database host
#!/usr/sbin/nft -f

flush ruleset

table inet filter {
  chain input {
    type filter hook input priority 0; policy drop;
    iif "lo" accept
    ct state established,related accept
    ct state invalid drop

    # SSH only from management VLAN bastion
    ip saddr 10.10.0.10/32 tcp dport 22 accept

    # Postgres only from application VLAN
    ip saddr 10.40.0.0/24 tcp dport 5432 accept

    # Prometheus scraping from monitoring host
    ip saddr 10.10.0.20/32 tcp dport 9100 accept

    # Drop everything else, log first 10 per minute
    limit rate 10/minute counter log prefix "fw-drop: "
  }

  chain forward {
    type filter hook forward priority 0; policy drop;
  }
}

The host now refuses connections from any IP except the explicit allow-list. A compromised application VLAN host that tries to ssh to the database server fails at the host firewall, regardless of network-layer policy.

Identity-aware access policies (the policy engine)

The hard part is not the firewalls — it is the policy. The policy describes "who can talk to what" in business terms, not IP terms. The discipline that produces honest policy:

Step 01: Inventory who-talks-to-what

For each application, document:

• What identities legitimately use this app (humans / service accounts / automation)
• What dependencies it has (database, message queue, external API)
• What clients it serves (users, other services, external partners)
• What management traffic exists (monitoring scrape, backup connector, log shipper)

This sounds tedious. It is. It is also the only honest way to build segmentation policy. The inventory becomes the source of truth for policy generation.

Step 02: Group identities by role + sensitivity

Step 03: Build the deny-by-default policy

The default policy is "deny everything". Specific allow rules enable the inventoried flows. Every rule has:

• A named owner (who is responsible for this rule)
• A business justification (why this access is needed)
• A review cadence (when this rule will be re-evaluated)
• An expiry date for temporary rules

The policy lives in code (YAML / HCL) in a Git repo. Changes go through PR review. The policy is the deployment artefact, not the firewall config; the firewall config is generated from the policy.

The visibility piece

Segmentation without visibility is faith-based. The monitoring stack we layer over:

• Firewall flow logs → Loki for searchable history
• Connection-attempt drops → metrics counter → Grafana dashboard
• Per-VLAN bandwidth + connection counts → Prometheus metrics
• Unexpected denied flows → alert (often surfaces a missing rule or a compromised workload)

The visibility surfaces two patterns: legitimate flows that policy missed (need allow rules), and illegitimate flows that policy correctly blocked (indicates compromise or misconfiguration).

The rollout sequence that does not break the business

Week 1-2: Discovery + design

• Inventory existing flows via passive monitoring (netflow / sflow / firewall flow logs)
• Map identities to roles
• Design the VLAN scheme + policy model
• Procure / provision the gear (firewall, switches, RADIUS host)

Week 3-4: Foundation

• Deploy the new firewall + core switch
• Configure VLANs without enforcement (devices stay on legacy VLAN initially)
• Stand up RADIUS + 802.1X infrastructure
• Pilot 802.1X on a single switch port for a single test laptop

Week 5-6: Pilot migration

• Migrate IT team laptops first (the people who can debug their own connectivity)
• Deploy ZTNA for the first internal application
• Validate end-to-end: connect, authenticate, get assigned VLAN, access ZTNA-protected app
• Capture lessons

Week 7-8: Broader rollout

• Migrate engineering team
• Migrate non-IT departments (one at a time)
• Migrate printers, IoT devices, conference rooms

Week 9-12: Policy hardening + visibility

• Move policy from "log and allow" to "log and deny" on inter-VLAN flows
• Add host-level firewalls to critical workloads
• Establish the monthly policy-review cadence
• Document runbooks for "user cannot connect" troubleshooting

The five things that go wrong

1. 802.1X breaks the receptionist's laptop on day 1. Cert deployment lagged. Mitigation: dual-rollout window where 802.1X is opt-in for 4 weeks before becoming mandatory.
2. Printers do not speak 802.1X. They speak MAC-Authentication-Bypass (MAB). FreeRADIUS handles both. Allow-list of known MACs feeds the MAB path.
3. The conference room TV stops casting from laptops. Casting protocols (mDNS, SSDP) need explicit allowance across VLANs. Document and exception-list.
4. Engineers complain that internal apps are slower via ZTNA. Latency added is typically 5-15 ms. Real, occasionally noticeable, almost always acceptable.
5. Policy bloat over 12 months. Without a quarterly review cycle, the "specific allow rules" accumulate without retirement. The review is mandatory operational discipline.

What this does not give you

Honest scoping. Budget Zero-Trust does not give you:

• Workload-level visualisation like Illumio's flow maps. You can build it with passive flow monitoring + Grafana, but it requires engineering effort.
• Automated policy recommendation like the enterprise tooling that learns flows and suggests rules. You write rules manually.
• Cross-cloud / hybrid micro-segmentation for workloads spanning AWS / Azure / GCP / on-prem. Each cloud's native segmentation tooling has to be added separately.
• Compliance-grade audit dashboards for regulators expecting specific reports. The data is there in logs; the dashboards are your build.

For organisations under 200 employees with mostly on-prem + Microsoft 365 / Google Workspace traffic, the budget stack delivers 80-85% of the security value. Above that scale or in heterogeneous cloud, the enterprise tooling earns its premium.

The compliance angle

Segmentation maps directly to:

• ISO 27001 Annex A.8.20 (Networks security) + A.8.22 (Segregation of networks)
• NIS2 Article 21(2)(h) (cyber-security risk-management measures, technical baseline)
• DORA Article 9 (ICT systems, protocols, and tools — risk-based segregation)
• PCI-DSS 1.x (network segmentation requirements)

The auditor expectations are practical: documented design + evidence of implementation + evidence of operation (logs showing the policy in effect) + evidence of review (policy reviewed quarterly with documented outputs).

The one paragraph version

Zero-Trust at SMB budget: VLAN segmentation (deny inter-VLAN by default), 802.1X with RADIUS for identity-aware VLAN assignment, ZTNA overlay (Tailscale / Twingate / Cloudflare) for application-layer trust, Linux nftables on critical workloads for host-level firewalling, monthly policy review cadence. Total CAPEX €1,400-€3,800 + €5k-€8k engineering. Delivers 80-85% of the security value of enterprise micro-segmentation tooling for under 5% of the cost. Maps cleanly to ISO 27001, NIS2, DORA, PCI-DSS network-segmentation requirements. The hard part is the policy inventory, not the firewall config. The discipline is the operational review cadence.

If you want this designed + deployed + handed over, that is the engagement shape under our Microsoft 365 Defender service for the identity + ZTNA piece, plus broader infrastructure work for the network-layer segmentation. The free Bloodbath Scan can spot obvious flat-network exposures during the initial diagnostic.