Segmentation is the most valuable scope-reduction tool in PCI DSS, and it's only worth something if it works. Requirement 11.4.5 makes you prove that it does with penetration testing at least once every 12 months and after any change to your segmentation controls. For service providers, 11.4.6 shortens that to every six months.

We've covered what Requirement 11.4.5 requires on this blog before. This post is the practical side: how I actually run segmentation testing on a Radical Security PCI engagement, and what I look for.

What we're trying to prove

The requirement asks for testing that confirms segmentation controls are operational and effective, and that they isolate the CDE from all out-of-scope systems. Read that carefully: all out-of-scope systems, and every segmentation control and method in use. A segmentation test that checks one firewall from one subnet answers a much smaller question than the one your assessor is asking.

So the test has two halves: build a complete list of what needs proving, then prove each item from the places an attacker would actually start.

Step 1: Map every segmentation control

Before I send a single packet, I build a matrix from your network diagram, cardholder data flow diagram and the scoping work we did together (see how I scope a PCI penetration test):

  • Every out-of-scope segment: corporate user networks, guest Wi-Fi, development and test, other business units, partner connections and VPN pools.
  • Every control between those segments and the CDE: perimeter and internal firewalls, router ACLs, VLAN boundaries, cloud security groups and network ACLs, host-based firewalls and micro-segmentation policies.
  • Every legitimate path into the CDE: jump hosts, management interfaces and the connected-to systems that are allowed through on purpose.

That matrix becomes the backbone of the test, and later of the segmentation section in the report. If it doesn't match what's actually deployed, that's the first finding.

Step 2: Test from inside each out-of-scope segment

Segmentation testing has to happen from the networks you say are out of scope, not from a convenient test box that happens to be next to the CDE. For each segment in the matrix, I test from a host placed in that segment, with the same network position a compromised workstation or server there would have.

From each position, I check:

  • Full TCP and UDP port coverage toward CDE address ranges, not just common ports. A single forgotten rule on a high port is a working path into the CDE.
  • Every CDE range, including the ones that aren't on the diagram. I discover live hosts and compare them with your inventory.
  • Layer 2 controls: VLAN hopping, double tagging and trunk negotiation where switches allow it.
  • Routing and egress: whether traffic can reach the CDE indirectly through a dual-homed host, a proxy or a VPN concentrator.

Anything that answers from the CDE side gets investigated by hand. An open port isn't automatically a failure, because it may be an approved connected-to path. But every open path has to be explained by a documented business need.

Step 3: Look hard at shared services

Most of the segmentation failures I find aren't firewall mistakes. They're shared services that quietly bridge the CDE and the rest of the network:

  • Directory services. A domain shared between corporate and CDE systems means a compromised corporate account can often authenticate inside the CDE.
  • Management and monitoring tools. Patch management, EDR consoles, backup servers and monitoring agents that can push code or commands into CDE hosts.
  • Jump hosts. Reachable from the corporate network by design. I test what it takes to get onto one and what it can reach.
  • Logging and SIEM. Usually one-way by design, but worth confirming.

Systems like these are connected-to systems and in scope themselves. The question for segmentation testing is whether they create a path from out-of-scope systems into the CDE that your controls don't stop.

Step 4: Cloud and hybrid environments

In cloud environments, segmentation is usually a combination of separate accounts or subscriptions, VPC or VNet design, security groups, network ACLs and peering. I review the configuration and test from instances placed in out-of-scope VPCs and accounts. I pay particular attention to peering connections, transit gateways, shared service VPCs and identity-based access that bypasses the network entirely, such as IAM roles that can reach CDE resources from outside the segment.

For hybrid environments, the on-premises to cloud links (site-to-site VPNs and dedicated connections) get the same treatment as any other segment boundary. The PCI SSC's scoping and segmentation guidance for modern network architectures is a useful companion here. Our post on PCI and the cloud shared responsibility model covers the provider side.

Step 5: Document every result

For each pair of out-of-scope segment and CDE target, the report records what we tested from, what we tested against, the methods, the result and the evidence. Failures include what was reachable and how to close it. Passes are documented just as carefully, because those are what your assessor relies on to accept the reduced scope.

If something fails, we retest after it's fixed as part of the same engagement, at no extra cost. A segmentation failure is one of the most consequential findings in a PCI test, because if the CDE isn't isolated, the systems on the other side are in scope too.

How we engage

Segmentation testing is always part of the written scope of a Radical Security PCI engagement when you rely on segmentation, with every segment and control listed. We never ask for money up front, you pay only once the work is complete, and every engagement is backed by our 100% money-back guarantee.

Key takeaways

  • 11.4.5 requires proof that every segmentation control isolates the CDE from all out-of-scope systems, at least every 12 months (every six months for service providers).
  • Build a matrix of out-of-scope segments, controls and legitimate paths before testing.
  • Test from inside each out-of-scope segment with full TCP and UDP coverage, and include Layer 2 and indirect paths.
  • Shared services like directory, management tools and jump hosts are the most common segmentation failures.
  • Document passes as carefully as failures, and retest anything that fails.
About the author. Marcello Duarte is a cybersecurity consultant at Radical Security and the author of this blog. He scopes and leads penetration tests for organizations working toward PCI DSS, SOC 2 and ISO 27001, and previously worked in vulnerability research, where he discovered CVE-2015-7392. To scope a PCI penetration test with Marcello, email [email protected].