PCI DSS 4.0.1: New Rules for Online Shops

In this article, we summarize the most important findings from our webinar with the Magento experts from basecom. Included: practical examples, helpful tools and clear to-dos. You will find out what measures you should take now to make your store system PCI-compliant and future-proof.

Tip in advance: Do you want to understand what PCI DSS is all about first? Then take a look at our basic article: PCI DSS: What e-commerce merchants need to know.

What is PCI DSS 4.0.1 - and why does it affect retailers?

PCI DSS stands for Payment Card Industry Data Security Standard. The standard has existed since 2004 and defines security requirements for anyone who stores, processes or transfers credit card data - including many e-commerce merchants.

Version 4.0.1 tightens the focus on technical security, traceability and clear processes. And: Even if you do not store credit card data directly, your store may be affected.

Important: Even the integration of a payment service provider via iFrame or script in the checkout is sufficient to fall under the scope of application.

Aim of PCI DSS 4.0.1:

• Protect credit card data and personal information even better
• Prevent security gaps and misuse
• Avoid fines and legal consequences

Many requirements that were previously only recommended will be mandatory from April 2025 - including, for example

• Two-factor authentication (2FA) for admins
• Stronger password guidelines
• Regular security scans by certified providers
• The use of a content security policy (CSP) in check-out

Many requirements that were previously only recommended will be mandatory from April 2025 - including, for example

• Two-factor authentication (2FA) for admins
• Stronger password guidelines
• Regular security scans by certified providers
• The use of a Content Security Policy (CSP) at check-out

What specifically changes with PCI DSS 4.0.1?

PCI DSS 4.0.1 not only brings an update, but a real paradigm shift: Many technical and organizational measures that were previously only considered “best practice” will be mandatory from April 2025 - and thus part of the audit or SAQ (Self-Assessment Questionnaires).

To help you keep track, we have summarized the most important changes for you - with a focus on Magento and typical set-ups in e-commerce.

Two-factor authentication (2FA) becomes mandatory

All access to the admin backend must be secured with 2FA with immediate effect. This means that a simple login with username and password is no longer sufficient.

Magento already offers this function in the core - however, many store operators had deactivated it or only used it for selected accounts.

Important for you:

• Activate 2FA for all admin accesses
• If necessary, remove older extensions that allow bypassing
• Document your 2FA policy in the security concept

Stronger password guidelines

Clear guidelines now also apply to passwords. The following applies to admin accounts:

• At least 12 characters
• Regular change (rotation e.g. every 90 days - if no 2FA)
• No reuse of previous passwords

Magento itself does not yet meet these requirements as standard - but a pull request has already been submitted. Until then, a separate module or individual configuration will help.

Practical tip from the webinar: If you use 2FA consistently, you can dispense with regular password changes - which improves usability and still remains secure.

Security scans: Now mandatory

Whether a regular vulnerability scan is mandatory depends on the respective SAQ level.

For SAQ A-EP or more complex payment setups, these scans are mandatory - at least every 90 days.

They are not mandatory for a full redirect (e.g. SAQ A), but are nevertheless strongly recommended in order to identify and rectify potential security vulnerabilities at an early stage.

An overview:

In Germany, the following providers are currently certified as Approved Scanning Vendors (ASV):

• SRC GmbH (Bonn)
• USD AG (Neu-Isenburg)

Clear responsibilities

Who is allowed to do what in the system? Who is responsible for security? PCI DSS 4.0.1 requires a clear allocation of roles and documentation of all security-relevant responsibilities - from deployment to emergency response.

In concrete terms, this means

• Defined processes for access rights, deployments and updates
• Clear escalation paths in the event of incidents
• Regular review and logging of all security-critical actions

No storage of credit card data

Even if it sounds banal: credit card data must never be stored in the store - neither deliberately nor accidentally.

If you rely on external payment providers such as PayPal, Stripe or Klarna and process everything via redirect or iFrame, you not only reduce the risk, but also significantly reduce your own PCI DSS effort.

Content Security Policy (CSP): protective shield at checkout

Checkout is a particularly sensitive area in online stores - this is where customer data, payment information and tracking scripts come together. A popular attack vector for e-skimming or cross-site scripting (XSS). This is why PCI DSS 4.0.1 focuses on a security mechanism that is often underestimated: the Content Security Policy (CSP).

What is a CSP anyway?

The Content Security Policy is an HTTP header that precisely specifies to the browser:

• Which scripts and resources may be loaded
• Which domains they must originate from
• How inline scripts, styles and iframes are handled

In short: CSP acts like a security filter at browser level - and blocks everything that has not been explicitly permitted. This effectively prevents many typical attacks before they even take place.

CSP in Magento - this is already integrated

Magento has included a solid CSP framework since version 2.3.5. This offers you:

• A rule-based system directly in the code (not in the admin area - deliberately for security)
• A report-only mode for all pages except the checkout
• Support for Subresource Integrity (SRI) for locally integrated files

Important: In the checkout area, the CSP must run in “Enforced” mode - otherwise your setup is not PCI-compliant.

How the implementation works in practice

CSP rules must be individually adapted to your store - depending on which scripts, fonts, tools or pixels you use. There are two proven ways to maintain your whitelist:

Variant 1: Manually with browser extension

• With tools such as the Magento CSP Whitelist Generator, you can click through the checkout
• The tool generates an .xml file for your whitelist
• You must then deploy this file to the project

Disadvantage: Changes to scripts or external sources require a new deployment each time.

Variant 2: Automated CSP monitoring

• Tools such as Sansec Watch, Sentry or the CSP module from IntegerNet
• Violations are automatically detected and processed as a report
• Whitelist can be maintained directly via a web UI and transferred if required
• Synchronization with Magento is automated

Best practice: Combine Sansec Watch with the CSP module from integer_net for a convenient and audit-proof solution - without any manual deployments.

Typical pitfalls & solutions

Technical measures: How to implement PCI DSS 4.0.1 in your Magento store

Many of the new PCI DSS 4.0.1 requirements specifically affect the technical operation of your store. Good news: Magento already meets many of the requirements - you just need to actively use them and configure them correctly. Here are the most important points that you should check now (and adjust if necessary).

Activate two-factor authentication (2FA)

In future, access to the Magento admin panel must be secured by two-factor authentication. This was previously only “best practice” - now it is mandatory.

• Magento already supports 2FA out of the box
• Attention: Deactivation is no longer permitted
• Check existing admin users - and only assign necessary roles!

No longer use extensions that disable or bypass 2FA. These are not PCI-compliant and pose a security risk.

Adjust password policy & session timeout

PCI DSS 4.0.1 requires stronger password rules for admin access:

• At least 12 characters
• No reuse (history)
• Regular change - every 90 days (if no 2FA is activated)

Magento currently only allows 7 characters - Basecom has already submitted a pull request to Adobe. Until then you can:

• implement your own password requirements in the code or via module
• Use your own security module

Also mandatory: an automatic session timeout after 15 minutes of inactivity. You can set this directly in the Magento configurations.

Access control with ACL

Magento offers a finely granular controllable Access Control List (ACL) system. Use it to:

• Assign roles and rights precisely
• Avoid shared accounts
• Check access rights regularly
• Maintain documentation: Who is allowed to do what - and why?

A regular rights check is part of the PCI documentation and can be queried in the audit.

Close points of attack: Deactivate what you don't need

“Reduce your attack surface” - a central idea of PCI DSS. Deactivate everything that is not absolutely necessary:

• SOAP / GraphQL APIs, if not used
• Default accounts & unused extensions
• Old modules without security updates
• Example: Remove old development tools from the live system

System passwords (e.g. API keys) should also be automatically rotated on a regular basis - ideally via CI/CD processes.

Security scans & monitoring

Whether regular security scans are mandatory depends on the type of SAQ used. They are mandatory for SAQ A-EP and similar set-ups - in other cases they are strongly recommended. These tools are particularly helpful:

• Magento Security Scan from Adobe
• Sansec eComscan
• Approved Scanning Vendors (ASV) such as SRC GmbH or USD AG

Also useful:

• Logging of admin logins, failed attempts & accesses
• Documentation of all installed extensions
• Logs of updates and system changes

Secure deployment & update management

A secure store system does not end with the installation - the operation must also meet certain standards.

Best practices for deployment:

• Separation of dev, staging and production system
• No direct changes to the live system
• Use of deployment tools such as Deployer, GitLab CI or GitHub Actions
• Logging & rollback options

Update times according to PCI DSS 4.0.1:

Tip: Activate watchlists to be informed about new Magento releases and third-party updates in good time.

Penetration tests, SAQs & contingency plans: preparing for an emergency

PCI DSS 4.0.1 not only brings with it technical requirements, but also formal and organizational obligations. In addition to clean code and secure access, a secure store system also includes clearly documented processes - for audits, security incidents and self-audits.

Self-Assessment Questionnaires (SAQs)

The security requirements that apply to your store depend on how you process credit card payments.

The most important SAQ types:

• SAQ A: You forward completely to a payment provider via iFrame or redirect (e.g. Stripe Check-out).
• SAQ A-EP: There are separate scripts in the check-out, but the payment data still runs via the PSP.
• SAQ B/IP/B-SP: For terminal or app-based payments (rare in e-commerce).

Important: Even if you do not store any card data yourself, you must complete SAQs - and submit them annually if necessary. The requirements from PCI DSS 4.0.1 also apply to iframe-based setups!

What you need for this:

• Proof of regular vulnerability scans
• Documented CSP rules in the checkout
• Securing admin access (e.g. via 2FA)
• Overview of all extensions used
• Clearly defined distribution of roles and rights in the team

Penetration tests - useful & sometimes mandatory

For more complex payment methods (e.g. SAQ A-EP) or your own payment integration, a penetration test may be mandatory.

The aim is to find out whether access to the system or card data can be gained via known security vulnerabilities.

When does it make sense?

• For customized Magento checkouts
• After major updates or deployment changes
• When using your own payment modules

Tip: Many Approved Scanning Vendors offer combined packages of ASV scan & penetration test - ideal for the annual check.

Emergency plan: What to do if there's a fire?

A data leak, compromised access or a manipulated script in the check-out - in an emergency, every minute counts. That's why PCI DSS 4.0.1 requires a concrete incident response plan, including:

• Designation of a responsible team or contact person
• Overview of how & when the team can be reached (including outside office hours)
• Checklist for immediate measures (e.g. block admins, check backups, analyze logs)
• Communication plan for customers, partners and - if necessary - the supervisory authority (GDPR!)

Log security incidents - even if nothing has happened. This shows that You take your duties seriously.

Conclusion

PCI DSS 4.0.1 brings clear and binding security requirements for online stores - especially when handling credit card data. Anyone using Magento already has many tools on board, but must actively configure and maintain them. Now is the right time to systematically implement processes, access and protection mechanisms such as CSP or 2FA - for more security, less risk and long-term compliance.

You can find the complete webinar recording here: https://maxcluster.de/events/pci-dss - with many practical examples and recommendations directly from our partners at basecom.

Published on 24.04.2025 | PCI DSS 4.0.1: New Rules for Online Shops | KS