Does the Cyber Resilience Act apply to mobile apps?
Updated 6 November 2026 · 9 min read · Based on Regulation (EU) 2024/2847 and the Commission guidance of 27 July 2026
Short answer: yes, for most apps published by companies.
- An app that users download and run on their phone is software "provided to and obtained by a user", which the Commission treats as a product with digital elements.
- It is covered when it is made available in the EU in the course of a commercial activity. A price is not required: monetisation through ads, data or related services can be enough.
- A website or web app used only in the browser is not covered on that basis alone, but the backend of an installed app can be.
- Reporting of actively exploited vulnerabilities already applies, since 11 September 2026, to apps that are on the market today. Everything else applies from 11 December 2027.
What the regulation says
The Cyber Resilience Act (CRA), Regulation (EU) 2024/2847, applies to "products with digital elements made available on the market" whose intended or reasonably foreseeable use includes a data connection to a device or network (Article 2(1)). Article 3(1) defines a product with digital elements as a software or hardware product and its remote data processing solutions.
A mobile app is software, and it connects to networks almost by definition. The questions that decide whether a specific app is in scope are therefore narrower: is it supplied for local use, is it made available in a commercial context, and does an exclusion apply?
1. Installed apps are products, browser-only web apps are not
The Commission's guidance on the application of the CRA, adopted on 27 July 2026 (C(2026) 5252), explains that standalone software is in scope when it is provided to and obtained by a user and executed on the user's side. That covers apps downloaded from the App Store or Google Play, installed desktop software and browser extensions.
Software that executes remotely and is merely accessed by the user, such as a typical website or web app, is not a product with digital elements on that basis alone. The guidance uses online banking as an example: the banking app customers install is in scope and the bank is its manufacturer, while banking used purely through a web browser is not itself a product.
2. "Commercial activity" is broader than charging a price
The CRA covers products made available in the course of a commercial activity. According to the Commission guidance and the summaries published by law firms, a commercial context can exist without a direct price, for example when:
- the software is used to monetise other products or services;
- personal data is required for purposes other than security, compatibility or interoperability;
- access to the software is tied to buying a service.
The assessment is made per product, not per company. A donation link alone does not make software commercial, and separately sold consulting or training does not automatically make a free product commercial.
| Example | Likely position |
|---|---|
| Paid app, or free app with in-app purchases | In scope |
| Free app from a company, financed by ads or data collection | In scope |
| Free app that is part of a paid service (banking, retail, utilities, fitness) | In scope; the company that publishes it is the manufacturer |
| Companion app for a connected device | In scope, together with the device |
| Free hobby app by an individual, with no monetisation of any kind | Usually outside scope |
| Website or web app used only in the browser | Not a product on that basis alone |
These examples summarise the guidance for practical use. Borderline cases depend on the facts and are worth checking with a lawyer.
3. The app's backend can be in scope too
Because the definition includes remote data processing solutions (Article 3(2)), the servers an app relies on can fall under the CRA. The Commission applies three tests: the processing happens at a distance, the app cannot perform one of its functions without it, and it was designed by or under the responsibility of the manufacturer. Internal systems the app does not interact with, such as a CRM, HR tools or CI/CD pipelines, are not remote data processing solutions.
In practice: the API your app calls to log users in or load their data is likely part of the product. Your company's marketing tools are not.
4. What is excluded
Article 2 leaves out products already covered by specific EU rules, including:
- medical devices and in vitro diagnostic medical devices under Regulations (EU) 2017/745 and 2017/746;
- motor vehicles and related systems covered by type-approval rules, and certain civil aviation and marine equipment;
- products developed or modified exclusively for national security or defence purposes.
A health app that is not itself a medical device under the MDR is not excluded by this rule. The test is whether the app is certified as a medical device, not whether it deals with health.
5. Some apps are "important products"
Most apps fall into the default category, for which the manufacturer can assess conformity itself. Annex III lists important products with digital elements that face stricter conformity assessment. App-relevant examples include password managers, VPN products, standalone browsers and software that searches for, removes or quarantines malicious software. If your app's core function is one of these, check Annex III before planning the work.
6. The dates that matter
| Date | What applies |
|---|---|
| 11 September 2026 | Manufacturers must report actively exploited vulnerabilities and severe incidents through ENISA's Single Reporting Platform: an early warning within 24 hours, a notification within 72 hours and a final report within 14 days of a fix (one month for severe incidents). This applies to apps already on the market. There is no duty to report retroactively a vulnerability that was exploited and known before that date. |
| 11 December 2027 | All other obligations: the essential cybersecurity requirements of Annex I, an SBOM, vulnerability handling, a declared support period of generally at least five years, the technical documentation of Annex VII and the EU declaration of conformity. |
Each version placed on the market should have a declared support period. Later downloads of the same version are not new placements, while variants with different components, configurations or functions are separate products.
What app teams should do now
- List every app you publish or maintain in the EU, with its platforms and current version.
- For each one, note who publishes it under their name. That company is normally the manufacturer.
- Set up a way to notice actively exploited vulnerabilities in your dependencies quickly. Without an SBOM per release, the 24-hour deadline is very hard to meet.
- Register for ENISA's Single Reporting Platform before you need it. Access requires an EU Login account with multi-factor authentication.
- Decide the support period you will declare for each app and plan the updates it implies.
Start with the first step: see what is inside one of your apps and whether any component has known vulnerabilities.
Open the free scannerSources
- Regulation (EU) 2024/2847 (Cyber Resilience Act), EUR-Lex: Articles 2, 3, 13, 14 and Annexes I, III, VII.
- European Commission: guidance to support the implementation of the CRA, C(2026) 5252, 27 July 2026.
- ENISA: The CRA Single Reporting Platform is launched, 11 September 2026.
- ENISA: Single Reporting Platform FAQ.
- Summary of the final Commission guidance and Osborne Clarke's analysis.
This guide summarises EU law and non-binding Commission guidance for practical use. It is not legal advice. Related: SBOM for Flutter apps · SBOM for React Native apps.