Network Segmentation and Microsegmentation Guide

On a flat network, one compromised laptop or server can reach almost everything, so a single foothold becomes an enterprise-wide incident. Segmentation limits what can talk to what, and microsegmentation shrinks those boundaries down to individual applications and workloads. This guide covers VLANs and zones, private VLANs and overlays, host, cloud and Kubernetes enforcement, identity-based policy for workloads, PCI DSS scoping, rollout, monitoring and framework mapping. It is written for network and security architects, platform engineers and SOC teams who need to design, deploy or audit segmentation, and it relies on NIST, CISA, NCSC, PCI SSC, MITRE and IETF sources.

Key takeaways

• Segment by what systems need, not by where they sit. NCSC advises that systems and data "that do not need to communicate or interact with each other should be separated", and NIST SP 800-207 states that network location alone does not imply trust.
• Map dependencies before you write a single deny rule. CISA's 2025 microsegmentation guidance puts dependency discovery and a permissive test mode before enforcement, because missed flows are what break applications and kill projects.
• Use several enforcement points, not one. Network firewalls suit OT and legacy systems, host agents and hypervisors suit servers, and security groups, NetworkPolicy and service mesh policy suit cloud and containers.
• Workload identity makes policy survive change. Rules written against certificates or service accounts keep working when IP addresses churn, and they stop an attacker who simply lands on an allowed subnet.
• Prove it works, repeatedly. PCI DSS requires segmentation testing at least every 12 months for merchants and every six months for service providers, and ATT&CK T1599 Network Boundary Bridging shows attackers target the devices that enforce segmentation.

Segmentation, microsegmentation and zero trust

Traditional segmentation divides a network using IP ranges, VLANs and static firewall rules. CISA describes macrosegmentation as dividing the internal network into chunks that match business needs, and microsegmentation as "a design philosophy focused on minimizing the size of network segments", with segments that can be defined statically or dynamically and may cut across old trust zones.

• North-south traffic crosses the perimeter between users or the internet and your services. Most organisations already filter it.
• East-west traffic moves between systems inside the network: server to server, workstation to workstation, pod to pod. Ransomware operators and intrusion sets live here, using RDP (T1021.001), WinRM (T1021.006), exploitation of remote services (T1210) and network service discovery (T1046). MITRE lists Network Segmentation (M1030) as a mitigation for each.
• Application segmentation rings one application's tiers and dependencies so a compromise of that application, or of a neighbour, has a small blast radius. It is the usual unit of work in a microsegmentation project.
• Zero trust: NIST SP 800-207 section 3.1.2 describes a micro-segmentation variant of zero trust architecture, placing resources behind gateways such as "intelligent switches (or routers) or next generation firewalls" or host-based software agents that act as policy enforcement points. NIST adds that this approach "requires an identity governance program (IGP) to fully function". In the CISA Zero Trust Maturity Model, microsegmentation sits in the Network pillar.
• ZTNA versus segmentation: zero trust network access brokers a user's connection to a named application, replacing broad VPN access. It does not control what a compromised server can reach next. You need both: ZTNA for user-to-application access, segmentation for workload-to-workload traffic. See the Remote Access Identity Guide.

Enforcement options compared

CISA's guidance groups enforcement into network, endpoint, container, hypervisor and cloud-native types. Most estates need a mix.

Cloud and Kubernetes specifics

• Accounts and VPCs as macro-segments: separate production, non-production and shared services into different cloud accounts or subscriptions and VPCs, and connect them only through inspected transit or private endpoints. MITRE M1030 names VPCs, subnets and security groups as segmentation controls.
• Security groups that reference groups: allow the application tier's group to reach the database group on its port, instead of allowing a CIDR. The rule then follows scaling events without edits.
• Kubernetes default deny: the Kubernetes documentation is explicit: "Your cluster must use a network plugin that supports NetworkPolicy enforcement." Without one, policies are stored but have no effect. Apply a namespace-wide policy with an empty podSelector: {} and policyTypes: [Ingress, Egress], then add allows by pod and namespace label, remembering to allow DNS egress to the cluster resolver.

Designing zones and the east-west policy

Start with a small number of zones that reflect risk, then subdivide the highest-value ones. NCSC calls this segregating networks "as sets: identify, group and isolate critical business systems".

• Deny by default: NIST SP 800-53 SC-7(5) is "Deny by Default, Allow by Exception". Write every inter-zone rule as an allow with an owner, a business reason and a review date.
• Visibility first: you cannot segment flows you cannot see. Collect NetFlow or IPFIX from core switches, cloud VPC flow logs and host agent telemetry, and keep enough history to cover month-end and quarter-end jobs.
• DMZ design: terminate inbound connections in the DMZ and open new, inspected connections to back ends, rather than port-forwarding straight to an internal server. A DMZ host should never hold domain admin sessions or be domain-joined to the production forest, and MITRE lists T1190 Exploit Public-Facing Application among the techniques M1030 mitigates.
• Guest and BYOD networks: route guest Wi-Fi straight to the internet through its own firewall interface, block all RFC 1918 destinations, and enable client isolation on the wireless controller so guests cannot reach each other.
• East-west firewalls: a central internal firewall works for zone boundaries but becomes a bottleneck and a single rule base for thousands of server pairs. Distributed enforcement (host agents, hypervisor firewalls, security groups) scales better inside a zone; keep the central firewall for zone-to-zone inspection.
• Encrypt east-west where it matters: segmentation decides who may connect; it does not stop sniffing on a shared segment (T1040). Use TLS or mTLS between services, MACsec on links you do not physically control, and IPsec for overlays.

Layer 2 hardening: VLANs, private VLANs and VXLAN

• VLAN hopping: switch spoofing abuses dynamic trunk negotiation, and double tagging abuses the native VLAN. Set user ports to access mode, disable trunk negotiation, use an unused native VLAN on trunks, allow only required VLANs on each trunk, and shut or park unused ports in a dead VLAN.
• Private VLANs: RFC 5517 defines promiscuous ports (gateways, DHCP), isolated ports that reach only promiscuous ports, and community ports that reach their own community. Isolation is layer 2 only, so add router ACLs or the hosts can still talk via the gateway.
• VXLAN overlays: RFC 7348 uses UDP 4789 and a 24-bit VNI, about 16 million segments, but adds no authentication of its own. Rogue endpoints can inject frames or join multicast groups, so restrict UDP 4789 to known VTEPs with ACLs, keep VXLAN transport on a dedicated VLAN, and use IPsec where the underlay is untrusted.
• Admission control: segmentation assumes you know what is plugged in. IEEE 802.1X port authentication with RADIUS-assigned VLANs places each device in the right segment as it connects, and RFC 7348 itself suggests 802.1X for admission to VXLAN segments.

Where identity fits

IP-based rules trust whatever holds the address. Identity-based segmentation authenticates the workload itself, which is a genuine non-human identity control.

• Workload identity as the policy subject: Istio issues each workload an X.509 certificate tied to its Kubernetes service account, then evaluates AuthorizationPolicy against the peer principal, for example cluster.local/ns/default/sa/curl. SPIFFE IDs (spiffe://trust-domain/path) do the same across platforms. See the Cloud Workload Identity Guide.
• Know the defaults: Istio's mesh-wide mTLS mode is PERMISSIVE unless set, accepting plain text; with no AuthorizationPolicy, all requests are allowed. Move to STRICT mode and default-deny policies per namespace. Kubernetes pods are non-isolated until a NetworkPolicy selects them. See the Kubernetes NHI Security Guide.
• Protect the identities that control the boundary: MITRE's mitigations for T1599 are credential access protection, MFA, password policies and privileged account management. Firewall, SDN controller and cloud network admin accounts, plus the API tokens behind infrastructure-as-code pipelines, can rewrite every segment. NCSC advises ensuring "a single account cannot grant access to all devices and components across an enterprise". See the Privileged Access Management Guide.
• Service accounts that span zones: backup, monitoring and deployment accounts often hold allowed paths into every segment. Inventory them and their network paths together.

Rolling out segmentation in phases

1. Pick candidates: CISA's first phase is to identify candidate resources and prioritise by criticality or ease of transition. Good first targets are domain controllers, backup servers, the CDE and management interfaces.
2. Map dependencies: collect flows for at least one full business cycle, interview application owners, and record each flow as source, destination, port, protocol, owner and reason. CISA notes dependencies can be found by "tracking the communications of the transition candidate".
3. Write policy as code: express rules by label, tag or identity, not IP, keep them in version control, and require review for any rule wider than a single application.
4. Test in monitor mode: run the policy in permissive, log-only or alert mode so violations reveal missed dependencies without blocking. Fix gaps, then repeat until the violation rate is stable and explained.
5. Enforce in rings: non-production first, then a pilot application, then the rest by business unit. Agree a change window and a named approver for each ring.
6. Plan rollback: keep the previous rule set version deployable in one step, keep a pre-approved emergency allow rule with an expiry, and confirm monitoring and backup paths still work before closing the change.
7. Maintain: tie rule creation to application onboarding, expire unused rules, and revalidate segmentation after major changes, as CISA's maintenance section advises.

Choosing an approach

• Network-based first when you have OT, IoT, medical or legacy systems that cannot run agents. CISA notes these may require network enforcement. See the OT and ICS Identity and Access Guide.
• Host or hypervisor-based when you have a large server estate with heavy east-west traffic and frequent change. Agents give per-process flow maps that make dependency mapping far easier.
• Cloud-native and Kubernetes controls for workloads that already live there, managed as code with the application. Do not backhaul cloud traffic to an on-premises firewall just to reuse a familiar tool.
• Identity-based (mTLS and service mesh) where workloads are ephemeral and IPs are meaningless, and where you need layer 7 rules such as method or path.
• Small organisations: four or five zones on an existing firewall, host firewalls on, guest Wi-Fi isolated and management interfaces off the user network will remove most flat-network risk at low cost.
• Large organisations: granularity costs operations. CISA warns fine-grained segments are harder to maintain, so go fine-grained for crown jewels and stay coarse elsewhere, with one policy model across on-premises and cloud.

PCI DSS scoping and segmentation testing

The PCI SSC scoping supplement states segmentation "is not a PCI DSS requirement. However, it is strongly recommended", because without it "the entire network is in scope". It classes systems as CDE, connected-to or security-impacting, and out of scope, and treats anything on the same subnet or VLAN as a CDE system as part of the CDE. It also warns that "the existence of separate network segments alone does not automatically create PCI DSS segmentation": the controls must actually prevent out-of-scope systems from reaching the CDE. Under PCI DSS v4.0, merchants penetration test segmentation controls at least every 12 months (requirement 11.4.5) and service providers at least every six months and after changes (11.4.6).

Detection and measurement

• Rule changes: forward firewall, switch, SDN and cloud network configuration changes to the SIEM. MITRE's detection for T1599 looks for ACL or rule changes followed by unexpected cross-boundary flows and notes that "multi-event correlation is key".
• Denied and unexpected flows: alert on denies from servers (servers rarely scan), new east-west SMB, RDP or WinRM pairs, and any flow from the user zone to management or identity tiers.
• Drift: compare deployed rules with the policy repository daily and alert on any rule added outside the pipeline.

Metrics that show segmentation is working:

• Percentage of critical assets in an enforced (not monitor-mode) segment.
• Count of any-any or overly broad rules, trending down, and percentage of rules with an owner and review date.
• Number of hosts reachable from a standard workstation on SMB, RDP and WinRM, measured by an internal scan.
• Segmentation test findings closed within target, and time since last successful segmentation test.
• Percentage of meshed services in STRICT mTLS with a default-deny authorisation policy.

Framework mapping

Common failure patterns

• Segmenting by VLAN and calling it done: VLANs without filtering between them, or with a permit-any between user and server ranges, give the appearance of segmentation and none of the effect.
• Enforcing before mapping: a production outage in the first week usually ends the project. Monitor mode and dependency maps are not optional steps.
• No boundary between IT and operations: in the Colonial Pipeline ransomware attack, the company proactively shut down its pipeline in response to an attack on IT systems. When you cannot prove the boundary holds, containment means stopping the business.
• Management planes on the user network: firewall, hypervisor and BMC interfaces reachable from workstations let one stolen admin credential bridge every boundary (T1599).
• Shared infrastructure paths: backup, monitoring and deployment servers allowed into every zone become the bridge attackers use. Treat them as tier zero.
• Permanent temporary rules: emergency allow rules without expiry accumulate until the policy is flat again.

Practitioner checklist

• Inventory assets and classify them into a small set of risk-based zones, with crown jewels named.
• Collect flow data across a full business cycle and record every allowed flow with an owner and reason.
• Move management interfaces, security tooling and identity systems into dedicated, restricted zones.
• Enable host firewalls that block inbound SMB, RDP and WinRM between workstations.
• Harden switching: access mode on user ports, no trunk negotiation, unused native VLAN, unused ports shut.
• Run new policy in monitor mode, then enforce in rings with a tested one-step rollback.
• Use workload identity (mTLS, service accounts, SPIFFE) for cloud and Kubernetes policy, with STRICT mode and default deny.
• Protect and monitor every account and token that can change network policy.
• Penetration test segmentation at least annually, and every six months for PCI service providers.
• Report the metrics above to risk owners quarterly and expire unused rules.

Standards and references

• NIST: SP 800-207 Zero Trust Architecture
• CISA: Microsegmentation in Zero Trust, Part One: Introduction and Planning
• NCSC: Preventing Lateral Movement
• PCI SSC: Guidance for PCI DSS Scoping and Network Segmentation
• MITRE ATT&CK: M1030 Network Segmentation
• MITRE ATT&CK: T1599 Network Boundary Bridging
• IETF: RFC 5517 Cisco Systems' Private VLANs
• Istio: Security Concepts

Related NHI Mgmt Group resources: Zero Trust Identity Guide · Cloud Workload Identity Guide · Network Ports and Protocols Security Guide · Ransomware Prevention Guide