CRA Vulnerability Reporting: ENISA SRP, 24h/72h/14d clock

The EU Cyber Resilience Act (Regulation (EU) 2024/2847) makes vulnerability reporting a hard, time-bound legal duty for every manufacturer of a product with digital elements. From 11 September 2026, Article 14 requires actively exploited vulnerabilities and severe incidents to be reported through the ENISA Single Reporting Platform (SRP). Both streams share a 24-hour early warning and a 72-hour notification, but the final-report clock differs: 14 days after a corrective measure is available for vulnerabilities (Article 14(2)(c)), and 1 month after the 72-hour notification for severe incidents (Article 14(4)(c)). The reporting regime is backed by a mandatory coordinated vulnerability disclosure (CVD) policy under Annex I Part II. This page is the canonical reference: what the law requires, when each clock starts, what a compliant CVD policy must contain, how VEX supports the "no known exploitable vulnerabilities" obligation, and which Article 64 fines apply when reporting fails.

What Does the CRA Require for Vulnerability Reporting?

Article 14 of the Cyber Resilience Act is the operational core of the regulation's incident-handling regime. It places three duties on every manufacturer of a product with digital elements placed on the EU market:

1. Notify any actively exploited vulnerability in the product simultaneously to the coordinator CSIRT and to ENISA, on the 24h / 72h / 14d cadence (Art. 14(1), 14(2)).
2. Notify any severe incident affecting the security of the product on a 24h / 72h / 1-month cadence (Art. 14(3), 14(4)).
3. Inform users of the affected product about the vulnerability or incident and any corrective measures, without undue delay (Art. 14(8)).

Article 14 sits alongside two other obligations that this page also covers: the mandatory CVD policy under Annex I Part II, and the "no known exploitable vulnerabilities" requirement under Annex I Part I, which is why VEX matters for a CRA-compliant product. None of these obligations carry a size threshold. SMEs benefit from a narrow penalty relief on the 24-hour clock (see below) but are not exempt from reporting.

The ENISA Single Reporting Platform (SRP)

The SRP is the single channel through which every Article 14 notification flows. It exists because Article 14(1) requires the manufacturer to notify the coordinator CSIRT and ENISA simultaneously, and 27 separate filings would be unworkable. Article 16(1) places the platform under ENISA's operational responsibility: "the day-to-day operations of that single reporting platform shall be managed and maintained by ENISA."

How it works in practice:

• You submit once, using the electronic end-point of the CSIRT designated as your coordinator under Article 14(7).
• The submission lands simultaneously at the coordinator CSIRT and at ENISA.
• The coordinator CSIRT then disseminates the notification to CSIRTs in other Member States where your product is placed on the market (Art. 16). That secondary dissemination is the CSIRT's responsibility, not the manufacturer's.
• Article 16(2) allows a CSIRT to delay onward dissemination in particularly exceptional circumstances. Article 16(6) allows a delay during coordinated disclosure with the manufacturer's consent.

Status as of May 2026: the SRP is scheduled to be operational by 11 September 2026, per the ENISA SRP page. The implementation was tendered under ENISA/2025/OP/0001 (4-year contract) with the tender closing in March 2025. The vendor has not been publicly disclosed. No registration URL has been published. A pre-launch testing period is expected; specific dates have not been announced. Implementing acts under Article 14 setting the formats and structure of notifications were still pending at the time of writing.

What manufacturers should do now: identify your coordinator CSIRT under Article 14(7), draft and pre-approve report templates for the 24h, 72h, and final-report submissions in both streams (14 days for vulnerabilities under Article 14(2)(c) and 1 month for severe incidents under Article 14(4)(c)), and define an out-of-hours escalation rota. Templates and processes cannot be drafted while the 24-hour clock is running.

Reporting Timelines in Detail

Both vulnerabilities and severe incidents follow a staged reporting model. The clocks differ on the final-report leg.

Article 14 Reporting Timetable

What Each Submission Contains

Early warning (24 hours). Minimum information to alert authorities: manufacturer identity, affected product and version, brief description, initial severity, whether exploitation is confirmed or suspected, and an indication of impact scope. The early warning is an alert, not an analysis.

Detailed notification (72 hours). Two distinct duties live at this stage. The 72-hour vulnerability notification under Article 14(2)(b) applies to actively exploited vulnerabilities. The 72-hour incident notification under Article 14(4)(b) applies to severe incidents. In both cases the submission expands on the early warning with technical details, affected versions and configurations, exploitation method (if known), current mitigation status, remediation timeline, known affected user scope, and any ongoing coordination with other parties.

Final report. For vulnerabilities, the 14-day clock starts "no later than 14 days after a corrective or mitigating measure is available" (Art. 14(2)(c)), not from discovery and not from the 72-hour notification. For severe incidents, the 1-month clock anchors to the 72-hour incident notification under Article 14(4)(c). The final report covers root cause, full technical description, remediation actions taken, prevention measures implemented, and confirmed impact assessment.

1. Manufacturer awareness. The 24-hour clock starts the moment reasonable belief of active exploitation is formed.
2. + 24 hours. Early warning submitted via the ENISA SRP (Art. 14(2)(a)).
3. + 72 hours. Detailed notification submitted with technical details, affected versions, and mitigation status (Art. 14(2)(b)).
4. Corrective or mitigating measure available. The 14-day final-report clock starts here, not at discovery.
5. + 14 days. Final report submitted: root cause, full technical description, remediation, confirmed impact (Art. 14(2)(c)).

What Triggers a Reporting Obligation?

Article 14 covers two trigger categories.

1. Actively Exploited Vulnerabilities

A vulnerability in your product that:

• is known to you (discovered internally or reported externally),
• has been used by a malicious actor, and
• affects, or could affect, users of the product.

The CRA defines an actively exploited vulnerability as one where "a malicious actor makes use of a flaw." This is not the same as public disclosure, a published proof-of-concept, or a researcher demonstrating exploitability. The trigger is actual malicious use.

2. Severe Incidents

Security incidents that impact the product's security, compromise the development environment in a way that affects product security, cause widespread service disruption to users, or result in widespread compromise.

Reportable vs Non-Reportable Scenarios

The "Reasonable Belief" Standard

Forensic proof of exploitation is not required. The Article 14 standard is reasonable belief based on available evidence: unusual access patterns consistent with known exploit techniques, customer reports of compromise, threat intelligence indicating your product is targeted, or detection of exploit code designed for your product. When uncertain, report. A premature early warning that turns out to be unfounded is far better than a missed deadline for actual exploitation, and the 72-hour notification can update the assessment.

Coordinated Vulnerability Disclosure (CVD) Policy: the link to Article 14

Annex I Part II point 5 of the CRA requires manufacturers to "put in place and enforce a policy on coordinated vulnerability disclosure." The CVD policy is the operational mechanism that turns external researcher reports into a structured triage flow and, when active exploitation is detected during triage, fires the Article 14 reporting clock in parallel. The policy is mandatory for every product with digital elements; there is no SME or size threshold. The minimum delivery is a public URL plus a security.txt file under /.well-known/security.txt (RFC 9116) so reports are discoverable by the researchers the regulation is designed to channel.

For the CVD policy itself, including required contents, disclosure-window conventions, safe-harbour language and researcher-communication templates, see the dedicated CRA Coordinated Vulnerability Disclosure guide. For how CVD sits among the other Annex I Part II duties (SBOM, remediation, secure updates, free-of-charge delivery), see CRA vulnerability handling. This page focuses on the Article 14 reporting cadence that triggers when triage confirms active exploitation.

VEX: Communicating Vulnerability Applicability

Annex I Part I requires CRA products to ship with no known exploitable vulnerabilities and to be delivered with a secure-by-default configuration. SBOM scanning produces long lists of CVEs against components, most of which are not actually exploitable in your specific product. VEX (Vulnerability Exploitability eXchange) is the mechanism that turns those raw scan results into a defensible "not affected / affected / fixed / under investigation" position per CVE, which is what the regulation, harmonised standards in development, and German procurement under BSI TR-03183 Part 3 all expect.

What VEX Is

VEX is a structured, machine-readable statement about whether a vulnerability in a component actually affects a specific product. It answers: "CVE-XXXX exists in our SBOM. Does it affect our product, why or why not, and what should the user do?" The four core states are:

CRA Connection

VEX is not named in the CRA text, but it is the operational tool behind three of the regulation's clauses:

• Annex I Part I, no known exploitable vulnerabilities. A not_affected VEX statement with a documented justification is the evidence that you have evaluated a CVE and concluded it does not apply. Without it, every CVE in your SBOM is a presumed liability.
• Annex I Part II, vulnerability handling. VEX is the audit trail of how each CVE moved from under_investigation to not_affected, affected, or fixed over time.
• Article 14, reporting triggers. A vulnerability marked affected and known to be actively exploited is exactly the trigger that starts the 24-hour clock. A vulnerability marked not_affected with sound justification is not.

VEX Formats

Two formats matter in practice. CycloneDX VEX is embedded directly in a CycloneDX SBOM under vulnerabilities[].analysis. CSAF VEX is a separate document in CSAF 2.0 (the format BSI TR-03183 Part 3 requires for security advisories, and the format German CERTs publish and consume by default). Both are machine-readable and both satisfy the same operational role.

A minimal CycloneDX VEX assertion:

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.5",
  "version": 1,
  "vulnerabilities": [
    {
      "id": "CVE-2027-XXXXX",
      "source": { "name": "NVD" },
      "analysis": {
        "state": "not_affected",
        "justification": "code_not_reachable",
        "detail": "The vulnerable function is not called in our implementation."
      },
      "affects": [{ "ref": "pkg:generic/openssl@3.0.12" }]
    }
  ]
}

The CycloneDX 1.5 specification defines six analysis states (in_triage, exploitable, not_affected, false_positive, resolved, resolved_with_pedigree), a finer-grained vocabulary than OpenVEX's four (not_affected, affected, fixed, under_investigation), which it maps onto. BSI TR-03183 Part 3 expects VEX statements alongside SBOMs for CRA-aligned products. For the full SBOM and BSI TR-03183 picture, see the SBOM cluster guide.

SME Exemptions and Reduced Obligations

Article 64(10) provides a narrow penalty relief for the smallest manufacturers. It does not exempt anyone from reporting.

Microenterprises and small enterprises (defined as fewer than 50 employees and an annual turnover or balance sheet of up to EUR 10 million; microenterprises: fewer than 10 employees, EUR 2 million) are exempt from fines specifically for missing the 24-hour early-warning deadlines under Article 14(2)(a) and Article 14(4)(a). The relief covers timing fines on the 24-hour leg only.

Still required, with no SME relief:

• The 72-hour detailed notification (Art. 14(2)(b) and 14(4)(b)).
• The 14-day final report for vulnerabilities and the 1-month final report for severe incidents.
• The CVD policy under Annex I Part II.
• All other CRA obligations, including the "no known exploitable vulnerabilities" requirement under Annex I Part I.

Medium enterprises (up to 250 employees) are not covered by the SME relief at all. The exemption is a narrow penalty carve-out, not a reduced reporting regime.

Common Mistakes

• Waiting for forensic certainty before starting the clock. Article 14 uses a reasonable-belief standard. Waiting for proof misses the deadline.
• Confusing CVD with Article 14 reporting. A researcher report is a CVD input; Article 14 reporting is triggered when there is evidence of active exploitation. The CVD policy must contain an explicit gate for this.
• Single-point-of-failure escalation. One person authorised to report, unreachable on a Friday night. The 24-hour clock does not pause.
• First contact with the coordinator CSIRT during an incident. Establish the relationship and the routing now, while there is no clock running.
• No published CVD policy. The Annex I Part II obligation is not satisfied by an internal document.
• No VEX assertions. Every CVE in your SBOM is presumed exploitable until you say otherwise. Annex I Part I is much harder to defend without VEX.
• Treating the SRP launch as a future problem. Templates, escalation rotas, and CSIRT relationships have to be in place before September 2026, not built afterwards.