Most privacy programs have a consent banner, a preference center, and a CMP dashboard showing everything is green. But regulators and plaintiffs no longer stop at “do you have a consent tool?” They ask what the browser actually did after the user made a choice.
This post covers what a consent management platform (CMP) does well, where it stops, why litigation and enforcement have made that gap costly, and how browser runtime enforcement closes it without replacing your CMP.
What a CMP is Good At
A CMP is your system of record for user choice. It shows the banner and preference center, applies the right rules by region (opt-in in the EU and UK, opt-out in most US states), and honors signals like Global Privacy Control. It logs who chose what and when, publishes that state to the rest of the site, and holds back marketing and analytics tags until the user allows them.
This is essential, and it isn’t going away. Without a CMP, you have no reliable way to capture or prove user choice. But it was never designed to enforce what scripts and trackers do at runtime.
Where CMPs Fall Short at Runtime
A CMP works at the level of “should this script load?” Once a script is running, the CMP has very little say in what it does. That leaves a few predictable gaps.
Timing is the first one. The CMP is a script too, and it has to load and make a decision before it can gate anything. Anything that fires earlier, like a hardcoded tag or a tag released when the CMP times out, can send data before the user’s choice takes effect.
Visibility is the second. Modern pages are chains of third-party code, where one vendor pulls in another. A CMP can only govern the vendors it knows about, and the ones it doesn’t know about are usually the ones you’d most want to catch.
Then there’s granularity. A CMP can decide whether a vendor runs, but it can’t limit what page data that vendor reads or sends once it’s allowed. And sites change all the time. New tags, vendor updates, and redesigned checkout flows all mean a configuration that was right at audit time can quietly become wrong.
Underneath all of these is the real problem. The CMP records what it asked, and what the user answered. It doesn’t check whether what happened in the browser matched the answer.
What We Found When We Looked
The Jscrambler security research team ran runtime analyses of production retail websites to see how third-party pixels behave in practice. The point isn’t that banners were misconfigured. Even consent tools deployed correctly still didn’t deliver the intended outcome.
In our analysis of the TikTok and Meta pixels, the pixel code could load and start sending data before the site’s consent system could block it. We saw TikTok capture sensitive data before a visitor had made a choice, and in some cases after they had clicked “Reject All.” We also saw that these pixels collect more than basic conversion data, including personal identifiers and checkout details, and that much of this happens by default. Nobody on the merchant side turned it on. Separately, we looked at 14 financial-services sites and found tracking active without valid consent on nine of them, with data going to a dozen third parties.
For this conversation, three conclusions matter:
- A configured consent tool isn’t the same as an enforced one.
- A vendor’s defaults can go well beyond what your privacy notice describes.
- The exposure is worst where the data is most sensitive: checkout, forms, and account pages.
Why The Pressure is Rising
CIPA litigation
California’s Invasion of Privacy Act became the main vehicle for website tracking claims. The “pen register” theory in particular drove enormous volume, growing from roughly 600 cases in early 2025 to more than 4,000 eighteen months later.
In September 2026, California enacted SB 690, which ends private pen-register and trap-and-trace suits arising from websites and apps, makes the Attorney General the exclusive enforcer, and reaches back to pending claims in actions commenced on or after January 1, 2025. It takes effect January 1, 2027.
That is meaningful relief, but not an all-clear:
- Section 631 interception claims are a separate cause of action and remain available to private plaintiffs, including claims based on the same tracking technology. Those claims already underpin many pixel, session-replay, and chatbot suits.
- Plaintiffs are already pleading multiple CIPA claims alongside federal wiretap claims to hedge against the bill.
- The Attorney General retains enforcement authority.
The most likely outcome is that litigation shifts rather than stops. The underlying fact pattern, where visitor data flows to third parties without effective consent, stays the same, and it’s what gets litigated under whichever statute is available.
CCPA/CPRA enforcement
California’s regulator has made clear it tests how consent works in practice:
- Honda was fined $632,000 in 2025, partly over a banner that made opting out harder than opting in.
- Todd Snyder paid $345,178 after a consent banner malfunctioned for 40 days, with the finding that the company failed to monitor its third-party privacy tool.
- Tractor Supply paid $1.35 million, including for failing to honor Global Privacy Control signals.
- PlayOn Sports agreed to a $1.1 million fine in March 2026 over tracking tools, including Meta pixels, and a banner with no equivalent option to reject.
Regulators are also coordinating. California, Colorado, and Connecticut launched a joint sweep on GPC compliance in late 2025. And the updated CCPA regulations, effective January 1, 2026, require symmetrical choices, treat dark patterns as invalidating consent, and state that closing a banner is not consent.
The Todd Snyder case is the one to remember. The finding was not just that a tool failed. It was that nobody was checking.
Beyond California
The same theme runs through GDPR and ePrivacy enforcement in Europe, a growing set of US state laws like in Colorado, Oregon, and Maryland requiring honoring opt-out signals, and sector rules in healthcare, financial services, and payments. Everywhere, the question is shifting from “what did you tell users?” to “what did your site actually do?”
Why You Need Browser Runtime Enforcement
Browser runtime enforcement moves the control point. Instead of governing only whether a script is allowed to load, it governs what third-party code can access and send while it runs in the browser. It sits in the page alongside your CMP, observes real behavior, and applies policy as it happens.
A runtime layer typically works like this:
- Loads first to map all scripts. A lightweight agent is deployed as the first script on the page and executes before third-party code to map every script on the page (including fourth- and fifth-party tags injected downstream) and track their data access in real time.
- Applies proactive guardrails. Restricts scripts from reading sensitive data fields or transferring user data to unauthorized domains.
- Monitors runtime activity and deploys active defenses. Tracks script behavior to establish a baseline and detect anomalies or drift. When unauthorized actions occur, active defenses automatically step in to block the action without killing the script.
- Maintains a runtime audit trail. Captures detailed telemetry of every allowed and blocked script action, providing proof that privacy policies are actively enforced inside the browser.
Without that layer, you’re exposed in ways that are easy to miss. You could be out of compliance while your dashboard says otherwise, and hear about it from a demand letter or a regulator. Personal, financial, or health-related data can reach ad platforms through defaults nobody deliberately enabled. A vendor update can widen collection overnight without any change on your side. And after a complaint, you can show what you asked for but not what actually happened, which regulators have made clear isn’t enough.
How They Work Together
This is not a CMP-or-runtime decision. The two layers do different jobs and strengthen each other.
- The CMP decides. Runtime enforcement enforces. The CMP stays the source of truth for user choice, legal basis, and regional rules. Runtime enforcement helps ensure third-party scripts follow privacy policies at runtime.
- Runtime enforcement covers the CMP’s blind spots around timing, unknown third parties, and data-level access.
- Runtime findings improve the CMP. Observed behavior reveals undeclared vendors, misclassified tags, and drift, which feeds back into your configuration.
- Together they complete the evidence trail: what you disclosed, what the user chose, and what the browser did.
A practical way to start:
- Observe first. Monitor your highest-risk pages, such as checkout, forms, and logged-in areas, before blocking anything.
- Compare reality to paper. Check what’s actually running against your CMP inventory and privacy notice. Expect surprises.
- Fix the defaults. Turn off vendor features that conflict with your policy.
- Enforce. Block unauthorized access to sensitive data and unapproved destinations to align reality with your privacy policies.
- Keep watching. Treat new scripts and behavior changes as alerts, not annual audit findings.
- Test outcomes, not banners. Include “Reject All” and GPC scenarios in release testing and verify what actually leaves the browser.
The Bottom Line
A CMP tells you what users asked for. Runtime enforcement helps make sure the browser honors it. The research shows how wide that distance can be, and the enforcement record shows who pays for it.
If your compliance story ends at “the banner works,” the next step is to extend it to, “and we verified what the browser did.”
Ready to Uncover Your Website’s Privacy Blind Spots?
Request a Browser Privacy Risk Assessment today to audit your active scripts, identify tracking pixels operating outside of their intended scope, and uncover the client-side vulnerabilities your standard CMP misses. Gain full visibility into your digital properties and get an actionable roadmap to protect your business and close your runtime privacy gaps.
*Disclaimer: This article is for general information and is not legal advice.*
