CRA Vulnerability Reporting Hits US Firms Sept 2026: Your First 24 Hours

CRA Vulnerability Reporting Hits US Firms Sept 2026: Your First 24 Hours

Jacobian Engineering
October 20, 2026

Article 14 of the EU Cyber Resilience Act has applied since September 11, 2026, more than a year before the rest of the Regulation applies. If your company manufactures a hardware or software product sold into the EU, or a connected service your product depends on to function, this is already live law, and the clock on a reportable incident starts the moment you become aware of it, not when you get around to reading this.

Many of Jacobian's clients buy and run these products rather than make them, and for them this article is still useful: it tells you what to ask your vendors. But if you are a manufacturer, the next several hundred words are not background reading. They are the procedure you need in place before you need it.

Does this apply to you? A 60-second test

Answer three questions honestly.

  1. Do you sell a hardware or software product, or a connected service your product depends on to function, to customers in the EU?
  2. Is that product outside the CRA's exclusions, meaning it is not already governed by the EU's medical device regulations, the vehicle type-approval regulation, aviation certification, or marine equipment rules?
  3. Does the product go to market under your name or your trademark?

If you answered yes to all three, you are a manufacturer under the CRA, and Article 14 applies to you right now, regardless of where your company is headquartered. If you only buy and operate products like this, the CRA's Article 14 reporting duty belongs to your vendor, not to you, but it is still worth a phone call: ask whether that vendor has registered on ENISA's reporting platform.

What the law actually requires, in the law's own words

Article 14(1) states it plainly: "A manufacturer shall notify any actively exploited vulnerability contained in the product with digital elements that it becomes aware of simultaneously to the CSIRT designated as coordinator... and to ENISA." The notification goes through a single reporting platform established under Article 16.

An "actively exploited vulnerability" has a specific legal definition, not a loose one. Article 3 defines it as "a vulnerability for which there is reliable evidence that a malicious actor has exploited it in a system without permission of the system owner." A vulnerability that is merely disclosed, or theoretically exploitable, does not trigger this clock. Evidence that someone is actually using it against a system does.

Article 14(2) lays out three deadlines once that clock starts:

  • An early warning within 24 hours of becoming aware of the exploitation, noting which EU member states the affected product has been made available in, where that is known.
  • A vulnerability notification within 72 hours, with general information about the product, the nature of the exploit and the vulnerability, and any corrective or mitigating measures already taken or available to users.
  • A final report no later than 14 days after a corrective or mitigating measure becomes available, describing the vulnerability's severity and impact, any known malicious actor, and the details of the fix.

Article 14(3) and 14(4) set the identical 24-hour and 72-hour structure for a "severe incident having an impact on the security of the product," with a final report due within one month of the incident notification rather than 14 days after a fix ships. The 24-hour warning for an incident must also say whether it is suspected to involve unlawful or malicious acts.

Article 14(8) adds an obligation that sits alongside the regulator-facing deadlines and is easy to overlook under the pressure of the first three: once you become aware of an actively exploited vulnerability or a severe incident, you have to inform the users of the affected product, not only ENISA and the coordinating CSIRT, of the risk and of any mitigation they can take, where appropriate in a structured, machine-readable format. If you fail to do that in a timely way, the notified CSIRTs are authorized to inform your users for you, which is not a position any manufacturer wants a regulator to be in.

Where a US company with no EU office actually reports

This is the detail that catches US manufacturers off guard, because the obvious question, "which country's authority do I even talk to," does not have an obvious answer if you have no EU establishment.

Article 14(7) sets out the order. First, the member state where the authorised representative (Article 18) acting for the largest number of your products is established. If that does not settle it, the member state where the importer placing the largest number of your products on the market is established, then the same test for your distributors, then, failing all of that, the member state where the largest number of your product's users are actually located.

ENISA's own guidance on this is worth quoting directly, because it resolves a question that comes up constantly in practice: "Only one notification is required for any given actively exploited vulnerability or severe incident, even when a manufacturer has multiple branches or subsidiaries in the EU and/or its parent company is headquartered outside the EU. It is the manufacturer's responsibility to coordinate internally across its corporate structure." One filing covers the whole corporate group. The coordination burden is internal, not external.

The platform exists now, and registration is not something you do at hour 20

ENISA's Single Reporting Platform went live the same day Article 14 became enforceable, September 11, 2026, at the initial operating capability level, with ENISA stating it will expand functionality over the coming months. The platform is at portal.cra-srp.enisa.europa.eu.

Three details matter for how you prepare, not how you react:

First, every person who will file on your company's behalf, called an Assigned Representative, needs a personal EU Login account with multi-factor authentication enabled. There can be exactly one Primary AR per manufacturer, who registers first and selects the coordinating CSIRT; any Secondary ARs join afterward by the Primary AR's invitation.

Second, there is no API at this stage of the platform's life. Filing happens through the web interface, by a human, which means your Primary AR needs to actually know how to use it before the clock is running, not during the 24-hour window.

Third, there is a narrow accommodation called Particularly Exceptional Circumstances, which applies only to the 72-hour vulnerability notification, not to incident notifications. You flag it in the 72-hour notification, and the coordinating CSIRT decides whether to delay passing the full notification on. In that case ENISA receives only limited information, under Article 16(2). It is not a way to avoid the 24-hour early warning, and it does not apply to severe incidents at all.

Legacy products are not grandfathered out

Article 69(3) extends Article 14's reporting duty to any in-scope product already on the market before the CRA's general application date of December 11, 2027. If you shipped the product five years ago and it is still out there running, it is still covered.

What is not retroactive is the awareness itself. Per ENISA's FAQ guidance, if you already knew about active exploitation before September 11, 2026, you do not have to go back and file a report for that specific knowledge. But the moment you become aware of active exploitation after that date, the obligation applies in full, including when the underlying vulnerability itself is old and was already known to you or anyone else. An old bug, newly and actively exploited, is a new reporting event.

A vulnerability in a library you didn't write is still your problem

The CRA does not let you point at a third-party component and call it someone else's filing. Per the European Commission's own FAQ guidance: "Where the product with digital elements contains an actively exploited vulnerability originating from an integrated component, the manufacturer of the product with digital elements is required to notify that vulnerability. The manufacturer of the integrated component is also required to notify it, if that component has been placed on the market." Both of you file, not one or the other.

The one narrowing: if you know a component contains a vulnerability but it cannot actually be exploited in the way your product uses it, that is not an "actively exploited vulnerability" under the Article 3 definition, and mandatory reporting does not apply. You may still report it voluntarily, and you are required separately, under Article 13(6), to notify the component's own maintainer.

Who is actually excluded

The CRA's exclusions, set out in Article 2(2) through 2(4), are narrower than many vendor explainers have suggested, and they are unconditional rather than partial. If your product is already governed by the EU's Medical Devices Regulation, its In Vitro Diagnostic Regulation, or the vehicle type-approval regulation, the CRA simply does not apply to it, full stop, not "applies except where those frameworks overlap." The same clean exclusion covers certified aviation products and marine equipment under their respective EU regimes.

For Jacobian's healthcare clients specifically: if the MDR or IVDR genuinely governs your product, you are outside the CRA entirely. If neither does, and that covers a fair amount of connected wellness technology and practice-management software that is adjacent to clinical care without being a regulated medical device itself, the CRA can still reach you.

One more scoping detail worth getting right: standalone SaaS is not automatically in scope. The CRA only reaches "remote data processing" under Article 3(2): data processing at a distance whose software the manufacturer designed or is responsible for, and without which a hardware or software product could not perform one of its functions. If no product with digital elements depends on your SaaS in that way, the CRA does not reach the SaaS on its own.

Your first 24 hours, as a checklist

Before any incident, not during one:

  1. Name a Primary Assigned Representative, with an EU Login account and MFA already configured.
  2. Work out which member state's CSIRT you report to under the Article 14(7) cascade, and confirm it before you need to use it.
  3. Start keeping a timestamped internal log of when evidence of active exploitation reaches your company. The CRA does not specify how you must become aware, through threat intelligence, a customer report, a researcher disclosure, or your own telemetry, but it does hold you to the moment you actually knew, and a contemporaneous record is how you prove that moment later.

Once exploitation evidence actually arrives:

  1. Hour zero: reliable evidence of active exploitation lands. Timestamp it in your log immediately; this is the moment the clock legally starts.
  2. By hour 24: file the early warning, including which EU member states you know the affected product is available in.
  3. By hour 72: file the full notification, with the mitigations available to users. This is also the point at which you decide whether to request Particularly Exceptional Circumstances treatment, if the vulnerability notification (not an incident) qualifies.
  4. When a fix ships: the final report is due no later than 14 days after a corrective or mitigating measure becomes available for a vulnerability, or within one month of the incident notification for a severe incident.
  5. Throughout: inform the users of the affected product under Article 14(8), not only the regulator. This duty runs in parallel with the filing deadlines, not after them.

What this is not

The CRA's Article 14 duty is not the same obligation as incident reporting under NIS2. NIS2, Directive 2022/2555, reaches companies through each member state's own transposed law, and only if your organization is designated an essential or important entity under it; it covers significant incidents in your own services. The CRA is a directly applicable Regulation that reaches manufacturers wherever they are, covering vulnerabilities and incidents in the products they make, filed once through ENISA's single platform to a coordinating CSIRT and ENISA together, rather than under each country's own law. A managed service provider that also ships its own product can owe reports under both regimes, for different reasons, on different timelines, to different places. Do not assume meeting one discharges the other.

The penalties for getting Article 14 wrong are not symbolic. Non-compliance with Article 14 itself, or with Article 13 or Annex I, can draw a fine of up to EUR 15 million or 2.5 percent of worldwide annual turnover, whichever is higher. That is a ceiling set at the EU level; individual member states set the actual penalty rules that apply it.

If you build, sell, or operate a product with digital elements anywhere the EU market reaches, the smart time to work through this checklist is before the Primary AR registration screen is the first time anyone at your company has seen it.

Sources

Resource Details

Author:Jacobian Engineering
Published:October 20, 2026
Categories:
Compliance
Application Security

About This Resource

Article 14 of the EU Cyber Resilience Act has applied since 11 September 2026: once a vulnerability in your product is actively exploited, a 24-hour early warning is due to ENISA. Who it reaches, where a US firm with no EU office files, and what to do in the first 24 hours.

Categories:
Compliance
Application Security