By the Breachfin Team
Published: July 21, 2025
Introduction
The latest evolution of the Payment Card Industry Data Security Standard (PCI DSS v4.0) introduced new and updated requirements to address modern attack vectors — particularly those targeting client-side vulnerabilities.
Two of the most important but often misunderstood controls are:
- 6.4.3: Change management for payment page content
- 11.6.1: Tamper detection for script integrity
Both are focused on protecting customer data during transactions — but they target different risks, require different tooling, and must work together for full compliance.
This blog breaks down what each requirement means, how they differ, and how Breachfin helps you cover both.
What Is PCI DSS 6.4.3?
PCI DSS 6.4.3 requires organizations to implement change management processes for any modifications to payment page content and scripts that are loaded and executed in the consumer’s browser.
This includes:
- Documenting and approving changes
- Verifying that updates are legitimate
- Keeping a record of what was changed, when, and by whom
This requirement addresses the intentional deployment of code — making sure that no changes go live without proper authorization.
Key idea:
You must control what you deploy to the browser.
What Is PCI DSS 11.6.1?
PCI DSS 11.6.1 takes a different approach. It focuses on tamper detection — ensuring that JavaScript on the payment page has not been altered after deployment, either by attackers, compromised third parties, or CDN manipulation.
This includes:
- Maintaining a list of authorized scripts
- Monitoring for unauthorized modifications
- Alerting and responding when changes are detected
This requirement is about runtime integrity, not deployment process.
Key idea:
You must detect when something changes outside of your control.
The Key Differences
| Requirement | Focus | Trigger | Responsibility | Tools Needed |
|---|---|---|---|---|
| 6.4.3 | Change management | Before deployment | DevOps / Engineering | CI/CD controls, change logs |
| 11.6.1 | Tamper detection | After deployment | Security / Compliance | Script scanners, runtime monitoring |
Why You Need Both
Modern web applications are highly dynamic and rely on numerous external scripts — chat tools, analytics, payments, CDNs, A/B testing, and more. A secure deployment pipeline (6.4.3) is essential, but not enough.
Even if your engineering team deploys clean code, a compromised third-party script can still introduce malicious behavior after the fact. That’s where 11.6.1 becomes critical.
Real-world example:
You approve a script from js.vendorcdn.com. A week later, that vendor is compromised, and the script starts logging keystrokes on your checkout page.
Your change log won’t catch it — but Breachfin will.
How Breachfin Helps You Meet Both Requirements
Breachfin was designed to address client-side visibility and script control, with built-in features to support both 6.4.3 and 11.6.1.
For 6.4.3:
- Snapshot baseline of deployed scripts at the time of scan
- Change logs and audit trails
- Verification against expected sources and file paths
For 11.6.1:
- Script hashing (SHA-256)
- Entropy analysis for obfuscated code
- Detection of
eval(),Function(), and suspicious runtime behavior - Historical comparisons to detect tampering
- Webhook alerts for unauthorized changes
With Breachfin, you’re not just logging changes — you’re actively watching the client-side behavior as it happens, in real-world conditions.
Final Thoughts
If you’re only relying on deployment approvals (6.4.3), you’re assuming nothing will go wrong after your code is live. In today’s environment of dynamic, third-party-heavy applications, that assumption is risky.
Compliance is not just about what you push — it’s about what your users actually execute.
By combining robust change management with real-time tamper detection, you fully align with PCI DSS v4.0’s intent: securing every part of the payment experience.
Start protecting your payment pages today.
Try Breachfin for free at breachfin.com and get complete coverage across 6.4.3 and 11.6.1.
