Cyber Resilience Act: does it affect your company?
The CRA reporting rules apply since 11 September. Most company websites are not affected, but apps, connected products and custom systems may be. Here is a simple checklist.
Got an email about the CRA? It is usually not your website it is about
If you have read a warning or received an email about the EU Cyber Resilience Act (CRA), it may sound as if every company with a website must now act. For most, that is not the case. For a few it is, and then you want to know before you sign a contract.
Most of our customers have an ordinary company website, and those are normally not covered by the CRA. It is only when you sell an app, a connected product or software, or have a custom system built under your name, that the law can become your responsibility. This post explains who the law applies to and which four questions to ask. It is not legal advice.
What is the Cyber Resilience Act, and what happened on 11 September?
The law in one sentence: cybersecurity in products with digital elements
The CRA (Regulation (EU) 2024/2847) sets cybersecurity requirements for products with digital elements. These are hardware and software connected to a device or a network and supplied in the course of commercial activity on the EU market. That can be an app, a smart device or a program the customer installs, and it does not matter where the manufacturer is based. See the European Commission overview.
Two dates: reporting since 11 September 2026, main requirements 11 December 2027
The law entered into force on 10 December 2024. The reporting requirements apply from 11 September 2026 and the main requirements from 11 December 2027. Since 11 September, manufacturers must report actively exploited vulnerabilities and severe incidents that affect the security of products with digital elements. The deadlines, according to the Commission's reporting page, are:
- An early warning within 24 hours of the manufacturer becoming aware.
- A full notification within 72 hours.
- A final report no later than 14 days after a fix is available for a vulnerability.
- For severe incidents, the final report is due within one month of the 72-hour notification.
Reporting goes through ENISA's Single Reporting Platform, and the reports go to ENISA and to the national CSIRT. The requirement applies to all products with digital elements on the EU market, including those launched before 11 September 2026. Being an old product gives no exemption, as explained in this guide to Article 14.
According to a third-party summary, the main requirements from 2027 include secure development, vulnerability handling, technical documentation, CE marking and a support period during which the manufacturer handles vulnerabilities, often at least five years. A software bill of materials (SBOM) is mentioned as a tool in vulnerability handling. Since this is a summary, the details should be checked against the regulation text.
The Commission guidance from 27 July 2026
The Commission published its first official guidance on 27 July 2026 (C(2026) 5252). It is non-binding but shows how the authorities are expected to interpret the law, including when a product is covered, what counts as a substantial modification and how support periods and reporting apply. According to a review of the guidance, it is written with small companies in mind, runs to 84 pages with 67 examples, flowcharts and use cases, and moves no dates.
A simple rule of thumb based on the guidance: a plain website falls outside, while a cloud backend that a product depends on can fall inside.
Who the law applies to and who it does not
Probably outside: ordinary company websites and pure web services
Websites that do not support the function of a product with digital elements are not covered by the regulation. This follows from the recitals, reproduced here. An ordinary company website that only presents the business is therefore normally outside.
Pure SaaS, meaning a service used in the browser and not installed, is also normally outside. That can change, as we describe below.
Probably inside: apps, connected products and software you sell
A downloadable app or an installed client program is always a product. The same goes for a smart device or a program you supply to customers in commercial activity.
The manufacturer is whoever markets the product under their own name or brand, even if someone else wrote the code. If you commission an app and publish it under your own brand, you are the manufacturer, and hiring a supplier does not move the legal responsibility. This is described in, among others, this article on custom software development.
Borderline cases: commissioned systems, open source and cloud backends
Cloud backends: pure SaaS changes if the cloud part is developed by the manufacturer and the product does not work without it, so-called remote data processing. An example is the backend of an app. This is explained in this overview of common CRA questions.
Commissioned systems: if you only use the system internally and do not market anything under your own name, it is unclear who the manufacturer is. One source says it is then usually the supplier, but the question is not finally settled. Software used only internally and never made available to others is not considered placed on the market. The sources disagree about custom software built for a single customer, as this overview shows. We therefore do not give a ready answer here, and in such cases we recommend a lawyer.
Open source: free and open source software supplied outside commercial activity is exempt. When such code is built into a commercial product, the manufacturer of the product takes responsibility for the components, as Jama Software describes. This matters if you build on WordPress plugins, libraries or frameworks in a product you sell.
Four questions to ask: manufacturer, reporting, updates and code
We advise you to ask these questions in the contract. For custom software built for a specific business user, the parties can expressly agree to exclude two requirements: secure default configuration and free security updates. Greenberg Traurig describes this, and it is why the contract matters. This is a practical checklist and not legal advice.
Who is the manufacturer, and is it enough that someone else wrote the code?
No, it is not enough. If the product is sold under your name or brand, you are the manufacturer, even if a supplier wrote every line of code. Ask plainly: who is the manufacturer under the law, and does the contract say so?
Who reports within 24 hours?
An early warning must be sent within 24 hours of the manufacturer becoming aware of an exploited vulnerability. Ask who detects and reports it, and who is in contact with the authorities. If the answer is that nobody knows, you lack a person who can act in time.
How and for how long is the system updated?
Ask how and for how long security updates are delivered, and who pays. Since the main requirements include a support period that is often at least five years, you should not settle for a verbal promise. Also make sure the contract does not quietly waive updates that you would then have to arrange yourself.
Who owns the code?
This is our clearest recommendation: demand that you own your code, and that you receive it if the collaboration ends. Without the code you cannot update, change supplier or fix a vulnerability yourself. Also ask which open source components are included and who keeps track of them.
Common mistakes and what is at stake
Five mistakes we can foresee
Most of this follows from the sources above, but the selection is our own judgement.
- Believing the company is exempt because it is small.
- Believing a supplier who wrote the code automatically takes all the responsibility.
- Assuming the cloud is outside when the app does not work without it.
- Forgetting that third-party components and plugins are part of the responsibility.
- Missing that the rules apply to products already sold, and lacking a person who can act within 24 hours.
Fines and authorities
Penalties can reach 15 million euro or 2.5 percent of global annual turnover, whichever is higher. That level applies to breaches of the manufacturer's obligations in Articles 13 and 14 and the essential security requirements, according to Finite State. The sources disagree on when fines can be applied: one source claims that Article 64 on penalties only applies from 11 December 2027 and that law firms have interpreted it differently. We therefore do not claim that fines are already being issued, and the regulation text should be checked.
In Sweden, the inquiry SOU 2025:115 proposed that the Swedish Post and Telecom Authority (PTS) be the market surveillance authority. CERT-SE, Sweden's national CSIRT, has been part of the National Cybersecurity Center (NCSC) since 1 July 2026, according to a secondary source. Check the roles of the authorities with the government or PTS before making decisions.
What to take with you
- An ordinary company website that only presents the business is normally not covered by the CRA.
- An app, a connected product or software you sell under your name can make you the manufacturer.
- A supplier writing the code does not move the responsibility.
- Ask about manufacturer, reporting within 24 hours, updates and code ownership before the contract is signed.
- Demand that you own your code, and that you receive it if the collaboration ends.
- In borderline cases, such as commissioned systems, a lawyer should answer. This post is not legal advice.
Unsure whether you are affected? Ask us before you sign a contract
We are happy to go through your questions, and we would rather say no to security services you do not need than sell you something unnecessarily. For legal borderline cases we recommend a lawyer. Get in touch via our contact page if you want a second opinion on a contract or a system.