Notifications
Clear all
Topic starter
10/07/2026 9:10 pm
TL;DR: PCI DSS 4.0 does not require network segmentation, but it makes segmentation the practical mechanism for shrinking cardholder data environment scope, with documented, justified, and penetration-tested boundaries under Requirements 1.2.6 and 11.4.1, per the PCI Security Standards Council. Scope reduction is an architecture decision that directly changes cost, testing burden, and residual risk.
NHIMG editorial — based on content published by Elisity: PCI DSS 4.0 segmentation is about scope control, not mandatory design
By the numbers:
- PCI DSS 3.2.1 was retired on March 31, 2024, leaving 4.0 as the only active version.
- The future-dated requirements introduced in PCI DSS 4.0 became mandatory on March 31, 2025.
Questions worth separating out
Q: How should security teams implement PCI DSS 4.0 segmentation without creating hidden scope creep?
A: Start by mapping every system that can store, process, transmit, or influence card data, then prove which systems truly cannot reach the CDE.
Q: Why do segmentation failures often turn into IAM and PAM problems as well?
A: Because network isolation can be undermined by privileged identities that cross the boundary through jump hosts, management tools, or service accounts.
Q: What signals show that PCI segmentation is still working as intended?
A: Look for a small and stable set of approved paths into the CDE, regular validation results from segmentation testing, and a low volume of temporary exceptions.
Practitioner guidance
- Map every CDE-adjacent access path Inventory management planes, jump hosts, directory services, monitoring tools, and non-human accounts that can reach payment systems.
- Tie segmentation rules to business justification Document each allowed service, protocol, and port across the boundary with a clear owner and purpose so the allow list can survive audit review under Requirement 1.2.6.
- Test the boundary like an attacker would Run penetration tests against the segmentation boundary after meaningful changes and on the required cadence, with explicit attempts to pivot from out-of-scope networks into the CDE.
What's in the full article
Elisity's full article covers the operational detail this post intentionally leaves for the source:
- The exact PCI DSS 4.0 requirement references that govern boundary rules, validation, and retesting.
- The step-by-step scoping logic for deciding which connected systems remain in the Cardholder Data Environment.
- The testing cadence and evidence expectations assessors look for when segmentation is used to reduce scope.
- The comparison between traditional network segmentation and identity-based microsegmentation in payment environments.
👉 Read Elisity's guide to PCI DSS 4.0 segmentation and CDE scope reduction →
PCI DSS 4.0 segmentation: what it means for compliance teams?
Explore further
10/07/2026 9:33 pm
Segmentation is a governance decision, not a network preference. PCI DSS 4.0 shows that the real control question is who and what can still affect the CDE after the boundary is drawn. If the answer is too broad, scope expands with it, and the assessment burden follows. Practitioners should treat segmentation as a formal governance boundary with evidence, ownership, and review cadence, not an engineering convenience.
A question worth separating out:
Q: Which frameworks help teams align segmentation with compliance and control testing?
A: PCI DSS v4.0 is the primary standard for payment environments, but NIST SP 800-53 and NIST SP 800-207 help teams connect segmentation to access control, auditability, and zero trust design. Use them together to translate boundary design into measurable control objectives.
👉 Read our full editorial: PCI DSS 4.0 segmentation is about scope control, not mandatory design
