We use essential cookies to run this site. Analytics & marketing cookies load only with your consent — see our Cookie Policy and Privacy Policy.

Talk to an expert
PCI DSS v4.0.1 · Requirement 2 of 12

Requirement 2: Apply Secure Configurations to All System Components

Requirement 2 is the hardening requirement: vendor defaults die here. The assessor compares your running configurations against your own hardening standard — so the standard must exist, map to an accepted benchmark, and actually be applied.

Reviewed by Abhay Singh, PCI SSC-qualified QSA professional · CyberSigma is a PCI SSC-listed QSA company · Part of the Requirement 1–12 series

The controls that decide your assessment

2.2.1
Configuration standards for all component types

Documented hardening standards covering every system type in scope, consistent with industry benchmarks (CIS, vendor guides) and kept current as vulnerabilities emerge.

2.2.2
Vendor default accounts changed or removed

Default accounts and passwords are changed, disabled or removed before deployment — on servers, network devices, POS terminals, HSMs and appliances alike.

2.2.4
Only necessary services, protocols and daemons

Everything not required for the component’s function is removed or disabled — the control behind "reduce the attack surface".

2.2.5
Insecure services documented and mitigated

Where an insecure service must run, the business justification and additional mitigations are documented.

2.2.7
Non-console admin access encrypted

All non-console administrative access uses strong cryptography — SSH and HTTPS, never telnet or plain HTTP, including appliance web consoles.

2.3.1
Wireless defaults changed

Wireless environments connected to the CDE change all wireless vendor defaults — keys, SNMP strings, passwords, firmware defaults.

Control numbers reference PCI DSS v4.0.1 (June 2024). Verify wording against the standard itself — PCI SSC document library.

Where programmes actually fail

A hardening "policy" but no benchmark mapping

A one-page policy saying "systems shall be hardened" fails 2.2.1. The standard must specify settings per platform, traceable to CIS or vendor baselines.

Defaults surviving on appliances and POS devices

Servers get hardened; the HSM, printer, POS terminal or load balancer keeps admin/admin. Requirement 2 applies to every system component in scope.

Default SNMP community strings

"public/private" strings on network devices are a classic 2.2.2 finding that internal vulnerability scans should have caught quarters earlier.

Telnet or HTTP management "temporarily" enabled

2.2.7 has no temporary exception — unencrypted admin channels are findings the day the assessor sees them.

Evidence a QSA accepts

A policy document proves intent; configuration proves control. Bring these to the assessment:

  • Hardening standards per platform with benchmark references and review dates
  • Configuration exports or benchmark-scan results demonstrating application
  • Account listings showing vendor defaults removed or disabled
  • Service/port inventories per component type against documented necessity
  • Wireless configuration showing all defaults changed

Requirement 2 FAQ

Do we have to use CIS Benchmarks?

No specific benchmark is mandated — 2.2.1 requires standards consistent with industry-accepted hardening sources, and CIS or vendor security guides are the accepted route in practice.

Does Requirement 2 apply to cloud PaaS services?

Yes, to the configuration surface you control: platform hardening options, exposed services, default credentials in managed services, and administrative access channels.

One system, multiple functions — allowed?

Primary functions with different security levels on one system must be isolated or all secured to the level of the highest-risk function (2.2.3).

← Requirement 1: Network Security ControlsRequirement 3: Protect Stored Data →

Requirement 2 in your environment

A PCI SSC-listed QSA firm can tell you in one session whether your controls will survive assessment — before the assessment.