PCI Compliance for Magento: What Enterprise Stores Need to Know

In short: PCI compliance for Magento stores means meeting the full PCI DSS v4.0 standard. Since 31 March 2025, that includes 51 previously optional requirements that are now mandatory. Because neither Magento nor Adobe Commerce is PCI certified out of the box, the merchant is responsible for meeting them. The biggest changes for Magento are:

• The new payment-page script controls (Requirements 6.4.3 and 11.6.1)
• Expanded multi-factor authentication
• Self-Assessment Questionnaire (SAQ) level, which depends on whether card data touches your server

The deadline that changed the rules: PCI DSS v4.0

PCI DSS v4.0 introduced 64 new or updated requirements. Of those, 51 were designated as ‘future-dated’: best practices you had time to prepare for, rather than rules enforced immediately. That grace period ended on 31 March 2025. Every one of those 51 requirements is now mandatory and will be assessed in any compliance validation as we advance.

The practical implication is simple but easy to miss. If you validated under PCI DSS v4.0 in 2024 and treated the future-dated items as optional, your next assessment can fail unless those controls are now in place. The standard hasn’t just been updated; it has been fully switched on.

The PCI Security Standards Council’s intent behind v4.0 is moving payment security from a periodic audit into a continuous discipline. With particular focus on the modern threats hitting ecommerce hardest: e-skimming, Magecart-style script injection, phishing and unauthorised access.

Why Magento stores carry more PCI responsibility than other SaaS platforms

PCI DSS applies to any business that stores, processes or transmits cardholder data, regardless of platform.

What differs significantly is who carries the burden of meeting it.

The PCI DSS standard is identical on every platform. However, Magento and Adobe Commerce place far more of the compliance burden on the merchant than fully hosted SaaS platforms like Shopify or BigCommerce. It’s a question we hear at the consideration stage: is PCI compliance the same for Magento as BigCommerce or Shopify?

Fully hosted SaaS platforms like Shopify and BigCommerce are Level 1 PCI DSS compliant as standard. They run the infrastructure, patch it and absorb a large share of the compliance obligation on your behalf. You still have responsibilities, but the platform shoulders most of the heavy lifting. Magento sits at the other end of the spectrum, and this is the part many enterprise teams underestimate. The table below shows how responsibility shifts across the three common models.

With Magento Open Source, neither the platform nor the underlying server is PCI certified out of the box. Initial hardening and ongoing security maintenance are entirely your responsibility – as are TLS configuration, patching, file-integrity monitoring, admin lockdown, quarterly scans and the annual self-assessment.

With Adobe Commerce Cloud, the managed product covers infrastructure-level controls, TLS termination, OS patching, network segmentation and physical security of the AWS environment. Adobe publishes a shared-responsibility model that splits each control into Adobe-owned, shared and merchant-owned. It reduces your burden but doesn’t eliminate it: application-level controls, Magento patch currency, checkout customisations and your SAQ filing remain yours.

To learn more about your broader obligations, read our complete Magento Security Guide.

The three PCI DSS v4.0 changes that hit Magento stores hardest

The three changes with the biggest impact on Magento stores are the new payment-page script controls (Requirements 6.4.3 and 11.6.1), expanded multi-factor authentication and authenticated internal vulnerability scanning. Not every one of the 51 new requirements is equally relevant to your store, but these three account for the bulk of the work for most Magento and Adobe Commerce merchants.

1. Payment-page script management and tamper detection (6.4.3 and 11.6.1)

This is the single biggest change for ecommerce, and the one most directly aimed at the way Magento stores get breached.

Requirement 6.4.3

You must maintain a complete inventory of every script that loads and executes on your payment pages (yours and any third party’s – ),with a documented business justification for each, and a way to confirm it hasn’t been tampered with. Subresource Integrity (SRI) is what does the actual verifying; it checks each script against a known cryptographic hash and blocks it if the file has changed. A Content Security Policy (CSP) works alongside that, controlling which sources are allowed to load scripts in the first place and flagging anything unexpected. The two are strongest together: SRI confirms the integrity of the scripts you already trust, while a CSP limits and monitors what can run at all.

Requirement 11.6.1

This is the detection side of the same problem: you must deploy a change- and tamper-detection mechanism that monitors the scripts and security-relevant HTTP headers your customers’ browsers actually receive, and alerts your team to unauthorised modifications.

Together, these requirements are the standard’s answer to e-skimming, or Magecart, the class of attack where malicious JavaScript is injected into a checkout page to harvest card data in real time, completely bypassing your server-side defences. A typical Magento store loads marketing tags, analytics pixels and chat widgets on or near checkout. Under v4.0, every one of those needs to be inventoried, justified and monitored. For many teams, the hardest part is organisational, not technical: marketing, sales and engineering all have to come to the table to account for each tag.

The risk is acute for this platform in particular. Security firm Sansec reported that the 2024 CosmicSting vulnerability (CVE-2024-34102) left more than 75% of Adobe Commerce and Magento stores exposed, and attackers used it to plant skimmers on thousands of stores. This is exactly the type of client-side theft 6.4.3 and 11.6.1 are designed to catch.

If you’d like to know more on this topic, we’ve outlined the most significant Magento vulnerabilities in another post.

What it costs to get it wrong

The two largest UK penalties for payment-page attacks were both script-injection (Magecart) breaches. The ICO fined British Airways £20m in 2020 after attackers modified JavaScript on its payment pages. The regulator specifically cited a failure to implement multi-factor authentication (MFA) and adequately test its systems. Ticketmaster was fined £1.25m for a 2018 breach that began with compromised third-party chatbot code running on its payment page. Requirements 6.4.3 and 11.6.1 exist precisely to catch this class of attack.

2. Expanded multi-factor authentication

PCI DSS v4.0 broadens MFA requirements well beyond the old expectations. For a Magento store, this most visibly affects access to the admin panel and to any system component within your cardholder-data environment. Single-factor admin logins, still surprisingly common on enterprise stores, no longer meet the standard. Alongside MFA, the password and authentication requirements under Requirement 8 have tightened, so legacy policies are worth reviewing now before your next assessment.

3. Authenticated internal vulnerability scanning and targeted risk analyses

Two quieter but important shifts worth noting.

• Internal vulnerability scans now need to be performed with authenticated access (so the scan sees what an attacker with credentials would see), and v4.0 formalises the use of Targeted Risk Analyses (TRAs) to justify how often you perform certain recurring controls.
• Increasingly, this means you need evidence of a continuous security process throughout the year, not just a clean snapshot at audit time.

Your Magento architecture decides your SAQ

Most Magento stores fall under SAQ A or SAQ A-EP, the lighter questionnaires, as long as cardholder data never touches their server. How much of PCI DSS applies to you depends heavily on that one architectural decision. Magento’s token-based payment architecture, using a payment service provider’s hosted fields or iframe together with Magento Vault, is designed to keep raw card data off your infrastructure entirely. When you get this right, your store typically lands on a lighter SAQ.

SAQ type	Applies when	Typical Magento set-up
SAQ A	All card handling is fully outsourced; card data never reaches your systems	Redirected or fully isolated iframe (shortest questionnaire)
SAQ A-EP	Your pages can affect payment security but never receive card data	Customised checkout that loads payment scripts
SAQ D	You control the payment environment directly or store card data	Self-managed or heavily customised payment handling

The single most effective way to reduce your PCI scope, and your ongoing compliance cost, is to ensure cardholder data never lands on your Magento server in the first place. Architecture is your biggest lever; configuration and process do the rest.

Where to start with compliance for Magento PCI 

PCI compliance for Magento stores is an architecture decision (keep cards off your server), a configuration baseline (TLS 1.2+, admin MFA, hardened access) and an ongoing cycle (monthly patches, quarterly ASV scans, annual SAQ and Attestation of Compliance).

A sensible first pass looks like this:

1. Confirm which SAQ your current checkout architecture puts you in, and whether a change could move you to a lighter one. (Adobe’s official PCI compliance guidelines are a useful reference point.)
2. Build a full inventory of the scripts running on your payment pages, and decide which can be removed.
3. Deploy tamper and change detection monitoring for those pages.
4. Audit admin access for MFA coverage and review your password policy against Requirement 8.
5. Verify your patch cadence and ASV scan schedule are documented and current.

None of this is insurmountable, but it does reward a structured approach. Getting it wrong risks fines, a failed assessment and the reputational damage of a checkout breach.

Key takeaways

• PCI DSS v4.0 is fully enforced: as of 31 March 2025, the 51 previously ‘future-dated’ requirements are mandatory.
• Magento and Adobe Commerce aren’t PCI certified out of the box. The merchant carries the compliance burden, unlike fully hosted SaaS platforms.
• The two requirements that matter most for Magento are 6.4.3 (payment-page script inventory) and 11.6.1 (tamper detection), both aimed at stopping e-skimming and Magecart attacks.
• Your SAQ level (A, A-EP or D) is decided by your checkout architecture; keeping card data off your server is the single biggest scope reducer.
• Treat PCI as a continuous operational cycle – patching, scanning and evidence-keeping year-round – not an annual checkbox.

How Bright can help with Magento PCI compliance

PCI compliance for Magento stores is an ongoing discipline, and it’s exactly the kind of work Bright’s Magento and Adobe Commerce specialists handle every day.

Our team has secured and maintained 100+ stores, with critical security patches deployed within 24-48 hours and a track record of five successful penetration tests earning “Strong” security ratings. We can support enterprise stores with complex Magento and Adobe Commerce migrations with a 100% zero data loss record. So if moving to a lighter SAQ means changing your checkout architecture, we can make that transition without risking your data or your uptime.

We can help you:

• Audit your payment-page scripts and build the inventory Requirement 6.4.3 demands, then implement SRI and CSP to lock it down
• Deploy tamper and change detection monitoring to satisfy Requirement 11.6.1
• Review and harden admin access, closing out MFA and password-policy gaps under Requirement 8
• Assess your checkout architecture to confirm your SAQ level, and re-architect it if a lighter questionnaire is within reach
• Set up a continuous patching and ASV scan cadence, with documentation ready for your annual SAQ and Attestation of Compliance

With over 37 years of combined senior development experience in our team, and deep specialism in Magento and Adobe Commerce specifically (not ecommerce platforms in general), we know where these stores actually get breached and how to close those gaps without disrupting your trading.

If you’re worried about your PCI DSS v4.0 exposure, get in touch with Bright’s Magento specialists for a compliance audit and a clear, prioritised action plan.

Frequently asked questions

Is Magento PCI compliant out of the box?

No. Neither Magento Open Source nor Adobe Commerce is PCI certified on its own, PCI compliance is the merchant’s responsibility. On Adobe Commerce Cloud, Adobe certifies the underlying infrastructure but you remain responsible for your application, custom code, extensions, configuration and annual self-assessment.

Is PCI compliance the same for Magento and Adobe Commerce?

The standard is identical: Magento is now Adobe Commerce, and PCI DSS applies the same way to both. The practical difference comes down to hosting: a self-hosted Magento Open Source store carries the full compliance burden, while Adobe Commerce Cloud covers infrastructure-level controls and shares the rest under a defined responsibility model. The requirements you must meet don’t change; how much of the work falls to you does.

Does PCI DSS apply differently to Magento than to Shopify or BigCommerce?

The requirements are the same for every platform. What differs is responsibility. Fully hosted SaaS platforms are Level 1 PCI compliant by default and absorb most of the burden, whereas Magento and Adobe Commerce give you more control over your stack and, with it, more direct responsibility for meeting and evidencing the controls.

What SAQ does a Magento store need?

It depends on whether cardholder data touches your systems, and that comes down to how you integrate your payment provider. Stores that fully outsource card handling often qualify for SAQ A. This means a redirect or fully hosted payment page, where the shopper enters their card details on the provider’s own domain (a PayPal-style redirect) and the data never reaches Magento. Stores whose pages can affect payment security but never receive card data typically fall under SAQ A-EP. This is the common Magento pattern of embedded hosted fields or an iframe (Adyen, Stripe, Braintree), where you only ever handle a token, not the card number. Stores that capture or store card data directly complete the full SAQ D, the heaviest questionnaire.

Keeping cards off your server, through a redirect or isolated hosted fields with tokenisation, is the most effective way to land on a lighter questionnaire.

What are PCI DSS requirements 6.4.3 and 11.6.1?

They’re the two PCI DSS v4.0 requirements aimed at stopping e-skimming or Magecart attacks. Requirement 6.4.3 requires you to inventory, justify and verify the integrity of every script on your payment pages. Requirement 11.6.1 requires a mechanism that detects and alerts to unauthorised changes to those scripts and security-relevant HTTP headers. Both are now mandatory since 31 March 2025.

What happens if my Magento store isn’t PCI DSS v4.0 compliant?

Non-compliance can mean monthly fines from your acquirer, a failed assessment, higher transaction costs and, most damagingly, full liability and reputational fallout if a checkout breach exposes customer card data. Because v4.0’s future-dated requirements are now enforced, outdated approaches may no longer pass as acceptable.