Network Segmentation for PCI DSS: Firewalls and Encrypted Transit

The Payment Card Industry Data Security Standard (PCI DSS) is the contractual security standard that applies to any organization that stores, processes, or transmits payment card data. On the network side, it drives three designs the N10-009 exam cares about: segmenting the cardholder data environment (CDE) behind firewalls to shrink audit scope, funneling administrative access through a hardened, logged chokepoint such as a jump box, and encrypting cardholder data with strong cryptography whenever it crosses open, public networks.

Why segmentation is the foundation of PCI networking

The CDE is every system that touches cardholder data plus anything that can directly affect its security. Here is the part that shapes network architecture: by default, PCI DSS scope is the entire connected network. If your point-of-sale (POS) terminals sit on the same flat network as the office printers and the guest Wi-Fi, all of it is in scope for assessment — every host must meet PCI controls, and every host is a potential pivot into card data.

Segmentation is how you shrink that. Placing the CDE in its own isolated segment — dedicated virtual local area networks (VLANs) enforced by firewall rules, not VLANs alone — means only the segmented environment carries PCI obligations. Effective segmentation requires:

• Default-deny at the boundary. The firewall between the CDE and everything else permits only the specific flows card processing needs (POS to payment processor, defined management flows) and denies all else, in both directions. “Deny all inbound by default” is the posture assessors expect to see.
• No direct paths from untrusted networks. Nothing on the internet, guest wireless, or the general corporate LAN should reach a CDE host directly.
• Documented and tested isolation. Segmentation only reduces scope if penetration testing confirms the boundary actually holds.

VLAN separation without a filtering device between VLANs is not segmentation — a layer 3 device happily routes between VLANs unless access control lists (ACLs) or a firewall say otherwise.

Administrative access: the jump box chokepoint

Segmentation creates a practical problem: administrators still need to manage the servers inside the CDE, but the boundary firewall denies inbound administrative connections. Opening Remote Desktop Protocol (RDP) or Secure Shell (SSH) from every admin workstation would punch dozens of holes in the boundary and scatter the audit trail across the fleet.

The accepted design is a jump box (also called a jump server or bastion host): a single hardened host that is the only system permitted to originate administrative sessions into the segment. Administrators authenticate to the jump box — with multifactor authentication (MFA), which PCI DSS requires for all access into the CDE — and from there open sessions to the internal servers. The pattern delivers exactly what assessors ask for:

• One chokepoint — the firewall allows management traffic from a single source address, keeping the rule base tiny and reviewable.
• Complete logging — every administrative session traverses one host, so session logs, keystroke recording, and monitoring live in one place.
• Strong authentication — MFA is enforced once, at the gate, for everyone.
• A hardened target — the jump box runs minimal software, is patched aggressively, and is watched closely, because it is the door.

When a scenario describes auditors demanding that all admin access to an isolated segment pass through a single logged, monitored, MFA-protected host, the answer is a jump box. A general-purpose remote-access VPN into the segment fails the “single monitored chokepoint” test; opening per-admin firewall exceptions fails harder. Pairing the segment with monitoring sensors is common too — see IDS/IPS deployment modes for how passive sensors watch a sensitive segment without touching its traffic.

Encryption in transit: the non-negotiable requirement

Segmentation protects card data inside your walls, but transaction data has to leave — POS terminals transmit to a payment processor, often across the public internet. PCI DSS dedicates a requirement area to this: protect cardholder data with strong cryptography during transmission over open, public networks. Plaintext card numbers crossing the internet, unencrypted wireless, or any other network you do not control is a direct violation of that transmission-security requirement — not a firewall finding, not an access-control finding, but specifically a failure to encrypt cardholder data in transit.

Meeting it means current, strong protocols: Transport Layer Security (TLS) 1.2 or higher for application traffic, or an encrypted tunnel such as an IPsec (Internet Protocol Security) VPN carrying the processor connection. Deprecated protocols — Secure Sockets Layer (SSL), early TLS 1.0/1.1, Wired Equivalent Privacy (WEP) on wireless — do not count as strong cryptography. The same logic extends inside the building: card data crossing your own wireless must ride a modern Wi-Fi Protected Access (WPA2/WPA3) network — see wireless security protocols for why WEP and TKIP are disqualified — never an open or WEP-protected one.

Network control	PCI DSS requirement area it satisfies
Firewall isolating the CDE, default-deny rules	Install and maintain network security controls
Jump box with MFA for admin access	Restrict and authenticate access to system components
Session logging on the chokepoint	Log and monitor all access to cardholder data
TLS/IPsec to the payment processor	Protect cardholder data during transmission over open, public networks
Segmentation penetration testing	Test security of systems and networks regularly

How the N10-009 exam tests this

• A retail scenario has an isolated card-processing segment, a firewall denying inbound admin connections, and auditors requiring a single logged, MFA-protected path for administrators — the answer is a jump box (bastion host). Distractors like “open RDP through the firewall” or a plain VPN lack the single monitored chokepoint.
• An assessor finds cardholder data sent from POS terminals to the processor in plaintext across the internet — identify the violated area: encrypting cardholder data in transit over open, public networks. Watch for distractors naming storage encryption or firewall requirements instead.
• A design question asks how to reduce PCI assessment scope on a mixed network — segment the CDE behind a firewall so only that environment is in scope.
• A trap pattern: VLANs alone offered as “segmentation.” Without firewall/ACL enforcement between segments, VLANs do not isolate anything an assessor will accept.

Compliance scenarios reward familiarity — drill them with practice questions so the jump-box pattern registers at a glance.

Quick reference

• PCI DSS applies to anyone storing, processing, or transmitting payment card data; the CDE is the set of systems that touch it.
• Unsegmented networks put everything in PCI scope; firewalled segmentation shrinks scope to the CDE.
• CDE boundary posture: default-deny, only explicitly required flows, no direct access from untrusted networks, isolation verified by testing.
• VLANs without a filtering device between them are not segmentation.
• Admin access enters the CDE through one hardened jump box: MFA at the gate, every session logged and monitored, firewall allows management traffic from that host only.
• Cardholder data over open/public networks must use strong cryptography — TLS 1.2+, IPsec; SSL, early TLS, and WEP are disqualified.
• Plaintext card data on the internet = transmission-encryption violation, full stop.