On September 11, 2026, the vulnerability reporting obligations under Article 14 of the Cyber Resilience Act (Regulation 2024/2847) become enforceable. This is not the CRA's full application date — that comes in December 2027 — but Article 14 was deliberately front-loaded. The European Commission and ENISA determined that vulnerability intelligence is too critical to wait for the broader compliance timeline. In practical terms: manufacturers of products with digital elements have roughly six months from the date of this writing to build reporting workflows that can operate under regulatory pressure.
Most CRA programs are still in legal analysis mode. Teams are mapping product scope, debating classification criteria, and building governance frameworks. That work matters, but it will not help when a zero-day hits a shipping product and the 24-hour reporting clock starts. Article 14 is a product security operations test, and operations readiness requires more than policy documents.
What Article 14 Requires
Article 14 imposes two distinct reporting obligations on manufacturers:
Actively exploited vulnerability reporting (Art. 14(1)): Manufacturers must notify ENISA of any actively exploited vulnerability contained in their products with digital elements. The notification must be submitted within 24 hours of becoming aware that the vulnerability is being actively exploited. A follow-up notification with more details — including corrective or mitigating measures — must be provided within 72 hours.
Severe incident reporting (Art. 14(2)): Manufacturers must notify ENISA of any incident having an impact on the security of the product with digital elements. The notification timeline mirrors the vulnerability reporting: early warning within 24 hours, detailed notification within 72 hours, and a final report within one month.
The 24-hour window is not 24 business hours. It is 24 clock hours from awareness. For organizations with distributed product teams, this means the clock can start at any time of day, in any time zone, and the reporting process must function accordingly. This is a fundamentally different operational requirement than NIS2 incident reporting, which applies to the entity experiencing the incident. Under CRA Art. 14, the obligation falls on the manufacturer of the product, regardless of who discovers or reports the vulnerability.
How CRA Reporting Differs from NIS2
Organizations subject to both CRA and NIS2 must understand the distinct reporting streams. The differences are material and create operational complexity.
Who reports: Under NIS2 Art. 23, the entity that experiences a significant incident reports to its CSIRT and competent authority. Under CRA Art. 14, the manufacturer of the affected product reports to ENISA. These are different reporting subjects with different notification targets.
What triggers reporting: NIS2 incident reporting is triggered by significant incidents affecting the entity's services. CRA vulnerability reporting is triggered by awareness of an actively exploited vulnerability in the manufacturer's product — even if the manufacturer's own operations are unaffected. A vulnerability in your product that is exploited against your customers triggers CRA reporting even if your systems are untouched.
Reporting target: NIS2 reports go to national CSIRTs and competent authorities. CRA reports go to ENISA, which operates the single reporting platform established under Art. 16. ENISA then forwards relevant information to the CSIRT of the member state where the manufacturer is established and, where appropriate, to the market surveillance authority.
Scope overlap: An organization that is both a NIS2 essential entity and a manufacturer of products with digital elements may need to file parallel reports for the same underlying event — one under NIS2 (as an affected entity) and one under CRA (as a product manufacturer). The notification content, timelines, and recipients differ.
This dual-reporting scenario is not theoretical. It will be the norm for any software company that is both a NIS2-regulated operator and a product manufacturer. Building a unified incident management process that can generate both report types from a single incident data model is an essential preparation step.
The SBOM Requirement
Article 14 does not operate in isolation. Its effectiveness depends on manufacturers maintaining accurate knowledge of their product composition — which is where the Software Bill of Materials (SBOM) requirement under Annex I, Part II, Section 1 becomes operationally critical.
The CRA requires manufacturers to identify and document vulnerabilities and components contained in the product, "including by drawing up a software bill of materials in a commonly used and machine-readable format covering at least the top-level dependencies of the product." This SBOM must be updated throughout the product lifecycle.
The connection to Article 14 reporting is direct: you cannot report vulnerabilities in components you have not tracked. When a new CVE is published for a library used in your product, your ability to determine exposure within the 24-hour reporting window depends entirely on whether your SBOM is current, accurate, and queryable.
For organizations with complex product portfolios — multiple products, multiple versions, multiple deployment configurations — SBOM management is a non-trivial infrastructure investment. The SBOM must be:
- Generated from build systems, not maintained manually. Manual SBOMs become stale the moment a developer updates a dependency.
- Version-specific. Different releases of the same product may contain different component versions and therefore have different vulnerability exposure.
- Queryable in real time. When a new actively exploited vulnerability is announced, you need to determine within hours — not days — which products and versions are affected. This requires a searchable database, not a static document.
- Machine-readable. The CRA specifies machine-readable formats. SPDX and CycloneDX are the two dominant standards. Choose one and standardize across all product lines.
The 24-Hour Operational Challenge
The 24-hour reporting window is the single most demanding operational requirement in Article 14. To meet it consistently, manufacturers need a pre-built reporting pipeline that can execute under pressure.
The failure mode is predictable. A vulnerability disclosure arrives — from a researcher, a CERT, an internal scan, or a customer report. The security team confirms it is actively exploited. The 24-hour clock starts. Now: who writes the report? Who approves it? What format does ENISA require? Which product versions are affected (requires SBOM query)? What corrective measures can be communicated (requires engineering input)? Who has signing authority?
If any of these questions require real-time negotiation, the 24-hour window is at risk. The solution is pre-engineering:
Pre-defined roles and escalation paths. Before any vulnerability arrives, define who is the reporting lead, who provides technical analysis, who provides legal review, who has approval authority, and who has backup authority when primary contacts are unavailable. Document this as a duty roster, not a RACI chart.
Pre-built report templates. ENISA will establish reporting templates through the single reporting platform. Before September 2026, obtain those templates (or their draft equivalents), pre-populate all static fields (manufacturer information, product identifiers, contact details), and build tooling that auto-fills dynamic fields from your vulnerability management system.
Pre-tested SBOM query capability. Run a drill: pick a random CVE from the last 30 days. Measure how long it takes to determine which of your products and versions contain the affected component. If the answer is more than two hours, your SBOM infrastructure is not Article 14-ready.
Pre-approved communication frameworks. Legal review of regulatory notifications under time pressure creates bottlenecks. Work with legal counsel now to develop pre-approved communication frameworks — templated language for common vulnerability scenarios that has been pre-cleared for regulatory use. This does not eliminate legal review; it reduces it from drafting to verification.
Preparation Timeline: Six Months to September 2026
With approximately six months remaining, manufacturers should structure their preparation in three phases.
Phase 1: Foundation (Months 1-2)
Product inventory and SBOM baseline. Enumerate all products with digital elements that fall within CRA scope. For each, ensure a current SBOM exists. If SBOMs do not exist, prioritize generation for products with the largest installed base or highest criticality.
Vulnerability monitoring integration. Connect your SBOM database to vulnerability intelligence feeds (NVD, ENISA advisories, vendor-specific feeds). Build or configure automated matching that flags when a new vulnerability affects a component in your SBOM. FortisEU's regulatory intelligence module can supplement this with CRA-specific regulatory updates and enforcement guidance.
Reporting role designation. Appoint the Article 14 reporting function. This may sit within product security, within compliance, or as a shared responsibility — but the roles, escalation paths, and backup arrangements must be defined and documented.
Phase 2: Process Build (Months 3-4)
Report template preparation. Based on ENISA's published format requirements, build report templates and tooling. Integrate with your vulnerability management system so that fields like affected product versions, CVSS scores, and component identifiers can be auto-populated.
Internal classification criteria. Define what "actively exploited" means operationally for your organization. The CRA uses this term but relies on established definitions. Your internal criteria should specify what evidence triggers the Art. 14 reporting obligation and who makes the classification determination.
Legal framework. Develop pre-approved language for regulatory notifications. Address common scenarios: remote code execution, data exposure, denial of service, supply chain compromise. Have legal counsel sign off on template language so that reporting under time pressure requires verification, not drafting.
Phase 3: Testing and Drill (Months 5-6)
End-to-end reporting drill. Simulate an actively exploited vulnerability scenario. Run the full reporting process from detection through ENISA notification within the 24-hour window. Measure actual elapsed time at each step. Identify bottlenecks.
Cross-functional coordination test. The drill should involve all functions that participate in reporting: product security, engineering (for impact assessment and corrective measures), legal (for notification review), communications (for customer advisory), and executive management (for approval). If any function delays the process beyond the 24-hour threshold, address the bottleneck.
SBOM accuracy verification. Select a sample of products and manually verify that the SBOM accurately reflects the current build. Correct any discrepancies. This is also an opportunity to verify that your SBOM query capability returns accurate results under time pressure.
Intersection with Product Security Programs
Article 14 does not stand alone — it is one obligation within the CRA's broader secure-by-design framework. Manufacturers who treat Art. 14 as an isolated reporting requirement will find themselves constantly firefighting because their underlying vulnerability management and product security processes are not designed for the CRA's expectations.
Annex I, Part II of the CRA requires manufacturers to handle and remediate vulnerabilities effectively throughout the product lifecycle. This includes: monitoring and addressing vulnerabilities on an ongoing basis, applying effective and regular security testing, publicly disclosing information about fixed vulnerabilities including advisories, and providing mechanisms for security updates.
Article 14 reporting is the output of these processes. If your vulnerability triage is slow, your reporting will be late. If your SBOM is incomplete, your impact assessment will be inaccurate. If your patching pipeline is fragile, your "corrective measures" field will be embarrassingly empty.
For CTOs and product security leads, the preparation for Article 14 is therefore inseparable from broader investment in product security operations: automated dependency scanning in CI/CD pipelines, vulnerability triage SLAs, security update delivery mechanisms, and customer communication workflows.
Penalty Framework
The CRA penalty regime under Art. 64 provides for administrative fines of up to EUR 15 million or 2.5% of worldwide annual turnover, whichever is higher, for failure to comply with essential requirements including Article 14 reporting obligations. Member states may implement additional enforcement mechanisms.
While enforcement patterns will not be established until after the September 2026 application date, the penalty quantum makes clear that the CRA is not a voluntary framework. Manufacturers that cannot demonstrate Article 14 readiness face both regulatory and market risk — enterprise customers subject to NIS2 and DORA supply chain requirements will increasingly demand evidence of CRA compliance from their product vendors.
Key Takeaways
-
Article 14 applies from September 11, 2026 — ahead of the broader CRA application date. Manufacturers must report actively exploited vulnerabilities to ENISA within 24 hours. This is an operational capability that must be built and tested before the deadline.
-
CRA reporting is distinct from NIS2 incident reporting. Different triggers, different subjects, different recipients. Organizations subject to both must build parallel reporting streams from a unified incident data model.
-
SBOM infrastructure is a prerequisite, not a nice-to-have. You cannot report on vulnerabilities in components you have not tracked. Invest in automated, version-specific, queryable SBOM generation integrated into your build pipeline.
-
Pre-engineer the reporting process. Define roles, build templates, pre-approve legal language, and test the full pipeline with drills. The 24-hour window does not accommodate real-time process design.
-
Connect Article 14 to broader product security. Reporting readiness depends on underlying vulnerability management, SBOM maintenance, and patching capabilities. Treat these as integrated investments, not separate workstreams.