CRA Vulnerability Reporting: Step-by-Step Guide

Why This Is the First CRA Deadline That Hits You

Article 14 reporting obligations are the first operational requirement of the Cyber Resilience Act. While the full CRA enforcement date is December 11, 2027, Article 71(2) explicitly states:

“Article 14 shall apply from 11 September 2026.” — Regulation (EU) 2024/2847, Article 71(2)

This means that four months from now, every manufacturer selling a connected product in the EU must have a functioning vulnerability reporting process — even if the product itself was placed on the market years ago.

CRA Milestone	Date	Legal Basis
CRA enters into force	December 10, 2024	Art. 71(1)
Conformity assessment bodies activated	June 11, 2026	Art. 71(2)
Vulnerability reporting obligation	September 11, 2026	Art. 71(2) — Art. 14 applies
Full enforcement (all requirements)	December 11, 2027	Art. 71(2)

What Must Be Reported

Article 14 defines two distinct categories of reportable events. Understanding the difference is critical — the reporting timelines differ.

1. Actively Exploited Vulnerabilities (Article 14(1))

A vulnerability that the manufacturer becomes aware is being actively exploited in any of its products with digital elements currently available on the EU market.

Key definition: The regulation does not define a minimum severity threshold. If you become aware that a vulnerability in your product is being actively exploited — regardless of CVSS score — you must report it.

2. Severe Security Incidents (Article 14(3))

An incident having an impact on the security of the product with digital elements. Article 14(5) defines “severe” as an incident that:

• (a) negatively affects or is capable of negatively affecting the ability of a product to protect the availability, authenticity, integrity, or confidentiality of sensitive or important data or functions; or
• (b) has led or is capable of leading to the introduction or execution of malicious code in a product or in the network and information systems of a user.

Practical note: The “or” conjunction means that a supply chain compromise affecting your firmware — even if no end-user device has been confirmed infected — likely qualifies as a severe incident under criterion (b).

The Three-Stage Reporting Timeline

Both vulnerability and incident reporting follow a mandatory three-stage process. Each stage has a legally binding deadline measured from the moment you become aware of the event.

Actively Exploited Vulnerabilities

Stage	Deadline	Content Required	Legal Basis
Early Warning	Within 24 hours	Notification that an actively exploited vulnerability exists; indicate Member States where the product has been made available	Art. 14(2)(a)
Vulnerability Notification	Within 72 hours	General product information, nature of the exploit and vulnerability, corrective/mitigating measures taken, measures users can take, sensitivity indication	Art. 14(2)(b)
Final Report	Within 14 days after a corrective or mitigating measure is available	Description of the vulnerability (severity, impact), information about malicious actors (if available), details of the security update or corrective measures	Art. 14(2)(c)

Severe Security Incidents

Stage	Deadline	Content Required	Legal Basis
Early Warning	Within 24 hours	Notification of the incident, whether suspected unlawful/malicious acts, affected Member States	Art. 14(4)(a)
Incident Notification	Within 72 hours	Nature of the incident, initial assessment, corrective/mitigating measures, sensitivity indication	Art. 14(4)(b)
Final Report	Within 1 month after the 72-hour notification	Detailed description (severity, impact), threat type or root cause, applied and ongoing mitigation measures	Art. 14(4)(c)

Critical distinction: For vulnerabilities, the 14-day final report clock starts when a patch or mitigating measure becomes available — not when you first become aware. For incidents, the one-month clock starts from the 72-hour notification submission date.

Where to Report: The ENISA Single Reporting Platform

Article 16 establishes a Single Reporting Platform (SRP) managed by ENISA. This is the mandatory channel — email, phone, or informal communication does not satisfy the legal requirement.

How the SRP Works

1. ENISA manages the platform — day-to-day operations, security, and maintenance (Art. 16(1))
2. Each Member State has its own electronic notification end-point — you submit through the end-point of the CSIRT designated as coordinator for the Member State of your main establishment in the Union (Art. 14(7))
3. Simultaneous access for ENISA — your submission is automatically accessible to both your national CSIRT coordinator and ENISA (Art. 14(7))
4. Automatic dissemination — the receiving CSIRT disseminates the notification to other affected Member States’ CSIRTs via the SRP (Art. 16(2))

Determining Your CSIRT Coordinator

Article 14(7) provides clear rules for determining which CSIRT receives your notifications:

• EU-established manufacturer: The CSIRT of the Member State where your main establishment is located — defined as where decisions related to cybersecurity of your products are predominantly taken
• Non-EU manufacturer with EU presence: Priority order: (a) the Member State of your authorized representative covering most products, (b) the Member State of your primary importer, (c) the Member State of your primary distributor, (d) the Member State with the most users

CSIRT Coordinators — Central Europe Quick Reference

For manufacturers based in Central Europe, here are the designated national CSIRTs to which you will submit CRA reports via the ENISA Single Reporting Platform:

Country	CSIRT Coordinator	Website	Parent Authority
🇸🇰 Slovakia	SK-CERT	sk-cert.sk	National Security Authority (NBÚ)
🇨🇿 Czech Republic	NÚKIB CERT	nukib.cz	National Cyber and Information Security Agency
🇵🇱 Poland	CERT Polska	cert.pl	NASK (Research and Academic Computer Network)
🇭🇺 Hungary	NKI	nki.gov.hu	National Cybersecurity Institute
🇦🇹 Austria	CERT.at	cert.at	GovCERT Austria
🇩🇪 Germany	CERT-Bund	bsi.bund.de	Federal Office for Information Security (BSI)
🇪🇺 EU Institutions	CERT-EU	cert.europa.eu	EU Cybersecurity Service

How to identify your coordinator: Under Article 14(7), you submit to the CSIRT of the Member State where your main establishment is located — defined as where cybersecurity decisions for your products are predominantly made. For the complete list of all 27 EU Member State CSIRTs, see the EU CSIRTs Network directory.

Penalties for Non-Compliance

Article 64 of the CRA establishes a three-tier penalty structure. Article 14 violations fall under the most severe category:

Violation	Maximum Fine	Legal Basis
Failure to report under Article 14	€15 million or 2.5% of global annual turnover (whichever higher)	Art. 64(2)
Other CRA compliance failures	€10 million or 2% of global turnover	Art. 64(3)
Supplying incorrect information	€5 million or 1% of global turnover	Art. 64(4)

SME Exception

Article 64(10)(a) provides a limited exception: microenterprises and small enterprises are exempt from administrative fines for failing to meet the 24-hour early warning deadline (Art. 14(2)(a) and Art. 14(4)(a)). However, they are not exempt from the remaining reporting obligations (72-hour notification and final report).

Important: This exemption applies only to the 24-hour deadline. It does not exempt SMEs from the obligation to report — only from the fine for missing the specific 24-hour timeline.

What Your Company Must Build Before September 2026

Meeting the 24-hour early warning deadline requires operational infrastructure that cannot be built overnight. Here is what needs to be in place:

1. Continuous Vulnerability Monitoring

You need automated processes that detect when a vulnerability in your product or its dependencies is being actively exploited:

• Subscribe to CVE feeds for every component in your firmware — MCU vendor advisories, RTOS security bulletins, open-source dependency trackers
• Monitor the European Vulnerability Database (EUVD) — launched by ENISA in May 2025 under the NIS2 Directive
• Integrate SBOM-based vulnerability scanning — your Software Bill of Materials should be machine-readable (CycloneDX or SPDX format) and continuously scanned against known vulnerability databases
• Monitor threat intelligence feeds — CISA KEV, vendor-specific PSIRTs, sector-specific ISACs

2. Internal Triage and Escalation Process

The 24-hour clock starts when your organization becomes aware — not when your security team confirms. Establish clear procedures:

• Single point of intake — a dedicated security inbox or ticketing system where all vulnerability reports (internal, customer, researcher) are funneled
• Defined triage criteria — clear decision tree: Is this vulnerability being actively exploited? Does it affect a product on the EU market?
• Escalation path to authorized reporter — the person submitting to the SRP must have authority and access credentials pre-configured
• 24/7 coverage plan — a vulnerability disclosed on Friday evening still requires a 24-hour early warning. On-call rotation is essential

3. SBOM as the Foundation

Without a complete, accurate SBOM, you cannot reliably determine whether a newly disclosed vulnerability affects your product:

• Generate SBOMs at build time — integrate into your CI/CD pipeline, not as a manual post-build exercise
• Include firmware dependencies — RTOS (FreeRTOS, Zephyr), HAL libraries, BSP packages, cryptographic libraries (mbedTLS, wolfSSL)
• Track transitive dependencies — a vulnerability in a library used by your RTOS, which you never directly reference, is still your responsibility
• Keep SBOMs current — regenerate with every firmware release and maintain an archive of past versions for products still on the market

4. Pre-Registered SRP Access

Before September 11, 2026:

• Register your company on the ENISA Single Reporting Platform (once operational)
• Identify your CSIRT coordinator based on your main establishment (Art. 14(7))
• Configure notification end-points — ensure your authorized reporters have tested credentials and access
• Conduct a dry run — submit a test notification to verify the workflow end-to-end

5. User Notification Process

Article 14(8) requires that after becoming aware of an actively exploited vulnerability or severe incident, manufacturers must inform the impacted users — and where appropriate, all users — of the vulnerability and any mitigation measures. This notification should be in a structured, machine-readable format where appropriate.

If you fail to inform users in a timely manner, the notified CSIRT may do so on your behalf (Art. 14(8), second subparagraph).

Step-by-Step: Your First CRA Vulnerability Report

Here is the exact sequence when your monitoring detects an actively exploited vulnerability:

Hour 0: Detection and Awareness

• Vulnerability is flagged by automated scanning, researcher report, or customer complaint
• Clock starts: 24 hours until early warning deadline

Hours 0–4: Internal Triage

• Confirm the vulnerability exists in your product
• Verify it is being actively exploited (not just theoretically exploitable)
• Determine which EU Member States your product has been made available in
• Assign the authorized reporter

Hours 4–24: Early Warning Submission

• Submit via SRP to your CSIRT coordinator end-point
• Include: product identification, Member States affected, confirmation of active exploitation
• Receive acknowledgment from the SRP

Hours 24–72: Detailed Notification

• Provide: general product information, nature of the exploit, nature of the vulnerability
• Include: corrective/mitigating measures already taken, measures users can take
• Indicate sensitivity level of the information (this affects dissemination to other CSIRTs)

Ongoing: Patch Development

• Develop and test the corrective measure (security update, configuration change, or workaround)
• Coordinate with component suppliers if the vulnerability originates in a third-party component

Within 14 Days After Patch Availability: Final Report

• Description of the vulnerability, including severity and impact
• Information about malicious actors (if available)
• Details of the security update or corrective measures deployed

Parallel: User Notification (Article 14(8))

• Notify impacted users of the vulnerability and available mitigation measures
• Use structured, machine-readable format where appropriate (e.g., CSAF, VEX)

CRA vs. NIS2 vs. RED: Reporting Overlap

If your company is both a manufacturer (CRA) and an operator of essential services (NIS2), you may face parallel reporting obligations:

Dimension	CRA (Article 14)	NIS2 (Article 23)	RED (Art. 3.3(d-f))
Who reports	Product manufacturer	Entity operating essential/important services	Product manufacturer (via Declaration of Conformity)
What triggers	Actively exploited product vulnerability or severe incident	Significant cybersecurity incident affecting the entity	Non-conformity with essential requirements
Early warning	24 hours	24 hours	N/A (pre-market)
Detailed report	72 hours	72 hours	N/A
Final report	14 days (vulnerability) / 1 month (incident)	1 month	N/A
Report to	CSIRT + ENISA via SRP	National competent authority / CSIRT	Market surveillance authority
Applicable from	September 11, 2026	Already active (October 2024)	Already active (August 2025)

Key insight: The RED Delegated Act (EU 2022/30) is scheduled to be repealed once the CRA becomes fully applicable, to avoid regulatory duplication. During the transition period (2026–2027), products with radio equipment must comply with both frameworks simultaneously. For the full RED-to-CRA transition analysis, see our RED Delegated Act & EN 18031 guide.

Implementation Checklist

Use this checklist to track your readiness for September 11, 2026:

Organizational Readiness

• Designated CRA reporting officer with authority to submit to SRP
• 24/7 on-call rotation for vulnerability triage
• Documented vulnerability handling policy (intake → triage → report → patch → user notification)
• Legal team briefed on Article 14 requirements and Article 64 penalties
• Internal tabletop exercise completed (simulated vulnerability report)

Technical Infrastructure

• Automated SBOM generation integrated into CI/CD pipeline
• Continuous vulnerability scanning against CVE/NVD/EUVD databases
• Threat intelligence feeds subscribed (CISA KEV, vendor PSIRTs)
• CSAF/VEX capability for machine-readable user advisories
• Asset inventory of all products with digital elements on the EU market

Regulatory Registration

• CSIRT coordinator identified based on main establishment (Art. 14(7))
• ENISA Single Reporting Platform account registered (when available)
• SRP notification end-point tested with dry run
• Authorized representative designated (if non-EU manufacturer)

Documentation

• Vulnerability disclosure policy published on company website
• Contact information for security researchers clearly visible
• Template for each report stage prepared (early warning, notification, final report)
• Archive system for past SBOMs and vulnerability records

---

Don’t Wait for September to Find Out You’re Not Ready

The 24-hour early warning deadline is unforgiving. There is no grace period, no “soft launch.” On September 11, 2026, Article 14 applies in its entirety.

Most hardware companies underestimate what it takes to detect an actively exploited vulnerability within 24 hours. Without continuous SBOM-based monitoring, automated CVE correlation, and a pre-established reporting workflow, you will miss the deadline — and face fines up to €15 million.

Need help building CRA-compliant vulnerability management into your hardware product? Our Embedded Security & IoT team architects complete vulnerability management systems — from SBOM generation at build time to automated CVE monitoring and incident response procedures.

---