CRA Art.14 14-Day Final Vulnerability Report: Complete Documentation Framework for ENISA

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

The Cyber Resilience Act's three-tier notification cascade — 24-hour early warning, 72-hour intermediate report, 14-day final report — is one of the most operationally demanding requirements EU software manufacturers face from September 2026. Most teams have started thinking about the 24-hour alert. Far fewer have mapped out what the 14-day final report must actually contain.

This is the fourth post in our CRA Art.14 operational series. We covered the 24-hour ENISA alert and the 72-hour intermediate report template in previous posts. Now we go deep on the final report: what documentation you need to produce, how to structure root cause analysis, and how to evidence that your corrective measures actually work.

What Changes at Day 14: The Final Report vs. Intermediate Report

The 72-hour intermediate report is primarily a status update: you confirm the vulnerability exists, describe its severity, and state whether a fix is in progress. ENISA uses it to coordinate the EU-level response across member states and flag cross-sector impacts.

The 14-day final report is substantively different. Under CRA Art.14(3), the final report must include:

• Complete vulnerability description including root cause, attack vector, and exploitability conditions
• Full scope of affected products including version ranges, deployment environments, and configurations
• Corrective measure description — what you changed, why it resolves the root cause, and how you verified the fix
• User notification status — confirmation that affected users have been informed per Art.13 manufacturer obligations
• Coordinated disclosure timeline — if a CVE has been issued or will be issued, the ENISA report should align with public disclosure timing

The 24h and 72h reports get you into the reporting system. The 14-day report is what regulators and national CERTs will scrutinize if they investigate whether your response was adequate.

The Five-Section Documentation Framework

Section 1: Vulnerability Identification and Classification

This section establishes the complete technical record of what was found and when.

Required elements:

Timestamp documentation matters. Under CRA Art.14, the 24h, 72h, and 14-day clocks all start from the same event: when you "became aware" of an actively exploited vulnerability. Document your discovery timestamp precisely. If there is any ambiguity about when awareness occurred — for example, if a customer reported suspicious behaviour before your team confirmed exploitation — document the chain of events explicitly.

Section 2: Root Cause Analysis

This is the section most teams underprepare. ENISA does not expect a PhD dissertation, but they do expect you to trace the vulnerability to its origin in your development or deployment process.

Root cause documentation structure:

Proximate cause: [The specific code, configuration, or component that contained the flaw]
  Example: "Input validation function in auth/token_validator.go line 234 failed to check
  token expiry for service-to-service tokens issued via the internal minting endpoint."

Contributing factors: [Why the flaw was introduced and why detection failed]
  Example: "Service-to-service tokens were added in v2.4.0 as a fast-follow to the user
  token system. The validation logic was copied from user tokens but the expiry check was
  commented out during debugging and never re-enabled before merge."

Detection gap: [Why your existing controls did not catch it]
  Example: "Unit tests covered user token validation but the service token path had no
  equivalent coverage. The integration test suite did not test expired service tokens
  because this scenario was not included in the threat model for internal services."

This is not an exercise in self-incrimination. ENISA is looking for evidence that you understand what happened well enough to prevent recurrence. A root cause analysis that says "unknown input led to execution of unintended code paths" will raise questions. One that traces the flaw to a specific gap in your test coverage and connects it to a remediation in your SDLC is what regulators want to see.

Section 3: Corrective Measures and Verification

The final report must document not just what you changed, but that the change actually resolves the root cause and has been verified.

Fix documentation framework:

Code-level changes:

• Commit references with descriptions (not just hashes — include the commit message)
• Before/after comparison for the critical path if the change is complex
• Explanation of why this change addresses the root cause (not just the symptom)

Verification evidence:

• Unit tests added to cover the exploit scenario — with test names and expected vs. actual results
• Integration test results showing the attack vector no longer succeeds
• If you performed penetration testing or engaged an external security researcher to verify: their report reference or confirmation email

Deployment evidence:

• Version number of the patched release
• Deployment timestamp to your production environment
• If you run staged rollouts: deployment log showing 100% of instances updated

Example verification table:

Section 4: User Notification Documentation

CRA Art.13 requires manufacturers to inform users about security vulnerabilities and available corrections as part of the manufacturer's core obligations. Your 14-day final report must include confirmation that user notification has occurred or is in progress.

Notification documentation checklist:

• Security advisory published: URL of your public security advisory (CVE databases, your security page, GitHub security advisories)
• Notification channels used: In-app notifications, email to affected users, RSS security feed, API changelog
• Notification content: Does it include: the vulnerability description, affected versions, recommended action (upgrade, configuration change, workaround), timeline for support if users cannot immediately upgrade?
• Timing: Was notification coordinated with your ENISA report and CVE publication? Premature disclosure before a patch is available creates risk; delayed disclosure after a patch is available also creates liability

Coordinated disclosure note: If a security researcher reported the vulnerability to you under a responsible disclosure programme, your user notification timing should respect the agreed embargo period. Document the researcher agreement and the embargo end date in the report. ENISA understands coordinated disclosure timelines.

Section 5: Process Improvements and Recurrence Prevention

This section shows ENISA that your organisation has learned from the incident. It does not need to be comprehensive — two to four concrete improvements is sufficient.

Format:

What ENISA Does With Your Final Report

Understanding how ENISA processes your report helps you calibrate the level of detail required.

After receiving your final report, ENISA:

1. Updates the EU Vulnerability Database (EUVDB) with the verified information. Your report becomes part of the public record if the vulnerability is confirmed as actively exploited under CRA Art.14 criteria.

2. Distributes to national CSIRTs via the CSIRT network. National cybersecurity authorities in member states where your product is deployed may follow up directly. If you sell to critical infrastructure operators or public sector entities, expect follow-up questions.

3. Assesses your response adequacy. ENISA does not adjudicate enforcement — that is the role of market surveillance authorities — but their assessment of your response quality can inform whether national authorities initiate investigations. A well-documented final report reduces that risk materially.

4. Feeds sector-level threat intelligence. If multiple manufacturers report similar vulnerabilities in the same period, ENISA may issue sector-level advisories. Your root cause analysis contributes to this.

The 14-Day Clock: What Counts as Day 1

One of the most operationally significant questions for CRA Art.14 compliance is: when does the clock start?

Under Art.14, the clock starts when you "become aware" of an actively exploited vulnerability. The word "actively exploited" is doing significant work here.

Practically, this means:

• A vulnerability report from a researcher does not start the clock if you have no evidence it is being exploited in the wild
• A SIEM alert showing exploitation attempts does start the clock — even if you are still investigating severity
• A customer report describing behaviour consistent with exploitation starts the clock — do not wait for internal confirmation

The safer approach: Treat any credible indication of in-the-wild exploitation as day zero. If your investigation later confirms the vulnerability is not being actively exploited, you can document this in your report and the premature notification will not create liability. The reverse — discovering you should have started the clock 5 days ago — is far more difficult to address.

Record-Keeping: What to Retain and for How Long

CRA Art.13 requires manufacturers to maintain technical documentation for a period that exceeds the product's economic lifetime, with a minimum of ten years. Your vulnerability report records are part of this documentation obligation.

Retain for each reported vulnerability:

Practical implementation: Most teams do not have a 10-year document retention system for security incidents. If you are starting from scratch: an encrypted S3 bucket (or EU-equivalent object storage) with object versioning enabled, a policy that blocks deletion for 10 years, and a quarterly audit that your incident records are landing there is a reasonable baseline. Store the ENISA submission reference numbers alongside your internal records.

Operational Timeline: Working Backwards from Day 14

If you want your 14-day final report to be accurate and complete, you need to start documentation work long before day 14.

The hardest part is usually root cause analysis. If your incident starts over a weekend, the developers who wrote the vulnerable code may not be available until Monday. Build your incident response procedure to account for this — root cause analysis requires developer involvement, not just security team involvement.

GDPR Art.33 Overlap: When You Need Both Reports

If the vulnerability is actively exploited and the exploitation involves personal data of EU data subjects, you may have a concurrent GDPR Art.33 notification obligation to your supervisory authority within 72 hours of becoming aware of a personal data breach.

The overlap scenario:

The CRA report goes to ENISA. The GDPR Art.33 report goes to your lead supervisory authority (typically DPA in your EU country of establishment). They are separate obligations to separate bodies on potentially different timelines.

Practical note: Your 14-day CRA final report and your GDPR Art.33 initial report may be submitted around the same time. Coordinate your DPO and security team on messaging — the descriptions of what happened should be consistent across both reports.

Final Report Quality Checklist

Before submitting your CRA Art.14 14-day final report to ENISA, verify:

• Discovery timestamp is documented to the minute, with source evidence
• CVE assigned or CNA contact documented
• CVSS v3.1 base score calculated and vector string included
• Root cause traced to specific code/configuration, not just "unknown vulnerability"
• Fix commits referenced with descriptions (not just hashes)
• At least one independent verification step documented (new test, external researcher, pentest)
• Deployment evidence shows 100% of production instances updated
• User notification: security advisory published or scheduled (with coordinated disclosure date if applicable)
• User notification confirmed in report per Art.13 obligations (channels used, timing, content)
• GDPR Art.33 overlap assessed — if personal data involved, DPA notification status documented
• At least two process improvements documented with implementation status
• All documentation stored in your 10-year retention system
• ENISA reference numbers from 24h and 72h reports included for cross-reference

What's Next in the Series

The fifth and final post in this series will be the complete CRA Art.14 compliance finale — a full operational checklist for September 2026 readiness, covering all three notification stages, your SBOM integration requirements, record-keeping infrastructure, and how to structure your vulnerability handling programme under CRA Art.13 and Art.14 together.

sota.io is an EU-native managed PaaS — deploy any language on Hetzner Germany infrastructure with no CLOUD Act exposure. Our 1,400+ EU compliance guides help development teams understand and implement their obligations under CRA, GDPR, AI Act, NIS2, and other EU digital regulations.