PCI DSS: Requirement 2 – Explained
PCI DSS (Payment Card Industry Data Security Standard) is a set of security standards designed to ensure that all companies that process, store, or transmit credit card information maintain a secure environment. This article focuses on Requirement 2 of PCI DSS v4.0.1, covering what it entails, how it has evolved from v3.2.1, and what your organisation needs to do to stay compliant.
For more on PCI DSS, see our Ultimate Guide.
What is PCI DSS Requirement 2?
Requirement 2: Apply secure configurations to all system components.
At its core, Requirement 2 mandates the removal of default settings and the implementation of secure configurations across all components within your cardholder data environment (CDE), including firewalls, routers, web servers, and cloud-based systems. Attackers often exploit default settings, such as factory-provided passwords, open ports, and vendor-supplied accounts.
By enforcing secure configurations, Requirement 2 aims to eliminate these vulnerabilities.
Why is Requirement 2 Important?
Secure configurations serve as a critical defence against opportunistic attacks. Out-of-the-box system installations are typically not secure, as vendors may include unnecessary services or leave default credentials in place for ease of setup. These default settings can introduce significant risks if not addressed. Standardising system hardening and maintenance reduces your organisation’s attack surface and makes it more challenging for attackers to exploit basic misconfigurations.
Key Changes in PCI DSS v4.0.1 for Requirement 2
In PCI DSS v3.2.1, Requirement 2 focused on avoiding vendor-supplied defaults for system passwords and other security parameters. While this remains crucial, v4.0.1 expands the requirement to encompass secure configurations more broadly. Notable enhancements include:
- Consistent use of secure baseline configurations.
- Improved documentation and version control of secure system builds.
- Regular reviews of configurations to maintain compliance.
- Baseline configurations applicable to both on-premise and cloud-based infrastructure
This evolution acknowledges the diverse configurations present in modern IT environments, including virtual machines, containers, and SaaS platforms, all requiring secure configuration.
A Breakdown of Requirement 2
2.1 Processes and mechanisms for applying secure configurations to all system components are defined and understood.
Organisations must ensure that all security policies and operational procedures relating to secure system configuration are properly defined, documented, maintained, and understood by all relevant personnel. These procedures must be kept up to date and in use across the organisation. Roles and responsibilities must also be clearly assigned and understood to avoid ambiguity or missed actions. This includes verifying that the right people are accountable for configuration-related tasks and are aware of their duties, supported by mechanisms such as responsibility assignment matrices. The goal is to establish clear governance and repeatable processes that ensure secure configurations are applied consistently and correctly throughout the environment.
2.2 System components are configured and managed securely.
System components must be configured using hardened, industry-accepted standards and best practices to minimise vulnerabilities. Configuration standards must be developed and applied to all components, covering known security weaknesses and being updated as new vulnerabilities emerge. This includes ensuring that systems are configured before entering production, with only essential services, protocols, and functionality enabled. Unnecessary elements must be disabled or removed to reduce the attack surface.
Vendor default accounts and passwords must either be changed or disabled entirely to prevent unauthorised access through commonly known credentials. Where system components serve multiple functions with different security requirements, these functions must either be separated, isolated, or secured to the highest required level to prevent lower-security functions from compromising more critical ones. This applies equally to physical and virtual environments, including containerised and cloud-hosted systems.
If insecure services, protocols, or daemons are present, such as outdated versions of TLS or legacy protocols like FTP, a clear business justification must be documented. Additional security features must also be implemented to mitigate the associated risks. Similarly, configuration settings must enforce secure parameter values that prevent misuse. These parameters, such as authentication settings or access controls, must be correctly set in accordance with documented standards and verified across all systems.
Non-console administrative access, such as remote logins or browser-based interfaces, must be encrypted using strong cryptography. This protects authentication credentials and administrative activity from being intercepted by attackers. The use of weak or fallback protocols must be avoided, and configurations must ensure only secure versions and methods are supported.
2.3 Wireless environments are configured and managed securely.
Wireless networks that are part of the CDE or that transmit account data must be securely configured. All wireless vendor defaults, including encryption keys, access point passwords, and SNMP community strings, must be changed at installation or otherwise confirmed to be secure. These settings must not remain in their default state, as doing so could allow attackers to intercept wireless traffic or gain unauthorised access.
Wireless encryption keys must be changed whenever someone with knowledge of them leaves the organisation or their role, or if the key is suspected of being compromised. This helps ensure that access remains limited to those with a valid business need and prevents unauthorised reuse of known credentials. Secure management of wireless settings is essential to prevent attackers from eavesdropping on sensitive data or infiltrating the network through wireless vectors.
Common Challenges with Requirement 2
Organisations often underestimate Requirement 2 due to its seemingly straightforward nature. However, common pitfalls include:
- Inconsistent configurations across servers or environments.
- Outdated system builds lacking current hardening best practices.
- Inadequate documentation, complicating compliance verification.
- Default credentials remaining on seldom-used systems or legacy devices.
- Unaccounted-for cloud assets or shadow IT not included in inventories.
These issues frequently emerge during PCI gap assessments and can delay compliance if not proactively addressed.
How Securious Can Help
Securious has been a PCI QSAC since 2016, with a team of qualified, highly experienced PCI DSS QSA and 3DS assessors ready to assist you in achieving and maintaining compliance with the latest PCI DSS standards.
Based in Exeter, Devon, we undertake PCI QSA work both nationally and internationally. As the only PCI DSS QSA company in the region, organisations in Devon, Cornwall, or Somerset can benefit from cost efficiencies with on-site assessments.
Our mission is to build cybersecurity confidence. When it comes to PCI DSS compliance, we collaborate with you to make the process as efficient as possible, helping you understand what needs to be done and why.
We offer three options to assist our clients with PCI DSS compliance:
- PCI DSS QSA Gap Analysis & Assessment (one-off fee)
Read more about our PCI DSS QSA Gap Analysis & Assessment by clicking here.
- Managed PCI DSS Compliance Service (fixed monthly fee)
Read more about our Managed PCI DSS Compliance Service by clicking here.
- Assisted PCI DSS SAQ Compliance Service (one-off fee)
Read more about our Assisted PCI DSS SAQ Compliance Service by clicking here.
Get in Touch to Get Started
To learn more, visit our PCI services page, call us on 01392 247 110, email info@securious.co.uk, or send us a message using the form below.
Find out whether you’re ready for PCI DSS v4.0.1 in minutes.