PCI DSS 4.0 Network Segmentation Requirements Explained

By William Toll, Head of Product Marketing, Elisity · Updated June 14, 2026 · 13 min read

Network segmentation is the single most consequential decision in a PCI DSS program, because it determines how much of your environment the assessor has to look at. The PCI Security Standards Council (PCI SSC) is explicit that segmentation is not a requirement, yet it is the recognized method for taking systems out of scope, which is why nearly every cost-conscious PCI DSS 4.0 effort starts here. This guide explains what PCI DSS 4.0 actually requires of segmentation, which requirements apply by number, how segmentation reduces cardholder data environment scope, and where modern approaches such as identity-based microsegmentation fit. It is written to be vendor-neutral; the named requirements are cited to the PCI SSC, and Elisity is positioned at the end so you can judge the fit on the merits.

“Under PCI DSS 4.0, segmentation is optional but scope is not. The systems you fail to isolate are the systems you have to secure, assess, and pay for every year. Reducing scope is the most durable way to reduce PCI cost and risk at the same time.” Elisity, on the economics of PCI DSS scope reduction

Is network segmentation required for PCI DSS 4.0 compliance?

No. According to the PCI Security Standards Council, network segmentation is not a PCI DSS requirement. The standard states plainly that segmentation is the recommended method to reduce the scope of a PCI DSS assessment, the cost of the assessment, the difficulty of maintaining controls, and the risk to an organization. In other words, you can be PCI DSS 4.0 compliant with a flat network, but you would then have to apply every applicable control to every connected system, because without segmentation the entire network is in scope.

This distinction is the most misunderstood point in PCI scoping, so it is worth stating definitively. PCI DSS 4.0 does not order you to segment. It defines what counts as in scope, and it allows segmentation as the mechanism that pulls systems out of scope. The moment you rely on segmentation to reduce scope, the segmentation itself becomes subject to specific PCI DSS 4.0 requirements: it must be documented, justified, and verified to actually work. The rest of this guide walks through exactly which requirements those are.

PCI DSS 4.0 has also moved from future tense to present tense. The PCI SSC retired PCI DSS 3.2.1 on March 31, 2024, making 4.0 the only active version of the standard, and the future-dated requirements introduced in 4.0 became mandatory on March 31, 2025. For any assessment dated after that, the 4.0 segmentation expectations described here are in force today, not on a roadmap.

Segmentation is optional. Scope is mandatory. PCI DSS 4.0 lets you choose how large your cardholder data environment is, and that single architectural choice drives the cost, effort, and risk of every assessment that follows. Source: PCI Security Standards Council, on the purpose of segmentation in PCI DSS.

Scope and the cardholder data environment

The cardholder data environment, or CDE, is the set of people, processes, and technology that store, process, or transmit cardholder data or sensitive authentication data, plus any system component that is connected to or could affect the security of those systems. That second clause is the one that surprises people. Per the PCI SSC, in-scope systems are not only the systems that touch card data, but also connected-to and security-impacting systems, the management plane, the jump hosts, the directory services, the monitoring tools, and anything else with a path into the CDE.

Segmentation works by cutting those paths. If a system has no connectivity to the CDE and cannot affect its security, it is out of scope. The PCI SSC guidance on scoping makes the burden of proof clear: a system is assumed in scope until segmentation is demonstrated to isolate it. This is why scoping and segmentation are the same conversation, and why the PCI SSC published dedicated guidance, the Information Supplement on Guidance for PCI DSS Scoping and Network Segmentation, to walk assessors and organizations through it.

The practical goal is to move as many systems as possible into the out-of-scope row, and to keep them there with segmentation that holds up under testing. For a broader treatment of how segmentation maps across regulatory regimes, see our overview of microsegmentation compliance requirements across six frameworks and our guide to network segmentation compliance best practices.

PCI DSS 4.0 segmentation requirements by number

Once segmentation is used to reduce scope, PCI DSS 4.0 attaches specific obligations to it. The following requirements, all defined by the PCI Security Standards Council in PCI DSS v4.0, are the ones a segmentation design has to satisfy. The numbers and intent are paraphrased from the standard; consult the official PCI DSS v4.0 document at the PCI SSC Document Library for the controlling text.

The two requirements buyers ask about most are 1.2.6 and the 11.4 testing family, so each gets its own treatment below. Requirement 1.2.6, per the PCI SSC, requires that security features be defined and implemented for any services, protocols, or ports that are allowed, including any that are considered insecure. In a segmentation context this means every connection permitted to cross the CDE boundary has to be documented with a business justification and protected, the standard does not allow an unexplained allow rule between an out-of-scope zone and the CDE. The PCI SSC also expects network security control rulesets to be reviewed at least once every six months under Requirement 1.2.7, which is the source of the widely cited six-month segmentation review cadence.

PCI DSS 4.0 network segmentation testing requirements

Segmentation is the only PCI DSS scope-reduction mechanism that the standard insists you prove with offensive testing. Under Requirement 11.4.5, the PCI SSC requires that penetration testing be performed on segmentation controls to confirm they are operational and effective, and that they isolate out-of-scope systems from systems in the CDE. This is not a configuration review. It is an active test in which the assessor attempts to reach the CDE from an out-of-scope network and confirms that the segmentation stops them.

The practical lesson is that segmentation is a living control, not a one-time architecture. A boundary that was tight at the last assessment can drift as new systems, firewall changes, and remote access tools accumulate. The PCI SSC ties the testing cadence to change precisely because static rules decay. This is also where the related discipline of blocking lateral movement with microsegmentation connects directly to the penetration tester’s job: the test is, in effect, an attempt to move laterally into the CDE, and the segmentation either contains it or it does not.

How does microsegmentation help with PCI DSS 4.0 scope reduction?

Traditional PCI segmentation is coarse. It puts the cardholder data environment behind a firewall or in a dedicated set of VLANs, then trusts everything inside that perimeter. It reduces scope at the network-zone level, but it leaves a large flat zone inside the boundary, and an attacker who reaches any system in that zone can often move freely to the rest. Microsegmentation reduces scope more precisely by isolating workloads and devices from one another, so the in-scope footprint shrinks from a whole VLAN to the specific systems that actually handle card data.

The scope-reduction benefit is direct: the fewer systems that can reach the CDE, the fewer systems are in scope, and the fewer systems you must secure, document, and assess each year. Microsegmentation also makes the boundary easier to prove under Requirement 11.4.5, because least-privilege policy between workloads gives the penetration tester far fewer paths to attempt, and gives the assessor a precise, auditable map of what is allowed to talk to the CDE.

All three approaches can satisfy PCI DSS 4.0, and many environments combine them. Host-based microsegmentation, offered by vendors such as Illumio and Akamai Guardicore, is well established and strong where every in-scope system can run an agent. Identity-based microsegmentation takes a different path that is described in the next section. The point of the table is not to declare a winner; it is to show that scope reduction has a granularity dimension, and that finer granularity generally means fewer in-scope systems and a boundary that is easier to test.

Identity-based microsegmentation for the cardholder data environment

Identity-based microsegmentation is an approach in which access policy follows the identity of a device and user rather than an IP address, a VLAN tag, or a static firewall rule. Each asset is classified by attributes it already exposes, its behavior, fingerprint, and context, and policy is enforced on the network infrastructure already in place, agentlessly and over any data plane. For a PCI DSS cardholder data environment, this has three properties that matter directly to an assessment.

First, it covers the assets a host-based approach cannot. Payment environments are full of devices that cannot run an agent: point-of-sale terminals, kiosks, payment peripherals, and operational devices on the same network. Agentless, identity-based enforcement reaches those devices, which means fewer systems have to be left in a trusted zone for lack of a way to isolate them. Second, policy that follows identity does not drift the way an IP-based ruleset does, which speaks directly to the six-month review cadence under Requirement 1.2.7 and the post-change re-test under Requirement 11.4.5; the policy stays attached to the device even when addresses change. Third, an observe-then-enforce rollout, discover assets, map real flows, run policy in monitor-only mode, then promote to enforcement, lets a payment environment tighten its CDE boundary without an outage, which is the practical objection that stalls most segmentation projects.

Elisity enforces identity-based microsegmentation on the network infrastructure already in place, agentlessly and over any data plane. For a PCI cardholder data environment, that means the boundary can reach the unmanaged payment devices a host-based agent cannot, and the policy follows the device rather than its address, so the CDE stays isolated as the environment changes. Elisity, on identity-based segmentation for the PCI cardholder data environment

None of this removes the need to test. Whatever approach isolates your CDE, PCI DSS 4.0 still requires the penetration test under Requirement 11.4.5 to prove it. What identity-based microsegmentation changes is how much surface the tester finds and how stable the boundary remains between assessments. For the architecture in depth, see what is microsegmentation, the difference between microsegmentation and network segmentation, and how it relates to zero trust microsegmentation.

How to meet PCI DSS 4.0 segmentation requirements, step by step

The reliable path to a defensible segmentation posture is the same regardless of vendor. The steps below sequence the work so that scope shrinks first and proof follows.

Steps two through four are where the choice of segmentation approach matters most. An identity-based, agentless rollout lets you map flows and enforce policy on the infrastructure you already run, which is what makes the no-downtime promotion in step four realistic for a live payment environment. For the discovery and visibility foundations those steps depend on, see network asset discovery for microsegmentation and network visibility and microsegmentation. For how the same discipline extends to unmanaged and connected devices in scope, see simplifying IoT segmentation for enterprises.

Frequently asked questions about PCI DSS 4.0 network segmentation

What are the network segmentation requirements for PCI DSS 4.0 compliance?

PCI DSS 4.0 does not require network segmentation, but it makes segmentation the recognized way to reduce the scope of the cardholder data environment. When you use segmentation for scope reduction, the PCI Security Standards Council requires that allowed connections across the boundary be justified and secured (Requirement 1.2.6), that inbound and outbound CDE traffic be limited to what is necessary (Requirement 1.3), that rulesets be reviewed every six months (Requirement 1.2.7), and that the segmentation be validated by penetration testing (Requirement 11.4.5).

Is network segmentation mandatory under PCI DSS 4.0?

No. Per the PCI Security Standards Council, segmentation is not a PCI DSS requirement; it is the recommended method to reduce assessment scope, cost, difficulty, and risk. You can comply with a flat, unsegmented network, but then every connected system is in scope and must meet the applicable controls. Most organizations segment because doing so dramatically shrinks the number of in-scope systems.

How does microsegmentation help with PCI DSS 4.0 scope reduction?

Microsegmentation isolates workloads and devices from one another rather than only separating network zones, so the in-scope footprint shrinks from a whole VLAN to the specific systems that handle card data. Fewer systems able to reach the cardholder data environment means fewer systems in scope to secure, document, and assess. It also gives the Requirement 11.4.5 penetration tester fewer paths to attempt and the assessor a precise map of what may reach the CDE.

What does PCI DSS 4.0 require for segmentation testing?

Under Requirement 11.4.5, the PCI Security Standards Council requires penetration testing of segmentation controls to confirm they isolate out-of-scope systems from the cardholder data environment and remain operational and effective. Most organizations must test at least once every twelve months and after any change to segmentation controls; service providers must test at least once every six months under Requirement 11.4.6. The test actively attempts to reach the CDE from an out-of-scope network.

When did PCI DSS 4.0 become mandatory?

PCI DSS 3.2.1 was retired on March 31, 2024, leaving 4.0 as the only active version, and the future-dated requirements introduced in 4.0 became mandatory on March 31, 2025, per the PCI Security Standards Council transition timeline. Any assessment dated after that date is conducted fully against PCI DSS 4.0, including its segmentation-related requirements.

What is identity-based microsegmentation for the PCI cardholder data environment?

Identity-based microsegmentation enforces access policy based on the identity of a device and user rather than an IP address or VLAN, applied on the existing network infrastructure without agents and over any data plane. For a PCI cardholder data environment it reaches unmanaged payment devices that cannot run an agent, keeps policy attached to the device as addresses change, and supports an observe-then-enforce rollout that isolates the CDE without production downtime. It still has to be validated by the Requirement 11.4.5 penetration test.

Related compliance and microsegmentation resources from Elisity

• Microsegmentation compliance requirements across six frameworks
• Microsegmentation for compliance with Elisity
• Network segmentation compliance best practices
• What is microsegmentation?
• Microsegmentation vs. network segmentation
• Zero trust microsegmentation
• Block lateral movement with microsegmentation
• Network visibility and microsegmentation
• Network asset discovery for microsegmentation
• Simplifying IoT segmentation for enterprises
• Top microsegmentation solutions for 2026, compared
• Microsegmentation for healthcare
• Microsegmentation for industrial and OT environments
• Enterprise microsegmentation
• Elisity integrations overview
• Omdia microsegmentation report
• Elisity awards and recognition
• The Elisity platform

Requirement numbers, intent, and testing cadences in this article are paraphrased from PCI DSS v4.0 as published by the PCI Security Standards Council (PCI SSC). For the controlling text, consult the official PCI DSS v4.0 standard and the Information Supplement on Guidance for PCI DSS Scoping and Network Segmentation in the PCI SSC Document Library. This article is general guidance, not a substitute for a Qualified Security Assessor’s scoping determination.