Network Segmentation Testing Guide: How to Prove Segments Really Isolate

Most segmentation designs are trusted on the strength of a diagram, and diagrams do not show the forgotten any-any rule, the dual-homed jump host or the cloud peering that quietly joins two zones. Segmentation testing is the evidence that a boundary blocks what it is meant to block, from every place an attacker could start. This guide covers how to build a test matrix, which test methods to combine, how to run active tests safely, how to read the results, how to test cloud and container boundaries, and how to keep validation continuous rather than annual. It is written for network security engineers, penetration testers and assessors, and for the PCI DSS owners who need segmentation evidence that stands up to a QSA. For the design side, see the Network Segmentation Guide.

Key takeaways

• Test the intent, not the rule base. Write down what must never be reachable (zone to zone, port by port) and test those statements; a clean firewall review does not prove there is no other path.
• Combine three kinds of evidence. Configuration analysis finds paths you would never probe, active probing proves what the data plane actually does, and flow logs show what is really crossing the boundary every day.
• Test from every source zone and every enforcement method. The PCI SSC penetration testing guidance asks for each type of segmentation methodology in use to be tested, and a representative subset of segments only where testing all of them is infeasible.
• Read "filtered" carefully. No reply is not the same as blocked by design: UDP, stateful return traffic and rate limiting all produce ambiguous results that need a second method to confirm.
• Retest on change, not just on the calendar. PCI DSS requires segmentation tests at least every 12 months for merchants and every six months for service providers, and after any change to segmentation controls; mature teams also run automated checks after every firewall or security group change.

What a segmentation test must prove

A segmentation test answers one question: can anything in zone A reach anything in zone B that policy says it should not? The PCI SSC information supplement on scoping and segmentation sets a useful bar for any environment, not only card data: segmentation must stop out-of-scope systems from reaching the protected zone or affecting its security even if an attacker gains administrative access to an out-of-scope system, and it must stop an out-of-scope system from using an in-scope system as a stepping stone.

• Isolation: no route, port or protocol from a lower-trust zone to a higher-trust zone except the documented, approved flows.
• Minimal allowed flows: each approved flow is limited to named sources, destinations, ports and directions, and nothing wider. An allowed flow to "the database subnet" when one host needs one port is a finding.
• No transitive paths: shared services (DNS, directory, patching, backup, monitoring, jump hosts) must not provide a path between zones. The PCI SSC supplement keeps such connected-to systems in scope precisely because they can bridge zones.
• Failure is visible: logging and monitoring should detect when segmentation fails. A test that crosses a boundary and raises no alert is two findings, not one.

Attackers look for the same gaps. ATT&CK T1046 Network Service Discovery and T1018 Remote System Discovery describe how they map what is reachable, T1021 Remote Services and T1210 Exploitation of Remote Services describe how they cross, and T1599 Network Boundary Bridging covers compromising the device that enforces the boundary. Your test should cover the same ground first. See the Lateral Movement Guide.

Building the test matrix

The matrix turns the segmentation design into testable statements. Without it, a tester scans what is convenient and the report says "no issues found" about the wrong boundaries.

1. List zones and their trust level: user networks, guest and BYOD, server zones, management networks, the protected zone (card data, OT, clinical, backup, identity tier 0), DMZs, partner and VPN pools, cloud VPCs or VNets and Kubernetes namespaces.
2. List enforcement methods per boundary: zone firewall, VLAN ACL, private VLAN, host firewall, hypervisor distributed firewall, cloud security group or network ACL, Kubernetes NetworkPolicy, service mesh policy. Each method needs its own test, because each fails differently.
3. Write the expected result for every pair: "deny all", or "allow only TCP 443 from these three hosts". The PCI SSC penetration testing guidance asks the organisation to give the tester a network diagram and a list of segments isolated from the protected zone; the matrix is that list made testable.
4. Add the shared services and management planes: directory, DNS, NTP, patching, backup agents, monitoring, out-of-band management (iLO, iDRAC, IPMI), hypervisor management and jump hosts. These are where most real cross-zone paths live.
5. Choose test points: at least one host in each source zone, including wireless, VPN pools and a cloud workload. In very large estates the PCI SSC guidance accepts a representative subset of LAN segments, as long as every unique segmentation method is still tested.

Test methods and when to use each

No single method is enough. Configuration analysis cannot see a misbehaving device, active probing only tests the paths you thought to probe, and flow logs only show traffic that has already happened.

• Configuration review: start with the rules between the zones in your matrix. Look for any-any, broad object groups, rules with no hit count in a year, and rules whose comment names a project that ended. See the Firewall Rule Review Checklist.
• Active probing: the PCI SSC guidance describes segmentation checks as early-stage network testing techniques such as host discovery and port scanning, run from each out-of-scope segment toward the protected zone. NIST SP 800-115 covers planning and running these technical tests within an approved assessment.
• Foothold testing: the scoping supplement's bar is an attacker with administrative access on an out-of-scope host, so a full test also tries stored credentials, management agents and shared services from that host, not only open ports. See the CIS Control 18 Penetration Testing Guide.
• Continuous checks: a scheduled probe or simulation between fixed test points catches regressions between annual tests. See the Breach and Attack Simulation (BAS) Guide.

Running active tests safely

Segmentation tests touch production networks and sometimes fragile systems. Treat them as an authorised assessment with written rules of engagement.

1. Get written authorisation and scope: zones, test hosts, IP ranges, time windows and exclusions, signed by the system owners. Notify the SOC so alerts are expected, but ask them to treat detections as real and record them: whether the test was seen is part of the result.
2. Exclude or rate-limit fragile targets: OT controllers, medical devices and legacy systems can fail under scanning. For those boundaries, test from the source side toward a dedicated listener, or rely on configuration analysis and flow logs. See the OT Network Segmentation, Purdue Model and IEC 62443 Zones and Conduits Guide.
3. Place a listener in the destination zone: a test host that accepts connections on every TCP and UDP port turns "filtered" into a clear yes or no, because you know the destination would have answered.
4. Probe all 65,535 TCP ports from each source zone to the listener and to a sample of real hosts, plus the UDP ports that matter (DNS 53, NTP 123, SNMP 161, syslog 514, IKE 500 and 4500, NetBIOS 137 and 138, and any application ports).
5. Test both directions: a boundary that blocks inbound connections but lets the protected zone open connections outward to user networks is a path for exfiltration and command and control.
6. Record evidence: source host and IP, time, tool and options, raw output, and the matching firewall or flow log entries. Assessors want to see what was tested from where, not only the conclusion.

Reading port scan results

The Nmap reference guide describes the ACK scan (-sA) as a way to map firewall rule sets and tell whether a firewall is stateful; it never reports ports as open, only filtered or unfiltered. For UDP (-sU), Nmap reports open|filtered when no reply arrives, because the port could be open or a filter could be dropping the probe. "Closed" is the result testers most often misread: it means the packet crossed the boundary.

Testing cloud and container boundaries

In cloud networks the boundary is made of route tables, peering, transit gateways, private endpoints, security groups and network ACLs. A port scan from one instance tests one path; configuration analysis can test all of them. The providers below are listed alphabetically.

• AWS: VPC Reachability Analyzer is a configuration analysis tool that tests connectivity between a source and destination and, when the destination is not reachable, names the blocking component (security group, network ACL, route table or load balancer). Network Access Analyzer lets you define Network Access Scopes with MatchPaths and ExcludePaths, and AWS lists verifying that production and development VPCs are isolated, and that card data systems are isolated, as example uses.
• Google Cloud: Connectivity Tests offers configuration analysis that simulates the forwarding path through firewall rules and routes, and live data plane analysis that sends probe packets for supported configurations. Google notes that a "could be delivered" configuration result does not guarantee traffic will pass, which is why both checks matter.
• Microsoft Azure: Network Watcher IP flow verify takes a direction, protocol, local and remote IP and port for a VM and returns allowed or denied with the name of the network security group rule that decided it. It tests TCP and UDP rules on the VM's network interface; NSG diagnostics covers ICMP and scale sets.

Use path analysis to answer "is there any path?" across all accounts or subscriptions, then confirm the paths that matter with a live probe from a real workload. Repeat the analysis whenever peering, transit or route tables change, and treat new peering between production and non-production as a change that triggers a segmentation retest.

Kubernetes: NetworkPolicy is enforced only if the cluster's network plugin supports it, so a policy object existing proves nothing. Test from a pod in each namespace toward pods in other namespaces, the node network, the cloud metadata endpoint and the control plane, and include host-network pods, which policies scoped to pod selectors may not cover. See the Cloud Penetration Testing Guide.

Where identity fits

Many segmentation failures are identity failures. A service account that is valid in both zones, a backup or monitoring agent with credentials on every host, or a jump host that accepts the same administrator from user networks all let an attacker cross a boundary that the firewall enforces correctly. When you test from a foothold, check which credentials, tokens and agents on that host are also accepted in the protected zone, and include machine identities used by management tools. See the Backup Identity Isolation Guide.

Retesting, change triggers and continuous validation

PCI DSS v4.0.1 requires penetration testing of segmentation controls at least every 12 months and after any change to segmentation controls or methods (Requirement 11.4.5), and at least every six months and after any such change for service providers (Requirement 11.4.6). Both requirements also expect testing to cover all segmentation controls and methods in use, follow the entity's defined penetration testing methodology, confirm the controls isolate the CDE from all out-of-scope systems, and be performed by a qualified internal resource or qualified external third party with organisational independence. The detail of what counts as adequate segmentation for scoping is covered in the PCI DSS Scoping and Network Segmentation Guide.

Outside PCI, treat these as change triggers that need a targeted retest:

• Firewall and ACL changes touching any rule between zones in the matrix.
• New network paths: VPN pools, SD-WAN sites, cloud peering, transit gateway attachments, private endpoints, partner links.
• New shared services or management tools with agents in more than one zone.
• Platform changes: firewall replacement, microsegmentation agent rollout or policy moving from monitor to enforce mode.
• Incidents where lateral movement occurred or was attempted.

Automate what you can: scheduled probes between fixed test points with alerts on any change in result, configuration path analysis on every infrastructure-as-code change, and flow log queries for traffic between zones that the matrix says should be empty.

Detection and measurement

A boundary that is crossed silently is failing twice. Every test should check that the SOC saw the attempt.

• Log denies at every boundary in the matrix and forward them to the SIEM; alert on denied traffic from protected zones outward and on port sweeps between zones.
• Baseline allowed inter-zone flows from flow logs, and alert on new source, destination or port combinations.
• Watch the enforcing devices: configuration changes, new administrators and firmware changes on firewalls and switches, the target of T1599 Network Boundary Bridging.

Framework mapping

See the M1030 Network Segmentation guide for the technique-to-segmentation mapping.

Common failure patterns

• Testing from one subnet: a scan from the tester's own laptop VLAN says nothing about wireless, VPN pools, partner links or cloud workloads, which often have different rules.
• Scanning the top 1,000 ports only: admin and application ports outside the default list (management agents, database replicas, custom services) are exactly what gets left open.
• Treating "closed" as blocked: a reset from the destination host means the packet crossed the boundary. Without a listener, a boundary can look tight only because nothing happened to be listening.
• Ignoring shared services and management planes: backup, monitoring and patching servers with agents in every zone, and out-of-band management interfaces, are common transitive paths. The Colonial Pipeline ransomware attack ended with the operator proactively shutting down its pipeline system to contain an intrusion on the business IT side; the physical impact came from that containment decision, which is far easier to calibrate when there is tested evidence of how IT and operational networks are separated.
• Annual test, weekly changes: segmentation passes in March and a peering connection or broad rule added in April undoes it until the next test.
• Tests nobody saw: sweeps across zones that raised no alert, recorded as a pass because no path was found.

Practitioner checklist

• Maintain a segmentation test matrix listing every zone pair, expected result and enforcement method, owned and versioned.
• Test every enforcement method in use, from at least one host in every source zone, including wireless, VPN, partner and cloud sources.
• Place listeners in protected zones so filtered and closed results can be interpreted correctly.
• Probe all TCP ports and the relevant UDP ports, in both directions, and keep raw output as evidence.
• Run configuration path analysis across cloud accounts and subscriptions, and confirm critical paths with live probes.
• Include shared services, management planes and machine credentials in foothold testing.
• Define change triggers that require a targeted retest, and meet the PCI DSS frequencies where they apply.
• Check that every cross-zone test was detected, and track coverage, unapproved paths and time to close.

Standards and references

• PCI Security Standards Council: Information Supplement, Penetration Testing Guidance
• PCI Security Standards Council: Guidance for PCI DSS Scoping and Network Segmentation
• NIST: SP 800-115, Technical Guide to Information Security Testing and Assessment
• NIST: SP 800-53 Rev. 5
• MITRE ATT&CK: Network Segmentation (M1030)
• Nmap: Port Scanning Techniques
• AWS: What is Network Access Analyzer?
• Microsoft Learn: IP flow verify overview

Related NHI Mgmt Group resources: Network Segmentation Guide · PCI DSS Scoping and Network Segmentation Guide · Zero Trust Network Segmentation Playbook for Flat Networks · Microsegmentation Buyers Guide