Requirements 1 and 2 form the perimeter defense layer of PCI DSS. They establish the network boundary around the Cardholder Data Environment (CDE) and ensure that every system component within and connecting to that boundary is configured securely. Together they represent the architectural baseline without which all other PCI DSS controls are undermined.
Requirement 1 — Network Security Controls
PCI DSS v4.0 broadened Requirement 1 from "firewalls" to "Network Security Controls (NSCs)" — a broader category that includes firewalls, cloud security groups, virtual firewalls, and any technology that filters network traffic based on defined rules. This change reflects the reality that modern CDEs span physical, virtual, and cloud environments.
What Must Be Documented
- Network diagrams showing all connections between the CDE and other networks (internal and external)
- Cardholder data flow diagrams showing where CHD enters, is processed, stored, and transmitted
- All inbound and outbound traffic rules for NSCs, with a documented business justification for each rule
- All NSC rule sets reviewed every six months, with a documented review process
NSC Configuration Requirements
All NSCs protecting the CDE must: deny all inbound and outbound traffic not explicitly required for business, prohibit direct public access between the internet and any CDE system component, restrict inbound and outbound traffic to that which is necessary, and use stateful inspection. A DMZ (demilitarized zone) is required for systems accessible from the internet.
| KEY IDEA | The "deny all, permit by exception" principle is the foundation of Requirement 1. Every NSC rule that allows traffic into or out of the CDE must have a documented business justification. Rules that exist without justification — common in long-running environments — are a finding that has to be remediated before assessment. |
Wireless Networks and the CDE
Wireless networks must be separated from the CDE unless they are part of the CDE. If CDE wireless exists, it must be secured with WPA3 (or WPA2 with specific configurations). Rogue wireless access point detection is required under Requirement 11.
| NSC Control | Requirement | Common QSA Finding |
|---|---|---|
| CDE firewall ruleset | All rules documented with business justification | Undocumented rules, overly permissive rules remaining from old projects |
| Outbound traffic filtering | CDE systems must not initiate unrestricted outbound connections | No outbound filtering — CDE systems can reach any internet destination |
| DMZ architecture | Required for any CDE-adjacent internet-facing system | Flat network — no DMZ between internet-facing and CDE systems |
| Rule review | Every 6 months | No documented review history, or review older than 6 months |
| Network diagrams | Current, complete, reviewed annually | Diagrams outdated or missing connections |
Requirement 2 — Secure Configurations
Requirement 2 addresses the secure configuration of all system components — servers, workstations, network devices, database systems, and any other technology in the CDE. Default configurations from vendors are almost always insecure — default passwords, unnecessary services enabled, open ports, sample applications installed.
Vendor Defaults Must Be Changed
Before any system component enters the CDE: change all vendor-supplied default credentials, remove or disable all default accounts that are not needed, disable all unnecessary services, protocols, and ports. This applies to every system type — operating systems, network devices, databases, applications, and cloud services.
System Hardening Standards
Each system component type must have a documented hardening standard. PCI DSS recommends using industry-accepted hardening standards from organizations such as the Center for Internet Security (CIS), NIST, and vendor security guides. The hardening standard must be applied consistently to all new systems before they enter the CDE.
| IMPORTANT | System hardening standards are not optional documentation — they are tested by QSAs. Assessors will select a sample of systems and verify that configurations match the hardening standard. Systems that have drifted from the standard — which is extremely common in active environments — must be brought back into compliance before assessment. |
Wireless Considerations
For wireless technology in the CDE: all wireless default keys, passwords, and security parameters must be changed at installation. Wireless encryption must meet or exceed WPA3.
Non-Console Admin Access
All non-console administrative access to system components in the CDE must use strong cryptography. SSH for Linux systems, RDP over TLS for Windows, or HTTPS for web-based administration. Telnet, rlogin, and unencrypted protocols are prohibited.
| System Type | Key Hardening Requirements | CIS Benchmark |
|---|---|---|
| Windows Server | Disable SMBv1, enforce NTLMv2, disable unused services, local admin accounts | CIS Microsoft Windows Server 2019/2022 |
| Linux/Ubuntu | Disable root SSH login, enforce SSH key auth, disable unused daemons, UFW rules | CIS Ubuntu Linux Benchmark |
| Network Devices | Change default credentials, disable CDP/LLDP where not needed, disable telnet | CIS Cisco IOS Benchmark |
| Database Servers | Remove sample schemas, restrict network access to app servers only, audit logging | CIS Oracle/MySQL/PostgreSQL Benchmarks |
| Cloud Instances | Disable password auth for SSH, security group restrictions, IMDSv2 enforcement (AWS) | CIS AWS Foundations Benchmark |
| In PCI DSS gap assessments of Indonesian fintech organizations, Requirement 2 failures are among the most common findings. Cloud instances deployed from marketplace images often retain default configurations, and development practices that prioritize speed over security hardening leave CDE systems with unnecessary exposed services, default credentials in configurations, and missing hardening standards documentation. |