The Cyber Resilience Act reporting obligations have applied since 11 September 2026, and they land on the company whose name is on the product. If a contractor builds and maintains your software, you hold the 24-hour clock, and the contractor only helps you meet it if the contract says so.
The Commission's CRA policy page gives three dates: the Regulation entered into force on 10 December 2024, reporting applies from 11 September 2026, and the main obligations apply from 11 December 2027. The practical gap sits in between: the 24-hour clock is yours, but the repository, the CI and the people who first see an exploit may all belong to someone else. For the wider contracting picture, see our guide to legal requirements for hiring developers in Europe.
Does the CRA reporting duty apply to your product?
Check scope before anything else. Kirkland & Ellis's September 2026 alert says purely SaaS offerings aren't intended to be covered by the Regulation. Remote data processing is the exception: where it's essential to the functioning of a covered product, it can be pulled in. That's decided case by case. For example (our illustration, not Kirkland's), a web dashboard with no installed software and a mobile app that can't work without your API are different questions.
If you ship software that runs on a customer's device or hardware you sell, assume you're in scope. If you only run a hosted service, write down why you think you're out, and have counsel confirm it.
Who is the manufacturer when an agency builds it?
Under the Article 3(13) definition in Regulation (EU) 2024/2847, a company that has a product "designed, developed or manufactured" by others and markets it under its own name is the manufacturer, so the brand owner holds the Article 14 duty. Kirkland quotes the definition and it's on EUR-Lex.
A startup that commissions an app from an agency and sells it under its own brand is therefore the manufacturer. Whether a contractor has CRA duties of its own depends on its role, for example if it also markets the product or places a component on the market itself, so confirm with counsel. What the contractor owes you in practice comes from your contract.
NIS2 is a separate law with its own clock. The CRA attaches to the product, NIS2 to the organisation, as our NIS2 supplier terms for outsourced developers guide explains, and you may need clauses for both in the same contract.
What must be reported, and by when?
Two things trigger a report: an actively exploited vulnerability in your product, or a severe incident that affects its security. The Commission's CRA reporting page sets the clocks.
| Stage | Deadline | Applies to |
|---|---|---|
| Early warning | 24 hours | Exploited vulnerability, severe incident |
| Notification | 72 hours | Exploited vulnerability, severe incident |
| Final report | 14 days after a corrective measure is available | Exploited vulnerability |
| Final report | 1 month after the 72-hour notification | Severe incident |
The clock starts when you become aware. The Commission's guidance, as summarised by Kirkland, ties awareness to a "reasonable degree of certainty" after an initial assessment. You don't start the clock on a rumour, but you can't sit on a credible finding either. That makes your internal assessment the step that decides whether you meet 24 hours, and it's the reason your contractor's notice time matters.
Component bugs get a narrower rule. According to Kirkland, a vulnerability in a third-party component triggers Article 14 reporting only if it's actively exploited in your product. Otherwise it falls under the upstream handling in Article 13, which applies from 11 December 2027.
Reports go through ENISA's Single Reporting Platform. The Commission page says it became operational on 11 September 2026 and that you report once: the platform routes the report to the CSIRT of the Member State where you have your main establishment, with ENISA copied, and it's shared with other CSIRTs. ENISA's platform page lists version 1.1 as of 12 October 2026.
The penalty tier is steep. Under Article 64, breaches of Articles 13 and 14 carry fines of up to EUR 15 million or 2.5% of worldwide annual turnover, whichever is higher. The EUR 10 million or 2% tier covers other listed obligations, and EUR 5 million or 1% applies to supplying incorrect, incomplete or misleading information to authorities. Micro and small enterprises can't be fined for missing the 24-hour early-warning deadline (Article 64(10)).
How to set up CRA reporting with an external dev team
1. Decide the manufacturer of record and the CSIRT
Name the legal entity that markets the product, and confirm it's your company rather than a subsidiary or a reseller. That entity is the manufacturer under Article 3(13), and its main establishment decides which Member State's CSIRT receives your report. If you have a holding structure with entities in two countries, settle this now with counsel, not during an incident.
2. Name a primary and a backup person for the Single Reporting Platform
The platform is run by ENISA and you file through it once. Our recommendation: put two named people from your own company on it, a primary and a backup, with one team mailbox that both receive. A 24-hour clock doesn't pause for a weekend, so agree who covers out-of-hours. Don't make the contractor's project manager your only login.
3. Write the contractor escalation clause
This is where outsourced teams usually fail. The clause should make the contractor notify you of a suspected exploited vulnerability or security incident within a fixed number of hours, name a contact who answers at any hour, extend to its subcontractors and freelancers, and state that you assess severity and decide whether to report.
The hours are our recommendation, not law. The Regulation gives you 24 hours from awareness and your own assessment eats into that, so we'd write 4 hours, and certainly nothing close to 24. A contractor that notices an exploit on Friday evening and mentions it on Monday has taken your deadline from you.
4. Require a dependency list and update it on each release
You can't tell whether a component bug is exploited in your product, or only sits upstream, without knowing what's in the build. Ask for a current list of third-party components and libraries with versions, handed over at delivery and refreshed with each release. This is our recommendation as contract practice. We aren't quoting a Regulation requirement here.
5. Log your own awareness timestamp and decision owner
Keep a simple record: when the contractor or a scanner flagged the issue, who assessed it, when you concluded there was a reasonable degree of certainty, and who decided to file. If a regulator asks why your early warning went out when it did, that log is the answer. Name one person who owns the decision, with the backup from step 2 as cover.
6. Keep repo, CI and release access in your hands
Your accounts should own the source repository, the CI configuration and the release credentials, with the contractor holding scoped access. If the contract ends in a dispute, you still need to push a fix. Agree the exit handover in writing, and tie it to your maintenance contract clauses after launch, since a vulnerability fix after go-live is a maintenance job.
What this means for your CTO or compliance owner
Decide now who in your company can file a CRA report at 2 a.m., and amend the contract with every external team that touches your code. Reporting has applied since 11 September 2026. You don't get until 11 December 2027, when the main obligations start.
The decision has three parts, and the first two are judgment on our side. Pick the filing owner and backup. Add the escalation clause to the contractor agreements that are live today, because renewal may be a year away. Then check whether any product you sell is covered at all, since the SaaS exclusion is narrower than it sounds. The exposure is concrete: the top fine tier for Article 13 and 14 breaches is EUR 15 million or 2.5% of worldwide annual turnover, whichever is higher.
For the wider contract checklist on IP, GDPR and liability, start at our EU engineering hiring compliance hub. Security answers from the contractor belong in the same file, and our guide to contractor answers on security questionnaires shows what a usable one looks like.
FAQ
Does the CRA apply to SaaS?
Mostly not. Kirkland reports that purely SaaS products aren't intended to be covered. The exception is remote data processing that's essential to a covered product, assessed case by case. If your service has no installed software component, you're probably out (our reading), but get that confirmed in writing.
Is my contractor or am I the manufacturer?
Under the Article 3(13) definition, a company that has a product designed or developed by others and markets it under its own name is the manufacturer, so the brand owner holds the Article 14 duty. Whether a contractor has CRA duties of its own depends on its role, for example if it also markets the product or places a component on the market itself, so confirm with counsel.
When does the 24-hour clock start?
When you become aware. Kirkland, summarising the Commission's guidance, describes that as a "reasonable degree of certainty" after an initial assessment. A contractor's suspicion doesn't start your clock automatically, but your contract should make them tell you fast enough that you can assess it well inside 24 hours.
Do I report a vulnerability in an open-source library?
Only if it's actively exploited in your product. A bug that exists upstream but isn't exploited in your product falls under Article 13 upstream handling, which applies from 11 December 2027. Open-source stewards have their own reporting duty from the same date, under Articles 24(3) and 71(2), per the Commission.
Can the contractor file for me?
The duty is yours, so treat the filing decision as yours too. A contractor can gather technical detail and draft the content under your contract, which is a sensible use of its knowledge. We'd still keep the platform logins and the final send with named people at your company.