PCI-DSS 4.0 Firewall Requirements: What Changed and How to Comply

PCI-DSS 4.0 took effect in March 2025, replacing version 3.2.1. If you handle cardholder data, your firewalls need to comply — and the requirements got stricter. Here's what network and security teams need to know.

What Changed in 4.0

PCI-DSS 4.0 moved from prescriptive rules to an "objective-based" approach. In practice, this means:

• Requirement 1.2.1 — Configuration standards must be defined, implemented, and maintained for all network security controls (firewalls, routers, switches). "Defined" means documented. "Maintained" means reviewed.
• Requirement 1.2.5 — All services, protocols, and ports must be identified, approved, and have a defined business need. No more "we think that rule is for the old payment terminal."
• Requirement 1.2.7 — Firewall configurations must be reviewed at least every six months. Not annually. Every six months.
• Requirement 1.3.1 — Inbound traffic to the cardholder data environment must be restricted to only necessary traffic. All other inbound traffic must be explicitly denied.
• Requirement 1.3.2 — Outbound traffic from the CDE must be restricted to only necessary traffic. This is new emphasis — 3.2.1 was softer on egress.

The Controls That Trip Up Most Organizations

Rule Documentation (1.2.5)

Every firewall rule needs a documented business justification. "Required for operations" is not a justification. "Allows payment terminal 10.1.5.20 to reach processor gateway at 203.0.113.50 on port 443 per request TICKET-1234 approved by John Smith on 2025-01-15" is a justification.

Six-Month Review (1.2.7)

Most organizations do annual reviews at best. PCI 4.0 cuts that to six months. The review must cover: all rules are still needed, rules are correctly ordered, no insecure protocols are permitted, default deny is in place, and all rules have current documentation.

Egress Filtering (1.3.2)

Many firewalls have tight inbound rules but wide-open outbound. PCI 4.0 requires explicit justification for outbound traffic from the CDE. An "allow all outbound" rule is a finding.

Building Audit Evidence

When your QSA arrives, they'll want to see:

1. A current firewall rule set with descriptions on every rule
2. Evidence of the six-month review (date, reviewer, findings, remediation)
3. A network diagram showing CDE boundaries and firewall placement
4. Documentation of all allowed services and their business justification
5. Default deny rules at the end of every ACL

The easiest way to produce this evidence is automated auditing. Run your firewall configs through a policy auditor that maps findings to PCI controls, fix the issues, then present the clean report as evidence. ShieldIQ generates reports formatted specifically for QSA review, mapping every finding to the relevant PCI-DSS 4.0 control.

Common Findings That Fail PCI Audits

Based on analysis of thousands of firewall policies:

• 72% have at least one rule with no description or business justification
• 45% have overly permissive egress rules that would fail 1.3.2
• 38% have disabled rules that haven't been cleaned up
• 23% allow insecure protocols (Telnet, FTP, SNMPv1) across trust boundaries
• 15% have no explicit default deny rule

Every one of these is a PCI finding. Every one is fixable in hours, not weeks — if you know where they are.