The CRA's first duties started on 11 September 2026
Since 11 September 2026, manufacturers that sell software into the EU must report actively exploited vulnerabilities and severe incidents within fixed deadlines. This is the first part of the EU Cyber Resilience Act to apply. The Act's main obligations follow on 11 December 2027 (European Commission).
If you build a mobile app, a desktop product or software that customers install, the Act may already apply to you. If you run a SaaS product that people reach only through a browser, it generally does not, but a few exceptions catch teams by surprise. This post helps product and engineering leads work out which side they are on, and what to do first. For a better context, this piece is general information, not legal advice.
What the CRA covers
The CRA, formally Regulation (EU) 2024/2847, regulates "products with digital elements". Article 3 defines that as a software or hardware product together with its remote data processing solutions. Remote data processing means processing at a distance that the manufacturer designs or controls, and without which the product could not perform one of its functions.
The Act applies to products made available on the EU market, wherever the manufacturer is based. The manufacturer carries the duties: secure design, vulnerability handling, security updates, documentation and reporting. Article 2 also lists exclusions, such as medical devices and certain aviation-certified products, which are covered by their own rules.
Does it apply to your software?
It depends on how you deliver the software, not on what it does. On 27 July 2026 the Commission approved its guidance on applying the Act (Communication C(2026) 5252). The guidance is not law: it sets out the Commission's reading of the Act, and the Commission will adopt it formally once all language versions are ready. The table below follows its text, with the point numbers noted.
| How you deliver the software | In scope? | Why (Commission guidance C(2026) 5252) |
|---|---|---|
| Web app or progressive web app used only through a browser | Generally, outside | Software that runs remotely and is only accessed by the user is not a product with digital elements on that basis alone (point 21, Example 5) |
| Website that only presents information | Outside | Example 6 |
| Mobile app | In scope | Downloaded and run on the user's device, so it is a product with digital elements (Example 3) |
| Desktop app built with web technologies, or a browser extension | In scope | Supplied to the user and run locally (point 20, Example 4) |
| Source code you license to a customer as a product | In scope | Code supplied to customers as a product is placed on the market (point 24, Example 7) |
| Cloud backend that your product needs to work | Part of the product | Remote data processing under Article 3(2) (points 184 to 201) |
Placing on the market. The Act reaches software that is supplied in the course of a commercial activity, so a free app you publish for non-commercial reasons may fall outside it (point 23).
When a cloud service counts as part of your product. Article 3(2) sets three elements: the processing happens at a distance, the product could not perform one of its functions without it, and the software was designed and developed by you or under your responsibility (point 184). Software you deploy on a third-party IaaS or PaaS platform can qualify when the other elements are met (points 198 and 199). A third-party SaaS application that you integrate does not qualify, because you did not design it, but the guidance expects you to treat it like a third-party component and carry out due diligence on it (points 200 and 201). A website counts only if it enables or supports a function of the product, such as an authentication portal that issues tokens the product needs (point 194).
The practical test. Ask two questions. Does any part of the software run on a user's device or on customer systems? Is the service the backend of a connected product? A yes to either puts you in scope. Two noes mean the Act generally does not apply to that offering, though the CRA is one of several rules your product may still face. Edge cases, such as a self-hosted version of a SaaS product, are worth taking counsel.
Key dates
The Act entered into force on 10 December 2024. Reporting duties apply from 11 September 2026, and the Regulation applies in its entirety from 11 December 2027 (European Commission). The reporting duty is not retroactive: you need not report an exploited vulnerability you already knew was being exploited before 11 September 2026. If you knew of a vulnerability but not of any exploitation, and exploitation is confirmed after that date, the duty applies (Commission guidance, point 217).
What software teams must do
1. Handle vulnerabilities for the whole support period. You must fix vulnerabilities and ship security updates for at least five years, or for the expected use time if that is shorter (Article 13(8)). The guidance treats five years as a safeguard, not a default, so a product expected to stay in use longer needs a longer support period (point 126). You must also state the end date, to the month and year, when the customer buys (Article 13(19), point 127). One timing point matters: the vulnerability handling duties in Annex I Part II do not apply to products placed on the market before 11 December 2027, but the reporting duties apply to all in-scope products from 11 September 2026, including after support ends (point 210).
2. Know what is inside your product. Annex I Part II, point 1, requires manufacturers to identify and document the components in their products, including by drawing up a software bill of materials (SBOM) "in a commonly used and machine-readable format" that covers at the very least the top-level dependencies (Regulation (EU) 2024/2847). That duty applies in full from 11 December 2027, but you cannot work out whether an exploited vulnerability is in your product without a component list, so teams should build it now. Recital 77 adds that the SBOM does not have to be made public. In practice, generate an SBOM from your build for every release and keep it with the release record.
3. Report on a fixed clock. For an actively exploited vulnerability or a severe incident, you send an early warning within 24 hours of becoming aware, and a fuller notification within 72 hours of becoming aware. The final report for an exploited vulnerability is due within 14 days after a corrective or mitigating measure is available. For a severe incident it is due within one month after the 72 hour notification (Commission guidance, point 215). You notify the national CSIRT and ENISA at the same time (point 209), through the ENISA Single Reporting Platform. You must also inform affected users, in a risk-based and proportionate way (Article 14(8), points 219 and 220).
4. Be able to show when you became aware. The clock starts on awareness, not on discovery. The guidance says you are aware when, after an initial assessment, you have a reasonable degree of certainty that a vulnerability in your product is being actively exploited, or that a severe incident has compromised its security (point 213). The emphasis is on carrying out that initial assessment promptly (point 214). A vulnerability that originates in a third-party component counts if it is actively exploited in your product. A known vulnerability that is not exploitable in your product, or has not been exploited, is not reportable (point 218). Keep a timestamped log of each assessment so you can show when the clock started.
The four duties share one dependency: someone has to own them. A team where one engineer holds all the release and patching knowledge will struggle to meet a 24 hour deadline. We covered that risk in When Your Product Depends on One Engineer.
What non-compliance costs
Article 64 sets three fine tiers. For companies, the higher of the fixed amount or the share of worldwide annual turnover applies.
| Tier | Maximum fine | What it covers |
|---|---|---|
| 1 | EUR 15 million or 2.5% of turnover | Annex I security requirements, and the manufacturer duties in Articles 13 and 14, including reporting |
| 2 | EUR 10 million or 2% of turnover | Most other listed obligations, such as the EU declaration of conformity, CE marking and technical documentation |
| 3 | EUR 5 million or 1% of turnover | Giving inaccurate or misleading information to authorities or notified bodies |
Micro and small enterprises cannot be fined for missing the 24 hour early warning deadlines, and open source stewards cannot be fined for any infringement of the Regulation (SpringLex).
A 90-day starting checklist
You can start without waiting for standards or further guidance. Six tasks give a product team a defensible position:
- Decide scope for each product. Use the two questions above, record the answer and the reasoning, and have counsel review any edge case.
- Name the owner. Choose who decides that a vulnerability is being exploited, and who sends the report.
- Generate an SBOM for every in-scope release. Build it from the pipeline rather than by hand and store it with the release.
- Set the support period and end date. Write down five years or more, per product, and plan how you will tell customers.
- Write the reporting runbook. Cover the 24-hour, 72 hours and 14-day steps, who is on call, and where the timestamped awareness log lives.
- Watch your third-party components. Track which dependencies have known exploited vulnerabilities, since only exploited ones trigger a report.
Patching and updates continue long after the first 90 days.
How maintenance work covers these duties
Most of the CRA's day-to-day duties are maintenance routines: patching, dependency updates, release discipline, and a clear owner for each product. Teams that already run these well have a head start. Teams that treat maintenance as a back-office chore, as we describe in application maintenance challenges, will feel the gap when a 24-hour clock starts.
Our web application maintenance and mobile app maintenance services cover the ongoing patching and update work that the support period requires. If you are unsure which of your products fall under the Act, start with the scope questions above and bring the result to a conversation with us.
Frequently asked questions
Does the Cyber Resilience Act apply to SaaS?
Generally, not when users reach the service only through a browser, and it is not the backend of a product with digital elements. A downloadable client, a self-hosted version or a backend that a product needs to work can bring it into scope.
Does it apply to open-source software?
It depends on whether the software is placed on the market through commercial activity. Where open-source software is published without being placed on the market, the publisher may be a steward with lighter duties, which depend on the support it provides (Gaming Tech Law).
Do we need an SBOM?
Yes. Annex I Part II, point 1, requires an SBOM in a commonly used, machine-readable format that covers the very least the top-level dependencies (Regulation (EU) 2024/2847). The duty applies in full of 11 December 2027, and the SBOM stays in your technical documentation rather than being published.
What do we have to report, and to whom?
Actively exploited vulnerabilities and severe incidents, to the national CSIRT and ENISA through a single reporting platform, on a 24-hour, 72 hour and final report schedule (CRA reporting guide).
Does a company outside the EU have to comply with?
Yes, if it makes products with digital elements available on the EU market. The Act applies to the product on the market, not to where the manufacturer is based.
