PCI DSS e-commerce compliance: card skimming controls that actually hold
Geert WarmenbolApril 29, 2026
Key takeaways
18% of e-commerce environments that pass initial PCI DSS scans contain critical vulnerabilities exploitable within 72 hours -- the scan passed because the vulnerability was outside scan scope, not because it did not exist.
PCI DSS v4.0 Requirement 6.4.3 requires inventory and integrity verification for every script loading on a payment page, including third-party scripts. This became mandatory in March 2025. Most e-commerce operators cannot produce this inventory.
SAQ A eligibility requires that merchant systems have zero ability to influence the payment page -- developer commit access to iframe JavaScript code is a scope failure, not a cosmetic concern.
Only 22% of e-commerce platforms using tokenization can demonstrate encryption key rotation within the period PCI DSS Requirement 3.7.4 requires. The procedure exists. Nobody owns the calendar task of running it.
Control drift between annual QSA audits is the primary cause of post-certification breaches. Network segmentation and payment page script integrity are the two control areas that degrade fastest in active development environments.
Deploying an EDR platform on payment servers does not satisfy PCI DSS file integrity monitoring requirements. The two controls serve different purposes and cannot be substituted for each other.
TL;DR
The PCI DSS audit tells you where your environment was on one specific day. Attackers operate on the days in between. The e-commerce compliance failures we see most consistently are not audit failures -- they are drift failures. A script gets added to a checkout page. A firewall rule from a deployment never gets cleaned up. A tokenization key rotation procedure sits in a runbook nobody executes. The controls existed. They stopped holding.
The checkout page nobody inventoried
A mid-size e-commerce operator passed their annual QSA review in September. By December, their checkout page was loading a third-party analytics script that had been compromised at the CDN level. The script was exfiltrating card numbers entered into the payment form before tokenization occurred. The compromise was not in their infrastructure -- it was in a vendor they had not listed as a service provider under Requirement 12.8, because the marketing team had added the analytics tag directly to the page template without routing it through IT. The QSA had reviewed their third-party service provider inventory. The script was not on it.
PCI DSS v4.0 Requirement 6.4.3 exists because of this exact attack pattern. It requires that every script executing on a payment page -- including scripts loaded from external domains -- is authorized, inventoried, and has its integrity verified. The requirement became mandatory in March 2025. In Vulnox assessments conducted since then, fewer than a third of e-commerce operators can produce a complete script inventory for their checkout pages when asked.
How Magecart works and what 6.4.3 actually requires
Magecart is not a single group. It is a technique. A malicious JavaScript snippet loads onto a checkout page and intercepts card data as the customer types it, before the data reaches the payment processor. The injection can happen through a compromised plugin, a third-party script loaded from an attacker-controlled CDN, or a Content Security Policy that permits unapproved script sources.
What makes this class of attack effective against compliant environments is that it operates entirely in the browser. The merchant server never sees the exfiltrated data. The tokenization system never processes it. Network-level monitoring does not catch it because the exfiltration happens client-side over HTTPS to a domain that resembles an analytics service. Standard vulnerability scans do not catch it because scanners test server-side configurations.
PCI DSS v3.2.1 had no control requiring merchants to inventory or verify scripts on payment pages. Requirement 6.4.3 fills that gap: merchants must maintain an inventory of all scripts on payment pages, document the authorization for each, and have a mechanism to detect unauthorized changes. Subresource Integrity tags handle this for scripts with stable hashes. For dynamically generated or frequently updated scripts, real-time script monitoring tools are the practical path.
CSP is a supporting control for 6.4.3, not a substitute. A strict CSP that whitelists specific domains still permits any script from those domains, including compromised ones. SRI provides hash-based verification but only works for scripts that do not change between deployments. What 6.4.3 requires is continuous: authorization, integrity check, and change detection -- not a one-time configuration audit.
Example
In a Vulnox assessment of a fashion e-commerce operator, the payment page loaded eleven external scripts at checkout -- tag managers, affiliate trackers, chat widgets, review tools, and two analytics platforms. The merchant could name four of them. None had SRI tags. Two were loading from domains that had changed ownership in the preceding 18 months. The CSP policy used unsafe-inline because a developer had added it to fix a broken widget and never reverted it. The page was passing automated scans because the scans were testing TLS version and HTTP header configuration, not script inventory.
The 6.4.3 inventory requirement has a specific implication for merchants using tag management systems: scripts loaded dynamically through a tag manager are in scope for 6.4.3 even if the tag manager itself is a trusted vendor. The authorization and integrity check applies to what the tag manager loads, not only to the tag manager script itself.
What assessments find after the QSA leaves
Assessment base: Vulnox assessment data, 2024-2025, across e-commerce operators on Magento, WooCommerce, and custom platforms handling direct card transactions and hosted payment page integrations.
TLS 1.0 re-enabled after compliant configuration was documented
The most consistent finding across Vulnox e-commerce scans is TLS 1.0 remaining negotiable on Nginx 1.18 payment gateway configurations. In several cases, the QSA had documented TLS 1.2 and 1.3 as the configured protocols. A subsequent infrastructure change -- a server rebuild, a configuration management tool rerun, a package update -- had reset the Nginx SSL configuration to build defaults, which on that version included TLS 1.0. No post-change TLS verification check was run because the control was considered already implemented and closed.
A compliant TLS configuration at audit time is not a compliant configuration in perpetuity. Infrastructure changes silently undo compliant configurations. TLS version enforcement needs to be in automated continuous monitoring, not just in QSA documentation. The two-line fix takes minutes. The process gap that allows the reversion to persist for months is the actual finding.
SAQ A claimed for a checkout flow where developers controlled the iframe JavaScript
A Vulnox assessment found a merchant claiming SAQ A eligibility based on using a hosted payment page iframe. Their frontend developers had direct commit access to the JavaScript served inside the iframe through a shared codebase repository. The iframe was hosted on a subdomain the development team controlled. The self-assessment had focused on the visual separation between the merchant site and the payment page. The technical question -- whether merchant systems could influence what the payment page executed -- had not been asked.
SAQ selection errors are not caught during self-assessment because the merchant applying the wrong SAQ does not know they are doing so. The iframe creates the impression of a hosted payment page. Whether the development team can modify what it executes is the actual scoping question, and it requires a specific technical review to answer correctly. The compliance gap is the same size regardless of whether it was discovered before or after a breach.
Payment gateway absent from Requirement 12.8 service provider inventory
In an assessment of a retail e-commerce operator, the Stripe API integration was not listed in the third-party service provider inventory required under Requirement 12.8. The integration had been added by a development contractor 14 months prior. The merchant's 12.8 list contained their hosting provider and fraud detection vendor -- both added during initial compliance program setup. The payment gateway was not in the process that maintained the list because it was added after the list was established and the addition never triggered a 12.8 review.
Service provider inventories go stale because the process that maintains them is not connected to the process that adds new integrations. New payment tools, analytics scripts, and third-party services added through normal development cycles do not automatically trigger a 12.8 update. The list that was accurate at audit time is often materially incomplete a year later, and incomplete in the direction of the highest-risk vendors.
The EDR deployment that created a compliance finding
Common belief
A recurring pre-assessment argument is that deploying an EDR platform on payment servers satisfies PCI DSS malware protection requirements and -- because the EDR provides behavioral visibility -- reduces the need for separate file integrity monitoring. The logic is that if the EDR detects anomalies, a dedicated FIM tool duplicates coverage.
What we found
One client deployed CrowdStrike Falcon specifically to satisfy the malware protection requirement before a QSA review. The QSA accepted the deployment for that control and issued a separate finding for the absence of dedicated file integrity monitoring on payment server configuration files. The client's exact complaint: 'We bought CrowdStrike specifically to check the malware protection box, but the QSA is still saying we need separate file integrity monitoring on our payment server.' The controls serve different requirements. Neither substitutes for the other.
PCI DSS Requirement 10.3.4 requires file integrity monitoring or change detection on audit logs specifically. Requirement 11.5.2 requires a change and tamper detection mechanism for critical system files and configuration files. An EDR platform satisfies neither as written. EDR behavioral detection is probabilistic and retrospective -- it identifies suspicious activity patterns after execution. FIM is deterministic and immediate -- it alerts on any change to a defined file baseline regardless of whether the changing process showed malicious behavior.
The substitution argument fails on the framework's own terms. More practically: deploying an EDR agent on a payment server without reviewing the management console's network placement can create a new compliance finding. If the EDR management console sits on infrastructure outside the cardholder data environment, the management traffic between the agent and the console creates a network path requiring segmentation controls. Several merchants in Vulnox assessments discovered their EDR deployment had added a CDE adjacency finding they did not have before the deployment.
Where PCI DSS scope breaks in modern e-commerce infrastructure
CI/CD pipeline components adjacent to the cardholder data environment
Automated deployment pipelines push code changes to production multiple times per day. If any part of that pipeline touches systems in the cardholder data environment -- build servers, artifact repositories, deployment tools -- those components are in scope. Most merchants scope their CDE to payment servers and databases. The Jenkins instance that deploys to those servers is often absent from the scoping diagram. The network path from the build server to the payment server creates a segmentation requirement that is consistently missed, and it is not a new requirement -- it has always been there. CI/CD just made the path more active and harder to notice.
Ephemeral cloud assets created during scaling events
Auto-scaling groups create new server instances on demand and terminate them when load decreases. If those instances handle payment traffic -- even briefly -- they are in scope during their operational lifetime. Whether the security configuration applied to them matches the compliant baseline, whether their logs are captured before termination, and whether their network placement respects CDE segmentation are questions most PCI DSS programs answer only for persistent infrastructure. Ephemeral instances follow whatever the launch template specifies. Launch templates are not always updated when the compliant baseline changes. The scope question the initial QSA answered about persistent infrastructure does not automatically answer it for instances that exist for four minutes during a traffic spike.
Tokenization key rotation as an undocumented manual process
Tokenization reduces CDE scope significantly by replacing card data with non-sensitive tokens. What is consistently underimplemented is the key rotation requirement underneath it. PCI DSS Requirement 3.7.4 mandates rotation at least annually. In Vulnox assessments, only 22% of e-commerce platforms using tokenization can demonstrate rotation within that period. The rotation procedure exists as a documented runbook in nearly every case. Calendar ownership of executing it -- and verification that it ran correctly -- is absent in the other 78%. The last documented rotation date, when it can be located at all, is typically the date the tokenization system was deployed.
Where this goes in the next 18 months
By the end of 2026, at least one publicly disclosed e-commerce breach will cite a compromised third-party script loaded via a tag management system as the skimming vector, with the merchant able to demonstrate PCI DSS v4.0 audit compliance at the time of compromise -- specifically because the tag manager was listed as an authorized vendor but the scripts it loaded dynamically were not inventoried under 6.4.3.
The 6.4.3 requirement became mandatory in March 2025. The majority of e-commerce operators are still in early implementation. Tag managers occupy a specific blind spot: merchants treat the tag manager as the authorized vendor and do not extend the 6.4.3 inventory requirement to what the tag manager loads dynamically. Attackers who have historically compromised CDN-hosted scripts are aware of this gap. The condition for this prediction is already present in current assessment data.
Confidence: highA published breach disclosure or PCI forensic investigation report citing the specific vector and whether the merchant had a completed 6.4.3 inventory at the time of compromise.Within 24 months, acquiring banks will begin requiring evidence of continuous script monitoring -- not just a 6.4.3 inventory produced at audit time -- as a condition of PCI DSS certification for merchants above a transaction volume threshold. The push will come from card brand liability exposure, not from PCI SSC guidance.
The card brands absorb significant fraud liability from skimming attacks on compliant merchants. A point-in-time 6.4.3 inventory satisfies the current audit standard but does not prevent a script from being compromised the day after the audit. Continuous monitoring tools exist and are operationally viable for mid-size merchants. The incentive for card brands to require them is direct and financial. PCI SSC guidance tends to follow card brand practice in these situations, not lead it.
Confidence: mediumCard brand operating regulations or acquiring bank contract addenda requiring continuous script monitoring as an independent certification condition by mid-2027.
The annual audit model is the wrong tool for this threat class
Magecart attacks operate on timescales that make annual audits irrelevant as a detection mechanism. A script compromise that runs for 78 days -- the average time from exposure to detection in compromised e-commerce environments, based on Vulnox assessment data -- can complete its entire operational lifecycle between QSA visits. The audit confirms that controls were configured correctly at a point in time. It does not detect a script that was clean during the audit and compromised the following week.
The argument for annual audits is that they provide a structured forcing function for compliance program maintenance and that continuous monitoring is operationally burdensome for smaller merchants. Both points are true. They do not make the annual model adequate for client-side skimming threats. The PCI SSC has moved in the right direction with 6.4.3, but an inventory requirement that is verified annually is still an annual control. The threat operates daily.
Organizations performing a framework gap analysis of their e-commerce environment will find the inventory gap quickly. What they will not find through a gap analysis alone is whether a script that was clean at review time remains clean. That requires continuous monitoring, and it requires someone to own the alert queue when it fires.
Counterargument
The strongest counterargument is cost and operational complexity. Real-time script monitoring tools add operational overhead that small merchants cannot staff. An annual inventory is achievable; a continuous monitoring program with active triage may not be. That argument holds for merchants processing a few hundred transactions per month. It does not hold for any merchant processing enough volume to be an attractive skimming target -- at that scale, the fraud liability from a single undetected skimming campaign exceeds the cost of the monitoring tool by a significant margin.
One thing to check before your next deployment
Before your next code push to the checkout page, run a full inventory of every script that loads on it -- first-party, third-party, tag manager-injected. List the domain each script loads from, when it was last verified as authorized, and whether it has an SRI hash. If you cannot produce that list in under an hour, your 6.4.3 implementation is not complete, regardless of what your last audit documented. That list is where Magecart finds its entry point. It is also where your next QSA will start.
Further Reading
PCIDSS
PCI DSS questionnaireGap Analysis
framework gap analysisPCI DSS SAQ types explained: which one applies to your organization
https://vulnox.io/blog/pci-dss-saq-types-explainedPCI DSS Standards Overview
PCI DSS standards overviewPCI DSS Compliance Stripe Guide
PCI compliance guidanceOWASP Testing Methodologies
OWASP testing methodologies
Frequently Asked Questions
Why do e-commerce merchants get breached after passing a PCI DSS audit?
The audit captures a point-in-time snapshot. The breach happens in the drift that follows. In Vulnox assessments, the most consistent post-audit failure is network segmentation degradation -- firewall rules added during a deployment that were never removed, CI/CD pipeline components that created new adjacency to the cardholder data environment, or a plugin update that changed checkout page script behavior. PCI DSS Requirement 11 controls are the ones that degrade fastest between annual reviews.
Does using an iframe for payments qualify my store for SAQ A?
Only if your developers have zero ability to modify the iframe's behavior -- no commit access to the JavaScript served inside it, no control over the payment page code. If developers can touch the iframe's script, you have in-scope systems and SAQ A does not apply. This is the most common SAQ scope error in Vulnox e-commerce assessments. The merchant believes outsourcing the payment page is sufficient for scope reduction. It is not when any of their systems can influence what that page executes.
What does PCI DSS v4.0 Requirement 6.4.3 require for payment page scripts?
Requirement 6.4.3 mandates that all scripts executing on payment pages -- including third-party scripts loaded from external domains -- are authorized, have their integrity verified, and are inventoried. This is a direct response to Magecart-style attacks where malicious scripts were injected via compromised third-party providers. Most e-commerce operators have no such inventory. This requirement became mandatory for all merchants in March 2025.
How often should tokenization encryption keys be rotated under PCI DSS?
PCI DSS Requirement 3.7.4 requires cryptographic key rotation at least annually, or when keys are suspected of compromise. In Vulnox assessments, only 22% of e-commerce platforms using tokenization can demonstrate key rotation within the required period. The failure is almost always the same: rotation was defined as a procedure but never assigned recurring ownership or a verification step.
What is a targeted risk analysis under PCI DSS v4.0 Requirement 12.3.2?
Requirement 12.3.2 mandates a targeted risk analysis whenever an organization implements a customized approach to a PCI DSS control rather than following the defined approach verbatim. The analysis must document the specific risk, the alternative control's effectiveness, and ongoing monitoring. Generic risk statements do not satisfy this. Most merchants encounter this requirement for the first time during a v4.0 audit -- it did not exist in this form in v3.2.1.
What TLS configuration failures appear most often in PCI DSS e-commerce assessments?
The most consistent finding in Vulnox e-commerce scans is TLS 1.0 remaining enabled on Nginx 1.18 payment gateway configurations. TLS 1.0 has been prohibited under PCI DSS since June 2018. It survives because it is a default on older Nginx builds and because automated scans that check for TLS presence do not always validate which versions are still negotiable. The fix is a two-line configuration change. The reason it persists is that post-change verification checks are rarely run.
What financial penalties apply to merchants who fail PCI DSS compliance?
Acquiring banks can fine non-compliant merchants between $5,000 and $100,000 per month. Beyond fines, a confirmed breach triggers forensic investigation costs, card replacement liability, and potential removal from card network programs. For small e-commerce operators, the combination of forensic costs and card replacement liability from a single skimming incident can exceed annual revenue. The monthly fine is typically the smallest part of the financial exposure.
Related Articles
GovRAMP Moderate authorization: why the Significant Change Request process catches providers off guard
GovRAMP Moderate is the first tier where you need a government sponsor, annual 3PAO reassessment, and a Significant Change Request process that can pause normal product releases for months. Most providers who stall post-authorization were not prepared for what maintaining Moderate status actually costs operationally.
GovRAMP Low+ authorization: the impact level that punishes providers who get the CUI boundary wrong
GovRAMP Low+ is where providers handling limited Controlled Unclassified Information land — or discover they should not be there. The defining failure is not a missing control. It is a CUI boundary that was drawn before anyone asked what data the government actually sends through the system.
GovRAMP High authorization: why FIPS-validated crypto and personnel security controls catch providers off guard
GovRAMP High is where cloud providers discover that having strong encryption is not the same as having FIPS 140-2 validated encryption — and that distinction alone has derailed authorizations from vendors who passed every other control family. The architectural constraints at High are qualitatively different from every lower tier.
Ready to Secure Your Digital Assets?
Get a comprehensive vulnerability assessment for your website today.