PCI DSS Requirement 2 Explained: Secure Configurations

TL;DR

PCI DSS Requirement 2 covers every system component in or connected to the cardholder data environment, and it splits into three parts: documented processes (2.1), securely configured components (2.2, with seven sub-controls), and secured wireless environments (2.3, with two sub-controls).
Adopting CIS Benchmarks, NIST guidance, or DISA STIGs is a starting point, not the finish line. PCI DSS 2.2.1 requires an organization’s own documented, verified, continuously updated configuration standard, informed by those sources rather than replaced by them.
The requirement extends fully to virtual machines, cloud accounts, and containers under a shared responsibility model, and assessors expect specific evidence: documented standards, sampled configuration exports, and proof each control was verified before a system reached production.

PCI DSS Requirement 2 requires organizations to apply secure, documented configurations to every system component that stores, processes, or transmits cardholder data, plus any component connected to that environment or capable of affecting its security. Under the PCI SSC’s own definition, “system component” is a wide net: network devices, servers, computing devices, virtual components, cloud infrastructure, and software, including custom and third-party applications. Scope is not limited to servers that touch cardholder data directly; a jump box, a management workstation, or a logging server that could affect the security of the cardholder data environment (CDE) also falls under Requirement 2.

The requirement sits inside the “Build and Maintain a Secure Network and Systems” control objective, directly after Requirement 1, which governs firewalls and network segmentation. Under the official PCI DSS standard, Requirement 2 organizes into three parts: 2.1 covers documented processes, 2.2 covers how components are configured and managed day to day (across seven sub-requirements), and 2.3 covers wireless-specific controls. For merchants and service providers working through a PCI DSS compliance program, all of these controls became mandatory on March 31, 2025, when the transition period from PCI DSS v4.0 fully closed.

How Did Requirement 2 Change From v3.2.1 to v4.0.1?

Requirement 2 evolved from a narrow rule about vendor-supplied passwords into a structured set of controls covering every system component, including virtual, cloud, and containerized infrastructure. PCI DSS v3.2.1 framed the requirement narrowly, focused on removing vendor defaults. PCI DSS v4.0 renamed it “Apply Secure Configurations to All System Components,” broke it into the 2.1 through 2.3.2 structure used today, and widened the scope well beyond passwords to explicitly include firmware, virtual machines, cloud instances, and containerized workloads.

The restructuring also clarified ownership. Where v3.2.1 bundled process and technical controls together, v4.0.1 separates documented processes (2.1) from the technical controls themselves (2.2, 2.3), which gives assessors a cleaner way to test governance and implementation independently. Most of what is now 2.2.7, encrypted non-console administrative access, existed under a different requirement number in v3.2.1; it moved into Requirement 2 as part of this restructuring rather than appearing as an entirely new control.

What Do All of PCI DSS Requirement 2’s Sub-Requirements Cover?

PCI DSS Requirement 2 contains eleven testable sub-requirements across its three sections. The table below summarizes what each one asks for, in plain language rather than the standard’s exact wording.

Sub-requirement	What it asks for
2.1.1	Documented, current policies and procedures for every control in Requirement 2, known to the people who carry them out
2.1.2	Clear, assigned ownership for who performs and maintains each Requirement 2 activity
2.2.1	A documented configuration standard covering every system component, built from recognized hardening guidance, updated as new vulnerabilities emerge, and verified in place before or immediately after a system reaches production
2.2.2	Vendor default accounts are either removed or have their passwords changed before use
2.2.3	Components with different security levels, such as a public-facing web server and a database holding cardholder data, are isolated from each other, limited to one primary function, or all secured to the highest level needed
2.2.4	Only the services, protocols, and functions a system needs to run stay enabled; everything else is removed or disabled
2.2.5	Any insecure service, protocol, or daemon kept for business reasons gets a documented justification plus compensating security controls
2.2.6	System-level security parameters, such as session timeouts and account lockout thresholds, are configured to prevent misuse
2.2.7	All administrative access that does not happen at the physical console is encrypted with strong cryptography
2.3.1	Wireless equipment connected to the CDE, or carrying account data, has every vendor default changed at installation or confirmed already secure
2.3.2	Wireless encryption keys get rotated whenever someone who knew the key changes roles or leaves, or the key is suspected of compromise

A few of these deserve more than a table row.

2.2.5, insecure protocols, is a documentation control as much as a technical one

Protocols such as Telnet, FTP, SNMPv1 and v2c, and SMBv1 lack the authenticity, integrity, or confidentiality PCI DSS expects. If a legacy application still depends on one of them, Requirement 2 does not automatically fail the organization; it requires a documented business justification and additional controls, such as network isolation or enhanced monitoring, that reduce the exposure the insecure protocol creates. An assessor testing this control looks for the justification and the compensating measure together, not just the fact that an exception exists.

2.2.6, security parameters, covers the settings that decide whether a properly patched, properly authenticated system can still be misused

This includes session timeout values, account lockout thresholds, and the removal of unnecessary sample files, default scripts, or test accounts that ship with many applications and operating systems.

2.2.7, encrypted non-console administrative access, applies to any admin session that is not physically at the machine

Which in a modern environment is nearly every session: SSH to a server, a cloud provider’s web console, an RDP session to a jump box. Strong cryptography here means current, unexpired TLS or SSH configurations, not legacy protocol versions kept on for compatibility.

2.3.1 and 2.3.2 together close the two most common wireless gaps: defaults left in place, and keys that outlive the people who knew them

A departing employee who once had the Wi-Fi passphrase for a store network is a live risk until that key rotates, regardless of how well the access point was configured on day one.

Do CIS Benchmarks, NIST, or STIGs Automatically Satisfy PCI DSS Requirement 2?

No single external hardening standard automatically satisfies PCI DSS Requirement 2 on its own. What 2.2.1 requires is an organization’s own documented configuration standard, one that covers every system component, addresses known vulnerabilities, and stays consistent with an industry-accepted source such as the CIS Benchmarks, NIST’s National Checklist Program, SANS guidance, or vendor-published hardening recommendations. The benchmark informs the standard; it does not replace the requirement to document, apply, and verify that standard across the environment.

This distinction matters at audit time. An organization that can only say “we follow CIS Benchmarks” has not yet produced evidence for 2.2.1. An organization that can show its own written configuration standard, referencing CIS or NIST for the technical baseline, applied consistently across sampled systems, and updated when new vulnerabilities surface, has. CISA’s Cross-Sector Cybersecurity Performance Goals make a similar point for critical infrastructure operators more broadly: changing default credentials and hardening configurations are treated as baseline practices, not a checkbox exercise completed once and left alone. Ampcus Cyber’s Configuration Management & Hardening service is built around that gap, turning a chosen benchmark into a documented, testable, audit-ready standard rather than a PDF sitting in a shared drive.

How Does PCI DSS Requirement 2 Apply to Cloud, Containers, Kubernetes, and IaC?

PCI DSS Requirement 2 applies to cloud instances, virtual machines, and containers under the same expectations as physical servers, filtered through the shared responsibility model that governs cloud infrastructure. A cloud provider typically secures the physical hardware, hypervisor, and underlying network; the organization remains responsible for the configuration of everything built on top of it, including identity and access permissions, storage bucket settings, security groups, container images, and orchestration layers such as Kubernetes. A misconfigured storage bucket, an overly permissive IAM role, or a container image built from an unpatched base layer can all violate Requirement 2 even though no one touched a physical server.

Kubernetes and container environments introduce their own hardening surface: the CIS Kubernetes Benchmark and the OWASP Kubernetes Security Cheat Sheet both describe controls that map directly onto 2.2.1 through 2.2.6: least-privilege RBAC configuration, network policies that restrict pod-to-pod traffic, Pod Security Standards or admission controllers that block unhardened workloads from deploying, image scanning before deployment, and secrets management that avoids storing credentials in plain environment variables. For teams managing infrastructure through code, the practical path is building hardening into the pipeline itself: golden images, hardened base containers, and policy-as-code checks that block a deployment before an unhardened resource ever reaches production, rather than trying to harden resources after they already exist. Configuration drift is a particular risk in autoscaling and ephemeral environments, since a hardened image can still spawn drifted instances if the pipeline that builds it is not itself controlled and versioned.

What Evidence Do PCI DSS Assessors Expect for Requirement 2?

PCI DSS assessors test Requirement 2 the same way they test any other requirement: through examination of documentation, interviews with responsible staff, and observation of systems in place, applied to a representative sample of in-scope components rather than every single asset. For Requirement 2 specifically, that typically means:

The written configuration standard itself (2.2.1), including evidence it references a recognized hardening source and has been updated within a defined cycle.
Configuration exports, screenshots, or scan output from sampled systems showing default accounts removed or disabled (2.2.2), unnecessary services disabled (2.2.4), and security parameters set as documented (2.2.6).
Documented business justifications and compensating controls for any insecure protocol still in use (2.2.5).
Evidence that administrative sessions are encrypted, such as SSH or TLS configuration exports and a list of remote administration tools in use (2.2.7).
Build or provisioning records showing a system was hardened before, or immediately after, it connected to the production network, which is often the hardest piece of evidence to produce after the fact if it was not captured at build time.
For wireless, configuration exports showing vendor defaults changed and a record of key rotation tied to personnel changes (2.3.1, 2.3.2).

Assessors sample by system type rather than checking every server individually, so an inconsistent hardening process across a fleet of otherwise identical systems is more likely to surface as a finding than a single unusual exception. Organizations preparing for assessment benefit from treating “can we produce this evidence today, for a system picked at random” as the real test, rather than treating the documented standard alone as sufficient.

What Are Common Gaps Organizations Encounter With PCI DSS Requirement 2?

Requirement 2 has historically been one of the harder controls to sustain, not just to implement once. In Verizon’s Payment Security Report analysis of full compliance by individual PCI DSS requirement, Requirement 2 sat at 70.5% full compliance, tied with Requirement 6 as the second-lowest of the twelve requirements measured that year, behind only Requirement 11. That figure reflects Verizon’s Payment Security Report data from assessed organizations in 2020, so it should be read as evidence of a persistent, longer-running pattern rather than a current-year statistic, particularly since PCI DSS v4.0.1’s restructuring of Requirement 2 postdates that data.

A few specific gap patterns are commonly discussed in QSA assessment writeups and vendor breach research, without a single definitive industry ranking of which is most frequent:

Default administrative credentials left active on a newly provisioned server or database, the pattern in this article’s opening scenario, is one of the most commonly cited findings because it is both easy to introduce under deadline pressure and trivial for an attacker to exploit once found.
Insecure legacy protocols such as FTP, Telnet, or SNMPv1 remaining enabled because an older application still depends on them, often without the documented justification 2.2.5 requires.
Configuration standards that exist as a document but were never verified against the live system before it reached production, which is a 2.2.1 gap that only surfaces once an assessor asks for build-time evidence.
Merchants assuming a point-of-sale installer or managed service provider has already hardened a system, when contractual responsibility for that hardening still sits with the merchant unless the agreement states otherwise.
Wireless encryption keys that never rotate after an employee with access leaves the organization, a 2.3.2 gap that tends to go unnoticed until an assessment specifically asks for rotation records.

Configuration drift is the quieter version of all of these. A system can pass its hardening review on day one, then slowly accumulate new ports, services, and accounts over months of routine changes that never get checked against the original baseline. Closing that gap calls for structured vulnerability remediation guidance paired with a recurring configuration review cycle, not a single point-in-time fix.

How Should Security Teams Operationalize PCI DSS Requirement 2 Long Term?

Sustainable compliance with Requirement 2 depends on treating secure configuration as a continuous control rather than a pre-audit checklist. That starts with a current inventory of every in-scope system component, including cloud resources that spin up and down automatically, a documented hardening standard referencing a recognized source, automated configuration checks where feasible, and a change management process that flags deviation from baseline before it becomes an audit finding rather than after.

Building this discipline also depends on people. Teams that complete structured payment security training, such as Ampcus Cyber’s CPSCM workshop, tend to catch configuration gaps earlier because they understand why each control exists rather than treating it as a box to check. The urgency has grown, not eased: Verizon’s 2026 Data Breach Investigations Report found that vulnerability exploitation overtook stolen credentials as the leading initial access vector for the first time in the report’s history, present in 31% of breaches, while only 26% of critical vulnerabilities were fully remediated within the year and the median time to resolution stretched to 43 days. Unpatched, default-configured systems remain among the easiest entry points attackers find, and Requirement 2 is the control built specifically to close that gap before it opens.

Closing

PCI DSS Requirement 2 turns a familiar idea, do not leave the factory settings on, into eleven testable controls spanning passwords, protocols, wireless networks, and modern cloud infrastructure. Organizations that document their own configuration standard, verify it before systems reach production, and keep it current tend to walk into assessments with fewer surprises and a measurably smaller attack surface.

Talk to an Ampcus Cyber compliance specialist about building a secure configuration program that holds up under audit and under attack.