Since 11 September 2026, the reporting obligations of the Cyber Resilience Act (CRA) apply. This means, for example, that you must report actively exploited vulnerabilities and severe incidents. Yet many companies still don’t know whether their product falls under the CRA. Does SaaS fall under it? And what about a browser extension, an app built with low-code, or healthcare software? During our CRA webinar, we received a lot of questions about the scope of the CRA. We listed them for you and asked Bernd, Stijn and Siebe for the answers.
Curious? Read on.
1. Does software without hardware fall under the CRA?
A product doesn’t need to contain hardware to fall under the CRA. Software on its own can very well be a product with digital elements (PDE). Think of a mobile app, desktop software (custom-built or not), or an online platform that complements your physical products, for instance to analyse statistics.
So, define clearly what your product consists of: hardware, software or a combination of both. How you define your product will determine how far your analysis needs to go.
2. Does SaaS fall under the CRA?
A service you only use through a browser falls outside the CRA. That changes, however, when the service provides remote data processing (a “remote data processing solution” or RDPS) for a product with digital elements. This is the case, for example, when the product cannot perform one of its functions without that processing, and the manufacturer manages that processing itself.
Take an industrial machine that uses sensors to determine when maintenance is needed. Through a SaaS platform, you can consult and analyse the sensor data. That SaaS platform is an RDPS, and therefore part of your product. The CRA won’t be the only relevant framework in this case.
Do you also offer the same software separately, for example as an on-premises version the customer installs themselves? Then that version is probably a PDE in its own right.
3. What if your SaaS has a browser extension or app?
A browser extension is software that the user downloads and installs, so it is a PDE. The backend also falls under the CRA as an RDPS, insofar as the extension cannot perform one of its functions without that backend.
The same logic applies to progressive web apps.
A handy rule of thumb: if your software is installed on the user’s device, the CRA applies in most cases.
4. Do customers and users also risk fines?
The obligations lie mainly with manufacturers, importers and distributors, and in specific cases with open-source software stewards and authorised representatives. The CRA exists precisely to protect users.
Still, vigilance is needed. A company that sees itself as a customer may in practice be an importer or distributor. And anyone who substantially modifies a product can become a manufacturer without realising it. That means you will fall under the heavier obligations for manufacturers. So set up the necessary internal processes and procedures, for example who may modify products and make them available, and which checks are needed for this.
5. Are you a manufacturer if you build with low-code or third-party AI?
How you make a product doesn’t change your role. Who makes your product doesn’t matter either. You don’t have to develop products yourself to be considered a manufacturer. If you use a low-code or no-code platform to build applications for external users, you remain the manufacturer of your own product. The platform provider may also fall under the CRA in its own right.
The same applies to a module built on top of third-party AI software. What is decisive, though, is that the product is actually placed on the market. If you only use it internally, that is probably not the case.
6. Does medical software fall under the CRA?
Software that is a medical device falls under its own regulation, such as the MDR, and therefore outside the CRA. Healthcare software that is not a medical device but does run in a hospital may well fall under it. So it’s important to check carefully which framework applies.
7. How does the CRA relate to the AI Act?
A high-risk AI system that meets the essential cybersecurity requirements of the CRA is deemed to meet the cybersecurity requirements of Article 15 AI Act (art. 12.1 CRA). A joint conformity assessment is also possible (art. 12.2 CRA).
8. What can you demand from your supplier as a user?
From 11 December 2027, you can expect, among other things, the following information and enforce it contractually:
- CE marking and EU declaration of conformity, or a simplified version with a link to the full one.
- The end of the support period, with at least the month and year.
- Contact details of the manufacturer and importer, plus a single point of contact for vulnerabilities.
- Product identification, intended purpose and known cybersecurity risks.
- Instructions for secure installation, updates and decommissioning, including deletion of data.
- When integrated into your own product: the information you need to comply with Annex I and Annex VII yourself.
Bear in mind that, unlike the GDPR, the CRA has an indirect impact on your contracts. Exactly what impact the CRA has on your contracts varies from case to case. The CRA has several roles, which means several combinations and types of contracts are possible. That increases complexity, but also contractual freedom. It’s wise to check the impact on your contracts.
Still in doubt? Start with your product list.
Whether or not your product falls under the CRA often depends on your specific situation. Don’t wait until 2027 to determine your scope: the reporting obligations already apply now, including for products currently on the market.
Three steps to get started:
- Map your products and your role.
- Build security into your development process.
- Set up a PSIRT process, a fixed way of working to capture and report vulnerabilities in your products.
Want to get up to speed in an hour? Rewatch our webinar “Up to speed on the CRA in one hour (NL)” or download the e-book (NL). Prefer to know straight away where you stand? Contact CRANIUM or Cingulum.
