For years, software could be sold in Europe without any general rule requiring a level of security. That is over. The Cyber Resilience Act, EU Regulation 2024/2847, applies to almost anything that contains software and connects to something: connected devices, but also mobile apps and installed software. It entered into force in December 2024, and its first concrete obligation has applied since 11 September 2026: reporting exploited vulnerabilities. If your business publishes an app or sells software, you are probably affected, even if someone else built it for you.
Is your app in scope?
The regulation covers “products with digital elements”, meaning any software or hardware product intended to connect to a device or a network. The guidance the Commission published in July 2026 is explicit: a mobile app downloaded from a store and installed on a phone is such a product, as is a program installed on a computer. It must also be supplied in the course of a commercial activity, which is not just about price: a free app funded by advertising, or one that requires personal data to be used, counts too.
The server behind the app is often included. The regulation covers the manufacturer’s “remote data processing solutions”, without which the product could not perform one of its functions. Its Recital 11 gives precisely the example of a mobile app that relies on an interface or a database developed by its publisher. Conversely, a web app used only in the browser and a brochure website fall outside the scope, unless they support the functioning of a product. As for software offered online on subscription, SaaS, the regulation in principle leaves it to different legislation, the NIS2 Directive.
Outsourced does not mean not responsible
This is the point that surprises our clients most. The regulation calls “manufacturer” whoever develops a product, or has it designed and developed, then markets it under their own name or trademark. In other words, if an agency builds your app and you publish it under your brand, it is you, on a reading of the text, who carries the manufacturer’s obligations. The developer obviously has a part to play, but it is your name on the store listing, and you are the one the authorities will contact.
Software built to order for a single business client remains in scope: the Commission only specifies that the manufacturer and its client can then agree, by contract, to depart from two requirements, secure-by-default configuration and free security updates. The case of a tool developed purely for internal use is less clear-cut: a product made for one’s own use is in principle not placed on the market, but the boundary deserves a case-by-case look.
Since September: 24 hours to report
Since 11 September 2026, a manufacturer that learns a vulnerability in its product is being actively exploited, or that a severe incident affects its security, must report it in three stages:
- An early warning within 24 hours of becoming aware
- A notification within 72 hours, with initial information on the vulnerability and the measures taken
- A final report no later than 14 days after a fix is made available for a vulnerability, or one month after the notification for an incident
Reports go through a single platform run by ENISA, the EU cybersecurity agency, and reach the national response centre. In Belgium, that is the Centre for Cybersecurity Belgium. You must also inform affected users and tell them how to protect themselves. This obligation covers every product in scope, including those already on the market before 2027. It is not retroactive, however: according to the Commission, an exploitation the manufacturer knew about before 11 September 2026 does not need to be reported.
Twenty-four hours is short, and the clock starts when you know. In practice, you need to know in advance who receives the alert, who decides, and who fills in the form. An app whose dependencies and logs nobody watches will not spot an exploited vulnerability in time, and that is precisely what the text sets out to change.
The question is no longer whether your app will have a vulnerability, but who will notice, and how fast.
December 2027: security becomes a product requirement
From 11 December 2027, the rest of the regulation applies. Products will have to be designed to a list of essential requirements, the core of which is:
- No known exploitable vulnerability when placed on the market, and a secure configuration by default
- Free security updates, automatic by default where relevant, for a support period of at least five years, unless the product is expected to be used for less time
- A software bill of materials, covering at least direct dependencies, in a machine-readable format
- A point of contact for vulnerability reports, and a policy for handling them
- Technical documentation and a declaration of conformity, kept for ten years, and a CE marking which, for software, may appear on the declaration or on the accompanying website
For the vast majority of apps and software, assessment is done through internal control: no outside body, but a file to keep. Only certain categories, such as password managers, VPNs or browsers, follow a stricter procedure. Products placed on the market before December 2027 are only subject to it after a substantial modification, but an app that regularly ships new versions will get there quickly.
Fines, and what is planned for small businesses
Breaching the essential requirements or the reporting obligations can cost up to €15 million or 2.5% of worldwide annual turnover, whichever is higher. Authorities must take the size of the business into account, and the regulation provides that micro and small enterprises are not fined for missing the 24-hour early warning deadline. The 72-hour and final report deadlines still apply. Member States must also offer small businesses awareness-raising, training and a dedicated contact channel.
Where to start
Right now, three things are enough to avoid being caught out: decide who receives and handles a security alert, publish a contact address for vulnerability reports, and list the third-party components your app ships with. By the end of 2027, you will then need to commit to a realistic support period, organise updates and build the technical file. If your app can already be fixed quickly, without waiting for store review, you are a step ahead.
This is not legal advice: for a borderline case, a lawyer will decide. It is, however, work we build into our product engineering and platforms and infrastructure projects: tracked dependencies, planned updates, usable logs. If your app was built a few years ago and nobody really knows what is inside it, write to us: an inventory is often enough to know where you stand.