- Installed apps are in scope; browser-only web apps are not. A SaaS back end is pulled in when an installed app of yours cannot work without it.
- Two dates matter. The Article 14 reporting obligation applies from 11 September 2026, and the remainder generally from 11 December 2027.
- Build the paperwork and the process, not just the code. You need a reporting runbook, an SBOM, a defined support period, technical documentation and a declaration of conformity.
The EU Cyber Resilience Act (CRA, Regulation (EU) 2024/2847) sets cybersecurity requirements for "products with digital elements". It applies to your app if it is installed software with a data connection, such as a mobile or desktop app. It applies to your SaaS only when that SaaS is the back end an installed app of yours needs in order to function. A web app used exclusively through a browser is generally outside it.
This article walks through the scope test, the dates, and the work to have done before you ship. It is a plain-language engineering view, not legal advice. Have a lawyer confirm your classification.
What the CRA actually covers
The Act entered into force on 10 December 2024. According to this explainer, it covers products whose intended or reasonably foreseeable use includes a direct or indirect data connection. That includes mobile and desktop applications, operating systems, libraries and components, unless a specific exclusion applies.
For a software team, that means two things. An app you distribute to users' devices is within the definition. So is a library or component that other products embed, unless an exclusion applies.
Is your web app or SaaS in scope?
This is where most founders get confused, so take it in steps.
Browser-only products are out
The Commission's guidance (Section 2.2), as summarised here, states that web applications and progressive web apps accessed exclusively through a browser are not products with digital elements. If your whole product is a website people log into, the CRA does not treat it as a product in its own right.
Your back end can be pulled in
The exception is "remote data processing". The same source says a web product falls in scope only where it qualifies as remote data processing for a product, such as a back end that an installed app cannot function without.
The CRA recital gives a direct example: a mobile application that needs access to an API or database provided by a service the manufacturer developed. In that case the service falls within scope as a remote data processing solution.
The three checks
The Commission's 27 July 2026 guidance sets three checks for remote data processing:
- The processing is at a distance.
- The product cannot perform a function without it.
- The software was designed and developed by, or under the responsibility of, the manufacturer.
The guidance is explicitly non-binding. It is identified as C(2026) 5252 and runs to 84 pages. Treat it as guidance on how the law may be read, not as the law itself.
Quick scope table
| What you ship | Likely in scope? | Why |
|---|---|---|
| iOS or Android app | Yes | Mobile applications with a data connection are named in scope |
| Back end and API your own app depends on | Yes, as remote data processing | The app cannot work without it and you built it |
| Browser-only SaaS or PWA, no installed client | Generally no | Not a product with digital elements |
| Library or component others embed | Yes, unless an exclusion applies | Libraries and components are named in scope |
| Browser-only SaaS plus a companion mobile app that needs it | The back end likely yes | The app cannot function without the back end you built |
Notice the last row. Adding a mobile app to a web SaaS can change your regulatory position, so account for that before you decide to ship a native client.
The dates that matter
The Act has two main application dates, per Crowell and Hunton:
- 11 September 2026: the Article 14 reporting obligation applies.
- 11 December 2027: the remainder generally applies.
Do not read the second date as a reason to relax. The reporting duty is already live. According to the Commission's guidance as summarised here, it applies to apps already on the market and continues after a product's support period ends. A second source says it applies even to products already on the market.
Reporting is not the whole regime, though. The vulnerability-handling requirements in Annex I are not legally binding until 11 December 2027. Even so, it makes sense to build the handling process now, because you cannot report well without it.
What you must be able to do: reporting
The Commission's reporting page sets the schedule:
- An early warning within 24 hours of becoming aware.
- A full notification within 72 hours.
- A final report no later than 14 days after a corrective measure is available, for actively exploited vulnerabilities. For severe incidents, the final report is due within a month of the 72-hour notification.
You report once, through the CRA Single Reporting Platform (SRP). ENISA established the platform, and it has been operational since 11 September 2026, per the same page.
For your build, this means you need to know in advance who decides that something is reportable, who files it, and what information they need. A 24-hour window leaves no time to find out who owns the app store account or where the dependency list lives.
What to build before you ship
Here is a practical checklist, in the order we would do it.
1. A vulnerability intake and triage process
Publish a way for researchers and users to tell you about a security problem. Decide who reads it, how fast, and who can authorise a fix. Keep a log. This is the front door to your reporting duty.
2. A reporting runbook
Write a one-page document covering the 24-hour, 72-hour and final-report steps, named owners with backups, and access to your SRP account. Run a tabletop drill once so the first real attempt is not the first attempt.
3. A software bill of materials (SBOM)
Manufacturers must document the components in their products, including an SBOM in a commonly used, machine-readable format covering at least the top-level dependencies. Generating it in your CI pipeline on every release keeps it from becoming a manual task. It also gives you a quick way to check whether a newly disclosed library flaw affects you.
4. A defined support period for each version
The support period must be at least five years, unless the product is expected to be used for less time. Security updates must remain available for a minimum of 10 years or, if longer, the duration of the support period.
For software that evolves through multiple versions, each version placed on the market should have its own defined support period. A fast-moving mobile app needs a written policy: which versions you patch, how users are pushed to update, and what happens when a version reaches end of support.
5. A working update path
Check that your release pipeline can get a security patch through review, build, store submission and rollout without improvisation. For mobile, include a way to prompt or require users to update.
6. Technical documentation and a declaration of conformity
Per the German BSI, the conformity route for most products is a self-assessment by the manufacturer, and for a few it is an assessment by a notified third-party body. A declaration of conformity is required either way. Keep your architecture notes, test results and SBOM together in one place so the declaration rests on evidence.
What non-compliance costs
The top penalty tier is fines of up to €15 million or 2.5% of total worldwide annual turnover, whichever is higher, for non-compliance with the essential requirements or manufacturer obligations. Two lower tiers sit beneath it, at 10 million euros or 2%, and 5 million euros or 1%. Those figures are ceilings, not predictions.
How this changes planning a new build
Treat the checklist above as part of the first build rather than a later add-on. An SBOM generated in CI, a vulnerability contact page and a written support policy can all be set up from the start.
If you are weighing up scope, our software development page explains how we work, and the project planner helps you outline what you need. You can also see how we price, or get in touch if you want a second opinion on whether your product falls under the Act.
FAQ
Does the Cyber Resilience Act apply to a SaaS that only runs in the browser?
Generally no. The Commission's guidance, as summarised by CyberCert Labs, says web applications and PWAs accessed exclusively through a browser are not products with digital elements. The exception is when your service is remote data processing for a product, for example a back end that an installed app of yours cannot function without.
Do I have to report vulnerabilities if my app launched before the deadline?
Yes, according to the guidance summaries. The reporting duty applies to apps already on the market and continues after a product's support period ends. Reporting has applied since 11 September 2026.
Do I need a third-party audit to comply?
For most products, no. The BSI explains that the route is a self-assessment by the manufacturer for most products, with a notified third-party body for a few. You still need a declaration of conformity either way, and a lawyer should confirm which route applies to you.
Is the Commission's guidance legally binding?
No. The 27 July 2026 guidance is explicitly non-binding. Plan around it, but revisit your decisions if the interpretation changes.
