Magento and Adobe Commerce PCI compliance
Self-hosted means the whole stack is yours, and the extension ecosystem that makes Magento powerful is also the route most attackers took.
TL;DR
Magento and PCI
SELF-HOSTED MEANS SELF-RESPONSIBLE
Unlike a hosted platform, the server, the patching, the extensions and the code are all in your scope.
THE HISTORICAL CONTEXT
Magecart is named after Magento. Early campaigns exploited unpatched installations and vulnerable extensions at scale.
WHERE 6.4.3 LANDS
Every script executing on checkout, which on a typical Magento store means a long list of extensions.
Short on time? The extension ecosystem is the platform's greatest strength and its largest attack surface.
Is Magento PCI compliant?
No, Magento is software rather than a service, so it cannot be compliant on your behalf: compliance depends on how you configure, host, patch and extend it. This is the fundamental difference from a hosted platform. With Shopify, the platform operator carries most of the standard. With self-hosted Magento or Adobe Commerce, you carry the server, the operating system, the patching, the extensions and the code. Adobe Commerce as a managed cloud service shifts some of the infrastructure burden, and the application layer, which is where the client-side requirements live, stays with you either way.
Requirement 6.4.3 is an authorisation record: every script on the payment page, where it came from, and why it is allowed to be there.
Magento PCI compliance and why Magecart shares the name
Magecart is a contraction of Magento and shopping cart. Early campaigns scanned for unpatched Magento installations and known-vulnerable extensions, exploited them, and injected skimmer code directly into the checkout template. It worked at scale because the platform was popular, self-hosted, and frequently behind on patches.
The name stuck even though the technique long since spread to every platform. The lesson that remains specific to Magento is the extension surface: a store with thirty extensions is trusting thirty codebases with full access to the checkout.
What is in your scope on self-hosted Magento
Layer
Who owns it
Server, OS and network
You, or your hosting provider under a shared responsibility model
Magento core patching
You
Extensions and their updates
You
Theme and custom code
You
Payment integration
Shared, depending on whether you use a hosted form or an iframe
Scripts on checkout (6.4.3)
You, entirely
Admin access and MFA
You
Start the inventory from what executes on checkout, not from the extension list.
The extension problem
Extensions are why Magento is chosen and they are the largest single risk on a typical store. An extension can add JavaScript to any page including checkout, can load code from the vendor's own infrastructure at runtime, may be abandoned by its author while remaining installed, and may not be reviewed by anyone after the day it was installed.
For 6.4.3 this means the inventory has to start from what actually executes. An extension list tells you what is installed. It does not tell you what each one loads at runtime, which is where fourth-party scripts enter.
A practical checklist
Patch Magento core promptly. Most historical compromises exploited known, patched vulnerabilities
Audit installed extensions, remove what is unused, and check which are still maintained
Inventory what executes on checkout from real sessions, not from the extension list
Enforce MFA on admin, and restrict admin access by IP where practical
Monitor for changes to checkout templates, which is where injected code traditionally lands
Write a justification per script, which usually removes several extensions from the checkout path
Sources and methodology
PCI DSS requirement text is quoted from PCI DSS v4.0.1 (June 2024), published by the PCI Security Standards Council, which is the current version at the time of writing. Requirements 6.4.3 and 11.6.1 became mandatory on 31 March 2025. Where we describe a competitor, we describe publicly available information and say so when something should be verified with the vendor. We publish this product and that is a bias worth knowing about while you read.
ASK AN AI
Don’t just take our word for it
Ask your assistant what to look for in a tool for PCI DSS 6.4.3 and 11.6.1.
Frequently asked questions
No. Adobe Commerce is software, and the managed cloud offering shifts some infrastructure responsibility. Configuration, extensions, custom code and everything executing on your checkout stay yours.
Commonly SAQ A for a full redirect, or for an embedded provider iframe that meets the script criterion in PCI SSC FAQ 1588. SAQ A-EP where your own site serves the payment fields or scripts that affect them, and SAQ D for stores handling card data directly. A-EP carries 6.4.3 and 11.6.1 in full. Confirm with your acquirer.
Yes, if it keeps card data off your servers by using a hosted form or iframe. It does not remove the checkout page itself from scope, because that is where a script would sit.
Yes, they are the main one in practice. Each extension can add JavaScript to checkout and can load further code at runtime. All of it is in scope for 6.4.3, including code you never explicitly chose.
By recording what actually executes in real sessions. The extension list shows what is installed, not what each extension loads at runtime, and the gap between those two is where the surprises are.
Yes, and no more than other platforms now. The technique spread everywhere years ago. What remains specific to Magento is the size of the extension surface on a typical store.
Yes, mainly in who runs the infrastructure. Adobe Commerce on cloud infrastructure shifts some hosting and patching responsibility. The application and client-side layers are the same in both.
Yes, if you are on an unsupported version. Running software that no longer receives security patches is difficult to defend to an assessor and is how a large share of historical compromises happened.
Yes, through the theme layout, a module, or your tag manager. A self-hosted platform gives you full control over the page, which makes this straightforward compared to a hosted platform.
Unpatched software combined with an unreviewed extension set. Those two account for most historical compromises, and both are addressable without much cost.
Related articles
Platforms
Shopify PCI compliance: what is yours to do
What Shopify handles, what stays with you, and where 6.4.3 lands on a hosted platform.
PCI DSS
PCI DSS compliance: a practical guide for 2026
What the standard covers, what changed in v4.0.1, and where the two client-side requirements fit.
PCI DSS
PCI DSS 4.0.1 requirements: what changed and when
The changes that matter, the dates that already passed, and the two requirements most teams missed.
PCI DSS
How to comply with PCI DSS 6.4.3 and 11.6.1
A step-by-step method, from defining payment-page scope to handing an assessor the evidence.
See every script on your own checkout.
Install the tag, mark your payment pages, and watch the inventory fill in. Free forever on 1,000 page views a month, no credit card.
Free forever plan. No credit card.