Cyber Resilience Act Reporting for Non-EU Manufacturers

.ecc-table{width:100%;border-collapse:collapse;margin:1.75rem 0;font-size:.9375rem;line-height:1.55}.ecc-table th,.ecc-table td{text-align:left;vertical-align:top;padding:.7rem .9rem;border-bottom:1px solid rgba(255,255,255,.22)}.ecc-table th{font-weight:700}.ecc-table tr:last-child td{border-bottom:none}@media(max-width:767px){.ecc-table{display:block;overflow-x:auto}.ecc-table thead,.ecc-table tbody{display:table;width:100%;min-width:32rem}}

TL;DR. Since 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 through ENISA's Single Reporting Platform, now live at portal.cra-srp.enisa.europa.eu: an early warning within 24 hours of becoming aware, a notification within 72 hours, and a final report within 14 days of a fix being available (vulnerabilities) or one month after the 72-hour notification (incidents). The clock starts at reasonable certainty that exploitation or a severe incident has occurred, not at the end of your investigation.

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, and ENISA has published the list of designated CSIRTs you choose from. Nothing else in the CRA switches on until 11 December 2027, and the obligation covers products already on the market.

Is the CRA Single Reporting Platform live?

Yes. ENISA switched on the CRA Single Reporting Platform on 11 September 2026 at portal.cra-srp.enisa.europa.eu, the same day Article 14 reporting became mandatory. It accepts mandatory notifications of actively exploited vulnerabilities and severe incidents only; voluntary reporting under Article 15 and an API come in a later phase, and the interface is English only.

How do you register on the ENISA Single Reporting Platform?

Create a personal EU Login account with multi-factor authentication, open the platform, choose "Assigned Representative", select your coordinating CSIRT under Article 14(7), and enter the manufacturer details to become the Primary AR. ENISA asks you to do this only when you actually have a notification to file: registration takes minutes, CSIRT validation runs in parallel, and you can submit up to 20 notifications before verification becomes mandatory.

Which CSIRT does a non-EU manufacturer report to under the CRA?

With no main establishment in the EU, Article 14(7) fixes the Member State in this order: where your authorised representative acts for the most products; failing that, your largest importer; failing that, your largest distributor; failing that, where most of your users are. You then pick that Member State's CSIRT from ENISA's list of designated coordinators. The cascade decides only where the report goes; the duty to file stays with you, not your importer.

Cyber Resilience Act timeline: what applies now and what waits until 2027

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 2026 date brought in exactly one article.

DateWhat appliesStatus11 June 2026Chapter IV (Articles 35–51): notification of conformity assessment bodiesIn force11 September 2026Article 14 only: reporting of actively exploited vulnerabilities and severe incidents, plus the duty to inform usersIn force since 11 September 202611 December 2027Everything else: Annex I essential requirements, technical documentation, CE marking, EU declaration of conformity, conformity assessment, market surveillance and penalties, plus open-source steward reporting under Article 24(3)Not yet applicable

This distinction matters commercially. Today you are not yet 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 now 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 today:

• 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

ArticleExcluded2(2)(a)–(b)Medical devices (Reg. (EU) 2017/745) and IVDs (Reg. (EU) 2017/746)2(2)(c)Motor vehicles under Reg. (EU) 2019/2144 and their systems and components2(3)Products certified under Reg. (EU) 2018/1139 (civil aviation)2(4)Marine equipment within Directive 2014/90/EU2(6)Spare parts replacing identical components to the same specifications2(7)Products developed exclusively for national security or defence

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 in law, although the platform does not yet accept voluntary notifications.

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.

One transitional point is now settled. You are not required to report retrospectively an exploitation you were already aware of before 11 September 2026. But if you become aware of active exploitation after that date, the duty applies, even where the underlying vulnerability was already known to you (Commission FAQ, sections 5.1 and 5.3).

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

StageActively exploited vulnerabilitySevere incidentEarly warningWithin 24 hours of becoming aware. Indicate the Member States where you know the product is available.Within 24 hours. Must state at minimum whether the incident is suspected of being caused by unlawful or malicious acts.NotificationWithin 72 hours. General information on the product; general nature of the exploit and the vulnerability; corrective measures taken; measures users can take; how sensitive you consider the information.Within 72 hours. Nature of the incident; initial assessment; measures taken; measures users can take; sensitivity.Final reportWithin 14 days of a corrective or mitigating measure becoming available. Description including severity and impact; information on the malicious actor where available; details of the security update.Within one month of submitting the 72-hour notification. Detailed description including severity and impact; type of threat or root cause; applied and ongoing mitigation.

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.

A platform quirk to know about. In its current release, the Single Reporting Platform's 72-hour counter shows a due time 48 hours after you submit the early warning, so a notification can display as overdue before 72 hours have actually elapsed since you became aware. ENISA says a later release will calculate from the awareness timestamp. The legal deadline is unchanged; the counter is a reminder, not the law.

{{cta}}

Where CRA reports go: ENISA's Single Reporting Platform 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. The platform went live on 11 September 2026 at portal.cra-srp.enisa.europa.eu, and ENISA published the list of CSIRTs designated as coordinators the day before.

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. One notification per event is enough even if you have several EU subsidiaries; coordinating internally so that exactly one is filed is your responsibility.

How the CRA Single Reporting Platform works in practice

PointWhat ENISA's platform guidance says (as of 17 September 2026)AccessEach filer needs a personal EU Login account with multi-factor authentication. There is no corporate authentication layer. The platform is in English only.RolesOne Primary Assigned Representative per manufacturer, plus up to 20 Secondary ARs. The Primary sees every notification; a Secondary sees only the notifications they submitted themselves.When to registerENISA asks you to register and start validation only when you have a notification to file, to keep CSIRT queues clear. Registration takes minutes if the EU Login account already exists.ValidationThe CSIRT validates the AR-to-manufacturer association in parallel with reporting. It is not a precondition, and you may submit up to 20 notifications before verification becomes mandatory.Choosing the CSIRTYou select the coordinating CSIRT yourself under Article 14(7). Selecting the wrong one can invalidate the notification, which then has to be resubmitted.Delayed disseminationDuring the 72-hour window you assess whether one of the three particularly exceptional circumstances in Article 16(2) applies, as specified in Commission Delegated Regulation (EU) 2026/881 of 11 December 2025.f If you invoke it, ENISA receives only partial information until the receiving CSIRT releases the full notification.AutomationNo API at launch. Every notification goes through the web interface.Platform outageWait and file when it returns. If communication cannot wait, contact your designated CSIRT directly, but the notification must still be submitted through the platform afterwards.

What you should do in advance is create EU Login accounts with MFA 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 that cannot be determined, ENISA's FAQ points to the Member State where your largest EU workforce sits. If you have no main establishment in the Union at all, Article 14(7) sets a strict order, based on information available to you:

StepTestWhich Member State(a)Do you have an authorised representative?Where the AR acting for the highest number of your products is established(b)Failing that, importerWhere the importer placing the highest number of your products on the market is established(c)Failing that, distributorWhere the distributor making available the highest number of your products is established(d)Failing that, usersWhere the highest number of users of your products are located

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, on a platform where ENISA warns that selecting the wrong coordinating CSIRT can invalidate the notification.

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 up to 20 Secondary users. 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.

TierBreachMaximumArt. 64(2)Annex I essential requirements, and Articles 13 and 14€15m or 2.5% of worldwide turnoverArt. 64(3)Articles 18–23, 28, 30, 31, 32 and others€10m or 2% of worldwide turnoverArt. 64(4)Incorrect, incomplete or misleading information to a notified body or MSA€5m or 1% of worldwide turnover

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 has been legally binding since 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 reporting checklist: what to have in place now

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, match it against ENISA's published list of coordinating CSIRTs, and write it down. If the answer is unstable, that is itself the argument for appointing an AR.
4. Create EU Login accounts with MFA for at least two people. Do not register on the platform pre-emptively, because ENISA asks you not to; registration takes minutes once you need it.
5. Write the 24-hour early warning template offline. A Secondary AR can only see the notifications they submitted themselves, so nothing on the platform functions as a shared 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. Decide in advance who assesses "particularly exceptional circumstances". The Article 16(2) call to delay dissemination has to be made inside the 72-hour window, and it changes what ENISA sees.
8. Write your user-notification path: the channel, the owner, the approval step. Article 14(8) has no deadline but has a CSIRT override.
9. 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 software steward regime in Article 24. One earlier uncertainty is now closed: the Commission and ENISA both confirm that steward reporting under Article 24(3) applies from 11 December 2027, not September 2026.

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
• ENISA, CRA Single Reporting Platform (portal)
• ENISA, list of CSIRTs designated as coordinators
• ENISA, Single Reporting Platform FAQ (updated 17 September 2026)
• ENISA, Single Reporting Platform guidance and AR user manual
• European Commission, CRA reporting obligations
• European Commission guidance C(2026) 5252 of 27 July 2026, section 9.1
• European Commission FAQs on CRA implementation, sections 5 and 7.1
• Commission Delegated Regulation (EU) 2026/881 of 11 December 2025 on the cybersecurity-related grounds for delaying the dissemination of notifications

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