The PCI DSS firewall requirements live in Requirement 1 of PCI DSS v4.0.1, the only active version of the standard. In plain terms, if your organization handles credit card data, you must install and maintain network security controls that protect the cardholder data environment (CDE) from unauthorized access, document how those controls are configured and changed, deny all traffic by default and permit only what has a written business justification, and review every rule set at least once every six months.1PCI Security Standards Council. Just Published: PCI DSS v4.0.1 Every future-dated requirement in v4.0.1 became mandatory on March 31, 2025, so anything that used to be labeled “best practice” during the transition is now enforceable at assessment.2PCI Security Standards Council. Now Is the Time for Organizations to Adopt the Future-Dated Requirements of PCI DSS v4.x
One vocabulary change matters before anything else: what earlier versions of the standard called “firewalls and routers” is now “network security controls,” or NSCs. The broader term reflects that many organizations now protect the CDE with cloud security groups, software-defined perimeters, and containerized firewalls rather than physical appliances. Wherever the standard says NSC, read it as “any control that enforces traffic rules at a network boundary.”
Documented Policies and Named Owners (Requirement 1.1)
Requirement 1.1 says you must define and document the processes for installing and maintaining your NSCs.3PCI Security Standards Council. PCI DSS v4.0.1 The written standards need to cover how each NSC is configured, how changes are approved, and which personnel are responsible for oversight.
This is where most compliance failures actually begin. Configuration drift, the slow accumulation of small undocumented changes, is almost always a people problem before it becomes a technical one. Someone opened a port for a vendor two years ago. Nobody removed it. Now there is an entry point that no current employee remembers authorizing, and no document that says who was supposed to remove it.
Change Control, Network Diagrams, and Six-Month Reviews (Requirement 1.2)
Requirement 1.2 covers the operational work of keeping NSCs properly configured over time.3PCI Security Standards Council. PCI DSS v4.0.1
Every Change Goes Through Formal Change Control
Under Requirement 1.2.2, any change to a network connection or NSC configuration must go through the formal change control process in Requirement 6.5.1. Each change record must include the reason and description, a security impact analysis, documented approval from an authorized party before the change goes live, testing to confirm the change does not weaken security, and rollback procedures. This applies whether you are adding, removing, or modifying a connection, and whether the change involves new hardware or just a configuration tweak that alters how traffic flows.
Accurate Network Diagrams and Business Justifications
Requirement 1.2.3 requires accurate network diagrams that show every connection between the CDE and other networks, wireless networks included. The diagram must identify every pathway into the CDE: third-party connections, wireless entry points, internal links, and internet-facing interfaces. Alongside the diagram, every allowed service, protocol, and port needs a written business justification. HTTPS on port 443 to a web server needs an explanation of why. Insecure protocols like Telnet or FTP need a more detailed justification that describes the compensating controls managing their risk.
Rule Set Reviews Every Six Months
Requirement 1.2.7 requires a formal review of all NSC rule sets at least once every six months. Administrators confirm that each active rule still ties back to a valid business justification, and any rule that is redundant, outdated, or no longer supports a legitimate function gets removed. The review itself must be documented: when it happened, who performed it, what changed as a result. If your change management records are complete, the review is a reconciliation exercise. Without them, it is guesswork, and assessors can tell the difference.
Restricting Traffic To and From the CDE (Requirement 1.3)
Requirement 1.3 is the technical core of firewall compliance. All network access to and from the cardholder data environment must be restricted to what is necessary, and everything else denied by default.
- Requirement 1.3.1 (inbound): only necessary traffic is allowed into the CDE; all other inbound traffic is specifically denied.
- Requirement 1.3.2 (outbound): only necessary traffic is allowed out of the CDE; all other outbound traffic is specifically denied.
- Requirement 1.3.3 (wireless): NSCs must sit between all wireless networks and the CDE, denying wireless traffic by default and allowing only connections with an authorized business purpose.
The deny-all default posture is the concept that carries the weight. Instead of writing a blocklist of known threats, which will always be incomplete, you start by blocking everything and then open narrow, documented paths for specific business needs. Administrators must explicitly permit each allowed service and protocol.
Most compliant architectures also place a buffer zone (a DMZ) between the public internet and the CDE. Public-facing services like web servers live in that buffer zone and handle incoming connections without giving external traffic a direct path to the databases where card data lives. The CDE ends up at least one network hop away from the internet, which gives monitoring tools time to notice suspicious activity before it reaches anything sensitive.
Boundary Controls Between Trusted and Untrusted Networks (Requirement 1.4)
Requirement 1.4 governs the boundary between your trusted internal network and untrusted external networks. Requirement 1.4.5 in particular limits the disclosure of internal IP addresses and routing information to authorized parties only.
Organizations typically satisfy this with Network Address Translation, which replaces internal IP addresses with a public-facing address before traffic leaves the network. The reasoning is direct: an attacker who cannot see your internal network structure cannot map it, and internal IP ranges, subnet layouts, and routing paths are exactly the reconnaissance an adversary uses to move laterally after initial access.
Anti-spoofing measures belong here as well. Traffic arriving at an external interface that claims to originate from an internal IP address is almost certainly forged, since legitimate internal traffic does not enter from outside. Blocking those packets prevents attackers from impersonating trusted internal hosts to slip past access controls.
Portable Devices That Bridge Networks (Requirement 1.5)
Requirement 1.5 addresses laptops and tablets that connect to both the corporate network and untrusted networks such as public Wi-Fi or home internet. These dual-homed devices create a potential bridge that an attacker could use to reach the CDE through the device rather than through your perimeter.
Controls that prevent this typically include host-based firewalls on the devices themselves, endpoint detection tools, and policies that restrict how and when a device can access the CDE after it has connected to an untrusted network. Perimeter NSCs alone are not enough when employees carry network bridges in their bags.
Multi-Factor Authentication for Firewall Administrators
Firewall administration consoles are high-value targets. Anyone with admin access to your NSCs can open ports, change rules, and dismantle the perimeter. PCI DSS Requirement 8.4.1 requires multi-factor authentication for all non-console access to the CDE by personnel with administrative privileges. Requirement 8.4.2 extends MFA to all access into the CDE, and 8.4.3 covers all remote network access originating from outside the organization’s network.4PCI Security Standards Council. Guidance for Multi-Factor Authentication
MFA means at least two separate authentication factors: something you know, something you have, or something you are. A username and password alone will not satisfy the requirement no matter how strong the password policy. For firewall administrators, a compromised admin credential without MFA effectively hands over every rule protecting the CDE.
Shared Responsibility When Firewalls Live in the Cloud
Moving payment processing to a cloud provider does not move the compliance obligation with it. The PCI Security Standards Council states that using a third-party service provider does not relieve an organization of responsibility for its own PCI DSS compliance.5PCI Security Standards Council. Third Party Security Assurance Information Supplement
In practice this means writing a responsibility matrix that names, for each Requirement 1 obligation, whether the provider or the customer owns it. Typical split points for firewall requirements:
- Provider-managed: physical network infrastructure, hypervisor-level firewalls, backbone routing.
- Customer-managed: security group configurations, application-level firewall rules, network diagrams showing CDE connections, rule review documentation.
The matrix should follow a RACI format and cover daily operations, evidence gathering, and assessment participation. If your provider is not itself PCI-compliant, their systems and processes may fall under your own assessment, which expands scope and cost. Verifying the provider’s compliance status annually, with documentation, is a step too many organizations skip until an assessor asks for it.
Segmentation Is Not Required, But It Controls Your Scope
Network segmentation is not explicitly required by PCI DSS. Skipping it, however, pulls every system on your network into scope: every server, workstation, and device has to meet the full standard. Segmentation isolates the CDE into its own zone so that only the systems inside that zone carry the heavier controls.
Segmentation only reduces scope if it actually works. If the controls separating the CDE from other networks are misconfigured or incomplete, the assessor will treat the whole network as in-scope regardless of intent. Testing the segmentation controls during the six-month rule review is a practical way to catch gaps before they become audit findings.
What Non-Compliance Costs
PCI DSS does not impose fines directly. The card brands assess penalties through the acquiring banks that process a merchant’s transactions, and the cost flows down to the merchant. Visa’s published penalty schedule uses tiered monthly assessments that escalate until the violation is corrected, and for violations Visa considers significant to the integrity of the payment system, monthly penalties can reach $1,000,000 and increase at Visa’s discretion.6Visa. Visa Core Rules and Visa Product and Service Rules
Persistent non-compliance can also lead to temporary suspension or permanent termination of the ability to accept card payments, which effectively shuts down any business where cards are the primary payment method. The organizations that get caught are almost always the ones that let their configurations drift for months or years without a structured review process, which is why Requirement 1.2.7 exists in the first place.