California's CIPA pen-register lawsuit wave: what website owners need to know in 2026
If you run a website that gets even occasional California traffic, there is a category of demand letter you should know about before one lands in your registered agent's mailbox. A growing wave of plaintiffs' attorneys are filing California Invasion of Privacy Act ("CIPA") complaints against ordinary commercial websites — not adult sites, not data brokers, not health platforms — alleging that the third-party trackers that fire on page load (Google Analytics, Meta Pixel, Google Tag Manager, LinkedIn Insight, TikTok Pixel, and dozens of others) constitute illegal "pen registers" under California Penal Code §638.51(a). The statute carries $5,000 in statutory damages per violation. The complaints are templated. The settlement pressure is real. And almost every website built in the last decade is potentially exposed, because almost every website was built to fire trackers on the first byte.
The legal theory in one paragraph
California Penal Code §638.50(b) defines a "pen register" as a "device or process" that records "dialing, routing, addressing, or signaling information" transmitted with an electronic communication — but not the contents of that communication. §638.51(a) makes it illegal to install or use a pen register without a court order or the express consent of every party to the communication. The statute was written in 1988 to govern law-enforcement phone-tap procedure. Plaintiffs' counsel now argue that a third-party analytics tag, fired in a visitor's browser to a domain like region1.analytics.google.com, is structurally identical: it captures the visitor's IP address, browser fingerprint, and request URL — all "addressing and signaling information" — and transmits them to a third party (Google), via a "process" (the JavaScript loader), without a court order and without specific prior consent. Each fired request is one violation. Each violation is $5,000. A typical commercial homepage fires 8 to 20 such requests before the visitor has clicked anything.
Why this theory is suddenly everywhere
The pen-register theory is not new — California courts considered and rejected an early version of it in 2018. What changed in 2024 and 2025 was a string of California Superior Court rulings declining to dismiss CIPA pen-register complaints at the pleading stage, combined with a federal court order in Greenley v. Kochava (S.D. Cal. 2023) that explicitly approved the "third-party tracker as pen register" framing. Once those rulings hit Westlaw, the plaintiff bar industrialized. Templated complaints now circulate that need only a defendant name, a website URL, and a single screenshot of the Chrome DevTools Network tab showing one tracker request firing on initial page load. The whole package — letter, complaint, screenshot — can be assembled in under twenty minutes per defendant.
What this means in practice: any commercial site with measurable California traffic is a viable target. The plaintiff doesn't need to allege actual harm beyond "I visited the site and my IP was transmitted without my consent." The defendant doesn't need to be a large company; a plumber's marketing site, a regional law firm, a real-estate syndication landing page, and a Fortune 500 corporate homepage are all equivalent from the demand-letter writer's point of view. The leverage is the statutory-damages math: even a conservative reading of $5,000 per violation, multiplied by a handful of fired tags, multiplied by the threat of class certification, produces a settlement number high enough that most defendants pay rather than litigate.
The specific page-load behavior the lawsuits target
To understand whether your site is exposed, look at what your browser does in the first 500 milliseconds after a visitor opens the page. Most sites built before 2024 — and a depressing number built since — do something like this:
- Browser requests the HTML.
- HTML
<head>includes<script src="https://www.googletagmanager.com/gtag/js?id=G-XXXX">. - That script auto-executes, reads the visitor's IP address (transmitted in the outbound TCP handshake), and immediately fires a request to
region1.analytics.google.com/g/collectcarrying the page URL, the visitor's screen resolution, browser fingerprint, and a generated client ID. - The Meta Pixel snippet does the same to
connect.facebook.net. - The Google Ads conversion tag does the same to
googletagmanager.com. - Optionally, a chat widget, a heatmap recorder, an A/B testing tool, and a re-targeting pixel each fire their own equivalents.
All of this happens before the visitor sees the page, before any cookie banner renders, and certainly before the visitor has clicked "Accept." A footer hyperlink to a Privacy Policy two scrolls below the fold does not constitute notice or consent — the plaintiffs' bar has explicitly briefed and won this point. A cookie banner that asks for consent but loads the trackers anyway (the default behavior of most consent management platforms in their out-of-the-box configuration) is, under this theory, decorative rather than legally protective.
Why "I'm just using Google Analytics like everyone else" isn't a defense
The reflex from most site owners when they first hear about this is reasonable: every website fires analytics tags, this is how the internet works, surely the courts will see this as overreach. There are three reasons that reflex hasn't held up in practice.
First, the statute is old and the language is broad. California Penal Code §638.50(b) doesn't care that the technology in question is a JavaScript tag rather than a 1988-era telephone surveillance device. The language is functional: any "device or process" that records "addressing or signaling information." A modern court is not going to narrow a statute to a specific technology Congress couldn't have anticipated; it's going to apply the words on the page.
Second, the consent defense requires prior consent. A consent banner that pops up after the trackers have already fired is, by definition, not prior consent. The CIPA framework borrows directly from federal wiretap doctrine, which has held since the 1980s that consent obtained after the interception is no consent at all. This is why most consent management platforms — designed for the GDPR, where post-fire consent is also forbidden but enforcement has been spottier — are not, in their default configuration, CIPA-protective.
Third, the cost asymmetry favors the plaintiff. Even if the site owner is right on the law, the cost of litigating a CIPA pen-register complaint through summary judgment in California Superior Court is in the high five figures at minimum. The plaintiff's lawyer is working on contingency. The defendant is paying hourly. The settlement number that closes the case at the demand-letter stage — typically $15,000 to $75,000 — is engineered to sit just below what defense counsel would charge to litigate. Site owners settle not because they think the theory is correct, but because settling is cheaper than being right.
What the regulators and the plaintiffs' bar are actually demanding
The cease-and-desist letters that precede CIPA complaints all converge on a specific set of remediation steps. They are worth listing out, because they describe the technical posture a defensible 2026 website actually needs:
- No third-party network requests fire before the visitor affirmatively opts in. Not Google Analytics. Not Meta Pixel. Not Google Tag Manager (which is itself a third-party request). Not the chat widget, not the heatmap recorder, not the A/B testing SDK. The technical bar is "request blocked at the network layer until consent is recorded," not "tracker loads but doesn't write a cookie."
- The consent prompt is presented before any non-essential tracker has a chance to fire. This generally means the consent UI is rendered server-side and the tracking scripts are conditionally injected based on a server-readable consent cookie.
- Consent is granular. The "accept all / reject all" binary is no longer sufficient; the prompt must offer separate opt-in for analytics and marketing categories, and respect each independently.
- Rejection is as easy as acceptance. A consent UI that hides "reject" behind a "manage preferences" sub-screen, while presenting "accept" as a one-click button, is itself the subject of a separate emerging line of complaints.
- The site honors the Global Privacy Control (GPC) browser signal. Visitors whose browser sends the
Sec-GPC: 1header are treated as having opted out of analytics and marketing tracking by default, without seeing the prompt at all. - The cookie / tracker disclosure page is comprehensive. Every tracker the site may fire is listed by name, category, duration, and third party, with a link back to the consent UI to change one's mind.
This is not a wish list — it is the reverse-engineered specification implicit in the standard CIPA cease-and-desist letter. Sites that meet it are not litigation-proof (nothing is) but are not soft targets either. Sites that don't meet it are visible from a thousand yards through any of the cheap automated scanning tools the plaintiffs' bar has built for the purpose.
What most platforms force you to retrofit, and why retrofits keep failing
Every major CMS in 2026 has documentation explaining how to bolt on a CIPA-compliant consent flow. WordPress has plugins. Squarespace has a feature toggle. Webflow has an integration guide. Shopify has a privacy app store. Each of these adds a layer on top of a system that was originally designed to fire trackers unconditionally.
The retrofits keep failing in the same three ways. The first is that the consent management platform is itself a third-party script (loaded from a tag-manager vendor's CDN), so the very act of asking for consent is, technically, a non-consensual third-party request. The second is that the platform's "block until consent" mode is opt-in and easy to misconfigure — most installations end up in "log consent but load trackers" mode by default, which is the worst of both worlds. The third is that the consent prompt and the trackers race each other on page load; on a slow connection, the trackers win, and the consent banner renders after the data has already left the building.
The deeper problem is architectural. A website built around the assumption that trackers fire on page load can be patched to delay them, but the patches are fragile, and any new third-party integration (a new chat widget, a new conversion pixel, a new heatmap recorder) defaults back to the unsafe behavior unless someone remembers to manually gate it. The retrofit's protection is only as good as the discipline of every developer who touches the site afterward — and developers are not, structurally, the people responsible for the company's CIPA exposure.
How WorkspaceCMS handles this differently
WorkspaceCMS is a 2026 platform, designed from the first commit to treat the CIPA pen-register threat model as a baseline requirement rather than a retrofit. That timing matters: every prior generation of CMS had to bolt consent onto an architecture that already assumed trackers fire on page load. We started after the playbook was already public, which let us make a single architectural decision instead of a series of patches: no third-party tracker script is written to the page DOM at all until the visitor has affirmatively granted consent. Not delayed-loading, not cookie-suppressed, not behind a tag-manager conditional. Not written to the DOM. The browser literally cannot fire the request, because the <script> tag does not exist in the rendered HTML until the consent state cookie says "granted."
The pieces that make that work, as shipped today on every WorkspaceCMS site:
- A consent banner rendered as part of the site's own first-party response — no third-party request fires to load the banner itself, and it appears before any tracker has the opportunity to execute (which on our stack is structurally impossible anyway, because the tracker's
<script>tag is not present in the rendered HTML until consent is granted). - A request-blocking script gate for every third-party integration the platform supports out of the box — Google Analytics 4, Google Tag Manager, Meta Pixel, Google Ads, plus any custom HTML head injection a tenant configures through the dashboard. None of them are written to the DOM until consent is granted.
- Equivalent-prominence accept and reject buttons on the banner, plus a permanent Cookie Settings link in the site footer that re-opens the prompt at any time.
- Global Privacy Control honored automatically. Visitors whose browser sends
Sec-GPC: 1are detected server-side on the very first request and treated as opted-out — the consent state hydrates to "denied" before the banner has a chance to render, and the choice is persisted so it survives the visitor later turning GPC off. - First-party-only consent storage on the visitor's own device, scoped per tenant so a choice on one WorkspaceCMS site never leaks to another (each site has its own data controller). The storage is versioned so we can re-prompt cleanly if the tracker set materially changes, and persists long enough that the prompt does not re-appear on every visit.
- A public cookie-policy page enumerating every cookie the site may set, the category, the duration, the third party, and the link back to the consent UI.
The pen-register theory is, at its core, an argument that the website fired a request to a third party without the visitor's permission. The structural defense is the architectural choice that the request cannot fire without permission, because the script that would fire it has not been emitted to the page. Our platform is built around that defense as the default, not as a configurable add-on. A WorkspaceCMS tenant does not have a checkbox to disable it; the gate is the platform.
What to do today if your site isn't on WorkspaceCMS yet
If you're reading this on the way to checking what your current site does, here is the five-minute self-audit. Open your homepage in a fresh incognito Chrome window. Open DevTools, switch to the Network tab, filter by "third-party," and reload the page. Count the number of requests that fire to domains other than your own before you have clicked anything. If that number is greater than zero — and on most sites built in the last decade it will be somewhere between five and forty — your site is, under the prevailing 2026 reading of CIPA §638.51(a), exposed.
The right remediation depends on your stack. On WordPress, the cheapest correct path is a consent management plugin that operates in true script-blocking mode (not cookie-suppression mode), combined with a manual audit of every plugin that injects a tracker. On Squarespace and Webflow, the path is narrower because the platforms inject some trackers at the platform level that the user cannot remove. On a custom-built site, you have full control but also full responsibility — every new third-party integration has to be manually gated by the developer who adds it. None of these is impossible, but none of them is free, and the failure modes are all in the direction of "looks compliant, isn't."
If you'd rather not run that risk on a site that was built for a different decade's threat model, the alternative is a platform where the gate is the architecture. That is what we built WorkspaceCMS to be.
Want a real engineer to run the self-audit on your current site, walk you through the failure modes, and show you exactly what a CIPA-defensible setup looks like on a WorkspaceCMS tenant? Get in touch — the call is live, no decks, and we'll send you a written summary of what we found regardless of whether you switch.
The bigger picture for 2026
CIPA pen-register litigation is one front in a wider pattern. The same plaintiffs' bar that built the pen-register playbook is now testing parallel theories under the federal Video Privacy Protection Act (against any site that embeds a video and a tracking pixel), the state-level analogues to CIPA in Florida, Pennsylvania, and Massachusetts, and the EU ePrivacy directive (for any US site with EU visitors). The technical posture that defends against CIPA — true prior-consent gating of all third-party network requests — happens to be the same technical posture that defends against all of the others. Building the gate once, at the platform layer, costs less than building it three times at the integration layer and missing the fourth.
The sites that are going to do well in 2026 and 2027 are the ones whose privacy posture stops being a quarterly engineering project and starts being a property of the platform they're built on. That is the bet behind every architectural decision we've made on WorkspaceCMS, and it's why this post exists in our blog rather than in our incident log.
If you want a CMS with this built in, talk to us
If you've read this far, the question you're probably holding is the practical one: where do I move my site so this stops being a problem I have to think about? That is exactly the use case WorkspaceCMS is built for. Every tenant on the platform — from a single-location dental practice to a multi-state law firm to a real-estate syndicator running monthly investor traffic — ships with the full CIPA-defensible posture as the default, not as an upgrade tier and not as a configuration project. There is no checkbox to disable the consent gate, because the gate is the platform.
Get in touch for a 20-minute call. A 1Digital® operator will (a) run the five-minute Network-tab audit on your current site live, (b) show you the same audit on a WorkspaceCMS tenant so you can see the difference in pre-consent network traffic side by side, and (c) walk you through what a migration timeline looks like for a site your size. No slide decks, no salesperson, no obligation to switch. If you walk away and apply the audit findings to your existing stack instead, that is also a win for us — the whole point of this post is that someone in our space needed to write it.
Curious how WorkspaceCMS handles compliance for your specific industry? See our pages for law firms, dental practices, med spas, real-estate firms, and roofing companies — every vertical we serve ships with the same CIPA-defensible consent posture as the default. The full list lives on our industry hub. When you're ready to move, tell us about your site.
See how WorkspaceCMS compares.
Book a free call. We'll show you a live demo of WorkspaceCMS running on a site in your industry.
Want the full picture? Browse more posts