PCI DSS Requirement 2 Guide: Hardening Standards, Vendor Defaults and Admin Encryption

Most card data compromises start with something that was never configured properly: a default password left on a device, a service nobody needed, or an admin interface reachable in clear text. PCI DSS v4.0.1 Requirement 2, "Apply Secure Configurations to All System Components", exists to close those gaps before a system ever touches the cardholder data environment (CDE). This guide works through 2.1 to 2.3 sub-requirement by sub-requirement: configuration standards, vendor default accounts, primary functions, unnecessary and insecure services, security parameters, encrypted administrative access and wireless defaults. It is written for platform engineers, infrastructure leads and PCI programme owners who must produce configuration evidence for a Qualified Security Assessor (QSA) or a self-assessment. Requirement text is paraphrased from the standard and from secondary sources that reproduce it; check every point against the current standard in the PCI SSC Document Library before relying on it.

Source note: requirement wording is paraphrased from PCI DSS v4.0.1 as reproduced by secondary sources (the ComplianceAsCode PCI DSS v4 control file and Microsoft Learn) and from PCI SSC publications, because the standard itself is a PDF in the PCI SSC Document Library. Confirm against the official text before relying on it.

Key takeaways

• Configuration standards are the core artefact: 2.2.1 expects documented standards that cover all system components, address known vulnerabilities, follow industry hardening standards or vendor recommendations, and are applied before or immediately after a system joins production.
• Default accounts have two acceptable outcomes: under 2.2.2 a vendor default account is either used with its default password changed in line with 8.3.6, or it is removed or disabled.
• One function per server is not mandatory: 2.2.3 allows one primary function per component, isolation of functions with different security levels, or securing everything on the component to the highest level needed.
• Insecure protocols need a written case: 2.2.4 removes what is not needed and 2.2.5 requires documented business justification plus compensating security features for any insecure service, protocol or daemon that remains.
• Admin access must be encrypted: 2.2.7 requires all non-console administrative access to use strong cryptography, which rules out Telnet, plain HTTP management pages and unencrypted SNMP for administration.

How Requirement 2 is structured

Requirement 2 has three sections and eleven sub-requirements. It sits alongside network security controls (Requirement 1) and vulnerability management (Requirement 6), and the wider standard is summarised in the PCI DSS 4.0 Guide. Version 4.0.1, published in June 2024, added or deleted no requirements according to the PCI SSC announcement.

2.2.1: building configuration standards that hold up

2.2.1 lists five properties. As reproduced in Microsoft's PCI DSS mapping for Entra ID, the standards must cover all system components, address all known security vulnerabilities, be consistent with industry-accepted hardening standards or vendor hardening recommendations, be updated as new vulnerability issues are identified (as defined in 6.3.1), and be applied when new systems are configured and verified as in place before or immediately after a component is connected to production.

• Start from a published baseline: CIS Benchmarks are consensus configuration recommendations covering many vendor product families; vendor guides such as Microsoft security baselines and DISA STIGs serve the same purpose. Pick one source per platform and record the version. See the CIS Benchmarks Guide and the Microsoft Security Baselines and Security Compliance Toolkit Guide.
• Write down your deviations: a QSA will not accept "we use the CIS Benchmark" if a third of the recommendations are disabled without explanation. Keep a tailoring record per platform: setting, baseline value, your value, reason, approver.
• Cover every component type: operating systems, databases, web and application servers, hypervisors, container hosts and images, network devices, cloud services, payment terminals' management consoles, and security tools themselves. The last category is frequently forgotten.
• Link to vulnerability intake: when 6.3.1 identifies a new vulnerability that a configuration change mitigates (for example disabling a protocol), the standard is updated, not just the affected host.
• Enforce at build: apply the standard in the golden image, infrastructure-as-code module or configuration management role so a new system is compliant at first boot. See the Server Build and Golden Image Hardening Guide.

NIST SP 800-128, the guide for security-focused configuration management, describes the same lifecycle of establishing baselines, controlling change and monitoring drift, and is a useful model for the procedure documents 2.1.1 asks for.

2.2.2: vendor default accounts

2.2.2 gives two options. If a vendor default account will be used, its default password is changed in line with 8.3.6 (the password construction requirement). If it will not be used, it is removed or disabled. Default accounts are a well-known initial access route: MITRE ATT&CK tracks this as T1078.001 Default Accounts.

The requirement applies to application and system accounts as much as to human ones. Breaches that ran on default credentials are still reported: the JADEPUFFER agentic ransomware case used harvested and default credentials to reach a production database, and the LiteLLM MCP auth bypass involved default master keys on an AI gateway.

Where identity fits

Many default accounts are non-human identities: a database's built-in superuser that an application connects as, a vendor service account installed with a fixed password, an API key shipped in a sample configuration file. Changing the password once at installation meets the letter of 2.2.2 but leaves a shared, long-lived secret. Bring these accounts under Requirement 8.6 controls (no interactive use, credentials protected and rotated). See the PCI DSS Requirements for Service Accounts and NHIs Guide and the PCI DSS Requirement 8 Guide.

2.2.3 to 2.2.6: functions, services and parameters

2.2.3 primary functions: the standard accepts three models. Only one primary function per system component; or functions with differing security levels on the same component isolated from each other; or all functions on the component secured to the level required by the most sensitive one. In practice, virtual machines and containers make the first model cheap; where a shared host is unavoidable (a small merchant's single server running web and database), the third model applies and the database's security needs set the bar for the web tier.

2.2.4 necessary functionality only: enable only the services, protocols, daemons and functions the component needs, and remove or disable the rest. Typical removals: unused web server modules, sample applications, file sharing on servers that do not share files, legacy name resolution protocols such as LLMNR and NetBIOS over TCP/IP where not needed, development tools on production hosts, and unused cloud service endpoints.

2.2.5 insecure services: where an insecure service, protocol or daemon must stay, document the business justification and implement additional security features that reduce the risk. Our recommendation is an exception register with an owner, an expiry date and the compensating measures (for example FTP retained for a legacy acquirer link but restricted to one source IP, wrapped in a VPN tunnel and monitored).

2.2.6 security parameters: system security parameters are configured to prevent misuse. These are the settings inside the component that the hardening standard specifies: password and lockout policies where the system handles them, audit policy, kernel parameters, TLS settings, session timeouts, database security options, and cloud resource policies such as blocking public access on storage.

2.2.7: encrypting non-console administrative access

2.2.7 requires all non-console administrative access to be encrypted using strong cryptography. Non-console means anything other than a directly attached keyboard and screen: SSH sessions, RDP, web admin consoles, cloud control plane APIs, database administration tools and remote management cards (iLO, iDRAC, IPMI).

• SSH: disable protocol version 1, password authentication where keys or certificates can be used, and weak key exchange and cipher algorithms. See the OpenSSH Server Hardening Guide.
• RDP: require Network Level Authentication and TLS, and reach CDE hosts only through a jump host or privileged access gateway.
• Web consoles and APIs: TLS 1.2 or later only. Microsoft states that Entra ID admin interfaces, Microsoft Graph and PowerShell are encrypted with TLS, and points tenants to its TLS 1.0 and 1.1 deprecation guidance; check the same for every SaaS and cloud console that administers the CDE.
• Out-of-band management: baseboard management controllers often ship with HTTP, old TLS and IPMI enabled. Put them on an isolated management network and apply the same rules.
• Strong cryptography in records: 12.3.3 requires the cipher suites and protocols in use to be documented and reviewed at least once every 12 months; that inventory is the natural evidence for 2.2.7.

2.3: wireless environments

2.3 applies to wireless environments connected to the CDE or transmitting account data. 2.3.1 requires all wireless vendor defaults to be changed at installation or confirmed secure, including default encryption keys, passwords on access points, SNMP defaults and any other security-related wireless defaults. 2.3.2 requires wireless encryption keys to be changed whenever someone with knowledge of the key leaves the company or the role that needed it, and whenever a key is suspected or known to be compromised.

The second requirement is the strongest argument against pre-shared keys in the CDE. With WPA2 or WPA3 Enterprise and 802.1X, each device or user has its own credential and a leaver is handled by revoking one certificate or account rather than rekeying every terminal. See the 802.1X and EAP-TLS Enterprise Wi-Fi Guide. Detecting unauthorised wireless access points is a separate requirement, 11.2.

Decision guidance

• CIS Benchmark, STIG or vendor baseline: CIS Benchmarks suit most commercial estates and have Level 1 and Level 2 profiles in their documents; STIGs are stricter and fit organisations already working to US government requirements; vendor baselines (for example Microsoft's) are easiest to deploy with the vendor's own tooling. Mixing sources across platforms is fine; mixing within one platform makes evidence hard.
• Image-based or agent-based enforcement: immutable images rebuilt on change (containers, autoscaling groups) prevent drift by design; long-lived servers need configuration management agents or desired state tooling plus drift scanning.
• Small merchants: on SAQ routes with only a few in-scope devices, a documented checklist per device type plus vendor hardening guides may be enough. Larger entities need automated compliance scanning to prove 2.2.1 across thousands of components.
• Exceptions versus redesign: if the 2.2.5 register keeps growing for the same legacy system, the cheaper long-term answer is usually to move it out of the CDE through segmentation. See the PCI DSS Scoping and Network Segmentation Guide.
• Customised approach: entities with mature configuration tooling can meet 2.2.x objectives with the customised approach, which needs a targeted risk analysis under 12.3.2. See the PCI DSS Customised Approach and Targeted Risk Analysis Guide.

How to implement Requirement 2

1. Inventory components: start from the 12.5.1 in-scope inventory and group components by platform and version. Every group needs a standard.
2. Select and tailor baselines: choose the baseline per platform, record deviations with reasons, and get the standard approved by the owner named under 2.1.2.
3. Assess current state in audit mode: run a configuration scanner against the standard without enforcing anything. Record the gap list per host.
4. Fix defaults and admin protocols first: default accounts (2.2.2) and clear-text admin access (2.2.7) carry the highest risk and are fastest to evidence.
5. Pilot enforcement: apply the standard to a pilot ring (non-production, then a small set of production hosts), watch for application breakage for an agreed period, and keep the prior configuration or image so changes can be rolled back.
6. Roll out by ring and build it in: extend enforcement in waves, and update images and infrastructure-as-code so new systems are compliant before connection to production.
7. Run the exception process: anything that cannot meet the standard goes into the 2.2.5 register with justification, compensating controls and an expiry date.
8. Monitor drift: schedule recurring scans and alert on deviations; feed results into change management. See the Configuration Drift and Baseline Enforcement Guide.

Detection and measurement

Useful detections include logons by built-in or default account names, new listening ports on CDE hosts, SNMP requests using default community strings, and configuration changes made outside change windows. Configuration changes on CDE systems should also appear in Requirement 10 logs; see the PCI DSS Requirement 10 Guide.

Framework mapping

In ISO/IEC 27001:2022 Annex A, Requirement 2 aligns most closely with control 8.9 Configuration management. See the PCI DSS 4.0 to ISO 27001 Mapping Guide.

Common failure patterns

• Standard exists, nobody applied it: a hardening document sits in a wiki while images are built from an older template; scan results tell a different story from the policy.
• Security tools left out: SIEM servers, PAM vaults, backup consoles and EDR management servers run with default admin accounts or HTTP consoles because they are "security", not "production".
• Default passwords changed once, then shared: the vendor account password was changed at installation but is now known to every engineer and embedded in scripts, which defeats 2.2.2 in practice and fails 8.6.
• Management plane forgotten: iLO, iDRAC and switch management interfaces on the CDE network still accept HTTP or Telnet.
• Unexpiring exceptions: 2.2.5 justifications written years ago for systems whose business case has gone.
• Wireless PSK never rotated: a single shared key used by store terminals for years despite staff turnover, contrary to 2.3.2.

Practitioner checklist

• Publish an approved configuration standard for every in-scope platform, with baseline source, version and deviation record (2.2.1).
• Verify new systems against the standard before or immediately after production connection.
• Inventory vendor default accounts on every component and disable, remove or re-credential each one (2.2.2).
• Document how each component meets one of the three 2.2.3 primary function models.
• Compare listening services and ports with the standard and remove the rest (2.2.4).
• Keep a 2.2.5 exception register with justification, compensating controls, owner and expiry.
• Prove that all non-console admin access uses strong cryptography, including out-of-band management (2.2.7).
• Change wireless defaults at installation and tie wireless key changes to leaver events (2.3).
• Scan for configuration drift on a schedule and route findings into change management.

Standards and references

• PCI SSC: Document Library (PCI DSS v4.0.1)
• PCI SSC: Just Published, PCI DSS v4.0.1
• Microsoft Learn: Microsoft Entra ID and PCI DSS Requirement 2
• NIST: SP 800-128 Guide for Security-Focused Configuration Management of Information Systems
• CIS: CIS Benchmarks
• MITRE ATT&CK: T1078.001 Default Accounts
• NIST: SP 800-53 Rev. 5 Security and Privacy Controls
• NIST: Cybersecurity Framework 2.0

Related NHI Mgmt Group resources: PCI DSS 4.0 Guide, PCI DSS Readiness Checklist, CIS Benchmarks Guide, Endpoint Hardening Checklist, PCI DSS Requirement 5 Guide. This guide summarises PCI DSS v4.0.1 Requirement 2 and is not legal or assessment advice.