Dev.to Security ๐Ÿ” Cybersecurity ๐Ÿ‘ 0 ๐Ÿ“– 6 min read

Does the Cyber Resilience Act apply to mobile apps?

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 element

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

  1. List every app you publish or maintain in the EU, with its platforms and current version.
  2. For each one, note who publishes it under their name. That company is normally the manufacturer.
  3. 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. See how CRA vulnerability reporting works.
  4. Register for ENISA's Single Reporting Platform before you need it. Access requires an EU Login account with multi-factor authentication.
  5. Decide the support period you will declare for each app and plan the updates it implies.

Try it on your own app: the free Shipmark scanner builds a CycloneDX SBOM from a lockfile in the browser and checks it against OSV.dev. Not sure the CRA applies? Use the six-question CRA check.

Sources

This guide summarises EU law and non-binding Commission guidance for practical use. It is not legal advice. Related: CRA vulnerability reporting ยท SBOM for Flutter apps ยท SBOM for React Native apps.

Originally published on shipmark.eu, where the guide is kept up to date. More guides for app teams: shipmark.eu/guides.

๐Ÿ“ฐ Read the original article on Dev.to Security

Originally published by Dev.to Security. Aggregated on AIWithGhost for educational purposes โ€” full credit and traffic to the original publisher.

Share ๐• Twitter โœˆ Telegram โ†— Reddit ๐ŸŸง HN
โ† News ๐Ÿ” Cybersecurity ๐Ÿ  Home