# Cyber Resilience Act Article 14 Reporting: What Manufacturers Must Do Now

Source: https://activatedigital.ai/knowledge/regulation/cyber-resilience-act-reporting
Last verified: 20 September 2026
Summary: Cyber Resilience Act Article 14 reporting has applied since 11 September 2026.

## 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:

- [smart clothing and connected textiles](https://activatedigital.ai/knowledge/regulation/smart-clothing-connected-textiles)
- [connected toys](https://activatedigital.ai/knowledge/regulation/connected-toy-regulatory-classification)
- [smartwatch regulatory classification](https://activatedigital.ai/knowledge/regulation/smartwatch-regulatory-classification)
- [connected beauty devices](https://activatedigital.ai/knowledge/regulation/beauty-device-regulatory-classification)

## 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.→](https://activatedigital.ai/knowledge/regulation/smart-clothing-connected-textiles)
- [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.→](https://activatedigital.ai/knowledge/regulation/connected-toy-regulatory-classification)
- [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…→](https://activatedigital.ai/knowledge/regulation/smartwatch-regulatory-classification)
- [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.→](https://activatedigital.ai/knowledge/regulation/beauty-device-regulatory-classification)

## Primary sources

- [Regulation (EU) 2024/2847, especially Articles 14, 64, 69 and 71](https://eur-lex.europa.eu/eli/reg/2024/2847/oj)
- [European Commission, Cyber Resilience Act reporting obligations](https://digital-strategy.ec.europa.eu/en/policies/cra-reporting)
- [ENISA, CRA Single Reporting Platform](https://www.enisa.europa.eu/topics/product-security/vulnerability-services/eu-incident-response-and-cyber-crisis-management/single-reporting-platform-srp)