CRA compliance for mobile apps

A mobile app is software (Art. 3(4)) and a product with digital elements (Art. 3(1)); a phone app is connected by nature, so Article 2(1) is met. Distributing it through an app store does not change who the manufacturer is: whoever develops the app and markets it under its own name or trademark, for payment or free of charge (Art. 3(13)).

Free apps are usually still commercial. Commercial activity covers apps offered free of charge (Art. 3(22)), and an app funded by subscriptions, in-app purchases or a paid companion product is monetised (Recital 18; FAQ 4.5.2). The exceptions are the same as for any software: non-monetised open-source apps (Recitals 18 and 20) and apps built only for your own organisation’s use (FAQ 1.5).

Most apps depend on a backend. Where the app cannot perform one of its functions without a service designed by you or under your responsibility, that service is remote data processing and part of the product (Art. 3(2); FAQ 1.2); your risk assessment must cover it (Art. 13(2)) and a vulnerability in it is a product vulnerability for Article 14. A standalone service no product of yours depends on is outside the Regulation (Recital 12).

Class follows the core functionality described in Implementing Regulation (EU) 2025/2392. An app whose core functionality is a password manager, a VPN client, an authentication app or a browser is important (Annex III, class I, points 3, 5, 1 and 2), and so is software that centrally controls smart locks, alarms or home cameras (point 17). Everything else is a default product and self-assesses under module A (Art. 32(1)).

Reporting is already live. Since 11 September 2026, every manufacturer of an in-scope product, including products already on the market, must notify actively exploited vulnerabilities and severe incidents through ENISA’s Single Reporting Platform (Art. 14; Art. 69(3); Art. 71(2)): early warning within 24 hours of becoming aware, notification within 72 hours, final report within 14 days of a corrective measure or one month for an incident (Art. 14(2), (4)), all to the CSIRT coordinator of your main establishment (Art. 14(7)); impacted users must be informed (Art. 14(8)).

From 11 December 2027 the rest of the Regulation applies to products placed on the market from then: Annex I essential requirements, Annex VII technical documentation, Annex V declaration of conformity, CE marking and Annex II user information (Art. 71(2)). Earlier products stay under Article 14 alone unless substantially modified (Art. 69(2)–(3); Art. 3(30)); placing on the market is counted per unit and per version (FAQ 7.2). An update that affects compliance with Annex I or changes the intended purpose is a substantial modification (Art. 3(30)).

No harmonised standard has been cited in the Official Journal yet, so there is no presumption of conformity to rely on (Art. 27). Unfinished versions may be distributed for testing for a limited time if they carry a visible non-compliance notice (Art. 4(3); FAQ 1.6).

1. 1. Assess the app and its backend together

   Register the app and the services it cannot work without, record the scope reasoning for each, and determine the class from the core functionality; note which parts are remote data processing so the risk assessment and the reporting routine cover them.

2. 2. Publish where to report and what you will do

   Provide a vulnerability reporting address and a coordinated disclosure policy (Art. 13(17); Annex I, Part II, points (5) and (6)), publish a security.txt file on the domain the app uses, and make the point of contact one that allows direct, rapid communication with a person.

3. 3. Prepare for Article 14 with the store in mind

   The 24-hour early warning does not wait for app review. Decide in advance who declares awareness, who has Single Reporting Platform access and which CSIRT coordinates for you, and plan how to inform impacted users (Art. 14(8)) while the fix is in review.

4. 4. Generate an SBOM for every build

   Cover at least the top-level dependencies, including third-party SDKs and advertising or analytics libraries (Annex I, Part II, point (1)); exercise due diligence on the SDKs you integrate (Art. 13(5)); and report a vulnerability you find in one of them to its maintainer while you fix your own build (Art. 13(6)).

5. 5. Put the support period and the security properties in the listing

   Set a support period of at least five years (Art. 13(8)) and state its end date, at least month and year, at purchase (Art. 13(19)). Give users the Annex II information: intended purpose, security properties, where updates come from (Art. 13(18)); ship secure defaults, data minimisation and permanent data removal (Annex I, Part I, points (2)(b), (g), (m)); and start the Annex VII technical file so the Annex V declaration and CE marking, for software on the declaration or the website, are ready in time (Art. 28; Art. 30).

Permenta keeps the app, its backend and every release in one registry, records the scope reasoning and class, and publishes a trust page with the support period, the security contact and security.txt. SBOMs uploaded from CI are matched against vulnerability feeds daily, the Article 14 desk runs the clocks and the field list when something is exploited in the wild, and the ledger keeps the record for ten years.

• Art. 2(1)
• Art. 3(1), (2), (4), (13), (22), (30)
• Art. 4(3)
• Art. 13(2), (5), (6), (8), (17), (18), (19)
• Art. 14
• Art. 27
• Art. 28
• Art. 30
• Art. 32(1)
• Art. 69(2), (3)
• Art. 71(2)
• Annex I, Parts I and II
• Annex II
• Annex III, class I
• Annex V
• Annex VII
• Implementing Regulation (EU) 2025/2392
• Commission FAQ v1.4: 1.2, 1.5, 1.6, 4.5.2, 7.2
• Recitals 12, 18, 20