Requirement 2: Apply Secure Configurations to All System Components
PCI DSS v4.0.1 Requirement 2 in plain English: removing vendor defaults, hardening system components, and the wireless controls people forget.
PCIComplianceHubLast updated Last reviewed against PCI DSS v4.0.1
Requirement 2 exists because attackers do not need an exploit when a default password still works. Default passwords and vendor settings are well known and easy to find in public information.
PCI DSS v4.0.1 breaks this requirement into 3 sections containing 11 individual controls.
What this requirement is actually asking
Vendor defaults means more than passwords: default SNMP community strings, default certificates, default accounts, and sample applications all count. The obligation is to change them, or remove or disable what will not be used, and to verify the configuration standard is in place before or immediately after a system connects to production (2.2.1).
2.2 is where the work is. Configuration standards for every component type, applied consistently and derived from recognised hardening guidance. "We follow CIS benchmarks" is a claim; the evidence is the standard document plus a build that demonstrably matches it.
Does it apply to you?
Every system component in scope, not only servers: hypervisors, containers, network devices and cloud services all count.
The controls
Requirement 2 contains 11 controls across 3 sections. Each links to its own page with the requirement in full and the testing procedures an assessor uses to verify it.
2.1: Governance: who owns configuration standards and keeps them current
| Control | What it requires | Guidance |
|---|---|---|
| 2.1.1 | All security policies and operational procedures that are identified in Requirement 2… | Yes |
| 2.1.2 | Roles and responsibilities for performing activities in Requirement 2 are documented, assigned… | Yes |
2.2: Configuration standards per component type, verified before or immediately after a system goes live
| Control | What it requires | Guidance |
|---|---|---|
| 2.2.1 | Configuration standards are developed, implemented, and maintained… | Yes |
| 2.2.2 | Vendor default accounts… | Yes |
| 2.2.3 | Primary functions requiring different security levels… | Yes |
| 2.2.4 | Only necessary services, protocols, daemons, and functions are enabled… | Yes |
| 2.2.5 | If any insecure services, protocols, or daemons are present… | Yes |
| 2.2.6 | System security parameters are configured to prevent misuse | Yes |
| 2.2.7 | All non-console administrative access is encrypted using strong cryptography | Yes |
2.3: Wireless: defaults changed, and encryption keys rotated when staff leave
| Control | What it requires | Guidance |
|---|---|---|
| 2.3.1 | For wireless environments connected to the CDE or transmitting account data, all wireless vendor defaults are changed at installation or are confirmed to be secure, including but not limited… | Yes |
| 2.3.2 | For wireless environments connected to the CDE or transmitting account data, wireless encryption keys are changed… | Yes |
Evidence your assessor will ask for
- Written configuration standards per component type, referencing the industry benchmark they derive from
- A build or image showing the standard applied, with any deviation documented and justified
- An inventory showing every in-scope component maps to a standard
- For wireless: evidence that defaults were changed and keys rotated on personnel change
Where this commonly fails
- Hardening the base image but not the containers or cloud services built on it
- Standards that cite a CIS benchmark version that is several years out of date
- Forgetting that 2.2.3 applies to virtual components too. Functions with different security levels that share a component must be isolated from each other or all secured to the level of the most sensitive, and whichever route is used must be demonstrable
Terms
Glossary entries that name a control in this requirement:
- Administrative Access: 2.2.7
- Bluetooth: 2.2.4
- Console: 2.2.7
- Default Account: 2.2.2
- Default Password: 2.2.2, 2.3.1
- Encryption: 2.2.7
- Encryption Key: 2.3.1, 2.3.2
- File Transfer Protocol (FTP): 2.2.4
- Non-console Access: 2.2.7
- Risk: 2.2.5
- SNMP (Simple Network Management Protocol): 2.2.2, 2.2.5, 2.3.1
- SSH (Secure Shell): 2.2.5, 2.2.7
- Strong Cryptography: 2.2.7
- System Component: 2.2.1
- Telnet: 2.2.4, 2.2.5, 2.2.7
- Virtualization: 2.2.3
- Vulnerability: 2.2.1
- Wireless Access Point (WAP): 2.3.1
- Wireless Local Area Network (WLAN): 2.3.1
Official source
The commentary on this page is our own. The requirement title, and the control text in the tables above (shortened where it ends in an ellipsis), are reproduced from PCI DSS v4.0.1 (June 2024), ©2006-2024 PCI Security Standards Council, LLC. All rights reserved. Each control's own page carries its requirement text in full. For the authoritative wording, including each testing procedure and the customized approach objective, download the standard from the PCI Security Standards Council document library.
PCI DSS is a registered standard of the PCI Security Standards Council, LLC, which does not endorse this site.