Cyber Resilience Act Reporting for Non-EU Manufacturers

TL;DR. From 11 September 2026, Article 14 of the EU Cyber Resilience Act, Regulation (EU) 2024/2847, requires manufacturers of products with digital elements to report actively exploited vulnerabilities and severe incidents to ENISA and a national CSIRT: an early warning within 24 hours, a notification within 72 hours, and a final report within 14 days (vulnerabilities) or one month (incidents).

The duty falls on the manufacturer, wherever it is established, not on your EU importer. If you have no EU establishment, Article 14(7) sets a four-step cascade that decides which national CSIRT receives your report. Nothing else in the CRA switches on until 11 December 2027, and the obligation covers products already on the market.

What the Cyber Resilience Act changes on 11 September 2026

The Cyber Resilience Act entered into force on 10 December 2024, but it does not arrive all at once. Article 71(2) phases it in three steps, and the September date brings in exactly one article.

This distinction matters commercially. On 11 September you are not required to have a secure-by-design process, an SBOM, a coordinated vulnerability disclosure policy, a declared support period, or a CE mark under the CRA.

Those arrive in December 2027. What you are required to do is file a report within 24 hours of becoming aware that something has gone wrong.

And one provision makes this considerably wider than most manufacturers assume. Article 69(3) states that Article 14 applies to products with digital elements placed on the market before 11 December 2027.

Your installed base is in scope from day one. There is no grandfathering for legacy products, and Commission guidance confirms the reporting duty continues even after a product has passed the end of its support period.

Is your product in scope of the Cyber Resilience Act?

The most common misreading of the CRA is that it is a software law. It is not. Article 3(1) defines a "product with digital elements" as "a software or hardware product and its remote data processing solutions, including software or hardware components being placed on the market separately."

Article 2(1) then sets the scope trigger: the product is caught where "the intended purpose or reasonably foreseeable use of which includes a direct or indirect logical or physical data connection to a device or network."

There is no establishment condition anywhere in that test. Scope is triggered by supplying the EU market, not by where you sit.

Consumer electronics caught by the Cyber Resilience Act

Anything with a data connection is in scope at the default tier. A subset are additionally listed in Annex III as Class I "important products", which raises the conformity assessment burden from December 2027, but carries exactly the same Article 14 duty from September 2026:

• Routers, modems and network switches
• Smart home virtual assistants
• Smart door locks, security cameras, baby monitors, alarm systems
• Internet-connected toys with social interactive features or location tracking
• Personal wearables with a health-monitoring purpose outside the medical devices regime, and any personal wearable intended for children

Two scope points catch people out. First, a data connection does not require radio. Commission guidance draws the line at deliberately encoded binary information, so a device whose only port is USB or serial is in scope, while a product that merely switches an output on and off is not.

Second, exclusions are narrower than they look. The civil aviation carve-out in Article 2(3) applies only to certified products, so open-category leisure drones are fully in scope. The automotive carve-out applies only to components designed exclusively for those vehicles, so selling the same part through general retail defeats it.

What the Cyber Resilience Act excludes

The cloud boundary is set by Article 3(2): a remote data processing solution is in scope only where the software is designed and developed by, or under the responsibility of, the manufacturer and its absence would prevent the product performing one of its functions.

A smart thermostat's manufacturer-operated control cloud is in scope. A standalone SaaS product is not. That is NIS2 territory.

What you must report under CRA Article 14

Article 14 creates two separate tracks, with two separate definitions and two separate final-report clocks.

What counts as an actively exploited vulnerability under the CRA?

Article 3(42): "a vulnerability for which there is reliable evidence that a malicious actor has exploited it in a system without permission of the system owner."

Two boundaries are worth knowing. A zero-day is reportable if there is reliable evidence of malicious exploitation. The absence of a patch is irrelevant.

But a vulnerability found by an ethical hacker through your bug bounty, with no evidence of prior malicious exploitation, is not mandatorily reportable. Voluntary reporting under Article 15 stays open.

Third-party components sit in the middle. Commission guidance is that a vulnerability in a component that cannot be exploited in your product, or has not been exploited in your product, is not an actively exploited vulnerability contained in your product. But if it is exploited in your product, you report, even though you did not write the code.

What counts as a severe incident under the CRA?

Article 14(5) makes an incident severe where either limb is met: it negatively affects, or is capable of negatively affecting, the product's ability to protect sensitive or important data or functions; or it has led, or is capable of leading, to the introduction or execution of malicious code in the product or in a user's network.

Note "or is capable of". Capability is enough. You do not get to wait for realised harm.

When does the CRA 24-hour reporting clock start?

"Becoming aware" is not defined in the Regulation. Commission guidance of 27 July 2026 sets the standard: you must assess a suspicious event or third-party report immediately, and you are treated as aware once that initial assessment gives you a reasonable degree of certainty that a vulnerability is being actively exploited or a severe incident has compromised your product.

You cannot wait for forensic certainty. The 24-hour clock runs from reasonable certainty, not from the closing of the investigation.

CRA reporting deadlines: 24 hours, 72 hours, 14 days

The asymmetry in the final stage is deliberate and easy to get wrong. For a vulnerability, the 14-day clock does not start until a fix or mitigation exists.

If none ever becomes available, the trigger never fires, though the 24-hour, 72-hour and user-notification duties still bind. For an incident, the clock runs from the 72-hour notification, not from awareness.

Article 14(6) also allows the receiving CSIRT to demand intermediate status reports on request, with no fixed deadline in the text.

{{cta}}

Where CRA reports go: ENISA and the national CSIRT

You notify simultaneously to the CSIRT designated as coordinator and to ENISA, through the Single Reporting Platform established under Article 16.

You file once. The receiving CSIRT then disseminates to the CSIRTs of the Member States where you indicated the product is available, and those CSIRTs pass what is necessary to their market surveillance authorities.

Two practical notes as at today. The Single Reporting Platform is not yet live. The Commission's reporting page, last updated 31 July 2026, states it "will be operational by 11 September 2026" with functional and security testing under way, and the public URL has not been published.

The list of national CSIRTs designated as coordinators has also not been published, which matters more to non-EU manufacturers than to anyone else, for the reason set out in the next section.

ENISA's guidance is explicit that you should not register on the platform pre-emptively. It asks manufacturers to begin registration only when they need to submit a specific notification, to avoid overloading CSIRT validation queues, and confirms that validation is not a prerequisite for meeting the reporting obligation.

What you should do in advance is create EU Login accounts for the people who would file. That step involves no CSIRT and no queue.

Who files the CRA report if you have no EU entity?

This is where almost every published guide stops, because almost every published guide is written for an EU legal or security team. If you are a US, UK or Asian manufacturer selling into the EU, three things are true and they are not obvious.

You file the CRA report, not your importer

Article 3(13) defines the manufacturer as a person who develops or manufactures products with digital elements, or has them designed or manufactured, and markets them under its own name or trademark. There is no EU-establishment qualifier: not in Article 3(13), not in Article 14, not in Article 2(1).

Articles 19 and 20 give importers and distributors a different and much lighter duty: on becoming aware of a vulnerability, inform you without undue delay, and where the product presents a significant cybersecurity risk, inform the market surveillance authorities.

That is an MSA duty on a different trigger. It is not an Article 14 filing, and it does not discharge yours.

The Article 14(7) cascade: which CSIRT receives your report

Normally you file through the CSIRT of the Member State of your main establishment in the Union, defined as where decisions on the cybersecurity of your products are predominantly taken. If you have no main establishment in the Union, Article 14(7) sets a strict order, based on information available to you:

Read this carefully: the cascade determines the postbox, not the duty-holder. Landing on step (b) does not make your importer the filer. It only means their Member State's CSIRT is where your report goes.

There is a small mercy in the fourth subparagraph. If you land on step (d), you may route all subsequent notifications to the same CSIRT you first reported to, rather than recalculating each time.

An EU authorised representative is optional under the CRA

Article 18(1) says a manufacturer "may" appoint an authorised representative. Unlike the medical devices regime or the GPSR, the CRA does not require one.

But look at what the cascade does without one. Your reporting counterparty is determined by your distribution mix: by which importer or distributor happens to move the most units this year, or by where your users happen to cluster.

That moves. It can move between the incident and the report. And you are trying to determine it inside a 24-hour window, during a live security event, using a list of designated CSIRTs that has not yet been published.

Appointing an AR fixes step (a) and gives you one stable, known CSIRT with a known language and a known end-point, decided in advance rather than during the incident.

One drafting point that will not be in your standard AR mandate. Article 18(2) lists what cannot be delegated: Article 13(1) to (11), the first subparagraph of 13(12), and 13(14), covering secure design, risk assessment, component due diligence, vulnerability handling and the technical documentation.

Article 14 is not on that list. On the face of the text, reporting can lawfully be delegated to an AR. But Article 18(3) sets a minimum mandate covering documentation custody, reasoned requests and cooperation on risk, and says nothing about reporting. So a boilerplate mandate will not carry it.

If you want your AR to file, the mandate has to say so in terms. We flag this as our reading of the text: no Commission or ENISA guidance addresses AR delegation of Article 14 directly, and delegation would not transfer the underlying liability in any event.

If you are weighing this up, our EU Authorised Representative service starts at €1,500 per product category per year and includes the mandate drafting.

ENISA's "Assigned Representative" is not an authorised representative

ENISA's platform documentation uses "AR" to mean "Assigned Representative", a login role on the reporting platform, registered through EU Login, with a Primary and a Secondary (backup) user. This is not the Article 18 authorised representative.

One person can hold several Assigned Representative associations while being nobody's legal AR. Do not let your security team conclude from the platform docs that you have an authorised representative when you do not.

When your EU distributor becomes the CRA manufacturer

Article 21 converts an importer or distributor into the manufacturer, subject to Articles 13 and 14, where they place the product on the market under their own name or trademark or carry out a substantial modification.

If your EU distributor rebrands your product, they become the reporting manufacturer for that SKU, and you may not be. This changes who carries the risk, and it should change the commercial conversation.

The separate CRA duty to inform your users

Article 14(8) is a standalone obligation, and it is the one most likely to be overlooked because it has no numeric deadline.

After becoming aware, you must inform impacted users, and where appropriate all users, of the vulnerability or incident and, where necessary, of the mitigation and corrective measures they can deploy. Where appropriate, in a structured, machine-readable format.

The standard is a "timely manner", and it is enforced by a real power: if you fail to inform users in time, the notified CSIRT may tell your users directly.

This is risk-based, not automatically public. Commission guidance is explicit that informing users "does not imply that such information must be made public or disclosed indiscriminately".

You may limit detailed disclosure to affected customers, particularly for products in sensitive environments where publishing technical detail would increase risk. Broader disclosure becomes appropriate once the vulnerability is fixed.

The separate duty to publicly disclose fixed vulnerabilities sits in Annex I, Part II, point 4, and Annex I does not apply until 11 December 2027.

What are the Cyber Resilience Act penalties for late reporting?

Article 64(2) puts breaches of Articles 13 and 14 in the top penalty tier: €15,000,000 or 2.5% of total worldwide annual turnover, whichever is higher. Reporting is expressly named.

Now the honest part, because sources disagree and several vendor guides get it wrong. A number of published summaries assert that these fines bite from 11 September 2026.

The plain text of Article 71(2) does not carve Article 64 out of the December 2027 default, and the Commission's own FAQ places market surveillance and enforcement at 11 December 2027.

The safe reading: the Article 14 duty is legally binding from 11 September 2026, but the administrative fine machinery and national market surveillance do not apply until 11 December 2027.

That is not a free pass. A breach in that window is a breach of a binding obligation, on the record, in a filing system that authorities will be reading from December 2027, and it is discoverable by every customer, insurer and acquirer who asks.

One carve-out worth knowing: Article 64(10) exempts microenterprises and small enterprises from fines for missing the 24-hour early warning deadline only. The 72-hour and final-report deadlines remain fully exposed.

Note that the provision opens "By way of derogation from paragraphs 3 to 9" while the tier capturing Article 14 is paragraph 2, a cross-reference problem that no official source has yet resolved.

Cyber Resilience Act checklist before 11 September 2026

1. Decide whether you are in scope. Does the product have any logical or physical data connection to a device or network? If yes, assume in scope and work backwards through the Article 2 exclusions.
2. Classify your SKUs now. The platform's data fields include Product Type (Default / Important / Critical) and Product Category by Annex III or IV. Work that out on a calm Tuesday, not during an incident.
3. Work out your Article 14(7) Member State using the cascade above, and write it down. If the answer is unstable, that is itself the argument for appointing an AR.
4. Create EU Login accounts for at least two people. Do not register on the platform pre-emptively, because ENISA asks you not to.
5. Write the 24-hour early warning template offline. ENISA's guidance indicates drafts on the platform are visible only to their author, so a backup user cannot see a colleague's saved draft. Keep the template in your own systems.
6. Define "becoming aware" internally. Name the person who makes the call and the assessment they run. The clock is 24 hours from reasonable certainty, and an undefined process is how that gets missed.
7. Write your user-notification path: the channel, the owner, the approval step. Article 14(8) has no deadline but has a CSIRT override.
8. Check your AR mandate if you have one. Article 14 will not be in it.

What this Cyber Resilience Act guide does not cover

This page covers Article 14 reporting only. It does not cover the Annex I essential cybersecurity requirements, the conformity assessment routes for Annex III and Annex IV products, support-period determination, SBOM requirements, or CE marking under the CRA, all of which apply from 11 December 2027 and deserve their own treatment.

It does not cover the open-source steward regime in Article 24, where the interaction between Article 24(3) and the September 2026 date is genuinely unresolved.

It is not legal advice, and where we have given our own reading of the text rather than a sourced position, we have said so.

Cyber Resilience Act sources and further reading

• Regulation (EU) 2024/2847 (Cyber Resilience Act), Official Journal
• European Commission, CRA reporting obligations
• ENISA, Single Reporting Platform
• ENISA, Single Reporting Platform FAQ
• European Commission guidance C(2026) 5252 of 27 July 2026, section 9.1
• European Commission FAQs on CRA implementation, sections 5 and 7.1

Related reading: EU Authorised Representative service · CE marking for electronics · EMC compliance and testing · EU Declaration of Conformity