The 24-Hour Clock: The Cyber Resilience Act's Reporting Duty Is Already Live

On 11 September 2026, ENISA switched on its Single Reporting Platform at portal.cra-srp.enisa.europa.eu (opens in new tab), and Article 14 of the Cyber Resilience Act started to apply (Hogan Lovells, September 2026 (opens in new tab)). Since that morning, every manufacturer of an in-scope product has had 24 hours to send an early warning once it becomes aware of an actively exploited vulnerability in that product. That includes products placed on the market years ago.

Most of the engineering leaders we talk to still file the CRA under "December 2027". That is the date for conformity assessment, CE marking and the essential requirements. Reporting did not wait. ENISA's own SME survey, run in February and March 2026, found that two thirds of respondents had heard of the CRA, but only 35% use a software bill of materials, and ENISA itself warns that its voluntary sample probably overstates readiness (Digital Skills and Jobs Platform summary of the ENISA SME CRA Survey Report (opens in new tab)).

Our take: filling in the form is the easy part. The hard part is detection and triage. Can your organisation reliably reach the point of being "aware", record exactly when that happened, and get a qualified person to the reporting platform before the clock runs out, at 3 a.m. on a Sunday, for a product nobody has touched since 2022? And before any of that, you need to know which of your products are in scope. A pure web SaaS mostly is not. Your mobile app, desktop agent, on-prem installer or device firmware is, and so is the backend that keeps it working.

What has applied since 11 September

The legal text is short. Regulation (EU) 2024/2847 (opens in new tab), Article 14, imposes two reporting duties on manufacturers:

Actively exploited vulnerabilities. The Regulation defines these as vulnerabilities for which there is reliable evidence that a malicious actor exploited them in a system without the owner's permission (Art. 3(42)). A proof of concept on GitHub is not that. Exploitation in the wild is.
Severe incidents having an impact on the security of the product. An incident counts as severe if it affects, or could affect, the product's ability to protect the availability, authenticity, integrity or confidentiality of sensitive or important data or functions, or if it has led or could lead to malicious code running in the product or on a user's systems (Art. 14(5)). A compromised update server is the textbook case.

For both, the sequence is the same. An early warning within 24 hours of becoming aware. A fuller notification within 72 hours, covering the nature of the problem and any mitigations, including what users can do themselves. Then a final report: for vulnerabilities, no later than 14 days after a corrective or mitigating measure is available; for incidents, within one month of the 72-hour notification. Reports go through the Single Reporting Platform to the CSIRT designated as coordinator in the Member State of your main establishment, and to ENISA at the same time (Art. 14(1) to (4), (7)). Under Art. 14(7), main establishment means where decisions about your products' cybersecurity are predominantly taken. For a German manufacturer, the coordinating CSIRT is CERT-Bund at the BSI (opens in new tab).

Three details are routinely missed:

Legacy products are covered. Article 69(3) makes Article 14 apply to every in-scope product placed on the market before 11 December 2027, not only to new ones. The Commission's guidance adds that the duty continues after a product's support period ends (Hogan Lovells on the final guidance, July 2026 (opens in new tab)).
Users must be told as well. Article 14(8) requires you to inform impacted users, and where appropriate all users, along with the mitigations they can apply, "where appropriate in a structured, machine-readable format". If you stay silent, the CSIRT may notify your users itself.
The fines. Breaches of Article 14 can draw fines of up to EUR 15 million or 2.5% of worldwide annual turnover, whichever is higher (Art. 64(2)). Microenterprises and small enterprises are exempt from fines for missing the 24-hour early warning specifically (Art. 64(10)(a)). A typical Mittelstand manufacturer is medium-sized or larger, so that exemption does not apply. Neither does it remove the duty itself.

Pure SaaS is mostly out. Your app, agent and firmware are not.

Scoping goes wrong in both directions: some teams think the CRA is a hardware law, others think every cloud product is caught.

The Regulation defines a product with digital elements as a software or hardware product and its remote data processing solutions (Art. 3(1)). Remote data processing means processing at a distance, with software designed and developed by or under the responsibility of the manufacturer, without which the product could not perform one of its functions (Art. 3(2)). Recital 12 is explicit that cloud services such as SaaS, PaaS and IaaS are generally governed by NIS2, not the CRA, and that cloud services developed outside the manufacturer's responsibility are out of scope.

The Commission's final guidance (opens in new tab) of 27 July 2026 draws the line more sharply. As summarised by Hogan Lovells (opens in new tab), software that runs remotely and is only accessed by the user, typically a web application used exclusively through a browser, is not a product with digital elements on that basis alone. Software supplied to the user and run on the user's side is: installed applications, browser extensions, and apps built with web technologies but shipped for local execution.

The catch is that remote software comes back into scope as a remote data processing solution when another in-scope product needs it to function. Recital 11 uses almost exactly the example that applies to most Mittelstand software vendors: a mobile app that relies on an API or database provided by a service the manufacturer developed. In that case the service is part of the product. According to the guidance, this covers at least the modules responsible for the product's functionality and the interfaces they use. Back-end systems that do later processing, and that the product does not talk to directly, are not included.

In practice, the products we see in Mittelstand portfolios sort roughly like this:

Product shape	Our reading
Browser-only web app, no client software	Generally out of CRA scope; NIS2 may apply to you as a provider
Mobile app (iOS/Android) plus your own API	In scope; the API it depends on is an RDPS
Desktop app, Electron app, or "sync agent"	In scope, plus any backend it needs
On-prem installer or Docker image you ship to customers	In scope
Firmware on a device, plus its cloud control plane	In scope, both
Browser extension companion to your SaaS	In scope, and it may pull part of the SaaS in with it

The last row is the trap. Many SaaS companies ship a small client component: a companion app, an Outlook add-in, a scanner agent, a printer bridge for a POS system. That component is a product, and the backend it relies on can become its remote data processing solution. "We are a SaaS company" is not a scoping answer; a written, product-by-product one is.

The hard part is "aware", not the form

Every deadline in Article 14 runs from the moment the manufacturer becomes aware. As summarised by Hogan Lovells (opens in new tab), the Commission's reading is that awareness exists once the manufacturer has a reasonable degree of certainty that a vulnerability in its product is being actively exploited, or that a severe incident has compromised the product's security. That reading is helpful and dangerous at once.

It helps because the clock does not start with every scanner alert or every unverified email to security@. A CVE in a library you ship is not an Article 14 event by itself. The guidance is explicit that for third-party components, you have to report only where the vulnerability is actively exploited in your product. If the vulnerable code is unreachable, or nobody has exploited it, no Article 14 report is due, although your normal vulnerability handling still applies (para. 217 to 218 of the guidance, per the same summary). It also confirms there is no retroactive reporting of exploitation you already knew about before 11 September 2026.

It is dangerous because "we never triaged, so we were never aware" will not hold for long. If a customer sent your support desk log evidence of exploitation on Friday and the ticket sat until Tuesday, arguing that awareness began on Tuesday will be very hard.

So the engineering problem is not "fill in the SRP form in under 24 hours". It is:

Every signal that could indicate exploitation reaches one intake.
Someone qualified looks at it within hours, not days.
The decision "this is, or is not, reasonably certain exploitation" is recorded with a timestamp and a reason.
If it is, the early warning goes out with whatever is known, because the 24-hour notice is meant to be incomplete.

The Regulation asks for very little at 24 hours: the event itself and the Member States where you know the product is available, plus, for incidents, whether you suspect malicious acts. Teams that polish the early warning miss the deadline. Send it, then build the 72-hour notification.

The runbook

This is the minimum we would put in place for any in-scope product. None of it is exotic; most of it is unfinished plumbing.

1. Product inventory with scope decisions

Every product and version placed on the EU market, discontinued ones included, with the legal manufacturer entity, support status, a short scope rationale, its remote data processing components and an engineering owner. Under the guidance's reading, different variants of one product can be separate products with separate placing-on-the-market dates, so record versions and variants, not marketing names. Without it, your 24-hour window starts with a meeting about who owns the 2021 Android app.

2. SBOM per shipped version, queryable

An SBOM is not yet a legal deliverable today; Annex I requirements apply from December 2027. It is still the only practical way to answer "do we ship the library that is being exploited right now?" in minutes. Generate CycloneDX or SPDX in CI for every release artifact, including mobile builds and firmware images, and store it indexed by product and version. The BSI's TR-03183 (opens in new tab) Part 2 sets out what a good SBOM contains. Industry practice is far behind: a vendor survey of 505 engineering professionals found that only 25% generate and verify SBOMs automatically at every build (SecurityBrief on Cloudsmith, April 2026 (opens in new tab)). Vendor research on US/UK enterprises, so discount it, but it matches what we see.

3. Detection feeds that look for exploitation, not just existence

Most vulnerability tooling tells you a CVE exists. Article 14 needs signals of exploitation:

Known-exploited catalogues such as CISA KEV and the EU Vulnerability Database, matched automatically against your SBOM index.
Your own telemetry: WAF and API gateway logs for the RDPS, crash reports and integrity failures from the app or firmware, anomalies in update-server access.
Customer and partner reports via support and resellers: the channel most likely to carry real exploitation evidence, and the least likely to reach security.
A published security.txt and a coordinated vulnerability disclosure policy, so researchers know where to send things.

4. One intake, timestamped triage

Every signal lands in one queue that records an immutable "received at" timestamp. Triage adds "assessed at", the decision (reportable exploitation, reportable incident, not reportable, needs more data) and the reasoning, including for "not reportable". That record is your evidence of when awareness began, and when it did not.

5. Severity criteria written in advance

Translate the abstract Article 14(5) into product-specific triggers. For a field-service app: tampered updates, remote code execution, unauthorised API access to customer data. For a POS agent: anything touching payment data or running code on the till. A one-page decision tree per product beats a debate mid-incident.

6. On-call that includes someone allowed to decide

An engineer who can confirm exploitation is not enough. The rotation needs a named decision-maker with a deputy, who can authorise a submission at any hour. On SRP access: the platform requires an EU Login account with multi-factor authentication (opens in new tab), and ENISA recommends registering as an Assigned Representative only when you actually need to submit. CSIRT validation of that association runs in parallel and does not block your first notification. So create the EU Login accounts with MFA now for your primary and backup reporters, rehearse the registration flow from ENISA's user manual, and keep the manufacturer details ready to paste.

7. Templated submissions for all three stages

Prepare drafts for all three stages, mapped to the SRP fields in ENISA's glossary. Pre-fill what never changes: manufacturer identity, product identifiers, the Member States where each product is sold (from sales data, not memory) and contact roles. Notifications stay editable until closed; after the final report they are read-only, so that one deserves review by engineering and counsel.

8. User notification as a release artifact

Article 14(8) is the obligation teams forget and users actually see. Keep a template per product, a channel you control (in-app message, portal, admin email list) and ideally a machine-readable advisory; CSAF is the obvious format. The guidance allows a risk-based approach: notify affected users first, rather than publishing exploit details that make things worse.

Trade-offs we are making explicit

Over-reporting versus under-reporting. A low threshold for "aware" floods CERT-Bund and burns out your reporters. A high one risks a fine and a CSIRT telling your customers before you do. We bias toward reporting when exploitation evidence is credible and specific to your product, and toward documented non-reporting otherwise. The written reasoning matters more than any single call.

Scope minimisation versus architecture honesty. The guidance does leave room: later processing your app does not call directly is out. But a boundary drawn on paper rather than from actual dependencies will not survive a market surveillance question. Draw it from your architecture diagram.

Buying a platform versus wiring existing tools. An SBOM generator in CI, a dependency-tracking service, a KEV feed, one tracker project with mandatory timestamp fields, a pager rotation and a few templates cover most of this. The expensive part is inventory and ownership, which no tool provides.

What we are not saying

We are not saying every SaaS company now has a CRA problem; a browser-only product with no shipped client is generally outside it. Nor do you need your full December 2027 programme by next week.

We are saying that if you ship anything that runs on your customer's side, whether an app, an agent, an installer or firmware, you have carried a live 24-hour duty since 11 September, for your old releases too. It is tested the first time someone exploits one of them. The form takes ten minutes. Knowing, provably and on time, that you are aware takes the inventory, the SBOM, the intake and the on-call rotation. Build those first.