Is Magento PCI compliant?
Short answer Magento PCI compliance is the setup and the yearly audit routine that let a Magento store meet PCI DSS v4.0, whose new requirements became mandatory on 2025-03-31. Neither Magento Open Source nor Adobe Commerce is “PCI compliant” on its own. The merchant is responsible. What Magento gives you is a way to keep card numbers off your server: the payment provider’s iframe or hosted fields take the card, and Magento_Vault stores only a token. Most stores I work on end up on SAQ A or SAQ A-EP that way. The rest is ordinary hygiene: TLS 1.2+, admin 2FA, security patches applied on time, quarterly ASV scans and the yearly SAQ and AoC.
- Pick a PCI-compliant PSP that keeps cards off your server 01
- Configure HTTPS everywhere, TLS 1.2 floor, 1.3 preferred 02
- Lock down the admin, 2FA, strong passwords, rename /admin 03
- Apply Adobe security patches every month 04
- Run quarterly ASV scans + annual SAQ + AoC 05
Most common mistake Storing card numbers in the database “just for refunds”
Five steps to a PCI-compliant Magento store
There is no PCI switch in the admin. It is one design choice (keep cards off the server), some configuration (TLS, 2FA, a locked-down admin) and a routine you repeat every year (patches, scans, SAQ). This is the order I set it up in.
-
01
Pick a PCI-compliant PSP that keeps cards off your server
The biggest scope cut is never letting cardholder data (CHD) reach the Magento server. Stripe, Adyen, Braintree and Authorize.Net Accept Hosted all take the card in an iframe or on a redirect page they control, so the card number, CVV and expiry never touch your PHP code, your logs or your database. That one choice is the difference between the long
SAQ Dand the much shorterSAQ AorSAQ A-EP. For repeat purchases,Magento_Vaultkeeps the provider’s token, not the card. -
02
Configure HTTPS everywhere, TLS 1.2 floor, 1.3 preferred
TLS 1.0 and 1.1 are not acceptable for anything that carries card data, and that includes the page that hands the shopper to the payment provider. In nginx (or Apache) I set
TLS 1.2as the minimum, allowTLS 1.3, redirect all HTTP to HTTPS and turn onHSTS. In the admin, set the secure base URLs underStores > Configuration > General > Web > Base URLs (Secure)tohttps://and setUse Secure URLs on StorefrontandUse Secure URLs in AdmintoYes. An ASV scan will flag a weak protocol or cipher on the first run. -
03
Lock down the admin, 2FA, strong passwords, rename /admin
A stolen admin login is one of the most common ways Magento stores get skimmed. 2FA has been on by default since Magento 2.4.0 and is configured under
Stores > Configuration > Security > 2FA, with Google Authenticator, Duo and other providers. Keep the admin session lifetime short, require strong passwords with a forced change interval underAdvanced > Admin > Security, and change the admin path inapp/etc/env.phpunderbackend.frontNameso bots hitting/adminfind nothing. If your team works from fixed IPs, I also restrict the admin path to those IPs in nginx. -
04
Apply Adobe security patches every month
Adobe publishes Magento security fixes in its APSB security bulletins, on a regular release schedule plus the odd emergency hotfix. An unpatched
2.4.xstore is a quick way to fail an ASV scan and an easy target for attackers who read the same bulletins. I update withcomposer require magento/product-community-editionto the latest security release, test on staging, then deploy. PCI DSS expects critical security patches within one month of release, so plan for that window. -
05
Run quarterly ASV scans + annual SAQ + AoC
PCI is a cycle you repeat. An ASV (Approved Scanning Vendor) such as
TrustwaveorSecurityMetricsscans your public IPs every90 daysfor open ports, unpatched packages, weak TLS and known CVEs. Once a year you fill in the right SAQ (Self-Assessment Questionnaire) and sign the AoC (Attestation of Compliance) for your acquiring bank. A missed scan counts as non-compliance even if nothing on the store is actually broken.
Four moments PCI compliance is the front-of-mind question
PCI applies to every store that takes cards. These are the four moments when I stop and check the scope again before the next change goes live.
-
Going live with any Magento store that accepts cards
PCI DSS applies to every merchant that stores, processes or transmits card data. There is no minimum order volume and no “too small to matter” exemption, and using a payment provider does not move the responsibility off you. Once the store takes cards, you owe an SAQ and the scans. If the checkout uses a Stripe, Adyen or Braintree iframe and
Magento_Vaultfor tokens, you are usually in SAQ A scope, and most of the work is a checklist rather than development. -
Annual PCI re-certification (the SAQ + ASV cycle is annual)
PCI is not a once-and-done certificate, the SAQ is renewed every
12 monthsand the ASV external scan repeats every90 days. Bake the schedule into your operations calendar: quarterly scans (one per quarter, never four in December), annual SAQ in a slack month for the dev team, AoC signed by an executive officer. Miss the cycle and your acquiring bank can escalate fees, suspend processing, or impose a forensic PCI investigation. The annual review is also the moment to audit changes since last year that might have moved you into a higher SAQ tier without you noticing. -
Onboarding a new card processor or PSP
Every PSP requires you to attest to PCI compliance before they enable production card processing, some ask for your AoC up front, others trust you to self-certify but reserve the right to demand it after the fact. Migrating from Stripe to Adyen, or adding a regional PSP alongside your main rail, is the natural moment to re-verify your SAQ tier, the new PSP’s integration shape might land you in a different scope tier. Hosted fields vs full redirect is the most common gotcha: Adyen Drop-in is hosted fields =
SAQ A-EP; Adyen Pay by Link is redirect =SAQ A. -
Any custom checkout customization that touches payment
This is where teams accidentally move themselves from SAQ A to SAQ A-EP or even SAQ D without realising. Replacing the PSP’s iframe with a custom-built card form “because we want the brand to look better” pulls the card data through your JavaScript, you’re now in
SAQ A-EPwith e-skimming controls, web-app vuln scans every 6 months, and content-security-policy proofs. Routing card data through any Magento controller or observer puts you inSAQ D. Always audit checkout customizations against the PCI scoping flowchart before you ship them. The compliance cost of a vanity custom checkout almost never clears the conversion delta.
Three Magento PCI mistakes that fail the next ASV scan
Every PCI-remediation engagement I’ve been called in to fix came from one of these three patterns. Audit your store for these before the next quarterly scan.
-
Storing card numbers in the database “just for refunds”
Even one row of PAN (Primary Account Number) data in your Magento database drags you from
SAQ Aall the way toSAQ D, 350+ controls, quarterly internal scans, segmentation testing, the works. Refunds do not require the original card number; the PSP token (saved-payment-method) is enough. Magento’sMagento_Vaultmodule is built exactly for this, it stores the PSP’s reusable token, not the card. If you ever find a developer wrote a customcustomer_card_numbercolumn, the only safe fix is to securely wipe it, then run a forensic check to confirm no backups, no logs, and no replicas still hold the data. -
Disabling admin 2FA “because it slows me down”
2FA is mandatory in
PCI DSS v4and in Magento2.4.0+. Disabling it viabin/magento msp:security:tfa:disableis an automatic SAQ failure and an explicit compliance breach, if you suffer an admin compromise with 2FA disabled, your acquiring bank can refuse to honour the breach insurance and your QSA can escalate to a forensic investigation. The five seconds an admin saves per login is not worth the personal-liability exposure for the executive who signed the AoC. If 2FA is genuinely a friction point, ship hardware keys (YubiKey) instead of TOTP apps, one tap, no codes to type. -
Running unsupported Magento versions
Adobe stops shipping security patches for older
2.4.xlines on a published schedule (currently2.4.4and earlier are out of support). Running an unsupported version means missing patches for CVEs that your ASV scanner will detect on the next quarterly scan, immediate compliance failure, even before anyone actually exploits the bug. The remediation is always “upgrade to the latest2.4.xsecurity release”, which on a heavily customised store is a multi-week project. Plan upgrades around the Adobe end-of-life calendar (currently visible atexperienceleague.adobe.com) rather than waiting for the ASV to fail you.
Magento PCI Compliance, frequently asked questions
-
Is Magento PCI-compliant out of the box?
No, and that is an important distinction. Magento Open Source and Adobe Commerce are built to BE compliable (token-only payment architecture since 2.0, mandatory admin 2FA since 2.4.0, monthly security patches from Adobe, encrypted env.php key), but the store operator is the entity that signs the SAQ and the AoC. The merchant is responsible for: TLS configuration, admin lockdown, patch currency, file-integrity monitoring, WAF, quarterly ASV scans, annual SAQ, and the operational controls around staff access. Out of the box you are about 60% of the way to SAQ A on a fresh install, the remaining 40% is configuration plus the ongoing scan / audit cycle. -
SAQ A vs SAQ A-EP vs SAQ D, which applies to my store?
Depends entirely on how the card data is captured at checkout. SAQ A (~22 controls) applies if your checkout is a full PSP redirect or a PSP-controlled iframe, the card form lives on Stripe’s, Adyen’s, or Braintree’s domain, and your server never sees the card data. SAQ A-EP (~80 controls) applies if you use hosted fields, the card input is on your page but the form posts directly to the PSP, with your JavaScript orchestrating the flow. This pulls e-skimming controls into scope. SAQ D (~350 controls) applies if your server ever touches the PAN, full custom checkout, MOTO over the phone, or a developer storing card data. Most well-built Magento stores land on SAQ A or SAQ A-EP. -
Does Adobe Commerce Cloud cover PCI compliance for me?
Partially. Adobe Commerce Cloud (the managed AWS-hosted SaaS) covers infrastructure-level PCI controls: TLS termination, OS patching, network segmentation, WAF, intrusion detection, and physical-security attestation for the underlying AWS environment. Adobe publishes a Customer Responsibility Matrix that splits the controls into Adobe-owned, shared, and merchant-owned. The merchant still owns: application-level controls (admin 2FA, password policy, role-based access), Magento patch currency on top of Cloud’s base image, checkout customizations that affect SAQ tier, the annual SAQ and AoC filing, and quarterly ASV scans of any non-Cloud touchpoints. Cloud reduces the burden meaningfully but does not eliminate it. -
What changes in PCI DSS v4.0 vs v3.2.1?
PCI DSS v4.0 became mandatory 2025-03-31 and tightens several controls. Highlights: annual scope confirmation, you must re-verify your PCI scope every 12 months rather than at major-change moments only; MFA on all CHD access, not just admin, any account that can reach cardholder data needs MFA, not just /admin users; stronger password rules, minimum 12 characters (up from 7) for non-shared accounts, mandatory rotation removed if continuous monitoring is in place; e-skimming controls, new requirements 6.4.3 and 11.6.1 force you to inventory and integrity-check all scripts on the payment page; web-app vulnerability scans every 6 months instead of just at major changes. -
Do I need an annual penetration test for my Magento store?
It depends on your SAQ tier. SAQ A stores are not strictly required to commission an external pen test, but it is strongly recommended as defence in depth, ASV scans only check external network surface, not application logic. SAQ A-EP and SAQ D require an annual external penetration test and an internal one as well, both performed by a qualified third party. Scope must include the network perimeter, segmentation controls, and the cardholder data environment (CDE). Pen tests typically cost$5,000 to $20,000depending on scope and tester. Pick a tester certified by CREST, OSCP, or with PCI-specific accreditation, their report needs to satisfy your QSA at the annual review. -
How does the Magento crypt-key relate to PCI compliance?
The crypt-key (inapp/etc/env.php) is the symmetric AES-256-CBC key that Magento uses to encrypt saved payment-method tokens, payment-method credentials, and other sensitive config in the database. From a PCI perspective, the crypt-key is treated as a token-protecting key, losing or sharing it is functionally equivalent to a token compromise, and your incident-response plan should treat it as a reportable event. Rotate the crypt-key viabin/magento encryption:key:change; Magento will re-encrypt all encrypted columns with the new key in a single migration. Store the env.php outside of git (it is in.gitignoreby default for good reason), restrict file permissions to640with the web user as owner, and audit every staff member who has SSH access to the production server.
Want a PCI scoping review of your Magento store?
Send your storefront URL, I will audit your checkout architecture, identify your SAQ tier, flag any custom code that drifts scope, check TLS / 2FA / patch currency, then reply with a written remediation plan, fixed-price quote, and earliest start date. 24-business-hour turnaround.