Artifact GuideEU

Cyber Resilience Act Article 14 Reporting Obligations

A grounded guide to when manufacturers must notify actively exploited vulnerabilities and severe product-security incidents.

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

Author
Sorena AI
Published
Mar 4, 2026
Updated
May 25, 2026
Sections
6

Structured answer sets in this page tree.

Primary sources
2

Cited legal and guidance references.

Publication metadata
Sorena AI
Published Mar 4, 2026
Updated May 25, 2026
Overview

CRA Article 14 reporting starts applying on 11 September 2026. From that date, manufacturers of in-scope products with digital elements must be ready to report actively exploited vulnerabilities and severe incidents having an impact on product security, including for in-scope products placed on the market before the CRA's main 11 December 2027 application date.

Section 1

Start by separating the two Article 14 triggers

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

For an actively exploited vulnerability, 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 actively exploited vulnerability, a severe incident, both, voluntary Article 15 material, or not reportable.
  • For a severe incident, 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 actively exploited vulnerability, the final report is due no later than 14 days after a corrective or mitigating measure is available. For a severe incident, the final report is due within one month after the incident notification. If more status detail is needed, the CSIRT designated as coordinator initially receiving the notification may request intermediate reports.

  • 24-hour early warning for an actively exploited vulnerability: identify the vulnerability and, 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 severe incident: 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 ENISA single reporting platform

Article 14 notifications are submitted via the single reporting platform established by ENISA. The report uses the electronic notification endpoint of the CSIRT designated as coordinator for the relevant Member State and is simultaneously accessible to ENISA.

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.

  • For a manufacturer without a Union main establishment, apply Article 14's fallback order: authorised representative, importer, distributor, then 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 actively exploited vulnerability or severe incident, 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.

The CRA also says this user information should be provided, where appropriate, 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 that information to users 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 apply to the product with digital elements in its entirety, including integrated components. The Commission FAQ says that if an actively exploited vulnerability originates in an integrated component, the finished-product manufacturer must notify it when the vulnerability is contained in and actively exploitable in its product. The component manufacturer may also have its own obligation if it placed the component on the market.

If a component vulnerability exists but cannot be exploited in the finished product, it is not an actively exploited vulnerability 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

Evidence operations for a defensible Article 14 file

A useful Article 14 record is not just the submitted form. It should 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. That does not remove Article 14 reporting once the reporting obligation applies and the manufacturer becomes aware, so the file should also record investigation limits and the evidence available at each stage.

  • 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

ec.europa.eu
Referenced sections
  • Supports the implementation clarifications on awareness channels, zero-day reporting, legacy products, and actively exploited vulnerabilities that originate in integrated components.
"Reporting obligations start applying as of 11 September 2026."
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"
Related guides

Explore more topics

CRA Applicability Test for Products With Digital Elements
Check whether the EU Cyber Resilience Act applies to a hardware, software, firmware, open-source, or connected product before conformity planning.
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 and CE Marking
How to choose a Cyber Resilience Act conformity route, prepare technical documentation, issue the EU declaration of conformity, and affix CE marking.
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 deadlines and compliance calendar | EU Cyber Resilience Act
Track the Cyber Resilience Act entry into force, staged application dates, Article 14 reporting deadlines, transitional rules, and review dates.
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 Essential Cybersecurity Requirements in Annex I
A grounded guide to the Cyber Resilience Act Annex I requirements for product security, vulnerability handling, secure-by-design controls, documentation, and evidence.
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
Grounded 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 Penalties and Fines: Article 64 Caps and Enforcement Context
Article 64 of the EU Cyber Resilience Act sets administrative fine ceilings for Annex I, manufacturer, reporting, economic-operator, notified-body, and information-request breaches.
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 | EU Cyber Resilience Act
Apply the EU Cyber Resilience Act scope test for software, hardware, remote data processing, components, open-source software, exclusions, and economic-operator roles.
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 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 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 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 vs UK PSTI Act | Cyber Resilience Act Comparison
Compare grounded EU Cyber Resilience Act duties with UK PSTI planning points, with UK legal details clearly marked for separate source review.
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.
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 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 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 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 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 Repairs and Spare Parts FAQ
CRA FAQ for repairs, spare parts, legacy products, security updates, substantial modification, and responsibility after product changes.
EU Cyber Resilience Act Technical Documentation and Audit File
Build an audit-ready CRA technical file around Article 31 and Annex VII: product scope, risk assessment, vulnerability handling, conformity evidence, testing, and retention.