Ryan BrownPCI compliance scans have a way of triggering panic—especially when the report comes back with dozens of findings tied to “insecure TLS versions.”
Recently, a customer received 72 PCI scan findings, many of them duplicates, all pointing to deprecated TLS protocols like TLS 1.0 and TLS 1.1. The initial concern was understandable:
Are these real security issues, or false positives—and how should we respond?
Let’s break down what actually happened, why scanners get this wrong so often behind Cloudflare, and how to resolve it cleanly.
The Initial Concern: 72 PCI Findings (Mostly TLS-Related)
The scan results showed:
- Numerous findings referencing TLS 1.0 / TLS 1.1
- Repeated entries for the same issues
- A concern that the server was out of PCI compliance
At first glance, that sounds serious.
But context matters.
Step One: Confirm the Origin Server Configuration
The first thing we verified was the origin server itself.
- TLS 1.0 and 1.1 were already disabled
- Modern ciphers and protocols were enforced
- No insecure TLS configuration existed at the server level
That immediately ruled out the most obvious risk.
So why was the scanner still flagging it?
The Real Culprit: Cloudflare Edge TLS Settings
The key detail: the site was running behind Cloudflare.
When a site is proxied through Cloudflare:
- External scanners do not test your origin server
- They test Cloudflare’s edge
- Whatever TLS versions Cloudflare allows are what the scanner sees
In this case, Cloudflare was still configured to allow older TLS versions at the edge, even though the backend server was fully locked down.
That mismatch is what caused the findings.
Why This Triggers PCI False Positives
Most PCI scanners:
- Detect supported TLS versions
- Don’t differentiate between edge vs. origin
- Flag every endpoint they test (often redundantly)
So even though the server was compliant, the scan results reflected Cloudflare’s minimum TLS policy, not the server’s.
From a PCI standpoint, that still matters.
The Fix: Enforce Minimum TLS 1.2 in Cloudflare
The solution is straightforward and takes about a minute.
Steps in Cloudflare
- Log in to the Cloudflare dashboard
- Select your website
- Navigate to SSL/TLS → Edge Certificates
- Set Minimum TLS Version to TLS 1.2
That’s it.
Once this is applied:
- Cloudflare stops negotiating TLS 1.0 / 1.1
- PCI scanners no longer see deprecated protocols
- The findings clear on the next scan
Cloudflare’s official documentation covers this here:
👉 https://developers.cloudflare.com/ssl/edge-certificates/additional-options/minimum-tls/
Why ColdFusion Sites See This More Often Than Expected
This issue shows up constantly in ColdFusion environments—and not because ColdFusion is insecure.
It’s because many ColdFusion applications:
- Have long lifespans (10–20+ years is common)
- Support older clients or integrations
- Run behind IIS with modern TLS hardening at the server level
Teams correctly disable TLS 1.0 and 1.1 on the ColdFusion server, assume they’re compliant, and move on.
But when ColdFusion is behind Cloudflare, PCI scanners never see that server.
They see Cloudflare’s edge.
So even a fully hardened ColdFusion deployment can still fail a PCI scan if:
- Cloudflare’s Minimum TLS Version isn’t enforced
- Edge cipher policies don’t match compliance requirements
This creates confusion for ColdFusion teams because:
- The application server is correctly configured
- The scan results still look “wrong”
- The findings appear duplicated or exaggerated
In reality, it’s a boundary issue—not a ColdFusion issue.
👉 This is one of the reasons ColdFusion-specific hosting expertise matters. Knowing where TLS enforcement must occur is just as important as knowing how to configure the application itself.
