When PCI DSS version 4.0 was released in March 2022, it introduced a range of updates designed to modernise payment security and address evolving threat landscapes. Among these changes were 48 new requirements that were initially classified as best practice — giving organisations until 31 March 2025 to assess, plan, and implement the necessary controls.
That deadline is now fast approaching!
From 1 April 2025, these requirements become mandatory, and while your next PCI DSS assessment might not be scheduled until later in the year, it’s important to understand that you must already have these controls in place by the deadline. QSAs will be checking not just for implementation, but also for evidence that these controls were operational before they became mandatory — not rushed through the week prior to assessment.
These new requirements reflect the reality of today’s threat landscape. They bring the standard in line with current attack vectors and risks, such as phishing, malware on removable media, insecure scripts on payment pages, and failures in security control systems. When implemented effectively, they don’t just satisfy compliance, they provide real-world security benefits, reducing the likelihood of credit card data compromise.
Below is a summary of each of the 48 requirements becoming mandatory from 31 March 2025, what they involve, and why they matter.
3.3.2 – SAD Stored by Issuers Must Be Encrypted
For issuers and entities supporting issuing services that store sensitive authentication data (SAD), this data must be encrypted using strong cryptography. This applies only where there’s a legitimate business need and the entity is permitted to store SAD. The encryption must align with PCI DSS cryptographic standards to protect against unauthorised access. It should also be noted that this requirement is not eligible to leverage PCI DSS 4.0’s customised approach.
3.3.3 – Controls for Access to Stored SAD
As part of PCI DSS 4.0.1, issuers (and those supporting them) who retain SAD must ensure it is accessible only to roles with a documented, explicit need. From 31st of March, any storage of SAD must also be encrypted using strong cryptography.
3.4.2 – Controls to Prevent Copy/Relocation of PAN
Organisations must implement technical controls to prevent the unauthorised copying or relocation of PAN, particularly through remote access or removable media. This ensures that even authorised users cannot extract or move PAN outside of approved workflows.
3.5.1.1 – Hashes Used to Render PAN Unreadable
This requirement replaces the first bullet point in 3.5.1 that states “One-way hashes based on strong cryptography of the entire PAN.” After March 31, hashes used to render the PAN unreadable must be keyed cryptographic hashes of the entire pan, with associated key-management processes and procedures in accordance with Requirements 3.6 and 3.7.
3.5.1.2 – Disk-Level Encryption No Longer Sufficient Alone
If disk or partition-level encryption is used to protect stored PAN, it must be implemented on removable electronic media, or if used for non-removable media, the PAN must also be rendered unreadable via another mechanism that meets Requirement 3.5.1.
3.6.1.1 – Service Providers Must Document Cryptographic Architecture
Service providers are required to maintain detailed documentation of their cryptographic architecture, including algorithms, key lengths, and key usage. This documentation supports consistent and secure implementation of cryptographic protections and must be reviewed and kept up to date.
4.2.1 – Secure Transmission of PAN Using Trusted Protocols
When PAN is transmitted over open, public networks, it must be protected using strong cryptography and trusted protocols (e.g. TLS 1.2 or higher). This update adds further emphasis on verifying that untrusted certificates (for example, expired or revoked certificates) are rejected.
4.2.1.1 – Inventory of Trusted Keys and Certificates
Organisations must maintain an inventory of all trusted keys and certificates used to protect PAN during transmission. The inventory must be accurate and up to date, and includes details like issuing CAs and expiration dates. This helps support proactive certificate management and avoids reliance on outdated or compromised keys.
5.2.3.1 – Malware Evaluation Frequency for Non-Risk Systems
For system components identified (via risk analysis) as not at risk for malware, organisations must define how often they’ll re-evaluate that status. This is a refinement of malware management practices to ensure systems classified as “low risk” are not neglected over time.
5.3.2.1 – Defining Frequency for Malware Scans
If an organisation chooses to perform periodic malware scans instead of using continuous or real-time monitoring, it must define how often these scans are run. This must be documented via a targeted risk analysis, ensuring that scan frequency is appropriate to the level of risk.
5.3.3 – Malware Scanning for Removable Media
Anti-malware solutions must automatically scan removable electronic media (e.g. USB drives) when they are inserted or mounted. This requirement ensures removable media, which can introduce external threats, are actively monitored as part of malware protection strategies.
5.4.1 – Technical Controls to Protect Against Phishing
Organisations must implement technical or automated controls to detect and protect users against phishing attacks. These may include email filtering solutions, anti-phishing gateways, malicious link detection, domain spoofing protection (e.g. DMARC), and automated response mechanisms. This requirement ensures phishing threats are mitigated through proactive, system-driven defences — separate from user awareness or training efforts.
6.3.2 – Inventory of Custom and Third-Party Software
A documented inventory must be maintained for all bespoke, custom, and third-party software components. This supports effective vulnerability and patch management by ensuring visibility of all software in use, especially components that may not be automatically tracked by commercial tools.
6.4.1 – Public-Facing Web Application Protections
This requirement will be superseded by Requirement 6.4.2 after the 31st of March.
6.4.2 – Automated Protection for Public-Facing Web Applications
Public-facing web applications must be protected by an automated technical solution that continually detects and prevents web-based attacks. This solution must be actively running, up to date, generating audit logs, and configured to either block attacks or generate alerts that are immediately investigated. A common example is a Web Application Firewall (WAF). This control addresses modern web-based threats like brute-force attacks, injection attempts, and enumeration attacks — helping to secure one of the most commonly targeted components in a cardholder data environment.
6.4.3 – Management of Payment Page Scripts
Entities must manage all scripts that are loaded and executed on payment pages. This includes maintaining an inventory, ensuring each script is authorised, and implementing controls to prevent unauthorised script changes. This helps reduce the risk of client-side web skimming attacks. This is one of the most onerous changes that go into effect 31st of March, so if you need advice on how to implement this control, please reach out.
7.2.4 – Periodic Review of All User Accounts
Organisations must periodically review all user accounts and related access privileges, including third-party and vendor accounts, to confirm they are still necessary and appropriate. This helps ensure that outdated or excessive access is revoked in a timely manner, reducing the risk of unauthorised access.
7.2.5 – Manage Application and System Accounts
Access for system and application accounts must be restricted to only what is required for their function. These accounts must be uniquely assigned, tightly controlled, and reviewed for appropriateness. This includes limiting their use to specific systems and roles.
7.2.5.1 – Periodic Review of System and Application Accounts
Organisations must conduct periodic reviews of application and system accounts, based on a targeted risk analysis. The review confirms whether each account and its privileges are still valid, and whether any changes are required. Results must be documented and confirmed by management.
8.3.6 – Minimum Password Complexity Requirements
If passwords or passphrases are used to meet authentication requirements (per 8.3.1), they must meet minimum complexity standards — including a minimum of 12 characters (or 8 characters if the system cannot support 12) and must contain both alphabetic and numeric characters. This control does not apply to point-of-sale accounts limited to a single transaction or to system/application accounts (which are covered under section 8.6). This requirement strengthens access security by reducing the likelihood of weak or guessable credentials being used to compromise systems.
8.3.10.1 – Password-Only Access Restrictions (Service Providers Only)
If a service provider allows customer users to authenticate using only a password or passphrase (without MFA), then strict controls must be in place to enforce session timeouts and ensure secure access. This includes either changing passwords or passphrases every 90 days or ensuring the security posture of accounts is dynamically analysed. This applies only to service providers and enforces stronger accountability around password-only access.
8.4.2 – MFA for Non-Console Access to the CDE
Multi-Factor Authentication (MFA) is required for all non-console (i.e. remote or network-based) access into the Cardholder Data Environment (CDE). This applies regardless of whether the access is from an internal or external network. It ensures an additional layer of protection for critical environments.
8.5.1 – Secure MFA Configuration and Monitoring
MFA implementations must be resistant to replay attacks, require successful validation of all authentication factors before access is granted, and disallow bypasses unless formally authorised for a limited time. This raises the bar for MFA implementations, requiring them to be more robust and strictly controlled.
8.6.1 – Managing Interactive Login for System and Application Accounts
If system or application accounts are capable of interactive login, their use must be tightly controlled. Interactive access must be prevented unless required for an exceptional circumstance, and even then, access must be approved by management, time-limited, justified, and attributable to an individual user. This requirement ensures these powerful accounts cannot be misused and that any activity using them is fully traceable — reducing the risk of threat actors exploiting shared or unmanaged access.
8.6.2 – No Hardcoded or Embedded Credentials
Application and system accounts must not store passwords or passphrases in clear text within scripts, config files, or source code. These credentials must be stored securely using secure storage mechanisms or vaulting solutions, to prevent exposure during access or code inspection.
8.6.3 – Password Protection for System/Application Accounts
Passwords or passphrases for system and application accounts must follow complexity requirements and be protected against misuse. This includes using secure storage, rotating them appropriately, and conducting a risk analysis to determine suitable change frequency.
9.5.1.2.1 – POI Device Inspection Frequency Based on Risk
Organisations must determine how often to inspect Point-of-Interaction (POI) devices, and what those inspections include, based on a targeted risk analysis. This ensures that the approach to detecting tampering or substitution is tailored to the business’s specific threat environment.
10.4.1.1 – Automated Audit Log Reviews
Organisations must use automated mechanisms to perform audit log reviews. These tools — such as SIEMs, log analysers, or centralised log management systems — help identify suspicious or anomalous activity in a repeatable and consistent way. Manual log reviews alone are no longer sufficient due to the volume of data generated. This requirement supports early detection of potential threats and reduces the risk of missed warning signs in audit data.
10.4.2.1 – Risk-Based Frequency for Log Reviews
For system components not covered under 10.4.1 (i.e. lower-risk systems), the frequency of log reviews must be defined through a targeted risk analysis performed in accordance with Requirement 12.3.1. This allows organisations to tailor log review intervals based on the system’s function, sensitivity, and risk level — ensuring reviews are conducted often enough to detect issues without creating unnecessary overhead.
10.7.1 – Monitoring Security Control Failures (Service Providers Only)
Service providers must be able to detect, alert, and respond promptly to failures of critical security control systems — such as firewalls or antivirus solutions going offline. These failures can create blind spots in security monitoring and must be addressed swiftly.
10.7.2 – Monitoring Security Control Failures (All Entities)
This requirement expands on 10.7.1, applying it to all organisations (not just service providers). Entities must detect, alert on, and respond to failures of critical security systems, such as intrusion detection/prevention systems or security logging solutions.
10.7.3 – Respond to Security Control Failures
All entities must respond promptly to failures of any critical security control systems. This includes detecting and addressing outages or malfunctions in systems such as firewalls, antivirus, IDS/IPS, or logging infrastructure. Quick response is essential to maintain continuous protection and visibility.
11.3.1.1 – Risk-Based Management of Lower-Risk Vulnerabilities
Vulnerabilities that are not classified as high-risk or critical (based on the entity’s vulnerability risk rankings under 6.3.1) must still be addressed — but the timing and priority for remediation are determined by a targeted risk analysis in line with Requirement 12.3.1. This approach ensures that even lower-severity vulnerabilities are not ignored, and that rescans are conducted as needed to confirm they’ve been remediated. It balances security with practicality, ensuring resources are focused appropriately while still reducing overall risk.
11.3.1.2 – Authenticate Internal Vulnerability Scanning
Internal vulnerability scans must be conducted using authenticated scanning, wherever systems support it. This provides deeper visibility into vulnerabilities that unauthenticated scans may miss. For systems that cannot accept credentials, this must be documented. Credentials used must have sufficient privileges to ensure thorough scanning, and if those credentials allow interactive login, they must be managed in accordance with Requirement 8.2.2. This control ensures vulnerabilities are not overlooked due to limited access during scans and improves the accuracy of internal assessments.
11.4.7 – Penetration Testing Requirements for Multi-Tenant Service Providers
Multi-tenant service providers must conduct penetration testing in line with client requirements, and includes validation of isolation between tenants. This ensures one tenant cannot gain access to another’s data or systems, addressing the increased risk associated with shared environments.
11.5.1.1 – Detecting Covert Malware Channels (Service Providers Only)
Service providers must implement intrusion detection and/or prevention techniques that can detect, alert on, or block covert malware communication channels — such as DNS tunnelling or other command-and-control (C&C) techniques. These covert channels are often used by malware to communicate with threat actors, spread laterally across networks, or exfiltrate data. Controls must be strategically placed in the network to monitor high-risk paths and disrupt these stealthy communications before they cause widespread harm.
11.6.1 – Client-Side Change and Tamper Detection
A change and tamper detection mechanism must be implemented for web-based payment pages to detect unauthorised modifications. This helps protect against client-side attacks such as formjacking and web skimming, and supports early detection of script injection.
12.3.1 – Targeted Risk Analyses for Flexible Requirements
For any PCI DSS requirement that allows flexibility in implementation frequency (e.g. “periodically”), the entity must perform a targeted risk analysis. This ensures the defined frequency is appropriate, justified, and aligned with the organisation’s risk profile.
12.3.3 – Annual Review of Cryptographic Protocols
Cryptographic protocols and cipher suites in use must be reviewed at least annually. This includes checking for known vulnerabilities, deprecated protocols, and alignment with strong cryptography standards. The goal is to prevent insecure protocols from remaining in use unnoticed.
12.3.4 – Annual Review of Hardware and Software Technologies
All hardware and software technologies in use must be reviewed at least once a year. This review must identify technologies that are no longer supported or nearing end-of-life, allowing organisations to plan updates or replacements before vulnerabilities arise.
12.5.2.1 – Frequent Scope Validation for Service Providers
Service providers must formally review and confirm their PCI DSS scope at least every six months and after any significant change to the in-scope environment. This review must include all elements defined in Requirement 12.5.2. Due to the size, complexity, and elevated risk associated with service provider environments, more frequent scope validation ensures any changes or expansions are promptly captured and secured — reducing the likelihood of exposure due to overlooked systems or connections.
12.5.3 – Service Provider Organisational Changes
Service providers must document and assess the impact of significant changes to their organisational structure on their PCI DSS compliance. This includes mergers, acquisitions, or leadership changes that could affect roles, responsibilities, or control environments.
12.6.2 – Annual Review of Security Awareness Program
The security awareness program must be reviewed at least annually and updated as needed to reflect current threats. This ensures training materials remain relevant and that staff are educated on evolving risks, such as phishing or social engineering.
12.6.3.1 – Phishing Awareness Training
Organisations must provide personnel with specific training on recognising and responding to phishing and social engineering attempts. This is a separate requirement from general security awareness training and addresses the rising threat of email and messaging-based attacks.
12.6.3.2 – Awareness of Acceptable Use Policies
Security awareness training must include information about the acceptable use of end-user technologies, aligned with the organisation’s policy under Requirement 12.2.1. This ensures personnel understand how their everyday use of devices and systems can impact overall security — and reinforces responsible behaviour that supports compliance and reduces risk.
12.10.4.1 – Risk-Based Training Frequency for Incident Response Teams
The frequency of incident response training must be defined through a targeted risk analysis. This ensures that training schedules are tailored to the organisation’s risk profile and incident response team responsibilities, helping maintain readiness.
12.10.5 – Monitoring and Responding to Security Alerts
Incident response plans must include monitoring and responding to alerts from all security systems (e.g. intrusion detection, file integrity monitoring, unauthorised wireless detection). As of 31st of March, this is expanded to include responding to alerts from change and tamper detection mechanisms for payment pages.
12.10.7 – Response to Unintended PAN Storage
Organisations must have defined incident response procedures for cases where PAN (Primary Account Number) is found stored in unexpected locations. This includes initiating investigations, containing the issue, and preventing recurrence. It’s a critical control for reducing inadvertent data exposure.
Don’t Leave It Till The Last Minute
Some of these new requirements can be quite complex to implement, especially depending on your environment and the scope of your PCI DSS obligations. If you’re unsure where to start, or need support validating, implementing, or operationalising these controls, we’re here to help.
As a Qualified Security Assessor (QSA) company, we’re licensed to perform annual PCI DSS assessments and can guide you through the entire process, from initial gap assessments through to certification. Many of the new requirements also align closely with our broader solutions, including phishing awareness training, incident response planning and training, and risk-based control reviews.
If you’d like support preparing for the March 2025 deadline, want to validate your implementations before your next assessment, or want to understand how these changes apply in your environment, reach out for a conversation. We’re always happy to help.
0 Comments