The EU Cyber Resilience Act's 24-Hour Reporting Clock Is Live: What US SaaS Must Do Now

On 11 September 2026, the reporting half of the EU Cyber Resilience Act went live. The European Commission’s own words: “As of 11 September 2026, manufacturers are required to report actively exploited vulnerabilities and severe incidents impacting the security of products with digital elements.” If your company places software or devices on the EU market, that sentence stopped being a forecast a month ago.

Most US mid-market teams still file the CRA under December 2027, when the CE marking machinery and the full product obligations arrive. Those dates sit that far out. This one does not. Article 14 reporting is live now, it applies to the EU market whatever the seller’s nationality, and it reaches backward to products placed on the market before 11 December 2027. Software you shipped years ago is inside this regime today.

What follows is written for founders, CTOs, and product-security leads at mid-market SaaS, fintech, and crypto-infrastructure companies selling into the EU without a full-time CISO: the mechanics, the traps, and a 30-day checklist. In incident-notification regimes the deadline is rarely what hurts. What hurts is the window between “we saw something odd” and “someone with authority decided this is the reportable thing.” Twenty-four hours compresses that window hard, which is why this article is mostly about decisions, not dates.

Key takeaways

• Since 11 September 2026, manufacturers of products with digital elements must notify ENISA and the coordinating CSIRT of actively exploited vulnerabilities and severe incidents through ENISA’s Single Reporting Platform. One report does it.
• The ladder: early warning within 24 hours of awareness, full notification within 72 hours, final report within 14 days for vulnerabilities once a fix is available, or within one month for incidents.
• The duty covers products placed on the market before 11 December 2027 (Article 69(3)). For legacy products it is notification only, not the full vulnerability-handling regime.
• Zero-days with reliable evidence of malicious exploitation are reportable. Good-faith bug-bounty finds are not.
• Standalone SaaS is not per se a product with digital elements. The “remote data processing” definition decides, and the Commission’s dedicated guidance on it is still pending.
• Breaching Article 14 sits in the CRA’s top enforcement tier: fines up to EUR 15 million or 2.5% of worldwide annual turnover, whichever is higher.

What went live on September 11

The Commission’s reporting page lays out the mechanics in one paragraph:

“They need to submit an early warning within 24 hours of becoming aware, and a full notification within 72 hours. A final report needs to be submitted no later than 14 days after a corrective measure is available for actively exploited vulnerabilities and within a month from the 72-hour notification for severe incidents.”

Read that as three clocks, not one. The 24-hour clock is a short form: what happened, whether there is reliable evidence of active exploitation, which products and versions. The 72-hour notification is the substance. The final report closes it out, and for vulnerabilities it anchors to a fix being available.

Routing is deliberately simple. Manufacturers report once through the CRA Single Reporting Platform, operated by ENISA and live since September 11. In ENISA’s words, “the SRP allows users to report once through a single platform and communicate the relevant information to the appropriate authorities.” The notification goes to the CSIRT where the manufacturer has its main establishment, with ENISA copied apart from exceptional circumstances, and that CSIRT shares it across the Union without delay. You write once; the EU distributes.

Everything rides on the trigger: “becoming aware.” The CRA does not prescribe how manufacturers become aware, and the FAQ is explicit that awareness does not turn a company into a monitoring appliance: the listed examples “do not imply that the manufacturer is required to carry out such activities or monitor such channels to comply with the reporting obligations.” Four channels produce awareness in practice: customers or partners reporting unusual activity, researchers or threat intelligence naming your product, a government agency reaching out, or your own telemetry catching what nobody was watching for. The Commission’s implementation guidance reads awareness as reached once there is a reasonable degree of certainty that active exploitation or a severe incident exists. What the FAQ requires is a working path from “someone saw something” to a decision by someone with authority to start the clock. Teams that built continuous-evidence pipelines for SOC 2’s monitoring expectations already own the plumbing; the decision step is what they usually lack.

The obligation reaches backward

Article 69(3) is the sentence most teams have not internalized:

“By way of derogation from paragraph 2 of this Article, the obligations laid down in Article 14 shall apply to all products with digital elements that fall within the scope of this Regulation that have been placed on the market before 11 December 2027.”

The FAQ applies it plainly: the notification duty covers “all products with digital elements falling within the scope of the CRA, including products that have been placed on the market before 11 December 2027.” What the CRA does not demand for those legacy products is the full vulnerability-handling regime, and the Commission gives a sympathetic reason: old build environments may be impossible to recreate, dependencies unavailable, the engineers who knew the codebase long gone. “For such products, manufacturers are required to notify the vulnerability or incident but are not required by the CRA to comply with other obligations, e.g. in relation to vulnerability handling.”

Notification only is not notification light, though. Two obligations still attach. First, the reporting itself, on the same clock as everything else, if exploitation of a legacy vulnerability surfaces. Second, Article 14(8): the manufacturer must inform impacted users, and where appropriate all users, of the vulnerability or incident. Where the manufacturer decides not to inform users promptly, the CSIRTs receiving the notification may give users the information themselves, where they consider it “proportionate and necessary for preventing or mitigating the impact.”

For a mid-market company this redraws the perimeter of concern. Exposure now includes the end-of-life release still running at a customer, the SaaS version you deprecated last year, the firmware a distributor burned onto boards in 2024. Nobody asks you to go back and patch them. If one of them surfaces in an exploited-vulnerability report, you must notify, and you must decide what users hear, even with the original build unverifiable and the engineers gone.

Zero-days, bug bounties, and third-party components

The zero-day question answers itself once the definition is in view. Article 3(42) defines an actively exploited vulnerability as one with “reliable evidence that a malicious actor has exploited it in a system without permission of the system owner.” On that definition, the FAQ states the rule plainly: “Vulnerabilities for which a patch or a security update is not yet available (so-called ‘zero-day vulnerabilities’) are subject to reporting in accordance with Article 14, when the manufacturer has reliable evidence that a malicious actor has exploited that vulnerability.”

Exploitation is the gate, not patch availability. The same FAQ entry draws the line the market was hoping for, citing Recital 68: vulnerabilities discovered with “no malicious intent for purposes of good faith testing, investigation, correction or disclosure to promote the security or safety of the system owner and its users should not be subject to mandatory notification.” A zero-day reported by an ethical hacker with no evidence of malicious exploitation, through your bug-bounty program, is not reportable. A finding from a security assessment lab testing on your behalf is not reportable either. Both can still be notified voluntarily under Article 15.

Components cut three ways. Where an actively exploited vulnerability originates in an integrated component, the integrator reports, and the component maker reports too if that component was itself placed on the market. If a known component vulnerability cannot be exploited through your product, it is not “actively exploited” for regulatory purposes and no regulator notification is due, though you still owe the report to whoever makes or maintains that component under Article 13(6). In every gray zone, voluntary notification remains open.

The SaaS scope question is still open

This is the part SaaS operators tend to get wrong in both directions. From the Commission’s FAQ: “services, such as standalone Software-as-a-Service (SaaS) or other cloud solutions designed and developed outside the responsibility of a manufacturer of a product with digital elements are not themselves products with digital elements. Where, on the other hand, such services meet the definition of remote data processing, they fall within the scope of the CRA.”

Two things make that uncomfortable. A product with digital elements “also includes its remote data processing solutions,” so the concept reaches both the service you attach to someone else’s product and the possibility that your service is, in effect, the processing half of one. And the definition is not settled: “The concept of remote data processing will be part of separate guidance.” Until that lands, this is a triage exercise rather than a settled compliance position. A hardware wallet is clearly a product with digital elements. A custodial exchange backend is much less clearly one, and the pending definition will likely decide it. A SaaS console that manages a customer’s connected devices may be the remote data processing solution of their product, which pulls you inside a manufacturer’s CRA envelope as a component. The honest answer to “does the CRA apply to my SaaS” is: not per se, possibly, write down the analysis per offering, and revisit it when the guidance arrives.

Enforcement has teeth, in stages

The penalty ceiling for Article 14 breaches is the CRA’s top tier: fines up to EUR 15 million or 2.5% of total worldwide annual turnover, whichever is higher. The figure is consistent across the Commission’s FAQ context, Jones Day’s July 2026 alert, and Fisher Phillips’s September briefing; the operative legal text is Regulation (EU) 2024/2847 (CELEX 32024R2847), cited here as reference.

The machinery arrived in stages. Since 11 June 2026, the conformity-assessment-body provisions (Articles 35 to 51) have applied and member states have had to designate their notifying authorities, so the notified-body machinery is being built out now. Market-surveillance and enforcement provisions arrive with the main obligations on 11 December 2027, which is also when open-source software stewards pick up reporting duties under Article 24(3). Before the full stack activates, expect the pressure to come from customer security questionnaires and from discovering, on your own side, that something reportable happened with no one owning the call.

The 30-day readiness checklist

None of this needs new tooling. It is decisions written down, a few names attached to duties, and one dry run.

One, write the scope memo. A single page: which shipped things are products with digital elements, which were placed on the market before 11 December 2027, which offerings touch remote data processing, and which third-party components are integrated where. Date it, note that it will change when the remote-data-processing guidance lands, and file it where an auditor can find it.

Two, document the detection-to-decision pipeline. Map the four channels (customer and partner reports, researchers, threat intelligence, internal telemetry) to a named triage step with a target of hours, not days, for a decision, with the reasoning logged. Awareness is a legal threshold, so the record of what was known and when is your timeline if anyone ever challenges it.

Three, name who is aware. Two people, specifically, who can set the 24-hour clock running, and who sit where tickets and telemetry land. Train support and engineering that a report of “someone is using this in the wild” escalates the same day, not at the end of the sprint.

Four, register your entity on ENISA’s Single Reporting Platform and walk through the early-warning form once. Know which CSIRT covers your main establishment. The setup is an hour you will not regret.

Five, draft the two user-notification templates now, one for an actively exploited vulnerability and one for a severe incident, each with a decision rule for when “where appropriate” means all users. Remember the fallback: if you do not inform users in a timely manner, the CSIRT can, and what it sends will not have your name on the sender line.

Six, assign ownership. A fractional CISO works, as does a named executive with a deputy, but nothing works while the file travels between committees. Then give the board one paragraph: what became reportable on September 11, what the legacy reach-back means for the installed base, and what remains open. Boards do not need another security dashboard; they need to know which new obligation can reach the company’s installed base and margin.

What to do next

The list above is incident-response and reporting hygiene with one European deadline bolted on. If you want help executing it, see NTD Consulting’s cybersecurity, risk, and compliance services or the fintech and crypto-infrastructure security practice; to pressure-test the setup before the next reportable event, contact NTD Consulting.

Frequently asked questions

Does the Cyber Resilience Act apply to a US company selling software to EU customers? Yes. The CRA follows the product onto the EU market, and a company that places software or devices on that market is a manufacturer for CRA purposes regardless of where it is established, including a US company selling through a distributor. The Article 14 notification duty is already live. Manufacturers established outside the EU must also designate an authorized representative in the EU; the rest of the economic-operator mechanics (importer and distributor duties, conformity documentation) arrive with the December 2027 obligations.

What exactly starts the 24-hour clock? Becoming aware of an actively exploited vulnerability or a severe incident, meaning there is reliable evidence of malicious exploitation or, in the Commission guidance’s reading, a reasonable degree of certainty that one exists. You are not required to monitor specific channels, but once a customer ticket, researcher email, or telemetry alert reports exploitation in the wild, the clock matters and the decision must be made quickly.

Do I have to report a vulnerability in a product I can no longer patch? Yes, if it is actively exploited: Article 69(3) applies the notification duty to products placed on the market before 11 December 2027. For those products notification is the whole duty; the CRA does not require full vulnerability handling for legacy products. User notification under Article 14(8) still applies.

Is a bug-bounty finding reportable? Not when it is found in good faith with no evidence of malicious exploitation. A zero-day with reliable evidence a malicious actor is using it is reportable within 24 hours of awareness; bug-bounty finds are not. Gray findings can be notified voluntarily under Article 15.

Does the CRA apply to my SaaS product? Standalone SaaS is not per se a product with digital elements. It falls in scope where it meets the “remote data processing” definition in Article 3(2), and the Commission’s dedicated guidance on that concept is still pending. Where your service is the remote data processing solution attached to someone else’s product, you are treated as part of that product, which pulls you in as a component.

Ron Moore runs NTD Consulting, which provides fractional CISO and cybersecurity advisory services to mid-market SaaS, fintech, and digital-asset companies.