Thank you for joining us in Edinburgh
Thank you to everyone who stopped by Booth #19 at the PCI SSC Europe Community Meeting 2026. Over three days, we met QSAs, payment service providers, merchants, and security leaders. Each was working on the same question: what does good client-side security look like now that PCI DSS v4.0.1 has made the browser auditable?
One theme came up in almost every conversation: PCI DSS is a starting point.
PCI DSS Is a Starting Point
Requirements 6.4.3 and 11.6.1 gave security teams something they had lacked: a mandate to inventory, authorize, and monitor the scripts on their payment pages. That work matters. But the requirements answer a deliberately narrow question: is this script approved, and has it changed?
Many of the client-side attacks that matter most pass that test. They run through scripts that were already approved, or on pages outside PCI DSS scope such as login and account management. Some are built to behave one way for customers and another for anyone checking.
Authorization is not control. Knowing a script is allowed on the page doesn’t tell you what it can do once it runs: which fields it can read, which browser APIs it can call, and where it can send data.
What We Discussed at the Booth
- Audit readiness for 6.4.3 and 11.6.1: keeping script inventories, justifications, and change alerts current without slowing down the teams that add scripts.
- The SAQ A changes: what merchants using embedded payment forms now have to confirm, and how payment service providers can give them the technical basis for that confirmation.
- Going beyond the payment page: extending the same controls to login, registration, password reset, and any form that collects sensitive data.
- From alerts to enforcement: moving from detecting changes to enforcing what each script can access and send in live user sessions.
- Emerging AI threats: AI components on the page, and the way LLMs make client-side code cheaper to analyze and tamper with.
Read the Follow-Up: Beyond PCI DSS Compliance
We turned these conversations into a practical guide. It covers what PCI DSS asks of the browser and what it leaves out, why traditional controls miss client-side risk, and where to start extending your controls beyond checkout.
Missed Us in Edinburgh?
If we didn’t get a chance to talk at the event, we’d still like to hear about your payment page security and compliance priorities. Book a session with our team to see how Jscrambler can support your PCI DSS program and go beyond it.
Meet the Team
Beyond PCI DSS Compliance: From Script Authorization to Client-Side Control
Read Now
Beyond the Vault: What Banking Sites Quietly Share Before You Ever Log In
Read Now
Coalfire Advice for Payment Page Security & PCI DSS Requirements 6.4.3 & 11.6.1
Read Now