Free CRA reporting guides
Build the reporting process before the clock starts.
Short, source-grounded guides for Article 14 readiness. They are not legal advice; they show how to turn owners, SBOMs, scanners, tickets, and release records into a rehearsable workflow. Each guide cites Regulation (EU) 2024/2847 or the official EU guidance it draws on.
Scope and owners
What counts as an actively exploited vulnerability under the CRA?
The 24-hour clock is tied to a vulnerability being used in an attack, not merely one that exists. The gap is usually a written, agreed trigger and a named person who confirms exploitation from your own signals, so the clock starts on evidence rather than on a hunch or a vendor headline.
Which security incidents are severe enough to report under CRA Article 14?
Reporting covers a severe incident having an impact on the security of the product, alongside actively exploited vulnerabilities. Teams rarely lack awareness of the category; the gap is a written line between an internal hiccup and a reportable severe incident, plus who is allowed to make that call out of hours.
Who should own the first CRA reporting decision?
Name a role and a backup. If nobody owns the first decision today, keep that as a gap rather than implying the incident process already covers CRA reporting.
How do you cover the CRA 24-hour clock across weekends and time zones?
The 24-hour early-warning window does not pause for a weekend or a holiday. The gap is a named owner and a named backup with a way to be reached, so awareness on a Saturday still starts the clock with someone who can act rather than waiting for Monday.
Is your existing incident-response plan enough for CRA reporting?
An incident-response plan handles containment and recovery; CRA reporting adds fixed external deadlines, named EU recipients, and an evidence trail. The gap is usually not a missing plan but the absence of the CRA-specific clocks, destinations, and artifacts bolted onto the plan you already run.
Reporting timelines
What starts on September 11, 2026 under the Cyber Resilience Act?
Manufacturers need a process for actively exploited vulnerabilities and severe security incidents. The operational gap is usually not awareness of the law; it is knowing who starts the 24-hour clock, what evidence gets attached, and where the 72-hour update comes from.
What belongs in a 24-hour CRA early-warning draft?
Keep it factual and incomplete where facts are incomplete: product, awareness timestamp, exploitation or severity basis, affected versions if known, first corrective action, and evidence links. A useful draft prevents guessing under time pressure.
What goes in the CRA 72-hour notification?
The 72-hour notification expands the early warning with what is now known: affected versions, the nature of the issue, and any corrective or mitigating measures taken or planned. It can still be incomplete. The gap is knowing where each of those facts lives and who can assemble them without a scramble.
When does the CRA 14-day final-report clock start?
For an actively exploited vulnerability, the final report is due no later than 14 days after a corrective or mitigating measure is available, so the clock is tied to your release rather than to the first alert. The gap is a clear definition of measure available and a release record that proves the date.
What is the one-month final report for a severe incident under the CRA?
For a severe incident, the final report follows within one month of the 72-hour notification, describing the incident, its severity and impact, and where known the root cause and mitigations. The gap is owning that one-month deliverable now, so it is not improvised after the immediate response has wound down.
Where do CRA incident reports go — CSIRT, ENISA, or both?
Notifications go to the CSIRT designated as coordinator in your country of main establishment and, in parallel, to ENISA, through the Single Reporting Platform that ENISA operates. The gap is usually knowing your designated CSIRT and having a tested account on the platform before the first real clock starts.
Evidence sources
How should a software team use SBOMs for CRA reporting readiness?
Treat the SBOM as one evidence source, not the whole process. The pack should say which product surfaces are covered, what is missing, where artifacts are stored, and who can retrieve them during the first reporting window.
What belongs in a CRA reporting evidence register?
A useful register lists where each reportable fact lives — affected versions, exploitation signals, SBOM, scan output, release records — and who can retrieve it during the first reporting window. The gap is rarely the data; it is a single place that says where the data is and who holds the key.
Drills
What should a CRA reporting tabletop drill prove?
The drill should prove that owners can find evidence, identify affected versions, draft a 24-hour early warning, expand it by 72 hours, and list final-report evidence without inventing facts.
What does a CRA reporting-readiness self-check cover before September 2026?
A self-check walks the path end to end: can owners be reached, can affected versions be named, can a 24-hour early warning be drafted, expanded by 72 hours, and closed with final-report evidence, all without inventing facts. The gap is usually finding the one step that only one person knows how to do.
Need the product-specific version?
VulnBrief turns your attested facts into a reporting runbook, notification drafts, evidence register, vulnerability-intake policy, and tabletop drill. Flat $3,999, one time.
Build my reporting pack →