Server configuration hardening is a basic requirement for compliance with Payment Card Industry Data Security Standard (PCI DSS) v4.0 that was updated in April 2022 from PCI DSS Version 3.2.1. Server hardening is a fundamental process that ensures the security of servers in the network by reducing the servers attack surface through implementation of secure configurations. PCI-DSS has various challenging requirements, but requirement 2 that states 'Apply Secure Configurations to All System Components' poses a basic  challenge to IT and security teams that manage large production environments which need to comply with PCI-DSS.


server hardening


PCI DSS  requires IT organizations to address all known security vulnerabilities and remain consistent with industry-accepted system hardening standards. The default configurations of operating systems and applications prioritize ease of server deployment and user-friendliness over security considerations. When utilized in their default state, these servers introduce vulnerabilities into your IT infrastructure, rendering it susceptible to various forms of cyberattacks.


What Security Policies Should be used For Hardening?

Hardening is changing the Operating System (OS) and applications configurations from the default setting to the desired baseline security standard in order to lock down the server. The PCI DSS council recommend to use any of the following benchmarks as a hardening policy:


  • Center for Internet Security (CIS)
  • National Institute of Standards and Technology (NIST)
  • International Organization for Standardization (ISO)
  • SysAdmin, Audit, Network, and Security (SANS) Institute


A new reporting option was included to PCI DSS v4.0 document requirements called "In Place with Remediation." The goal of this option was to promote security as a continuous process, by providing a means for organizations to identify areas needing improvement year over year. 


The PCI 2.2 requirement as stated in the official standard are shown in the following table:

PCI Remediation



System hardening must be a recurrent and ingrained practice within IT security, rigorously adhered to each time a new server integrates into the network and sustained throughout the server’s operational life span. This process necessitates the existence of a meticulously documented system functionality and security baseline, with the overarching objective of eliminating superfluous functionalities and meticulously configuring those that are retained in a secure manner. Furthermore, it is imperative to carry out periodic system updates and re-hardening endeavors with every occurrence of an update to revalidate that the system maintains its robust state of hardening.


Changes from PCI DSS Version 3.2.1 to 4.0 Revision 2


 The following change types from PCI DSS v3.2.1 to 4.0 are:

PCI Change Types


PCI DSS changes made specifically for system hardening in Requirement 2: Apply Secure Configurations to All System Components are as follows:

PCI DSS changes 3 to 4V


You can find the entire document for the PCI DSS Summary of Changes from v3.2.1 to v4.0 – Dec 2022 here

Milestones for Prioritizing PCI DSS Compliance Efforts 


The Prioritized Approach for PCI DSS compliance includes six milestones. The following table summarizes the high level goals of each milestone. 


General Changes Implemented Throughout PCI DSS RequirementsChange Type
Reformatted overview sections and added a summary of the sections to the beginning of each principal requirement.Structure or
Updated overview sections and added guidance at the start of each requirement section.Clarification or
Added numbered requirement description headings throughout each requirement to organize and describe the requirements that fall under it.Structure or
Renumbered requirements and testing procedures and reorganized requirements due to the addition of numbered requirement description headingsStructure or
Rephrased directive requirements to be objective.Evolving
Moved examples from requirements or testing procedures into the guidance column.Structure or
Removed references to sampling from testing procedures.Clarification or
Shortened testing procedures by clarifying testing is to be done “in accordance with all elements specified in this requirement” to minimize redundancy between requirements and testing procedures.Clarification or
Updated language in requirements and/or corresponding testing procedures for alignment and consistency.Clarification or
Enhanced testing procedures to clarify level of validation expected for each requirement.Clarification or
Reformatted requirements and testing procedures and made minor wording changes for readability – for example, content from paragraphs reformatted to bullet points.Structure or
Combined requirements that support the same intent and separated requirements that support different intents.Structure or
Separated complex requirements / testing procedures and removed redundant or overlapping testing proceduresStructure or
Moved required elements that were included only in testing procedures to requirements, to clarify the requirement and to facilitate shortening of the testing procedures. Clarification or
Moved and reworded policies and procedures requirements from the end to the beginning of each principal requirementStructure or
Removed notes about SSSL/Early TLSSL/Early TLS from the guidance columns for requirements that referenced those specific protocols.Clarification or
Changed “cardholder data” to “account data” as needed to align with usage and intent.Clarification or
Changed terminology used to refer to frequency throughout the requirements in accordance with Description of Timeframes Used in PCI DSS Requirements.Clarification or
Added titles and reorganized content of the guidance column to aid understanding and merge similar information.Structure or

Requirement 2.2 System components are configured and managed securely

According to the PCI DSS Guide, Requirement 2.2 is one of the stringent requirements of the PCI DSS. This requirement mandates that the system should be hardened by ensuring that system elements are reinforced as much as possible before joining the network.


To comply with PCI DSS requirement 2.2, merchants must fix all identified vulnerabilities and comply with well-known hardening practices. CalCom Hardening Suite (CHS) platform locks down servers with the CIS security benchmarks in a cost effective way with no disturbance to production. The CHS learning capabilities overcome the need to commit your IT team to long hours of policy testing and putting out fires when outages occur due to hardening. Easily achieve PCI-DSS compliance and reduce IT administration costs for server hardening tasks.

server hardening


Automated Hardening Benefits:


  • Deploy the required security baseline without affecting the production services
  • Reduce costs and resources required for implementing and achieving compliance
  • Manage the hardening baseline for the entire infrastructure from a single point
  • Avoid configuration drifts and repeated hardening processes


In addition to following the recommended baselines PCI-DSS recommends additional server hardening procedures:


  • Implement only one primary function per server. PCI Requirement 2.2.1 recommends applying only one primary function per server and not to combine functions. For instance, a database server should not also be a mail server. But for budget constraints, best practice should be to separate primary functions using different servers. The security concern behind requirement 2.2.1 is that each server role will have a proper configuration. In the reality we see servers often get more than one role, this situations requires dedicated hardening policies per server.
  • Cover all system components. 
  • Address all known security vulnerabilities. 
  • Be consistent with industry-accepted system hardening standards or vendor hardening recommendations. 
  • Be updated as new vulnerability issues are identified, as defined in Requirement 6.3.1. 
  • Be applied when new systems are configured and verified as in place before or immediately after a system component is connected to a production environment.

You might be interested