PCI DSS Requirement 2: secure configurations
By Sam Rivera, Founder, SentinelPanda · August 6, 2026 · 2 min read · PCI DSS
Every default password shipped by a vendor is public knowledge. Requirement 2 starts there and ends up somewhere more useful: a configuration standard you can actually audit against.
Beyond the default password
The original framing of this requirement was about vendor-supplied defaults, and that part remains: default accounts and passwords must be changed or disabled before a system goes live (2.2.2), and unnecessary default accounts removed. Vendor default credentials are published in manuals and scanned for constantly — this is the lowest-effort compromise available to an attacker.
v4.0 reframed the requirement around secure configuration more broadly. The question is no longer "did you change the password" but "do you have a configuration standard, is it based on something defensible, and can you show systems match it".
Hardening standards
Requirement 2.2.1 expects configuration standards covering all system component types, addressing known vulnerabilities and consistent with industry-accepted hardening standards. In practice that means CIS Benchmarks, NIST checklists, or vendor hardening guides — you do not have to write them from first principles, and you should not.
What you do have to do is document which standard applies to which component type, record any deviations with justification, and be able to demonstrate that deployed systems actually match. A hardening standard nobody measures against is a document, not a control.
What the standard must cover
- Only necessary services, protocols, daemons, and functions enabled (2.2.4) — everything else disabled or removed.
- Insecure services and protocols either removed or their use justified with additional security features documented.
- System security parameters configured to prevent misuse (2.2.6).
- All non-console administrative access encrypted using strong cryptography (2.2.7).
- Primary functions with differing security levels isolated from one another (2.2.3) — the modern successor to "one primary function per server", satisfied by virtualisation or containerisation with proper isolation.
Wireless and inventory
Requirement 2.3 handles wireless specifically: default encryption keys, passphrases, and SNMP community strings changed on installation and whenever anyone with knowledge of them leaves. Wireless environments connected to the CDE are a recurring weak point because they are often installed by facilities rather than IT.
Underpinning all of it is the system component inventory. You cannot apply a hardening standard to a server you have forgotten, and cloud environments make forgetting easy — an instance spun up for a migration and never decommissioned is both in scope and unhardened. Inventory accuracy is the quiet prerequisite for most of PCI DSS, not just this requirement.