Artifact GuideEU

Cyber Resilience Act Article 14 Reporting Obligations

A guide based on official sources to when manufacturers must notify actively exploited vulnerabilities and severe product-security incidents.

Covers the Article 14 triggers, staged deadlines, live ENISA platform and CSIRT routing, user communication, component-origin vulnerabilities, and evidence records.

Author
Sorena AI
Published
Mar 4, 2026
Updated
Oct 15, 2026
Overview

CRA Article 14 reporting starts on 11 September 2026. From that date, a manufacturer must report an contained in an in-scope product and a having an impact on that product's security. The duty includes products placed on the market before the CRA's main 11 December 2027 application date, although Article 14 does not make every other CRA duty apply to that older product.

Section 1

Start by separating the two Article 14 triggers

Article 14 has two mandatory reporting tracks. The first is an contained in the product with digital elements. The second is a having an impact on the security of the product with digital elements. Treat them as separate triage outcomes because the tests, final-report timing, and final-report content are not identical.

For an , the legal trigger is reliable evidence that a malicious actor exploited a vulnerability without permission of the system owner. A zero-day is not automatically reportable just because no patch exists; the Commission FAQ says mandatory reporting depends on reliable evidence of malicious exploitation. Vulnerabilities found in good-faith testing, bug bounty, laboratory assessment, correction, or disclosure are not mandatory Article 14 notifications unless that exploitation evidence exists.

  • Record the first awareness timestamp and the evidence that made exploitation or incident severity reasonably credible.
  • Classify whether the event is an , a , both, voluntary Article 15 material, or not reportable.
  • For a , test whether product security is affected through availability, authenticity, integrity, or confidentiality of sensitive or important data or functions.
  • Also test whether the event has led, or could lead, to malicious code in the product or in the user's network and information systems.
  • Keep a non-reporting rationale when the team decides a vulnerability exists but is not actively exploited in the finished product.
Section 2

Use the Article 14 staged reporting clocks

Both mandatory tracks begin with awareness by the manufacturer. Article 14 requires an early warning without undue delay and in any event within 24 hours. The next notification is due without undue delay and in any event within 72 hours unless the relevant information has already been provided.

The final report clock is different for each track. For an , the final report is due no later than 14 days after a corrective or mitigating measure is available. For a , the final report is due within one month after the incident notification. If more status detail is needed, the initially receiving the notification may request intermediate reports.

  • 24-hour early warning for an : indicate, where applicable, Member States where the product is known to have been made available.
  • 72-hour vulnerability notification: provide available product details, the general nature of the exploit and vulnerability, measures already taken, measures users can take, and sensitivity of the information where applicable.
  • Final vulnerability report: include vulnerability description, severity and impact, available information on the malicious actor, and details of the security update or other corrective measures.
  • 24-hour early warning for a : include at least whether unlawful or malicious acts are suspected and relevant Member States where applicable.
  • 72-hour incident notification and final incident report: provide the incident nature, initial assessment, user measures, sensitivity where applicable, severity and impact, likely threat type or root cause, and applied or ongoing mitigations.
Section 3

Route notifications through the live ENISA Single Reporting Platform

From 11 September 2026, each Article 14 notification is to be submitted once through the established by ENISA instead of separately to multiple authorities. ENISA launched the platform on 11 September 2026. The submission uses the electronic notification endpoint of the for the relevant Member State and is simultaneously accessible to ENISA, subject to the CRA's exceptional dissemination-delay rules.

For a manufacturer with a Union main establishment, the relevant Member State is where decisions related to the cybersecurity of its products are predominantly taken. If that cannot be determined, Article 14 uses the Union establishment with the highest number of employees.

Use the live ENISA reporting portal linked below. Use ENISA's current registration instructions and Assigned Representative (AR) user manual to set up access and confirm the filing route before a deadline. Keep an authorised person able to submit a report through the platform.

  • For a manufacturer without a Union main establishment, apply Article 14's fallback order: the Member State of the authorised representative acting for the highest number of the manufacturer's products; then the importer placing the highest number on the market; then the distributor making the highest number available; then the Member State with the highest number of users.
  • Store the routing decision with the facts used to choose the CSIRT endpoint, especially for non-Union manufacturers and group structures.
  • Keep product availability by Member State available for the early warning because Article 14 asks for it where applicable.
  • Mark information sensitivity in the notification where applicable; Article 16 allows limited dissemination delays on justified cybersecurity-related grounds.
  • Prepare access credentials, alternates, legal entity details, product identifiers, and incident contacts before the first live submission.
Section 4

User communication is a parallel Article 14 duty

After becoming aware of an or , the manufacturer must inform impacted users and, where appropriate, all users. The notice must cover the vulnerability or incident and, where necessary, risk-mitigation and corrective measures users can deploy.

Where appropriate, the manufacturer must provide this user information in a structured, machine-readable format that is easily automatically processable. If the manufacturer does not inform users in a timely manner, the notified CSIRTs may provide the information when proportionate and necessary to prevent or mitigate impact.

  • Maintain separate user-notice patterns for targeted impacted-user notice, broad all-user notice, and machine-readable security advisory data.
  • Use consistent product name, model, version, component, support-period, and update identifiers across the Article 14 report, advisory, release notes, and support page.
  • Avoid publishing exploit-enabling detail before a mitigation is available unless the disclosure decision is justified and coordinated.
  • Record when each user segment was informed, through which channel, what mitigation advice was given, and who approved the wording.
  • Coordinate support, incident response, vulnerability disclosure, legal, and communications around the same Article 14 timeline.
Section 5

Handle component-origin vulnerabilities without losing ownership

The CRA vulnerability-handling obligations cover the product in its entirety, including integrated components. The July 2026 Commission guidance says the finished-product manufacturer must report an actively exploited component-origin vulnerability contained in its product when aware of it. A separately marketed component manufacturer may have its own duty. The guidance distinguishes this from a component vulnerability that cannot be exploited in the finished product or has not been exploited in that product; those cases do not trigger mandatory Article 14 reporting by that manufacturer on that basis.

If a component vulnerability exists but cannot be exploited in the finished product, it is not an for that product on that basis. Article 13(6) can still require the manufacturer to report the vulnerability upstream to the person or entity manufacturing or maintaining the component, and Article 15 voluntary reporting can still be considered.

  • Link reports to SBOM, dependency, firmware, hardware, and build records so affected product versions can be identified quickly.
  • Keep upstream maintainer or component manufacturer contacts and preserve when they were notified.
  • Track whether the affected component was placed on the market separately and whether the finished product exposes the vulnerable functionality.
  • Document product-specific exploitability, not only the existence of a CVE or upstream advisory.
  • If a mitigation is developed for a component, preserve the code or documentation shared upstream where appropriate.
Section 6

Keep a complete Article 14 evidence file

The Article 14 record should include the submitted form and show how the manufacturer identified awareness, classified the trigger, selected the CSIRT route, met each reporting stage, informed users, and followed through on corrective or mitigating measures.

For legacy products placed on the market before 11 December 2027, the Commission FAQ recognises that old tooling, build environments, dependencies, or staff knowledge may be missing. Those limits do not remove Article 14 reporting once it applies and the manufacturer becomes aware. Record the investigation limits and evidence available at each stage. The broader CRA cybersecurity and vulnerability-handling duties do not apply to that older product merely because Article 14 applies; Article 69(2) separately addresses products that are substantially modified from 11 December 2027.

  • Awareness log: first reliable evidence, source channel, initial assessment, decision owner, and timestamp used for the 24-hour and 72-hour clocks.
  • Classification memo: Article 14 trigger, severe-incident criteria, exploitation evidence, affected products, Member States, and non-reporting rationale where relevant.
  • Submission archive: early warning, 72-hour notification, final report, sensitivity marking, CSIRT endpoint, ENISA platform receipt, and any intermediate-report request.
  • Mitigation file: security update, workaround, configuration change, disabled function, release notes, affected versions, validation evidence, and residual risk.
  • User communication record: impacted-user list, all-user decision, message content, channel, timing, machine-readable advisory output where used, and approvals.
Recommended next step

Turn Article 14 reporting into an evidence-ready workflow

Use Sorena to keep CRA Article 14 triage, awareness timestamps, CSIRT routing, user notices, mitigation records, and source citations together before the first mandatory report is due.

Primary sources

References and citations

data.europa.eu
Referenced sections
  • Specifies the exceptional cybersecurity-related grounds and conditions under which a receiving CSIRT may delay dissemination through the Single Reporting Platform.
digital-strategy.ec.europa.eu
Referenced sections
  • Confirms the 11 September 2026 start date, the staged deadlines, submission through the Single Reporting Platform without separate filings to multiple authorities, CSIRT routing, and the platform reporting route.
data.europa.eu
Referenced sections
  • Supports the Article 14 reporting triggers, staged deadlines, CSIRT and ENISA routing, Article 16 platform handling, user-information duty, voluntary reporting context, and Article 71 application date.
"Reporting obligations of manufacturers"
Show all related guides (55)

CRA Requirements | Annex I, Manufacturer Duties and CE Evidence

Map Cyber Resilience Act requirements from Annex I to manufacturer duties, vulnerability handling, user information, technical documentation, declaration of conformity, and CE marking evidence.

CRA SBOM and Vulnerability Management Template

Build a CRA-ready SBOM and vulnerability handling record with component inventory, triage, remediation, disclosure, reporting, update, and technical documentation fields.

CRA vs RED Cybersecurity Delegated Act

Compare the EU Cyber Resilience Act with the RED cybersecurity delegated act for connected and radio equipment, including scope, timing, evidence, and transition treatment.

CRA Vulnerability Handling and Disclosure | Article 14 Reporting and Security Updates

How EU Cyber Resilience Act manufacturers should run vulnerability intake, remediation, coordinated disclosure, Article 14 reporting, secure updates, and evidence records.

EU CRA Compliance Program for Manufacturers and Economic Operators

Build a Cyber Resilience Act compliance program around product scope, Annex I security requirements, conformity assessment, technical documentation, vulnerability reporting, and market surveillance.

EU CRA vs UK PSTI Product Security Regime

Compare EU Cyber Resilience Act and UK PSTI product-security scope, duties, evidence, dates, actors, and enforcement for connected products.

EU Cyber Resilience Act Checklist for Product Security and CE Marking

A CRA checklist for products with digital elements: scope, Annex I security controls, vulnerability handling, Article 14 reporting, technical documentation, conformity assessment, CE marking, and support-period evidence.

EU Cyber Resilience Act FAQ

Direct CRA FAQ answers on scope, economic-operator roles, essential requirements, vulnerability reporting, conformity assessment, CE marking, support periods, and market surveillance.

EU Cyber Resilience Act Technical Documentation and Audit File

Build a CRA technical file around Article 31 and Annex VII: product scope, risk assessment, vulnerability handling, conformity evidence, testing, updates, and retention.

CRA Blue Guide Concepts FAQ | Placing on the Market, Making Available, Distance Sales

CRA FAQ explaining Blue Guide market-access concepts for products with digital elements: placing on the market, making available, imports, CE marking, operator roles, online sales, stock, and testing exceptions.

CRA CE Marking FAQ | Conformity Assessment, EU Declaration, Evidence

Practical CRA CE marking answers for products with digital elements: conformity assessment, EU declaration, technical documentation, standards, software placement, and launch evidence.

CRA Component Due Diligence FAQ | Third-Party Software, FOSS, SBOMs

Cyber Resilience Act FAQ on manufacturer due diligence for integrated components, third-party software, FOSS dependencies, SBOMs, vulnerability handling, and evidence records.

CRA Conformity Assessment Routes FAQ | Module A, Module B+C, Module H, Important and Critical Products

Cyber Resilience Act FAQ on when manufacturers can use module A, when module B+C or module H is required, and how important and critical products affect the route.

CRA Cybersecurity Risk Assessment FAQ | Article 13, Annex I, Updates

CRA FAQ on Article 13 cybersecurity risk assessments, Annex I applicability, intended purpose, foreseeable use, technical documentation, and update evidence.

CRA Declaration of Conformity FAQ | Annex V, Simplified Declaration, CE Marking

FAQ on the Cyber Resilience Act EU Declaration of Conformity: Annex V contents, simplified Annex VI wording, CE marking link, technical documentation, retention, updates, and operator duties.

CRA Economic Operators FAQ | Manufacturers, Importers, Distributors, Authorised Representatives

CRA FAQ on economic-operator roles: manufacturers, importers, distributors, authorised representatives, substantial modification, traceability, and evidence controls.

CRA Essential Cybersecurity Requirements FAQ | Annex I Part I and Part II

CRA FAQ on Annex I product cybersecurity requirements, vulnerability handling, secure-by-default design, risk assessment, documentation, lifecycle duties, and user information.

CRA Hardware and Software Boundaries FAQ | Product Scope, Components, RDPS

FAQ on Cyber Resilience Act hardware and software boundaries: combined products, standalone software, source code, components, remote data processing, SaaS and market-placement changes.

CRA Harmonised Standards FAQ | Presumption of Conformity, Common Specifications

Cyber Resilience Act FAQ on how harmonised standards, common specifications, certification schemes, and OJ publication affect CRA conformity evidence.

CRA Important and Critical Products FAQ | Annex III, Annex IV, Conformity Assessment

FAQ on CRA important and critical products, Annex III and Annex IV classification, core functionality, and conformity assessment consequences.

CRA Integrated Components and Dependencies FAQ | Third-Party Software and SBOM Evidence

Cyber Resilience Act FAQ on integrated components, third-party software, remote data processing, SBOM-style evidence, upstream fixes, FOSS dependencies, and manufacturer responsibility.

CRA Interplay With EU Product Laws FAQ | RED, Machinery, Data Act

Official source CRA FAQ on overlap with the Radio Equipment Directive, Machinery Regulation, GPSR, Data Act, exclusions, declarations, documentation, and existing certificates.

CRA Known Exploitable Vulnerabilities at Launch FAQ

FAQ for Cyber Resilience Act launch decisions: known exploitable vulnerabilities, CVEs, component flaws, secure-by-default settings, release gates, Article 14 reporting, and evidence.

CRA Legacy Products FAQ | Pre-11 December 2027 Products

Cyber Resilience Act FAQ on products placed on the market before 11 December 2027, Article 14 reporting, substantial modification, distributor stock, spare parts, and records.

CRA Manufacturer Obligations FAQ | Article 13, Annex I, CE Marking

FAQ for Cyber Resilience Act manufacturers covering Article 13 duties, risk assessment, Annex I, vulnerability handling, support periods, documentation, conformity assessment, reporting, CE marking, and evidence controls.

CRA Market Surveillance and Enforcement FAQ | Authorities, Corrective Action, Safeguards

Cyber Resilience Act FAQ on market-surveillance authorities, investigations, corrective action, withdrawal, recall, safeguards, sweeps, documentation access, and penalties.

CRA Module B+C FAQ | EU-Type Examination, Conformity to Type, Notified Bodies

CRA Module B+C FAQ explaining EU-type examination, conformity to type, notified-body evidence, production control, CE marking, declarations, and certificate changes.

CRA Module H FAQ | Full Quality Assurance, Notified Body Surveillance, CE Marking

CRA Module H FAQ explaining the full-quality-assurance route, notified-body assessment, quality-system scope, technical documentation, CE marking, declarations, and records.

CRA Notified Bodies FAQ | Scope, Modules B+C and H, Certificates

Practical CRA FAQ on when notified bodies are needed, how CRA bodies are designated, what their notified scope means, and how Module B+C and Module H assessments work.

CRA Open-Source Software FAQ | FOSS Scope, Stewards, Manufacturers

Cyber Resilience Act FAQ for free and open-source software: commercial activity, steward duties, manufacturer due diligence, vulnerability handling, public documentation, and user obligations.

CRA Over-the-Air Updates FAQ

Cyber Resilience Act FAQ on OTA updates, automatic security updates, secure update distribution, support-period evidence, and offline update paths.

CRA penalties and fines FAQ | Article 64 fine caps

FAQ on EU Cyber Resilience Act Article 64 penalties: maximum fine tiers, turnover caps, national enforcement, economic operators, reporting duties, and open-source steward carve-outs.

CRA Product Families FAQ | Variants, Shared Assessments, Family Reuse, Conformity Scope

CRA FAQ on product families, variant grouping, shared technical documentation, conformity evidence, and when cybersecurity-relevant differences need separate assessment.

CRA Products With Digital Elements Scope FAQ

EU Cyber Resilience Act FAQ on products with digital elements, software, firmware, remote data processing, components, exclusions, market placement, and CRA operator boundaries.

CRA Remote Data Processing Solutions FAQ | Product Scope, Cloud and Backend Boundaries

FAQ on how the EU Cyber Resilience Act treats remote data processing solutions, manufacturer-controlled backends, third-party cloud services, SaaS, risk assessment, documentation, and user information.

CRA Reporting Obligations FAQ | Article 14, CSIRTs, ENISA, User Notices

Cyber Resilience Act FAQ on Article 14 reporting for actively exploited vulnerabilities and severe incidents, including timing, CSIRT routing, ENISA access, user notices, and evidence.

CRA Secure-by-Default FAQ | Default Configuration and Annex I Controls

Cyber Resilience Act FAQ on secure-by-default configuration, automatic security updates, attack surface reduction, authentication, data minimisation, user information, and tailor-made products.

CRA Security Updates vs Functionality Updates FAQ

Cyber Resilience Act FAQ on classifying security updates, functionality updates, support-period duties, automatic updates, user notices, and substantial-modification review.

CRA Substantial Modification FAQ | Updates, Repairs, Manufacturer Duties

Cyber Resilience Act FAQ on when software updates, repairs, spare parts, and post-market changes become substantial modifications and trigger CRA manufacturer, evidence, and conformity duties.

CRA Support Period FAQ | Expected Product Lifetime, Security Updates, User Information

Practical CRA FAQ on how manufacturers determine support periods, disclose support end dates, keep security updates available, and document support-period evidence.

CRA Tailor-Made Products FAQ | Bespoke Products, Market Placement, Evidence

FAQ on when a bespoke product may be treated as tailor-made under the EU Cyber Resilience Act, what the carve-out changes, and what manufacturers still need to document.

CRA Technical Documentation FAQ | Annex VII Evidence and Technical File

CRA FAQ explaining Annex VII technical documentation, risk assessment evidence, conformity assessment files, vulnerability handling records, product families, RDPS, language, and authority access.

CRA Transition Period FAQ | Entry Into Force, Application Dates, Reporting, Legacy Products

CRA FAQ on the transition period covering entry into force, 2026 reporting, 2027 application, legacy products, stock, customs timing, and software versions.

CRA Update Availability and Software Archives FAQ

FAQ on CRA security-update availability, support-period notices, optional public software archives, historical versions, and Article 13(10) software-version limits.

CRA User Information and Transparency FAQ | Annex II Instructions

Practical CRA FAQ on Annex II user instructions, support-period disclosure, vulnerability contacts, update notices, importer and distributor information.

CRA Vulnerability Handling FAQ | Support Periods, Components, Reporting

Practical CRA FAQ on vulnerability handling: SBOMs, remediation, coordinated disclosure, component issues, security updates, support periods, Article 14 reporting, and user notices.

Cyber Resilience Act Module A FAQ | Internal Production Control

FAQ on when CRA Module A internal production control is available, when it is blocked, and what documentation, testing, standards, and evidence it still requires.

EU Cyber Resilience Act Core Functionality FAQ | CRA Product Classification

CRA FAQ on core functionality, product boundaries, remote data processing, integrated components, ancillary functions, and software changes that affect product classification.

EU Cyber Resilience Act Repairs and Spare Parts FAQ

CRA FAQ for repairs, spare parts, legacy products, security updates, substantial modification, and responsibility after product changes.