Apply secure configurations
Requirement 2 requires organizations to remove all default passwords and insecure settings from system components before they are deployed. It mandates the application of hardening standards to minimize the attack surface across the entire Cardholder Data Environment (CDE).
What it means
The core intent is "hardening." Out-of-the-box configurations are designed for ease of use and compatibility, not security; they often include default accounts, unnecessary services, and open ports that attackers can easily exploit.
This applies to every component in the CDE, including servers, workstations, network devices (firewalls/switches), databases, and cloud instances. If a system touches cardholder data or impacts the security of that data, it must be hardened according to a defined standard.
Implementation involves moving from a "default" state to a "known secure" state based on industry benchmarks or internal policies. The goal is to ensure that only necessary functions are enabled and all unnecessary risks are eliminated.
How to meet it
- Change all vendor-supplied default passwords and usernames for every system component before they are placed into production.
- Develop formal hardening standards for each system type (e.g., Windows, Linux, Cisco IOS) based on industry benchmarks such as CIS (Center for Internet Security) or NIST guidelines.
- Disable or remove unnecessary services, protocols, daemons, and ports to reduce the available attack surface.
- Implement "least functionality" by ensuring only required software and features are installed and active.
- Document a clear business justification for any necessary deviations from hardening standards (e.g., why a specific insecure port must remain open).
- Use automation tools or gold images to apply configurations consistently across the environment and prevent configuration drift.
Evidence an auditor asks for
- Hardening standard documents outlining the secure baseline requirements for each system type in scope.
- Configuration files, screenshots, or reports showing that default passwords have been changed and unnecessary services are disabled.
- An inventory of all system components to ensure no "shadow IT" devices bypassed the hardening process.
- Change management records proving that configuration changes were authorized and tested before being applied to production.
Common pitfalls
- Relying on cloud provider defaults without verifying if additional hardening is required at the OS or application level.
- Failing to document why a specific insecure setting was kept for business reasons, which auditors view as an unexcused vulnerability.
- Hardening systems during initial deployment but failing to maintain those configurations over time, leading to "configuration drift."