How to choose a tool for PCI DSS requirements 6.4.3 and 11.6.1

On March 10, 2025, the PCI Security Standards Council published a guidance document devoted to PCI DSS requirements 6.4.3 and 11.6.1, three weeks before both became mandatory. Since then, the market has filled up with tools that claim to solve both requirements, and anyone who has to pick one gets proposals that cannot be compared side by side: one monitors scripts, another visits the page from the outside, a third promises to handle everything at the CDN. This guide sorts those options and lists the questions that separate a good purchase from one that only lasts until the next assessment.

Short answer

Choose based on coverage of both requirements at once: script inventory and authorization (6.4.3) plus change detection with alerting (11.6.1). Favor tools that watch real buyer sessions, cover every payment method on your page (credit card, debit card, instant payments, bank slips, wallets) and produce a report your QSA can use without forcing you to change infrastructure.

Why the requirement exists

The attack behind both requirements happens in the buyer's browser. A script is placed on the payment page, whether through a compromised plugin, a breached third-party vendor or a direct change on the server. That script copies card data as it is typed and sends it to the criminal. The page keeps working, the order is approved and nobody notices for weeks.

Requirement 6.4.3 targets the cause: the company must know which scripts load on the payment page, who authorized each one and why. Requirement 11.6.1 targets the effect: the company needs a mechanism that detects unauthorized changes to the page content and security headers, and that raises an alert when it happens.

The requirements talk about cards, but the same technique swaps a Pix QR code, a bank slip line or a stablecoin wallet address. A tool that only watches the card field leaves half the checkout unguarded.

The four approaches on the market

1. Script agent on the page

A small piece of code installed on the store runs in each buyer's browser, records which scripts loaded and reports to a dashboard. This is the approach closest to what the requirement describes, because it sees the real session, on the real device, with the buyer's own extensions and network.

The limit is what the agent checks. Many only list scripts and compare them with the approved list. If an authorized script is altered at its source, or if the swap happens in the page content rather than in a script, the agent needs a second layer to notice.

2. External monitor with simulated visits

A robot run by the vendor opens your payment page at regular intervals, records what loaded and compares it with the previous visit. Nothing is installed on the store, and setup takes minutes.

The weak point is the sample. The robot sees what the robot sees: a known IP address, a standard browser, a session with no cart and no login. Attacks that only fire for buyers in a certain region, on mobile, or after the address form is filled go unnoticed. And between one visit and the next, the page is unwatched.

3. CSP policy from the CDN or application firewall

A content security policy (CSP) is a header that tells the browser which origins the page may load scripts from. Some CDN and application firewall vendors offer generation and monitoring of that policy as a product.

It works well for blocking unknown origins. It does not cover changes inside a script that is already allowed, it requires the store to move to that CDN or firewall, and the policy needs maintenance every time a new vendor is added to the checkout. For 6.4.3, CSP helps with the integrity part but does not replace an inventory with justifications.

4. Verifying the payment itself

Instead of asking "which scripts loaded", this approach asks "is what the buyer sees what the server issued?". The QR code, the Pix key, the bank slip line, the wallet address and the destination of the card form are checked against what the store generated. If there is a difference, the tool blocks and alerts.

The advantage is covering the outcome of the attack regardless of how it entered the page. The limit is that, on its own, it does not satisfy 6.4.3: script inventory and authorization must come with it.

Seven questions to ask any vendor

1. Which payment methods are covered? Ask for the list: credit card, debit card, Pix, bank slip, digital wallets, stablecoins. A generic answer such as "the whole page" usually means "scripts only".
2. Does the tool watch real or simulated sessions? Real sessions show what each buyer saw. Simulated sessions show what the robot saw.
3. Does it block automatically or only alert? Requirement 11.6.1 demands an alert. Blocking is what prevents the loss. Ask what happens in the minutes between the alert and your team's action.
4. Does it require me to use the vendor's CDN or firewall? Changing infrastructure because of one requirement usually costs more than the tool.
5. What report is delivered to the QSA? Ask for a real sample: inventory with owner and justification, change history, alerts raised and handled.
6. What happens between one assessment and the next? The requirement accepts weekly checks, but the attack does not wait. Ask what the actual detection interval is.
7. Who operates the tool day to day? How many hours per month your team will spend approving scripts, reviewing alerts and maintaining lists. That number defines the true cost.

Common mistakes

• Buying an inventory and assuming the job is done. 6.4.3 asks for inventory; 11.6.1 asks for detection and alerting. They are different deliverables.
• Treating the requirement as a card-only matter. The same script that copies cards swaps QR codes. Leaving instant payments and bank slips out leaves the door open.
• Planning a weekly check and discovering the attack on day six. The interval from your risk analysis is the minimum acceptable, not the target.
• Confusing anti-fraud with page integrity. Anti-fraud evaluates whether the buyer is legitimate. The requirements deal with whether the page is legitimate.
• Accepting screenshots and spreadsheets as evidence. The QSA wants history, with dates, owners and justifications.
• Choosing by plan price and forgetting the cost of operation. A cheap tool that needs a dedicated analyst ends up expensive.

Where Proteside fits

Proteside goes onto the page with one line of code, with no change of CDN or platform. On every real purchase session, it checks the QR code, the Pix key, the bank slip line and the wallet address against what the store's server issued, and blocks the swap before the buyer pays. At the same time, it keeps the inventory of scripts on the payment page, records authorizations and justifications, and exports evidence for requirements 6.4.3 and 11.6.1 with full history.

To see how each approach compares point by point, with public facts and the date they were checked, visit the comparison page.