Most companies assume the Cyber Resilience Act is something for makers of smart thermostats. It isn't. The moment you put software or a connected product on the European market under your own name, you are a manufacturer in the legal sense, and obligations start in five weeks.
The Cyber Resilience Act (CRA) is European Regulation (EU) 2024/2847, which sets security requirements for every product with digital elements placed on the EU market, from software and apps to IoT devices and industrial systems. The duty to report actively exploited vulnerabilities starts on 11 September 2026; the rest of the regulation applies from 11 December 2027.
This guide covers who the CRA applies to, which deadlines exist, what the support period means for your software, and what to put in your procurement terms now. This is general information, not legal advice.
Who does the Cyber Resilience Act apply to?
The scope is wider than the name suggests. A product with digital elements is any software or hardware product with a direct or indirect data connection to a device or network, including its remote data processing solutions.
What matters is not what you build but whether you place it on the market commercially. Three situations come up most often:
- You sell or distribute software or an app. You are the manufacturer, even if an external agency wrote the code. If it ships under your name or brand, the obligations sit with you.
- You import or resell third-party products. Importers and distributors have to check for CE marking, technical documentation, contact details and a stated support period, and may not pass on non-compliant products.
- You build software purely for internal use. In principle you fall outside scope, because nothing is placed on the market. That is the key exemption for organizations running an internal portal or their own planning system.
That last exemption is not a blanket pass. As soon as the same internal system is made available to customers or partners, for instance as a client portal with its own login, the situation changes. Free open-source software that isn't offered commercially generally falls outside scope too.
Which deadlines apply?
The CRA is phased. The first phase is a reporting duty rather than full product certification, and that difference determines what you need to do now.
| Date | What starts |
|---|---|
| 10 December 2024 | Regulation entered into force |
| 11 June 2026 | Rules for notified conformity assessment bodies |
| 11 September 2026 | Reporting duty for actively exploited vulnerabilities and severe incidents |
| 11 December 2027 | Full application: security requirements, CE marking, technical documentation |
For most organizations, 11 September 2026 is therefore not a certification deadline but an operational one: from that date you must be able to report within 24 hours. That doesn't take a year of preparation, but it does take a working process and a named owner.
What do you report, and how fast?
Reports go through a single reporting platform to the CSIRT of the country where your main establishment sits, and simultaneously to ENISA. You report once, not to each authority separately.
| Step | Deadline | Covering |
|---|---|---|
| Early warning | within 24 hours | actively exploited vulnerability or severe incident |
| Full notification | within 72 hours | details, severity, measures taken |
| Final report | within 14 days of a fix being available | vulnerabilities |
| Final report | within 1 month | severe incidents |
The threshold matters: this covers vulnerabilities with evidence of active exploitation, not every theoretical finding or proof of concept. A pentest result is not a reportable event; evidence of real exploitation in your product is.
Anyone without a process for receiving vulnerability reports will never make that 24 hours. A published reporting address and a fixed owner for security reports are the minimum. Our website security checklist is a good starting point for the technical groundwork underneath.
[ TIME SAVED ]
Save 5 hours per week on working out who is responsible for what when a security report comes in
What does the support period mean for your software?
This is the part that costs the most money and gets skipped most often. The CRA requires manufacturers to set a support period reflecting the product's expected time in use, and as a rule that is at least five years, unless the product is demonstrably in use for less.
Within that period you have to handle vulnerabilities and deliver security updates. Security updates you have issued must then remain available for at least ten years afterwards, or longer if the support period runs longer. The end date of support also has to be clear to the buyer at the point of purchase.
For anyone commissioning an app or platform, that shifts the financial picture. Maintenance is no longer an optional line you can cut in year two; it is an obligation with a term attached. Our breakdown of app maintenance and update costs shows the numbers that realistically go with it.
Does the CRA apply to custom software you commission?
The answer depends entirely on what you do with it. Commission an internal system that only your own staff use, and you place nothing on the market, so you're out of scope. Sell or license that same software to third parties and you are the manufacturer, even though your build partner wrote every line.
That makes the CRA a contractual question. Four terms belong in any engagement beyond a simple website:
- A current list of components and their versions, so a vulnerability in a dependency tells you within hours whether you're affected.
- An agreed response time for security updates, expressed in hours rather than "as soon as possible".
- A documented support period aligned with the five-year benchmark, at a price agreed now.
- Handover of documentation and configuration, so you can meet the reporting duty even without your current vendor.
These are the same terms that determine your freedom as a client. Our guide on custom software development covers how to surface them during the quotation stage, before you sign.
How does the CRA relate to NIS2 and the AI Act?
They overlap in subject but not in trigger, and that difference decides whether you're in scope.
The CRA is about products: what you place on the market must be secure and stay secure. The NIS2 Directive is about organizations: if you operate in a designated sector, your organization must take risk measures and report incidents. Our explainer on the NIS2 directive and cybersecurity covers that side. The AI Act is about AI systems and their risk classification, with the heavy obligations for high-risk systems now moved to December 2027.
A company building an AI feature into a product it sells can face all three. The practical route is to treat them not as three projects but as three requirements on the same development process. For the wider legal context, our pillar on AI legislation in the Netherlands and the EU AI Act is the place to start.
Conclusion: start with the reporting process
On 11 September 2026 the Cyber Resilience Act does not yet ask for CE marking, but it does ask that you can report within 24 hours that a vulnerability in your product is being actively exploited. That is an organizational task: a reporting address, an owner, a list of your components, and an agreement with your vendor.
The heavier requirements follow on 11 December 2027. Companies that write the support period and update process into contracts now won't be paying to catch up later. We deliver custom software with documented dependencies and clear maintenance terms, precisely because that documentation is the difference between a one-hour report and a week-long search.