Send a brief
Menu

What is Magento PCI Compliance?

Magento PCI compliance is the operator-side configuration and audit cycle that makes a Magento store satisfy PCI DSS v4.0 (fully enforced 2025-03-31). Neither Magento Open Source nor Adobe Commerce are PCI-certified out of the box, the merchant is responsible. Magento’s token-only architecture (PSP iframe/hosted fields + Magento_Vault) keeps the server out of cardholder-data scope, landing most stores on SAQ A or SAQ A-EP. Key controls: TLS 1.2+, encrypted crypt-key, admin 2FA, monthly patches, quarterly ASV scans, annual SAQ + AoC.

Send a brief WhatsApp first
  • Standard PCI DSS v4.0, fully enforced since 2025-03-31
  • Default scope SAQ A (redirect/iframe) or SAQ A-EP (hosted fields)
  • Since 2.4.0 Admin 2FA mandatory, non-negotiable

Five steps to a PCI-compliant Magento store

PCI compliance is not a single switch, it is an architecture decision (keep cards off-server) plus configuration (TLS, 2FA, admin lockdown) plus ongoing cycle (patches, scans, SAQ). Here is the wiring.

  1. 01Pick a PCI-compliant PSP that keeps cards off your server

    The single biggest PCI scope reducer is never letting cardholder data (CHD) touch the Magento server. Stripe, Adyen, Braintree, and Authorize.Net Accept Hosted all route the card entry through a PSP-controlled iframe or full redirect, so the card number, CVV, and expiry never hit your application code, your logs, or your database. That single architectural decision moves you from SAQ D (350+ controls) to SAQ A or SAQ A-EP (22-80 controls). Magento’s Magento_Vault module then stores the PSP token, not the card, for future charges.

  2. 02Configure HTTPS everywhere, TLS 1.2 floor, 1.3 preferred

    PCI DSS v4 explicitly bans TLS 1.0 and 1.1 on any system that transmits CHD, including the redirect that hands the shopper to the PSP. Configure nginx (or Apache) to require TLS 1.2 minimum, prefer TLS 1.3, redirect all HTTP to HTTPS, and enable HSTS with a long max-age. In Magento admin set Stores → Configuration → Web → Base URLs (Secure) to https:// for both storefront and admin and set Use Secure URLs on Storefront / in Admin to Yes. ASV scans will flag a weak TLS cipher on day one.

  3. 03Lock down the admin, 2FA, strong passwords, rename /admin

    Admin compromise is the #1 attack vector. Mandatory 2FA via Stores → Configuration → Security → 2FA (Google Authenticator, Duo, or U2F) is non-negotiable since Magento 2.4.0. Set session lifetime to 900 seconds (15 min idle), enforce passwords of 8+ chars with mixed-case + number + symbol, rotate every 90 days, and rename the admin URL via app/etc/env.php backend.frontName, /admin is the first path every bot hits. IP-whitelist the admin via nginx if your team has fixed IPs.

  4. 04Apply Adobe security patches every month

    Adobe ships Magento security patches on a roughly monthly cadence (Security Bulletins at magento.com/security). Running an unpatched 2.4.x version is the fastest route to a PCI ASV scan failure, the scanner fingerprints your Magento version and cross-references the public CVE list. Run composer require magento/product-community-edition with the latest security release, deploy through staging, and never let the gap between current Adobe release and your production version exceed 30 days. Track the PSIRT advisories so you know which patches are critical.

  5. 05Run quarterly ASV scans + annual SAQ + AoC

    PCI compliance is an ongoing cycle, not a one-time install. Engage a QSA (Qualified Security Assessor) like Trustwave, Coalfire, or SecurityMetrics, their ASV scanner (Approved Scanning Vendor) hits your public IPs every 90 days and flags open ports, unpatched OS packages, weak TLS, and known CVEs. Annually you complete the appropriate SAQ (Self-Assessment Questionnaire) and sign the AoC (Attestation of Compliance), which you share with your acquiring bank. Missing scans = compliance breach, even if nothing is actually broken.

Four moments PCI compliance is the front-of-mind question

PCI is always applicable on a card-accepting store, but these four moments are when teams should explicitly stop and re-verify scope before shipping the next change.

  • Going live with any Magento store that accepts cards

    PCI DSS applies to every merchant that stores, processes, or transmits cardholder data, full stop. There is no minimum transaction threshold, no “we’re too small to bother” exemption, and no PSP that absorbs the merchant’s responsibility. The moment your Magento store starts accepting payment cards, you are on the hook for an SAQ + ASV scans. The good news: if your checkout uses a Stripe / Adyen / Braintree iframe and Magento’s Magento_Vault for tokens, you’re typically in SAQ A scope, the easiest tier, and the controls are mostly checklist items rather than engineering work.

  • Annual PCI re-certification (the SAQ + ASV cycle is annual)

    PCI is not a once-and-done certificate, the SAQ is renewed every 12 months and the ASV external scan repeats every 90 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-EP with 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 in SAQ 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 A all the way to SAQ 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’s Magento_Vault module is built exactly for this, it stores the PSP’s reusable token, not the card. If you ever find a developer wrote a custom customer_card_number column, 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 v4 and in Magento 2.4.0+. Disabling it via bin/magento msp:security:tfa:disable is 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.x lines on a published schedule (currently 2.4.4 and 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 latest 2.4.x security release”, which on a heavily customised store is a multi-week project. Plan upgrades around the Adobe end-of-life calendar (currently visible at experienceleague.adobe.com) rather than waiting for the ASV to fail you.

Where PCI compliance touches the rest of the Magento stack

Five neighbour concepts most readers want to look at next. Click through for the full deep-dive.

Read the entryRead the entry

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, $20,000 depending 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 (in app/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 via bin/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 .gitignore by default for good reason), restrict file permissions to 640 with 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.

Send a briefWhatsApp