Cyber Resilience Act Article 14 Reporting: What Manufacturers Must Do Now
Cyber Resilience Act Article 14 reporting has applied since 11 September 2026.
Jump around this page
- Direct answer
- Who does the live reporting duty apply to?
- The two Article 14 reporting pathways
- What is an actively exploited vulnerability?
- What is a severe incident?
- The Single Reporting Platform is now an operating dependency
- Micro and small manufacturers: limited penalty treatment is
- What most of the CRA still does not require yet
- A practical internal ownership model
- What to put in the runbook now
- What this page does not own
- What would change this page
- Keep exploring
- Primary sources
Direct answer
Cyber Resilience Act Article 14 reporting has applied since 11 September 2026. Manufacturers of in-scope products with digital elements need an operating process to report actively exploited vulnerabilities and severe incidents having an impact on the security of the product through the EU Single Reporting Platform.
The reporting duty is staged ahead of the wider CRA. Most of the Regulation generally applies from 11 December 2027. Do not treat the live Article 14 duty as proof that every CRA product-security obligation already applies.
For both main Article 14 pathways, the reporting sequence starts with a 24-hour early warning and moves to a fuller notification within 72 hours. The later final-report step differs by pathway and should be built into the internal workflow rather than treated as one generic deadline.
Who does the live reporting duty apply to?
The duty is aimed at manufacturers of products with digital elements within CRA scope. Scope and manufacturer status must be established under the Regulation rather than inferred from commercial labels such as “software vendor”, “brand” or “connected product company”.
Article 14's application is also relevant to products with digital elements placed on the market before the CRA's wider 11 December 2027 application point in the circumstances set out by Article 69(3). Do not assume that a product is outside the reporting workflow simply because it was placed on the market before most CRA obligations begin.
Category pages can help with the first classification question, but they do not replace this horizontal reporting owner. For example:
The two Article 14 reporting pathways
| Trigger | First step | Second step | Final step | Operating point |
|---|---|---|---|---|
| Actively exploited vulnerability | Early warning without undue delay and in any event within 24 hours of becoming aware | Vulnerability notification within 72 hours of becoming aware | Final report no later than 14 days after a corrective or mitigating measure is available, unless an applicable exception changes the required handling | The workflow has to connect vulnerability triage, exploitation assessment, remediation and regulatory reporting |
| Severe incident having an impact on product security | Early warning without undue delay and in any event within 24 hours of becoming aware | Incident notification within 72 hours of becoming aware | Final report within one month after the incident notification, as established by the reporting framework | Incident-response and product-security teams need a regulatory escalation path, not just an internal severity process |
The legal text controls the trigger and timing. The Commission's CRA reporting page provides the current operational explanation of the sequence and the Single Reporting Platform.
What is an actively exploited vulnerability?
Do not collapse “a vulnerability exists” into “Article 14 reporting is triggered”. The CRA reporting pathway is tied to the Regulation's defined condition of active exploitation.
An internal vulnerability process therefore needs a documented decision point for:
- whether the affected product is within CRA scope
- whether the business is the manufacturer for the reporting duty
- whether exploitation is established or reasonably evidenced at the level required by the Regulation
- when the organisation became aware, because the 24-hour and 72-hour clocks depend on awareness
- which corrective or mitigating measure is available and when
The reporting process should preserve the evidence behind those decisions.
What is a severe incident?
The severe-incident pathway is separate from the actively exploited-vulnerability pathway. A product-security incident should be tested against the CRA threshold rather than assumed reportable because it is commercially serious, or assumed non-reportable because another incident regime also applies.
Connected products can sit inside more than one reporting regime. Build a routing decision that identifies the legal trigger and destination for each regime rather than sending one generic incident form everywhere.
The Single Reporting Platform is now an operating dependency
The EU Single Reporting Platform is the operational layer for CRA Article 14 notifications. The Commission and ENISA describe it as live for the 11 September 2026 reporting start.
For an in-scope manufacturer, that makes platform readiness a current control. At minimum:
- identify who owns the organisation's access and reporting capability
- validate access before an incident occurs
- define who can authorise a regulatory notification
- connect the 24-hour early-warning path to the security escalation process
- define the 72-hour handoff and evidence needed for the fuller notification
- calendar and own the pathway-specific final report
- retain the facts, timestamps, submitted versions and corrective-action evidence
A policy that says “report to ENISA if required” is not an operating workflow.
Micro and small manufacturers: limited penalty treatment is not an exemption
The CRA contains a bounded administrative-fine treatment for micro and small manufacturers in Article 64(10)(a) in relation to failure to meet specified 24-hour early-warning deadlines under Article 14.
That should not be rewritten as “micro and small companies are exempt from Article 14”. They are not. The reporting duty and the penalty provision are different legal questions.
If business size matters to the case, record exactly which Article 64 treatment is being relied on and do not generalise it beyond its wording.
What most of the CRA still does not require yet
The live reporting date is deliberately earlier than the wider Regulation's general application point.
As at 20 September 2026:
- Article 14 reporting is live from 11 September 2026
- most CRA obligations generally apply from 11 December 2027
- a current reporting workflow does not prove that every later conformity, lifecycle, documentation or vulnerability-handling duty is already applicable to the product today
This staged structure matters for product roadmaps. A manufacturer can need incident reporting now while still preparing for the wider 2027 operating model.
A practical internal ownership model
The law does not require one particular organisation chart, but the workflow needs clear owners. A practical model is:
- Product security / PSIRT: initial technical assessment, exploitation evidence, affected versions and remediation state
- Legal / regulatory: CRA scope, manufacturer role, reportability decision and cross-regime conflicts
- Engineering / product: corrective or mitigating measure, affected products and release evidence
- Operations / compliance: SRP access, submission records, deadline control and final-report closure
- Leadership escalation: material incident decisions and business continuity where needed
The objective is a closed chain from awareness to legal decision to submission to corrective action to final evidence.
What to put in the runbook now
A workable CRA Article 14 runbook should answer:
- Which products with digital elements are potentially in scope?
- Who is the manufacturer for each product line?
- What event starts the internal CRA clock?
- Who decides whether a vulnerability is actively exploited?
- Who decides whether an incident meets the severe-incident threshold?
- Who owns the 24-hour submission?
- What additional facts must be assembled for 72 hours?
- Who owns the corrective or mitigating measure and its availability date?
- Who owns the final report and closure evidence?
- Which other legal reporting regimes need to be checked in parallel?
If those questions do not have named owners and evidence locations, the organisation is relying on improvisation inside a short statutory window.
What this page does not own
This page owns the horizontal question:
What must an in-scope manufacturer report under CRA Article 14 now, when must it be reported and what operational workflow is needed?
It does not own:
- the full CRA product-security framework
- classification of every connected product category
- the future textile, toy, electronics or other DPP question
- a generic explanation of every CRA conformity obligation that applies from 2027
Use the relevant category owner to establish the product context, then return here for the live reporting process.
What would change this page
Re-check this page if:
- Article 14 or its timing is amended
- the Commission or ENISA changes the Single Reporting Platform workflow in a way that changes the operating steps
- implementing or delegated material changes the report content or routing
- the wider 11 December 2027 application point is legally changed
- authoritative guidance materially changes the interpretation of the two reporting triggers
Keep exploring
The questions this page usually raises next.
- CompareNext questionSmart Clothing and Connected Textiles: Textile Product, Electronics or Both?A connected garment can be textile, electronic, radio, battery-containing and digital at once.
- CompareNext questionConnected Toys: Toy, Radio Product, Cyber Product or Several at Once?A connected toy can sit under toy safety, radio and cybersecurity rules at once.
- CompareNext questionIs a Smartwatch Jewellery, Electronics or Another DPP Category?A smartwatch can be a “watch” for one legal or commercial purpose and still be electronic, radio and battery-containing equipment…
- CompareNext questionIs a Beauty Device a Cosmetic Product, Electronic Product or Medical Device?“Beauty device” is a marketing category, not a single EU regulatory category.
Primary sources
Does this reach your products?
Give ActivateDigital one product and it works out which obligations apply from the product's own character, and says which it cannot decide.