Does Cloudflare make you PCI compliant?
A common and reasonable assumption, because Cloudflare does carry real PCI weight. It is also the assumption that leaves the two client-side requirements open at assessment.
TL;DR
Cloudflare and PCI DSS
WHAT IT DOES COVER
Cloudflare is itself a PCI DSS compliant service provider, and the WAF and TLS termination map onto several requirements in requirement families 4 and 6.
WHAT IT DOES NOT
Being a compliant service provider is about their environment, not yours. Your payment page is still your scope.
WHERE 6.4.3 AND 11.6.1 SIT
Page Shield, renamed Client-Side Security in March 2026, is Cloudflare's answer to the client-side requirements. It is a real product, and it is not automatically on.
Short on time? A CDN cannot see what a script does after the browser has it.
Does Cloudflare make you PCI compliant?
No. Cloudflare covers parts of PCI DSS and can materially reduce your workload, but compliance is assessed against your cardholder data environment, not your CDN vendor's. Searches for Cloudflare PCI compliance usually carry one of two questions: whether being on Cloudflare reduces what you have to do, and whether it closes the two client-side requirements. The answer to the first is yes, and to the second is no. The confusion is understandable, because two true statements sit next to each other. Cloudflare is a PCI DSS compliant service provider, and Cloudflare provides controls that satisfy specific requirements. Neither statement transfers your obligation. For requirements 6.4.3 and 11.6.1 in particular, the control has to observe what executes inside the browser, which is a place a CDN sits in front of rather than inside.
A targeted skimmer fires for a slice of traffic: one country, one card BIN, one hour. Sampling is the norm in this category: Feroot samples 10% of sessions and Cloudflare Page Shield as little as 1%. That is a coin flip against an attack designed to be rare.
What Cloudflare genuinely does cover
Worth stating plainly, because underselling this is as unhelpful as overselling it. If you are on Cloudflare you are already getting real PCI value:
TLS and certificate management. Requirement 4 is about protecting cardholder data in transit, and terminating modern TLS correctly is not a small thing to run yourself.
The WAF. Requirement 6.4.1 asks for either an automated technical solution in front of public-facing web applications or regular manual review. A WAF is the usual way that is met.
Their own compliance. Cloudflare publishes an Attestation of Compliance as a service provider, which is what your assessor will ask you to hold on file for them.
DDoS and availability. Not a PCI requirement in itself, but it keeps the environment stable enough for the rest to be true.
If your assessment is stalling on any of those, Cloudflare is helping. The problem is elsewhere.
The service provider misreading
This is the single most common misunderstanding in the category, and it is not specific to Cloudflare.
A vendor being PCI DSS compliant means their own environment has been assessed. It says nothing about whether your use of them is compliant. Your assessor will want their Attestation of Compliance on file, and will then go on to assess your environment as though you had not mentioned it.
The practical test is ownership. Cloudflare's compliance covers Cloudflare's systems. The HTML your origin serves, the scripts that page loads, and the browser session your customer is in are yours. Requirements 6.4.3 and 11.6.1 are written about exactly that page.
Compare it against the scripts on your own checkout, not against a feature grid.
Where the CDN and WAF stop, and why
A WAF inspects requests and responses in transit. That is a genuinely useful position and it is the wrong position for these two requirements, for a structural reason rather than a quality one.
What happens
Visible to a CDN or WAF?
Why
A third-party script is requested by the browser
Only if it goes through the same proxy
Most vendor tags load from the vendor's own domain, which never touches your CDN
That script reads a card field
No
It happens in the DOM, after delivery, in the visitor's browser
It sends data to an attacker domain
No
The request originates in the browser and goes straight out, not back through your origin
A trusted vendor is breached and ships altered code
No
The URL, the origin and the headers are all unchanged. Only the payload differs
A tag manager publishes a new tag to checkout
No
Nothing about your origin response changed
Your own HTML changes
Yes
This one does pass through, and is the part a CDN can watch
That last row is the important one. Watching your own HTML change is real 11.6.1 value. It is also the easy half. The requirement covers the payment page and its HTTP headers, and most of what actually goes wrong on a payment page never appears in your own HTML at all.
Page Shield, which is the honest answer to 6.4.3
Cloudflare knows all of the above, which is why Page Shield exists. It is a genuine client-side security product and it should be evaluated seriously, especially if you already pay for the platform.
Three things to establish before you assume it is handled:
Whether it is switched on. Being a Cloudflare customer does not mean Page Shield is active or that its alerting is configured. Check the dashboard rather than the invoice.
Which capabilities your plan includes. Cloudflare gates these features by tier, and the split has changed more than once. Since March 2026 the base Client-Side Security tier is on every plan, and code change detection, the part 11.6.1 leans on, is on Client-Side Security Advanced, a self-serve add-on at $0.099 per 1,000 requests. Check what your zone has switched on today rather than relying on a blog post, ours included.
What the evidence looks like. An assessor asks for an inventory with a written justification per script and a change record over a period. A dashboard you screenshot is a weaker artefact than an export, whoever produces it.
The full head-to-head, including where Page Shield is genuinely stronger, is on the Cloudflare Page Shield comparison.
What stays with you on any plan
Whatever you decide about tooling, these remain your obligation:
Defining scope. Which pages are payment pages, and why. No vendor can decide this for you and every assessment starts here.
Justifying each script. 6.4.3 asks for a written business justification per script. That is a human sentence about why a tag is on a payment page, and no tool writes it.
Acting on alerts. 11.6.1 asks that personnel are alerted. An alert nobody acknowledged is a finding, not a control.
Holding the evidence. Assessments look backwards over a period, so the artefact has to survive longer than the dashboard's retention window.
If you are staying on Cloudflare, which is often right
There is no version of this post that ends with everyone switching, and pretending otherwise would waste your time.
If you are already on Cloudflare, Page Shield is one contract, one vendor review and one support relationship. That is a real advantage and it decides plenty of evaluations on its own. Turn it on, confirm what your plan includes, configure the alerting, and produce an evidence export before your assessment rather than during it.
The cases where teams look elsewhere are narrower and specific: they want coverage of every session rather than a sample, they want the evidence as an export rather than a view, they want per-script justifications held with the inventory, or they do not want the control tied to the plan tier of their CDN. If none of those apply to you, staying is the cheaper answer.
Sources and methodology
Statements about Cloudflare describe publicly documented behaviour of a CDN, a WAF and the Page Shield product, and where plan gating or pricing is concerned we quote Cloudflare's published figures and say to confirm with Cloudflare for your account. PCI DSS requirement text is quoted from PCI DSS v4.0.1 (June 2024), published by the PCI Security Standards Council. Requirements 6.4.3 and 11.6.1 became mandatory on 31 March 2025. We publish a competing product and that is a bias worth knowing about while you read. Primary sources: Cloudflare plans and pricing and Cloudflare Client-Side Security docs.
ASK AN AI
Don’t just take our word for it
Ask your assistant what to look for in a tool for PCI DSS 6.4.3 and 11.6.1.
Frequently asked questions
No. Cloudflare is a PCI DSS compliant service provider and provides controls that map onto specific requirements, particularly TLS in requirement 4 and the WAF in 6.4.1. Compliance is assessed against your cardholder data environment, so their attestation goes on your file and your own assessment still happens.
No. 6.4.3 asks you to inventory the scripts on your payment page, authorise each one and justify it in writing, with a method for assuring integrity. A WAF inspects traffic in transit and cannot see what a script does in the browser or that a trusted vendor shipped altered code at an unchanged URL.
Partly, and the part matters. Change detection on your own HTML and your HTTP headers is real 11.6.1 value and a CDN is well placed to do it. What it misses is the larger half: third-party script payloads that change without your origin response changing at all.
It can be, and that is a genuine answer rather than a hedge. Confirm three things first: that it is switched on, which capabilities your plan actually includes today, and whether the evidence it produces is an export your assessor will accept rather than a dashboard you screenshot.
The base tier, now called Client-Side Security, is included in every Cloudflare plan. Client-Side Security Advanced, formerly the Page Shield add-on and the tier with code change detection, is published at $0.099 per 1,000 requests and has been self-serve since March 2026. Our pricing is published: free for 1,000 page views a month, Pro from $99/month, overage at $0.0013 per page view.
No, just a clearer one. A CDN without a client-side product simply does not address 6.4.3 or 11.6.1, which is easier to reason about than a half-configured one. Nothing about your CDN choice makes the requirements harder.
No, and neither does the iframe. The iframe is your provider's, the page hosting it is yours, and a script on that page can overlay it or capture keystrokes before it. See hosted payment pages and PCI.
Yes, and plenty of teams do. They sit in different places: the WAF in front of your origin, a monitoring tag inside the browser session. There is no conflict, no DNS change and no traffic routed anywhere new.
No, not on its own. A CSP is an origin allowlist: it decides where a script may load from, never what an allowed script does. A breached vendor you already allow passes the policy cleanly. Both controls are worth having. See CSP vs script monitoring.
Four things, and get them in writing: whether Page Shield is active on the zones serving payment pages, which capabilities the current plan includes, what proportion of sessions are observed, and what the evidence export contains. Those four answers decide whether anything else is needed.
Related articles
Comparisons
Best client-side security tools in 2026
Thirteen tools, each with real pros and real cons, and an honest statement of our own bias.
Comparisons
Best PCI compliance software in 2026
Full-scope platforms and client-side tools are different categories. Both lists, kept apart.
Comparisons
Jscrambler pricing: what is published, and what is not
No public figures, what drives a quote, and what to ask for on the call.
PCI DSS
PCI DSS compliance: a practical guide for 2026
What the standard covers, what changed in v4.0.1, and where the two client-side requirements fit.
See every script on your own checkout.
Install the tag, mark your payment pages, and watch the inventory fill in. Free forever on 1,000 page views a month, no credit card.
Free forever plan. No credit card.