How CIPA applies to mobile apps: What privacy teams need to know?

Understanding how CIPA applies to mobile apps has become more important as online-tracking litigation now extends beyond websites. The California Invasion of Privacy Act (CIPA) has supported thousands of tracking claims involving websites. Mobile apps may draw more attention as plaintiffs gain better visibility into Software Development Kits (SDKs) and the data they transmit.

During Privado AI’s July 2026 webinar, Matthew Pearson, partner at Frankfurt Kurnit, and Romit Raj, founding product manager at Privado AI, examined why CIPA app claims may create a different litigation posture. Their central argument was that the legal theories remain familiar, while app evidence can be more identifiable and sensitive.

This blog covers the webinar’s discussion of statutory claims, app evidence, class certification, pending legal developments, and practical risk controls. It also explains how privacy teams can produce replicable evidence of SDK behavior without waiting for a complaint or demand letter.

Meet the experts

Matthew D. Pearson

Partner, Litigation Group, Frankfurt Kurnit Klein & Selz 

Matthew Pearson represents companies in consumer and privacy class actions, with a practice focused on privacy, data security, and advertising technology litigation. His work has earned recognition from Best Lawyers and Lawdragon’s 500 Leading Litigators in America.

Romit Raj

Founding Product Manager, Privado AI

Romit Raj brings the technical and product perspective to the discussion. His work at Privado AI focuses on helping privacy teams understand mobile SDK behavior, inspect app data flows, and review technical evidence from iOS and Android applications.

How does CIPA apply to mobile apps?

CIPA was written decades before mobile apps and modern SDKs existed. Even so, plaintiffs have brought claims under Sections 631, 632, and 638.51 involving app operators and SDK providers. How CIPA applies to mobile apps depends on the provision used, what happened technically, and how consent was handled.

As Pearson explained during the webinar, the legal theory is not very different from website cases. What changes is the evidence. Mobile apps can contain analytics tools, advertising SDKs, session replay software, and other technologies that collect user information. As Pearson put it, “The claims might be relatively the same. The evidence is different.”

That distinction is important when examining CIPA lawsuits involving mobile apps. The legal arguments may be familiar, while the evidence available to support or challenge them can differ.

Why website claims came first and why that is changing

Most online-tracking claims have targeted website operators. According to Pearson, one reason is simple: Plaintiffs’ counsel can inspect browser network traffic more easily than app-based traffic.

Browser tools expose requests and third-party activity with relatively little technical friction. Inspecting mobile app traffic has required more specialized methods, making the evidence harder for plaintiffs to obtain.

Privado AI’s analysis of server-side tracking and CIPA litigation risks explains how plaintiffs can collect website evidence directly from browser network activity, including outbound requests and the timing of third-party data sharing.

That difference is beginning to narrow. Better methods for inspecting app traffic can expose active SDKs and outbound requests. They can also show identifiers and other information transmitted during an app session.

As that technical gap narrows, CIPA lawsuits on mobile apps may become easier to investigate. Mobile applications also often have authenticated users, so transmitted information may be linked to account details or persistent device identifiers in ways that differ from anonymous website traffic.

Which laws are used in mobile app tracking claims?

CIPA is the main law discussed in the webinar, although plaintiffs have also brought claims under other state wiretapping statutes and federal privacy laws. Privado AI’s CIPA lawsuit-prevention playbook provides additional context on the tracking technologies and data flows that may be relevant in website and mobile app claims.

The current text of CIPA Section 637.2 authorizes a private plaintiff to seek the greater of $5,000 per violation or three times actual damages. The statute also states that actual damages are not a prerequisite for an action under the section. 

Section 638.51 separately restricts use or installation of a pen register or trap-and-trace device without a court order, subject to statutory exceptions. One exception applies when the user of the relevant service has consented. 

Understanding CIPA for mobile apps requires separating these legal theories because Sections 631, 632, and 638.51 address different conduct. The facts needed to evaluate a claim can therefore change depending on the provision being asserted.

Read more: CNN Stuck With CIPA Suit Over Alleged Data Sharing 

Pearson used a hypothetical calculation during the webinar to demonstrate why statutory-damages claims can become commercially significant. The example assumed 1,000 California users each day, with three trackers firing for every user.

Applying $5,000 to each assumed violation across 365 days produces a theoretical figure of $5.475 billion.

The example is not a prediction of what a court would award. Pearson used it to show how quickly alleged statutory exposure can grow once individual interactions are multiplied across a proposed class.

Why can mobile app evidence create greater litigation risk?

Pearson pointed out that mobile apps can make it easier to identify individual users. People often create an account or log in before using an app, so account details and device identifiers may connect activity to a specific person.

Website cases are often different because many visitors never identify themselves. They may leave behind an IP address, cookies, or browser activity. Mobile apps can reveal more, including account IDs, advertising identifiers, location data, health information, installed apps, and background activity.

Pearson connects this difference with class certification. His point is not that app classes are always certified. Instead, identifying who belongs in a proposed class may be easier when the application connects activity with known users.

The webinar notes that Pearson was not aware of certification orders involving website users who never identified themselves. It cites certification denials in ‘In re Meta Pixel Tax Filing Cases and Ingraham v. Capital One Financial Corp’.

The outcome was different in ‘Frasco v. Flo Health’, where a California subclass was certified. This does not mean every mobile app privacy lawsuit will qualify for class certification. It shows why authenticated app users can change the class-identification question.

Frasco later went to trial against Meta after other defendants settled. A September 2025 post-trial order states that the jury found Meta violated CIPA Section 632. The court also rejected Meta’s requests to undo the class certification or jury verdict. 

The same need for technical clarity appears in newer mobile privacy cases. Privado AI’s analysis of the Amazon MHMDA lawsuit examines allegations involving the Amazon Ads SDK and the data it collected from mobile apps.

What do leading app-based cases show?

Pearson discussed three cases involving mobile SDKs: Greenley v. Kochava, Inc., Frasco v. Flo Health, and Caldwell v. InMobi Pte Ltd. They illustrate different ways in which plaintiffs have connected app technologies to older interception statutes.

Greenley v. Kochava

In Greenley, the plaintiff alleged that Kochava supplied an SDK to app developers and used it to obtain information from app users. Allegations discussed during the webinar included geolocation, advertising clicks, customer identifiers, search terms, and activities within installed apps.

The 2023 district court decision became important because the court allowed part of the plaintiff’s pen-register theory to survive dismissal. The ruling did not establish that SDK-based collection automatically violates CIPA.

Frasco v. Flo Health

Frasco involved allegations that SDKs embedded in the Flo app transmitted intimate health information and device identifiers to third parties. The case demonstrates how authenticated app use and sensitive information can affect both privacy claims and class-certification analysis.

The case later went to trial against Meta after settlements involving other defendants. The jury found that Meta violated Section 632, and the district court denied Meta’s post-trial motions in September 2025. 

Caldwell v. InMobi

Caldwell concerns allegations that an SDK collected precise location information, mobile advertising identifiers, IP addresses, and device-fingerprinting data. The plaintiff also alleged that this information was linked with real-world identity data. 

On April 29, 2026, the Northern District of California denied InMobi’s motion to dismiss. That ruling means the allegations survived the pleading stage. It is not a final determination that InMobi violated CIPA or another privacy law. 

Together, these cases make one point clear. An SDK’s presence does not itself establish liability. Privacy teams need to know what the SDK does, what information it sends, which consent state applies, and who receives the data.

How is California’s CIPA landscape changing in 2026?

California’s CIPA landscape remains unsettled. Senate Bill 690 could change private Section 638.51 claims, while appellate courts are considering questions involving CIPA and related federal privacy laws.

As of August 26, 2026, SB 690 remains an active bill in the Assembly floor process. It cleared the Assembly Appropriations Committee on August 13 and was ordered to third reading. It appears on the August 26 Assembly Third Reading File. 

The July 2 version is narrower than earlier drafts. It now proposes an amendment to Section 637.2 rather than the broader commercial-purpose changes previously proposed for other CIPA provisions. 

If enacted in its current form, SB 690 would limit certain private Section 638.51 actions involving websites, online applications, or mobile applications. For those claims against private actors, only the California Attorney General could bring the action. 

The proposal also contains a retroactivity provision covering specified pending claims commenced within two years before the bill’s operative date. It would not eliminate the existing private-action framework for Sections 631 or 632.

Several appellate matters discussed during the webinar also deserve attention, although they do not all concern CIPA:

• Variety Media, LLC v. Superior Court addresses whether Section 638.51 applies to internet technologies and under what circumstances scripts may qualify. The California Court of Appeal issued a tentative opinion on August 21 and heard oral argument on August 25. A final opinion was not available when this article was updated on August 26. 
• Salazar v. Paramount Global concerns the definition of a “consumer” under the VPPA, not CIPA. The US Supreme Court granted review in January 2026 and has scheduled argument for October 14, 2026.
• Goulart v. Cape Cod Healthcare, Inc. concerns the crime-tort exception under the ECPA. The First Circuit heard argument on April 6, 2026. 

The practical takeaway does not depend on predicting how those matters will end. Privacy teams still need current evidence about what their apps do, while counsel tracks changes in the law.

How can privacy teams reduce CIPA mobile app exposure?

Risk reduction starts with knowing what the app is doing. That was the practical shift in the webinar after Pearson discussed statutes and cases.

His advice was direct: “You need to know what is happening on your app so that in your disclosures, you can be painfully transparent.”

The webinar recommends five steps:

1.Know what is running

Privacy teams need an inventory of active SDKs and relevant permissions. That inventory should also cover third parties, outbound requests, and the personal data leaving the application.

This is not always obvious from development records. Pearson noted that limited visibility into app traffic affects both companies and plaintiffs. A team should not assume a technology is absent because nobody remembers adding it.

2. Know what the business needs

Each SDK and transmission should have a documented business purpose. Pearson’s webinar slide makes the commercial question explicit: companies should be able to explain the purpose behind each transmission.

That review can expose SDKs that remain active after their original purpose has disappeared. Removing unnecessary transmissions can reduce the number of data flows requiring ongoing legal review.

3. Align disclosures with observed behavior

Privacy notices and consent language should reflect what the application does in practice. Teams need to understand the data involved and its recipient. The stated purpose and the applicable consent position should also align with the underlying behavior.

Technical evidence matters here because documentation can become stale after an SDK update or product release.

4. Use existing onboarding points

Apps often create natural moments to present notices or obtain agreements. Download, account creation, login, or a relevant feature interaction can provide context for privacy information.

Whether a specific consent mechanism is legally sufficient depends on the claim and facts. Privacy teams should work with qualified counsel when designing those controls.

5. Monitor material changes

A review cannot end after the initial launch. New SDKs and vendor updates can change the app’s behavior. Product releases can do the same. Court decisions and legislation can change the legal analysis around those facts.

The common requirement across all five actions is current visibility. Privacy teams need to know what their apps are doing before they can assess the legal implications or ensure disclosures align with actual product behavior.

Privado AI’s consent compliance monitoring guide explains how teams can compare recorded consent choices with observed cookies, network requests, SDK calls, and other downstream activity. This evidence can also give counsel clearer facts when reviewing a mobile app privacy lawsuit or demand letter. 

How does Privado AI help reduce CIPA exposure on mobile apps?

Pearson’s recommendations depend on evidence about what happens inside the application. Romit Raj used the technical portion of the webinar to show how privacy teams can obtain that evidence without relying solely on product documentation or developers' recollections.

Romit framed the issue with a direct question: “Can you name every SDK active in your iOS and Android apps right now?” He put the operational test in two questions: can you name every SDK active in your iOS and Android apps right now, and can you confirm each one has a valid consent signal before it fires?

If the answer is unclear, consent reviews and disclosures may be based on an incomplete view of the application.

Privado AI App Auditor is built for this type of product-level privacy review. It scans iOS and Android app files after updates and requires no technical implementation for the initial audit. 

App Auditor inspection coverage

App Auditor discovers third-party SDKs and user permissions across mobile applications. It simulates user journeys before and after login to show which consent actions trigger specific SDKs. 

The resulting analysis can expose sensitive-data sharing and other third-party flows. It can also identify cross-border activity that privacy teams need to assess against the relevant legal requirements.

This gives privacy teams a current technical record rather than relying only on an SDK inventory maintained during development.

Consent enforcement validation

A Consent Management Platform (CMP) can capture and store the user's choice. App Auditor provides a separate check of whether downstream behavior follows that choice.

Privado AI can inspect SDK activity and network requests across different consent states. Its consent-monitoring approach maps user choices to SDK calls and network activity, in accordance with applicable requirements.

This means App Auditor can work alongside an existing CMP. It does not replace the consent-management layer or make the legal decision about whether a particular transmission is lawful.

Evidence available for review

App Auditor connects a privacy finding to the underlying technical behavior. Teams can review the SDK or third party involved, as well as the information transmitted. The consent state and related data flow provide additional context for investigation.

This level of evidence helps privacy teams bring a defined issue to engineering. Instead of asking whether an app might be sharing data, the discussion can focus on a specific SDK and request.

The webinar demo illustrates the point. Raj showed an application transmitting installed-app information, a device identifier, location, and language preferences to YouTube. Privado AI displayed the associated data-flow relationship and underlying request for review.

This example reflects the application tested during the demonstration. It should not be read as evidence that the same data flows exist across other apps.

What should privacy teams do next about CIPA mobile apps?

Understanding how CIPA applies to mobile apps requires legal analysis and a current view of what the application does. CIPA for mobile apps is still developing, and SB 690 could change one category of claims. Other pending cases may clarify how older privacy laws apply to newer tracking technologies.

Privacy teams can identify active SDKs, compare consent choices with observed behavior, keep disclosures aligned with the app, and test again after releases. Technical evidence does not determine legal liability, but it gives counsel better facts to review.

This evidence-based approach is also central to product privacy management, where privacy teams use current information from websites, apps, source code, and other systems to identify risks and support remediation as products change.

The Privado AI webinar brings together Pearson’s legal analysis and Raj’s technical demonstration. Privacy teams that want to review their own app behavior can also use App Auditor to inspect SDK activity and consent enforcement.

Watch the full CIPA mobile apps webinar:

‍Use Privado AI App Auditor to identify SDK activity and consent gaps before the next mobile app release reaches users.

Disclaimer: This article and webinar is for informational purposes only and does not constitute legal advice. CIPA interpretation, pending litigation, proposed legislation, and enforcement can change. Consult qualified counsel for guidance specific to your organization.

FAQs

What is CIPA, and does it apply to mobile apps?

The California Invasion of Privacy Act regulates several forms of interception and recording in California. Plaintiffs have brought app-based claims under Sections 631, 632, and 638.51. How CIPA applies to mobile apps depends on the applicable legal provision, the technical facts, consent, and the court’s interpretation.

Which CIPA sections are used in mobile app claims?

Mobile app claims discussed in the webinar involve Sections 631, 632, and 638.51. Section 631 addresses certain interception activities, while Section 632 covers confidential communications. Section 638.51 regulates the use of pen registers and trap-and-trace devices without a court order, subject to exceptions, including user consent. 

Why may app-based CIPA claims be easier to certify?

App-based claims may make proposed class members easier to identify because many apps require accounts or authentication. Website visitors often remain anonymous. The webinar uses Frasco v. Flo Health as an app-based example where a California subclass was certified, while stressing that certification still depends on the facts of each case.

How does the CIPA pen-register theory apply to SDKs?

Plaintiffs have argued that some SDKs can qualify as a “device or process” under CIPA’s pen-register provisions when they collect covered routing, addressing, or signaling information. Courts are still working through that theory. The result depends on what the SDK does, the information involved, consent, and statutory exceptions.

What does California SB 690 propose for mobile app claims?

As of August 26, 2026, SB 690 is pending in the California Assembly. The current version would limit certain private Section 638.51 actions involving websites, online applications, or mobile applications, so that such actions against private actors could be brought only by the Attorney General.

Can a company outside California face a CIPA claim?

A company is not outside CIPA risk solely because its headquarters are elsewhere. Whether a claim can proceed depends on the alleged conduct, its connection with California, the people involved, and applicable jurisdictional rules. Businesses with apps used by California residents should review those facts with qualified counsel rather than relying on corporate location alone.