CRA Art.14 Compliance Finale: Complete September 2026 Vulnerability Reporting Ops Checklist

Post #1441 in the sota.io EU CRA Art.14 Vulnerability Reporting Ops Series

The Cyber Resilience Act's Art.14 vulnerability reporting regime applies from 11 September 2026 — the date when manufacturers of products with digital elements must have their incident response processes operational. This is not a planning horizon. This is a hard operational deadline.

This finale brings together the entire CRA Art.14 operational series into a single actionable checklist. We have covered ENISA notification requirements, the 24-hour early warning process, the 72-hour full report template, and the 14-day final documentation framework. Now we compress it all into what you actually need to implement by September 2026.

Who This Applies To

CRA Art.14 applies to manufacturers of products with digital elements — meaning any organisation that places a product containing software on the EU market. This includes:

• SaaS platforms accessible to EU users (even with no physical component)
• On-premise software products distributed in the EU
• Embedded software in hardware products
• Open-source components that commercial products bundle (under commercial entity obligations)

Art.14(1) specifically triggers when your product contains an actively exploited vulnerability or you become aware of a severe incident. You cannot wait until exploitation is confirmed at scale. If your monitoring detects active exploitation — even a single instance — the 24-hour clock starts.

The Three-Tier Reporting Cascade

Day 0: Discovery of actively exploited vulnerability or severe incident
  ↓
Within 24 hours: Early Warning to ENISA (Art.14(2))
  ↓
Within 72 hours: Intermediate Notification (Art.14(3)(a))
  ↓
Within 14 days: Final Report (Art.14(3)(b))

All three deadlines run from the same trigger event: when you became aware. This is different from NIS2, where the 24h clock starts from when you "become aware of a significant incident" — CRA uses the moment of discovery of an actively exploited vulnerability, which may be earlier than full incident confirmation.

Master Checklist: Pre-September 2026

Tier 1 — Process Infrastructure (Must be in place before 11 Sept 2026)

Vulnerability intake:

• Dedicated security reporting channel (security@yourdomain.com or equivalent)
• Responsible disclosure policy published and linked from product documentation
• Internal triage SLA defined: from receipt to severity classification ≤ 4 hours
• On-call rotation covering weekends and public holidays for P0 vulnerabilities

ENISA reporting access:

• ENISA reporting portal account registered (or national CERT channel established per Art.14(8))
• Designated reporting personnel with portal credentials and backup access
• Standard report templates pre-approved by legal/security teams (see our 24h and 72h templates)
• Contact information for relevant national CERT maintained and current

Evidence collection automation:

• Incident timeline logging with millisecond timestamps in immutable log store
• Automated CVE/CVSS scoring triggers integrated into vulnerability tracker
• SBOM registry current and accessible to security team (see Art.14 SBOM link below)
• Version-to-customer mapping maintained for impact scope calculation

Tier 2 — 24-Hour Early Warning Checklist (Art.14(2))

The 24-hour early warning is a brevity-first notification. ENISA does not expect a root cause analysis. They need to know:

• Vulnerability exists in a specified product/version range
• Exploitation is active (not theoretical — active exploitation must be confirmed or credibly suspected)
• Severity level (CVSS base score or equivalent)
• Whether a fix is in progress (no commitment required, just status)
• Contact point for follow-up from ENISA or national CERT

Practical implementation:

[CRA Art.14 Early Warning — 24h]
Manufacturer: [Legal entity name]
Product: [Product name, affected versions]
CVE (if assigned): [CVE-YYYY-NNNNN or "pending assignment"]
CVSS Base Score: [X.X]
Exploitation status: Actively exploited — confirmed / suspected
Fix status: In progress / Deployed to [version]
Estimated 72h report: [Datetime UTC]
Contact: [Name, email, phone]

Do not over-engineer the 24-hour report. Legal review that delays it beyond 24 hours is a compliance failure. Submit the early warning, then prepare the 72-hour report with legal input.

Tier 3 — 72-Hour Intermediate Report Checklist (Art.14(3)(a))

• Complete vulnerability technical description (attack vector, exploitability conditions, affected configurations)
• Full version range with unambiguous version identifiers
• Initial assessment of user impact (estimated affected user count or scope)
• Corrective measure status: patch available / in development / mitigation available
• Coordinated disclosure timeline: expected CVE publication date
• Art.13 user notification status: notified / in progress / pending on fix
• Cross-regulation overlap: does this incident also trigger NIS2 Art.23 or AI Act Art.73 reporting?

Cross-regulation alert: If your product is an AI system used in a high-risk application, a severe security incident may simultaneously trigger CRA Art.14 (to ENISA), NIS2 Art.23 (to national CSIRT, if you are an essential/important entity), and AI Act Art.73 (to national market surveillance authority). You need a single incident record that populates three different regulatory reports.

Tier 4 — 14-Day Final Report Checklist (Art.14(3)(b))

• Complete root cause analysis (proximate cause, contributing factors, detection gap)
• Full technical vulnerability write-up suitable for CVE description
• Evidence of corrective measure (patch commit hash, deployment confirmation, penetration test result if applicable)
• Art.13 user notification completion confirmation with notification method and date
• Coordinated disclosure confirmation: CVE public date aligned with ENISA submission
• Process improvement commitments: what SDLC change prevents recurrence
• SBOM update status: whether affected component entry has been updated (see below)

The SBOM Link: Why CRA Art.14 and Art.13 Are Inseparable

Art.14 vulnerability reporting does not exist in isolation from CRA Art.13, which requires manufacturers to maintain a Software Bill of Materials and ensure components remain secure throughout the product lifecycle. The connection is operational, not just conceptual.

When you file a 72-hour intermediate report for an actively exploited vulnerability, ENISA may ask:

1. Was this component listed in your SBOM?
2. Did your SBOM monitoring alert you to the vulnerability before exploitation occurred?
3. Have you updated your SBOM to reflect the patched version?

If your SBOM registry is absent or stale, you have two simultaneous compliance failures: the Art.14 reporting obligation and the Art.13 SBOM maintenance obligation. This is why SBOM infrastructure should be treated as a prerequisite for Art.14 compliance readiness, not a separate project.

Minimum SBOM requirements for Art.14 alignment:

• Component inventory updated on every release (not quarterly)
• Automated CVE correlation against SBOM entries (tools: Dependabot, Grype, OSV-Scanner)
• ENISA report template pre-populated from SBOM when a vulnerability is detected in a listed component
• Post-patch SBOM entry updated as part of the deployment checklist

The September 2026 Readiness Timeline

Working backwards from 11 September 2026:

The table-top exercise is not optional if you want to avoid a compliance failure under real-world conditions. ENISA reporting is unfamiliar to most security teams who have been operating under informal vendor disclosure norms. The first time you use the process should not be a real incident.

Cross-Regulation Reporting Matrix

Note: If a single incident triggers multiple regimes, you need a coordinated response that meets the strictest timeline across all obligations. In practice, this means treating CRA's 24-hour early warning as your universal trigger for all parallel notification workflows.

Common Failure Modes to Avoid

Failure 1: Legal review delays initial notification. The 24-hour clock does not pause for legal review. Build a pre-approved early warning template that legal has already signed off on. The early warning contains no admissions — it is a factual status update.

Failure 2: Conflating "awareness" with "confirmation." Under Art.14(1), the 24-hour clock starts when you become aware of an actively exploited vulnerability — not when you formally confirm it at P0. If your monitoring system alerts to a potential active exploit at 14:00 on Friday, the 24-hour clock starts at 14:00, not when your incident commander reviews it Monday morning.

Failure 3: Treating SBOM as a compliance document, not an operational tool. SBOM entries that are updated quarterly fail Art.13's "throughout the product lifecycle" requirement and undermine Art.14 response speed. Treat SBOM as a real-time operational artifact.

Failure 4: Missing the Art.13 user notification requirement. Art.13 requires manufacturers to inform users about vulnerabilities and available updates. The 14-day final report must confirm that Art.13 notification has occurred. If you are filing your final report before user notification is complete, explain why and when notification will occur.

Failure 5: No distinction between Art.14 and standard CVD (coordinated vulnerability disclosure). Standard CVD operates on 90-day disclosure timelines with the option to extend. CRA Art.14 imposes hard regulatory timescales regardless of whether the researcher agrees, whether a patch is ready, or whether disclosure would be inconvenient. These are not optional.

What Regulators Will Check Post-September 2026

National market surveillance authorities will audit CRA Art.14 compliance primarily through:

1. Post-incident review — after a public CVE, regulators can request your ENISA report and verify timelines
2. Coordinated inspections — national authorities may request documentation of your vulnerability reporting process without a triggering incident
3. Cross-authority information sharing — ENISA shares reports with national CERTs, who may escalate to market surveillance authorities if response is inadequate

The audit trail you need to maintain:

• All ENISA submissions with timestamps
• Internal incident records showing when awareness was first established
• Evidence of Art.13 user notifications
• SBOM version history with patch deployment records
• Root cause analysis documentation

Series Recap: CRA Art.14 Vulnerability Reporting Ops — All Five Posts

This concludes our five-post operational series on CRA Art.14 compliance for September 2026:

1. ENISA Notification Guide — What software publishers must report and the three-tier reporting structure
2. 24-Hour Early Warning — Developer ops guide for the first notification
3. 72-Hour Report Template — Complete intermediate notification template for SaaS providers
4. 14-Day Final Documentation — Root cause analysis framework and evidence documentation
5. This post — Master checklist for September 2026 readiness

EU-native deployment infrastructure is one part of CRA compliance readiness — your vulnerability reporting processes must be operational regardless of where you host. If you are still running on US-cloud-parent infrastructure, the CLOUD Act exposure adds a complication to coordinated disclosure: US law enforcement requests can compel disclosure before you have filed with ENISA. sota.io eliminates that vector — EU-hosted, no US parent, no CLOUD Act jurisdiction.