Requirement 2: Apply Secure Configurations to All System Components

Requirement 2 exists because attackers do not need an exploit when a default password still works. It is the least glamorous requirement and one of the most frequently failed.

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 or remove them before a system reaches production.

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, applied before 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 "one primary function per server" is satisfied differently under virtualisation. The isolation must be demonstrable

Official source

This page is original commentary. It cites requirement identifiers and the official requirement title, and does not reproduce the text of the standard. For the authoritative wording, including each testing procedure and the customized approach objective, download PCI DSS v4.0.1 (June 2024) 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.