Every business accepting credit card payments is impacted by the changes coming to the cardholder data protection standards. For businesses with an ecommerce application or website using iFrames or full site redirect to a PCI DSS-compliant service provider, there are immediate changes that can impact the ability to meet the March 31, 2024, deadline.
Changes coming with PCI DSS v4.0
The Payment Card Industry Security Standards Council (PCI SSC) establishes and maintains the Data Security Standards (DSS) intended to protect cardholder data, consumers, and the payment card industry.
The PCI DSS is in transition to version 4.0. There are 63 new and revised requirements and two pending deadlines. To align with PCI DSS v4.0, the PCI SSC has updated each self-assessment questionnaire (SAQ) for the changes in v4.0 requirements.
Entities identified by the PCI SSC as “card-not-present merchants” are eligible to use SAQ A. Established for merchants that fully outsource cardholder data functions to a third-party vendor, SAQ A dovetails with businesses who use iFrames and full site redirects on ecommerce websites to shift some compliance burden to a validated payment processor.
SAQ A changes
Currently, merchant organizations eligible to use SAQ A only need to comply with 24 controls. SAQ A for PCI DSS v4.0 includes a substantial increase to 31 controls, including a re-requirement for an Approved Scanning Vendor (ASV) scan for merchants using iFrames and full site redirects. Modifications to this requirement aren’t receiving much attention and can easily be missed.
Requirements needing a high level of effort to achieve for ecommerce merchants using iFrames or redirects to process payments are outlined below. Some of these must be implemented by March 31, 2024, once SAQ-A for PCI DSS v3.2.1 is retired. Others must be implemented by March 31, 2025, to achieve compliance with PCI DSS. Each future-dated requirement stands as a best practice until its effective date.
Key to success is ensuring your organization has a complete inventory of web pages and web servers used for ecommerce and where iFrames and full site redirects are used. For smaller organizations, this may be limited to one. Larger organizations may have many, and those may be self-hosted in the merchant’s data center or with a cloud service provider, such as Azure, AWS, or Google Cloud Platform.
PCI DSS 6.4 – Public-facing web applications are protected against attacks
This requirement is intended to prevent unauthorized code/scripts on ecommerce (iFrame and full redirect) websites.
| PCI DSS # | Requirement | Deadline |
| 6.4.3 | All payment page scripts that are loaded and executed in the consumer’s browser are managed as follows: • A method is implemented to confirm that each script is authorized. • A method is implemented to assure the integrity of each script. • An inventory of all scripts is maintained with written justification as to why each is necessary. | March 31, 2025 |
Essential elements of this requirement prevent unauthorized code/scripts from running in the payment page when it is executed in the consumer’s browser and to ensure code/scripts integrity. This requirement is designed to protect against maliciously added code/scripts and to stop potential attackers from executing malicious scripts that can read and exfiltrate cardholder data from the consumer’s browser, often going unnoticed and challenging to detect.
PCI SSC allows several ways that script integrity can be verified to meet the intent of this requirement, such as Sub-Resource Integrity (SRI), Content Security Policy (CSP), or proprietary script or tag-management systems.
To comply with this requirement, merchant organizations should:
- Implement policies and procedures for managing code/scripts executed on web pages used to redirect traffic flow to a payment page.
- Develop and deploy manual or automated processes/mechanisms to ensure that code/scripts are authorized and assure the integrity of each script.
- Document and maintain an inventory of all scripts (including those loaded from third and fourth parties) with documented justification for each.
- Consider third-party products that provide code/script integrity checks, including reporting and auto-protection features, loaded by the consumer browser.
PCI DSS 8.3 – Strong authentication for users and administrators is established and managed
Password and access for ecommerce (iFrame and full redirect) websites are established with this requirement.
| PCI DSS # | Requirement | Deadline |
| 8.3.5 | If passwords/passphrases are used as authentication factors to meet Requirement 8.3.1, they are set and reset for each user as follows: • Set to a unique value for first-time use and upon reset. • Forced to be changed immediately after the first use. | March 31, 2024 |
| 8.3.6 | If passwords/passphrases are used as authentication factors to meet Requirement 8.3.1, they meet the following minimum level of complexity: • A minimum length of 12 characters (or IF the system does not support 12 characters, a minimum length of eight characters). • Contain both numeric and alphabetic characters. | March 31, 2025 |
| 8.3.7 | Individuals are not allowed to submit a new password/passphrase that is the same as any of the last four passwords/passphrases used. | March 31, 2024 |
| 8.3.9 | If passwords/passphrases are used as the only authentication factor for user access (i.e., in any single-factor authentication implementation) then either: • Passwords/passphrases are changed at least once every 90 days, OR • The security posture of accounts is dynamically analyzed, and real-time access to resources is automatically determined accordingly. | March 31, 2024 |
This requirement is intended to prevent unauthorized access to the sensitive data that merchant organizations possess. Strong passwords are essential to ensure that ecommerce web servers hosting an iFrame or full redirect aren’t easily compromised due to weak authentication methods. Organizations with policies for creating strong, secure, phishing-resistant passwords can significantly reduce the risk of cyber criminals gaining unauthorized access to the merchant’s ecommerce web servers.
To comply with these requirements, merchant organizations should ensure these requirements are applied to web server environments:
- Implement policies and procedures for managing, setting, and resetting passwords.
- Deploy an access-control mechanism to force password change after the first use.
- Set password complexity to a minimum of 12 characters (or at least 8 if the system doesn’t support 12), prevent reuse of past passwords set to a minimum of the last 4, and configure policies to force password change at least every 90 days or use dynamic, real-time account security.
- Also, consider any content management systems that could impact the security of web pages or web servers containing the iFrame or full redirect.
PCI DSS 11.3 – External and internal vulnerabilities are regularly identified, prioritized, and addressed
ASV scans weren’t required with PCI SAQ A v3.2.1, but with PCI DSS v4.0, an ASV scan has been quietly added to the SAQ A to address evolving risks targeting ecommerce websites. Skilled QSAs like those on the Converge team have long known that compromise of a merchant web server hosting iFrames or redirect links to service provider-managed payment pages could lead to the theft of cardholder data. With PCI DSS v4.0, the Council is addressing this attack vector directly through the ASV scan requirement. This is a true attack vector seen in the wild today.
There are often several remediation efforts, such as patching of vulnerabilities rated CVSS 4.0 or higher, scope reduction opportunities, or compensating controls, needed to get a passing ASV scan, so merchants with iFrame and full redirect ecommerce sites and applications should restart the scanning process now to ensure compliance by the deadlines. Larger organizations with numerous ecommerce sites, some possibly controlled by content management systems, have additional risk.
| PCI DSS # | Requirement | Deadline |
| 11.3.2 | External vulnerability scans are performed as follows: • At least once every three months. • By PCI SSC Approved Scanning Vendor (ASV). • Vulnerabilities are resolved and ASV Program Guide requirements for a passing scan are met. • Rescans are performed as needed to confirm that vulnerabilities are resolved per the ASV Program Guide requirements for a passing scan. | March 31, 2024 |
| 11.3.2.1 | External vulnerability scans are performed after any significant change as follows: • Vulnerabilities that are scored 4.0 or higher by the CVSS are resolved. • Rescans are conducted as needed • Scans are performed by qualified personnel and organizational independence of the tester exists (not required to be a QSA or ASV). | March 31, 2024 |
These requirements apply to merchant systems hosting the iFrame or redirecting customers from the merchant website to a third-party service provider or payment processor for payment processing. With the release of SAQ A v4, passing external ASV scans are now required quarterly for consumer-facing web applications. External scans should also be performed after any significant changes, including when CVSS 4.0 vulnerabilities or higher are remediated, to confirm that the identified vulnerabilities are resolved.
With the release of PCI DSS v4, the Council has put some clarity behind what it sees as a significant change. Its guidance indicates that, at a minimum, significant change is that which “has potential impacts on the security of the CDE and must be considered as a significant change in the context of related PCI DSS requirements:
- New hardware, software, or networking equipment added to the CDE.
- Any replacement or major upgrades of hardware and software in the CDE.
- Any changes in the flow or storage of account data.
- Any changes to the boundary of the CDE and/or to the scope of the PCI DSS assessment.
- Any changes to the underlying supporting infrastructure of the CDE (including, but not limited to, changes to directory services, time servers, logging, and monitoring).
- Any changes to third-party vendors/service providers (or services provided) that support the CDE or meet PCI DSS requirements on behalf of the entity.”
To comply with these requirements, merchant organizations should:
- Implement policies and procedures for external vulnerability management.
- Clearly define the scope of the external vulnerability scans and identify all external-facing systems and networks that are within the cardholder data environment (CDE). Minimally, this would be the hosting web servers for the iFrame and redirect pages, but could potentially expand beyond those hosts.
- Choose a PCI SSC Approved Scanning Vendor (ASV) to conduct the scans.
- Ensure that external vulnerability scans are scheduled to occur at least once every three months. The Council specifies that the frequency of every three months should be understood as occurring at least once every 90 to 92 days or on a consistently used day of every third month.
- Ensure that identified vulnerabilities are resolved and rescans are performed as needed to confirm that vulnerabilities are resolved per the ASV Program Guide requirements for a passing scan.
For a comprehensive guide to ASV scans, the PCI SSC has a published the ASV Program Guide.
PCI DSS 11.6 – Unauthorized changes on payment pages are detected and responded to
This requirement establishes deployment of change- and tamper-detection mechanisms for HTTP headers for ecommerce sites using iFrames and full redirects.
| PCI DSS # | Requirement | Deadline |
| 11.6.1 | A change- and tamper-detection mechanism is deployed as follows: • To alert personnel to unauthorized modification (including indicators of compromise, changes, additions, and deletions) to the HTTP headers and the contents of payment pages as received by the consumer browser. •The mechanism is configured to evaluate the received HTTP header and payment page. • The mechanism functions are performed as follows: – At least once every seven days OR – Periodically (at the frequency defined in the entity’s targeted risk analysis, which is performed according to all elements specified in Requirement 12.3.1). | March 31, 2025 |
Rather than installing software on consumer browsers or systems, notes available for this requirement indicate that this requirement should be fulfilled using techniques described in PCI Data Security Standard Requirements and Testing Procedures document in the Guidance column under examples.
Example mechanisms include:
- Violations of the Content Security Policy (CSP) can be reported to the entity using the report-to or report-uri CSP directives.
- Changes to the CSP itself can indicate tampering.
- External monitoring by systems that request and analyze the received web pages (also known as synthetic user monitoring) can detect changes to JavaScript in payment pages and alert personnel.
- Embedding tamper-resistant, tamper-detection script in the payment page can alert and block when malicious script behavior is detected.
- Reverse proxies and content delivery networks can detect changes in scripts and alert personnel.
In addition, SAQ Completion guidance advises that this requirement is only applicable to the merchants who use iFrame technology to accept payments. If merchant uses URL redirect to the third-party service provider or payment processor to process payments, then this requirement can be marked as Not Applicable.
To comply with these requirements, merchant organizations should:
- Deploy a change- and tamper-detection mechanism using techniques described in the PCI Data Security Standard Requirements and Testing Procedures document in the Guidance column. under examples and configure it to alert personnel to unauthorized modifications.
- Perform checks weekly or complete a risk assessment to determine the appropriate frequency for these checks.
Start the ASV scan process for SAQ A now
If your organization is eligible to complete an SAQ A, put steps in motion now to address the new requirements, especially those with a March 31, 2024, deadline. ASV scans will now be mandatory, but scheduling and passing an ASV scan isn’t always a straightforward process. We believe this will be the most difficult requirement to achieve and should have your immediate focus.
Navigating the new PCI DSS requirements and related SAQ changes is easier with skilled guidance. Converge has helped hundreds of organizations achieve and sustain PCI compliance. If you’re ready for a smoother path to PCI compliance, connect with us today.
