CRA compliance for Electron and desktop apps

A desktop application, whether built with Electron, Tauri, Qt or .NET, is software and therefore a product with digital elements (Art. 3(1), (4)). It need not be a network product: the Regulation applies wherever the intended or reasonably foreseeable use includes a direct or indirect, logical or physical data connection, and an offline application is indirectly connected through the operating system it runs on (Art. 2(1); FAQ 1.3).

Whether you charge is not the test; commercial activity is. A free download that leads to a paid licence, a subscription, paid support or an in-app upgrade is supplied commercially (Art. 3(22); Recital 18; FAQ 4.5.2). A non-monetised open-source app funded by donations alone is not made available on the market (Recitals 18 and 20); an internal tool used only inside your company is not placed on the market (FAQ 1.5).

If the app cannot perform one of its functions without a service you operate, say a sync backend or a licence server, that service is remote data processing and part of the product (Art. 3(2)). A standalone online service the app merely talks to as a client is a separate question (Recital 12; FAQ 1.2).

Embedding Chromium does not make your app a browser: class follows the core functionality described in Implementing Regulation (EU) 2025/2392, and integrating an embedded browser does not turn the host into one (FAQ 3.2). Most desktop apps are default products and self-assess under module A (Art. 32(1)); an app whose core functionality is a password manager, a VPN client, antimalware or a network management system is class I (Annex III, class I, points 3, 5, 4 and 6) and follows the class I route (Art. 32(2)).

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).

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. Register the app and settle scope and class

   Record the product, its editions and the services it depends on, answer the scope questions with the reasoning, and confirm the class from the core functionality rather than from the libraries the app embeds.

2. 2. Make the updater a security control

   Security updates must be possible and, where applicable, automatic by default with an easy opt-out (Annex I, Part I, point (2)(c)); the update channel must be authenticated and integrity-protected (Annex I, Part II, point (7)); security updates ship without delay and free of charge, separately from feature updates where feasible (points (2) and (8)); and each stays available for ten years (Art. 13(9)).

3. 3. Publish a contact and a disclosure policy, and prepare to report

   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 your domain, and rehearse the Article 14 routine with Single Reporting Platform access and your coordinator CSIRT identified.

4. 4. Build the SBOM into the release pipeline

   An Electron app bundles a runtime and hundreds of packages. The SBOM must cover at least the top-level dependencies (Annex I, Part II, point (1)) and be watched continuously: a vulnerability in Chromium or Node.js becomes yours to remediate and report upstream, and integrating third-party components carries a due-diligence duty (Art. 13(5), (6)).

5. 5. Secure defaults, a support period and the technical file

   Ship a secure-by-default configuration with a reset to the original state (Annex I, Part I, point (2)(b)), let users remove their data permanently (point (2)(m)), set a support period of at least five years and state its end date at purchase (Art. 13(8), (19)), and start the Annex VII technical file with the risk assessment (Art. 13(2)–(3); Art. 31). For software, the CE marking goes on the declaration of conformity or the accompanying website (Art. 30).

Register the app and its backend as products, let the scope wizard record why the Act applies and which class the app is in, and upload the SBOM from each build so components are matched against vulnerability feeds daily. When a bundled runtime turns up on an exploited-vulnerability list, the Article 14 desk opens a case with the clocks running; advisories and releases go on the trust page and the ledger.

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