TL;DR: Payment security is shifting toward browser-side control, AI governance, and post-quantum planning, according to Jscrambler’s report on the 2025 PCI SSC Europe Community Meeting, with Verizon cited on nearly 52,000 third- and fourth-party scripts across 7,000 merchant websites. The operational lesson is that trust in payments now depends on continuous authorisation, monitoring, and cryptographic readiness, not annual compliance cycles.
At a glance
What this is: This is an analyst view of the PCI SSC Europe Community Meeting, with the key finding that payment security is moving toward browser-side control, AI governance, and quantum-ready cryptography.
Why it matters: It matters because payment platforms, scripts, AI-assisted workflows, and cryptographic dependencies all intersect with identity, access, and trust decisions that IAM and security teams must now govern continuously.
By the numbers:
- That script count has surged by almost 50% in just two years.
Context
Payment security is no longer only about protecting card data in transit or at rest. The larger governance problem is controlling what executes in the browser, how AI is used to accelerate security decisions, and how cryptography will hold up as the threat model evolves. For payment teams, that makes identity, trust, and authorisation decisions part of the runtime control plane.
The article frames these issues through a conference setting, but the underlying pattern is broader: modern payment systems depend on a chain of third parties, scripts, APIs, and machine-driven decisions. That chain is only as trustworthy as its weakest control over access, approval, and change. In that sense, the starting point is typical of many merchant environments, not an outlier.
Key questions
Q: How should payment teams govern third-party scripts in the browser?
A: Payment teams should treat every browser script as a controlled dependency, not just code delivered by the business. That means maintaining a complete inventory, approving scripts by business purpose, monitoring for runtime drift, and blocking unauthorised changes. The goal is to prevent data capture at the point of input, where back-end controls are too late.
Q: Why do AI-assisted fraud controls need human accountability?
A: AI-assisted fraud controls can improve speed and pattern detection, but they can also produce decisions that are difficult to explain after the fact. Human accountability matters because payment disputes, incident response, and compliance evidence all require traceable reasoning. Organisations should keep humans responsible for policy, thresholds, and exceptions.
Q: What signals show that browser-side payment controls are failing?
A: Warning signs include unexplained script additions, frequent third-party changes, missing approval records, and inconsistent behaviour between approved code and what runs in production. If the organisation cannot tie execution to a current authorisation decision, the control has already lost its value.
Q: Who is accountable for post-quantum migration across partners and contractors?
A: Accountability sits with the organisation that owns the trust boundary, but the work spans vendors, contractors, and federated partners. Identity teams should define who approves changes, who validates compatibility, and who owns rollback if a cryptographic transition disrupts access. Cross-organisation trust is a governance issue, not just a technical one.
Technical breakdown
Why the browser is now a control point for payment security
Client-side security matters because the browser is where data is first exposed to scripts, form handlers, and external dependencies. Unlike backend-only controls, browser-side protection has to deal with dynamic content, third-party code, and changes that can happen after deployment. This is why script inventory, authorisation, and integrity monitoring matter. If a script can read or alter payment input, it becomes part of the attack surface, whether it is first-party or third-party code.
Practical implication: treat browser scripts as governed assets and maintain a live inventory with integrity checks.
How AI changes fraud screening and security authorisation
AI in payment security is being used in two different ways: to assist control decisions and to detect suspicious activity before a transaction completes. That creates both efficiency gains and governance risk. AI-assisted authorisation must remain explainable and bounded, because any automation that approves scripts or flags fraud is now part of the trust chain. The article’s emphasis on optional AI control is important because it keeps human accountability in the loop rather than assuming machine output is self-validating.
Practical implication: require explainable AI decisions for fraud and script governance, with human override for high-risk cases.
Why post-quantum cryptography is a planning issue, not a future curiosity
Post-quantum planning matters because public key cryptography underpins authentication, trust, and secure exchange across payments infrastructure. The issue is not that quantum systems have already broken production payment flows, but that long-lived data, certificates, and infrastructure dependencies must eventually survive a changed cryptographic landscape. Hybrid approaches can reduce transition risk, but they also add operational complexity. That means key management, migration sequencing, and algorithm agility become governance decisions long before full quantum practicality arrives.
Practical implication: build a cryptographic inventory now and identify where hybrid or algorithm-agile migration will be required.
Threat narrative
Attacker objective: The attacker aims to capture payment data before security controls on the back end can detect or block it.
- Entry occurs when malicious code is introduced into a merchant’s browser-side environment through third- or fourth-party scripts or compromised client-side dependencies.
- Escalation happens when that script gains access to payment input fields, session data, or checkout logic before the data leaves the browser.
- Impact follows when attackers skim payment data, manipulate transactions, or exfiltrate sensitive information at the point of entry.
NHI Mgmt Group analysis
Browser-side trust is now the real perimeter for payment flows. Merchants can no longer treat the checkout page as a thin presentation layer. Third-party scripts, embedded services, and dynamic code now sit inside the transaction path, which means authorisation and integrity controls must operate at runtime. The governance problem is not only code provenance, but continuous control over what is allowed to execute.
AI-assisted security decisions create a new accountability layer. Using AI to authorise scripts or screen fraud can improve response speed, but it also shifts risk into model outputs and decision justification. In payment environments, the question is not whether AI can help. It is whether the organisation can explain, constrain, and audit AI-influenced security actions when disputes, chargebacks, or incidents occur.
Post-quantum readiness should be treated as cryptographic lifecycle management. The important issue is not speculative quantum hype, but the operational burden of replacing long-lived trust anchors across certificates, keys, and payment services. Organisations that do not maintain cryptographic inventories will struggle to prioritise migration paths. That makes algorithm agility and key lifecycle governance the practical starting point.
Payment security and compliance are converging into one continuous control model. The event reinforces that annual audit thinking is too slow for browser execution risk, AI-assisted governance, and cryptographic transition planning. Security leaders should assume the control environment is living, not periodic. Practitioners should align compliance evidence with runtime controls, not separate them.
What this signals
Browser-side payment governance is moving toward continuous verification, which means security and compliance teams need shared evidence for script approval, runtime integrity, and exception handling. A control that exists only on paper will not stop a checkout-page compromise, especially when third-party code can change between review cycles.
Client-side trust drift: the gap between approved browser code and what actually executes in production. Teams should expect greater pressure to prove that runtime controls, not just policy documents, are governing payment inputs and AI-assisted decisions.
As payment architectures absorb more scripts, more automation, and more cryptographic transition work, identity and access decisions will increasingly show up in places that were once treated as pure application security. That makes inventory, approval, and lifecycle governance the common thread across client-side protection, AI oversight, and future cryptography planning.
For practitioners
- Build a live client-side script inventory Track every first-party, third-party, and fourth-party script on payment pages, including owners, purpose, change history, and business approval status.
- Enforce script authorisation before execution Require pre-approved policy decisions for scripts that can read, write, or redirect payment data, and monitor for drift after deployment.
- Document AI decision boundaries Define where AI may assist fraud screening or script risk assessment, where humans must approve, and what evidence is required for auditability.
- Start cryptographic inventory and migration planning Catalogue certificates, algorithms, key dependencies, and renewal cycles so that hybrid or quantum-safe migration can be sequenced before forced change.
Key takeaways
- The central risk is no longer limited to payment data in transit because the browser has become a live trust boundary that can be altered before back-end controls see anything.
- Verizon’s script findings underline the scale of the exposure, with tens of thousands of embedded dependencies now operating across thousands of merchant sites.
- Practitioners should respond by governing browser scripts, bounding AI-assisted decisions, and preparing cryptographic inventories for a post-quantum migration path.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK address the attack surface, NIST CSF 2.0, NIST SP 800-53 Rev 5 and NIST AI RMF set the technical controls, and PCI DSS v4.0 define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | TA0006 , Credential Access; TA0010 , Exfiltration | Client-side skimming and script abuse map to credential or data theft tactics. |
| NIST CSF 2.0 | PR.AC-1 | Script authorisation and runtime control align with access management and verification. |
| NIST SP 800-53 Rev 5 | AC-6 | Least privilege is directly relevant to limiting script and service access. |
| NIST AI RMF | GOVERN | AI-assisted fraud and authorisation decisions need governance and accountability. |
| PCI DSS v4.0 | 6.4.3 | The article directly references PCI DSS script governance requirements. |
Map browser-side payment risks to ATT&CK and monitor for unauthorised script execution and data exfiltration paths.
Key terms
- Client-side code protection: A set of controls that makes browser-delivered application code harder to inspect, copy, or alter. It usually combines obfuscation, integrity checks, and release-stage enforcement so that proprietary logic remains usable for customers but more difficult for attackers to reverse engineer.
- Script authorisation: A control that defines which scripts are permitted to run on a payment page and under what conditions. It turns script execution into a governed decision rather than a developer assumption, supporting both compliance evidence and runtime protection against injected or unexpected code.
- Post-Quantum Cryptography: Cryptographic algorithms designed to remain secure against attacks from sufficiently powerful quantum computers. In practice, PQC is a migration problem as much as an algorithm problem because organisations must replace trust anchors, certificates, and secrets without breaking identity-dependent systems.
What's in the full article
Jscrambler's full article covers the operational detail this post intentionally leaves for the source:
- Specific PCI DSS 6.4.3 and 11.6.1 implications for client-side script governance and evidence collection
- Conference-level commentary on how merchant teams are using AI to support fraud screening and control authorisation
- Practical examples of how security teams are thinking about hybrid quantum-safe cryptography transitions
- Speaker perspectives from payment leaders on balancing compliance, browser integrity, and future cryptographic change
Deepen your knowledge
The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps security practitioners connect identity controls to broader runtime trust problems.
Published by the NHIMG editorial team on August 20, 2026.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
