Magento PCI Compliance: A QSA's Guide for Open Source and Adobe Commerce Stores

Magento PCI compliance is the merchant’s responsibility, not the platform’s. No edition of Magento Open Source or Adobe Commerce makes a store PCI compliant on its own. What you must do depends mainly on how your checkout collects card data and who runs the hosting. A store that sends customers to a payment provider’s hosted page, or shows card fields inside the provider’s iframes, usually validates with SAQ A. A store whose own pages collect card data and post it from the browser needs SAQ A-EP, and card data passing through Magento’s servers means SAQ D. Level 1 merchants are normally asked for a Report on Compliance whatever their checkout.

This guide covers what is specific to Magento. For the payment page script rules in depth, see our guide to PCI DSS 6.4.3 and 11.6.1.

Is Magento PCI compliant?

Magento cannot be PCI compliant by itself, because PCI DSS applies to organisations, not software. Each merchant validates its own compliance to its acquirer every year. What changes between the ways of running Magento is how much of the stack you operate, and so how much you must evidence.

Even on Adobe’s cloud, you must show which requirements Adobe covers. Ask for Adobe’s current Attestation of Compliance and responsibility matrix each year: PCI DSS 12.8.4 and 12.8.5 require you to monitor each service provider’s compliance status and record which requirements it manages. The same applies to your hosting company, payment provider and any agency with access to your store.

PCI compliant Magento hosting: what your host’s AOC covers

A Magento host advertised as PCI compliant has had its own hosting services assessed against PCI DSS. Its Attestation of Compliance for service providers covers the data centres, hardware and any services it manages for you, such as operating system patching, firewalls or backups, and only those listed in the AOC. It does not cover Magento itself, your extensions, admin users or checkout.

Before you rely on PCI DSS Magento hosting, check three things:

Our guide to PCI compliant hosting lists the questions to ask a host before you sign.

Which SAQ does a Magento store need?

The payment module decides. Two stores on the same Magento version can sit in different SAQs because their payment extensions work differently.

Check what the module actually does, not what its listing says. Open the checkout in your browser’s developer tools and confirm whether the card fields load from the provider’s domain inside iframes, then run our free PCI compliance check for a first view of your likely SAQ and gaps. Our guide to PCI SAQ A vs SAQ A-EP sets out the eligibility rules, the SAQ documents themselves are in the PCI SSC document library, and our PCI compliant payment gateway guide lists what to ask your provider for.

Phone orders keyed into the admin need their own scoping decision; see our guide to taking card payments over the phone.

Why are Magento stores a target for card skimming?

Digital skimming was first widely documented on Magento stores, which is where the name Magecart comes from. The platform’s popularity, its large extension ecosystem and the number of self-hosted stores that fall behind on patches have kept it a target. Skimming code usually reaches a Magento checkout in one of four ways:

• Unpatched core flaws. Critical vulnerabilities such as CVE-2022-24086 and CVE-2024-34102 (known as CosmicSting) were exploited against stores that had not applied Adobe’s fixes.
• Vulnerable or abandoned extensions, which run with the same privileges as Magento’s own code.
• Stolen admin credentials. Anyone with admin access can add script through settings such as the HTML head and footer fields in design configuration, or through CMS blocks, without changing a single file.
• Compromised third-party scripts, such as analytics, chat or review tags loaded on checkout pages.

The last two leave your code base untouched, which is why file integrity monitoring on the server cannot be your only control.

How do 6.4.3 and 11.6.1 apply to a Magento checkout?

If your checkout puts you in SAQ A-EP or SAQ D, both requirements apply in full: every script on the payment page must be authorised, integrity-assured and listed in an inventory with a written justification (6.4.3), and you must detect unauthorised changes to those scripts and to security-impacting HTTP headers at least every seven days, or as often as a targeted risk analysis sets (11.6.1). Both have been mandatory since 31 March 2025. Under SAQ A they are replaced by an eligibility criterion for stores that embed the provider’s payment form in iframes: you confirm your site is not susceptible to attacks from scripts. The PCI SSC has clarified that this criterion does not apply to stores that redirect customers to the provider’s payment page.

Magento helps with part of this. Its Content Security Policy module, added in version 2.3.5, controls which sources a page may load scripts from. From version 2.4.7, payment pages in the storefront and admin default to restrict mode, with other pages in report-only mode. Inline scripts then need a nonce or an allowlist entry, which can break payment extensions and tag manager snippets after an upgrade, so test the checkout in staging first.

A Content Security Policy is not the whole answer. It does not write your script inventory or justifications, it does not notice when an allowed third-party script changes its contents, and it does not check the page as customers receive it. The OWASP Content Security Policy Cheat Sheet explains what it can and cannot do.

How should you harden Magento for PCI DSS?

Hardening is mostly configuration and housekeeping. Which of these requirements your SAQ includes depends on your checkout.

Adobe’s free Security Scan Tool checks Magento stores for missing patches and known malware. Run it, but treat it as a health check: it is not an ASV scan.

How often should you patch Magento?

As soon as you can, and within one month of release for patches that fix critical vulnerabilities, which is what PCI DSS 6.3.3 requires; other security patches go in within a time frame you set from your risk ranking. Adobe publishes security bulletins for Magento Open Source and Adobe Commerce and offers security patch releases that carry fixes without a full feature upgrade. If your checkout embeds the provider’s card fields in iframes, an unpatched store also undermines the SAQ A confirmation that your site is not susceptible to script attacks.

Watch Adobe’s lifecycle policy as well. Release lines that reach end of support stop receiving patches, and Requirement 12.3.4 asks you to review your technologies at least once every 12 months, with a plan for anything approaching end of life. Magento 1 reached end of life on 30 June 2020 and receives no security patches from Adobe, so a store still running it should treat migration as the priority.

What testing does Magento PCI compliance require?

Your SAQ lists exactly which tests apply. A Magento penetration test should cover the checkout and customer account flows, the admin, the REST and GraphQL APIs and the installed extensions, which is the depth of our web application penetration testing. Even under SAQ A, where penetration testing is not required, a test is the most direct way to find the flaws skimmers use.

Why Sovereign Secure?

Sovereign Secure is a PCI SSC-approved Qualified Security Assessor (QSA) company, Qualified PIN Assessor (QPA) and Card Production Security Assessor (CPSA), and a member of the PCI SSC Global Executive Assessor Roundtable for 2026 to 2028. For Magento and Adobe Commerce merchants we:

• Confirm which SAQ your checkout supports and review your payment page controls before you validate.
• Test the store: checkout, accounts, admin, APIs and extensions.
• Arrange quarterly ASV scans, delivered through our PCI SSC Approved Scanning Vendor partner.
• Carry out the full assessment where your acquirer requires a Report on Compliance.

Where we both advise on and assess the same environment, we work within the PCI SSC’s independence requirements for QSA companies. Sovereign Secure Ltd was incorporated in 2012 and is headquartered in Accrington, Lancashire, with offices in Los Angeles, Singapore, Dubai and Dhaka. See also our page on retail and e-commerce cyber security.

What should you do next?

Note your Magento edition and version, your hosting model and the payment module you use, then check in the browser how the card fields are delivered. Send us those details through the enquiry form on this page or call +44 161 523 5276. We will tell you which SAQ your checkout supports and quote a fixed price for the scans, testing or assessment you need.