GET READY FOR EU CRA VULNERABILITY REPORTING EMERGENCY
CRA Vulnerability Reporting Template Pack
On 11 September 2026, the CRA vulnerability reporting clock starts. The clock runs from awareness, and there is no grace period. Can your team file within 24 hours?
Most of the Cyber Resilience Act arrives in 2027. One part does not. From 11 September 2026, if you make a product with digital elements available on the EU market, you must report an actively exploited vulnerability or a severe incident simultaneously to ENISA and the coordinating CSIRT within 24 hours — and that duty reaches products already on the market. This express kit gets you ready before the clock starts.
Built for software and hardware manufacturers, and the CTOs and security leads who’ll be holding the pager when a report is due. Fast to deploy — an assessment, a strategy session, and a ready-to-use execution pack.
What Changes on 11 September 2026?
The Cyber Resilience Act (CRA) introduces mandatory, strict-liability cybersecurity rules for software and hardware products placed on the EU market. Article 11 takes effect first, imposing immediate notification duties on software vendors:
- The 24-hour clock: You must formally notify the European Union Agency for Cybersecurity (ENISA) and designated national CSIRTs within 24 hours of becoming aware of an actively exploited vulnerability or severe incident.
- Mandatory Coordinated Vulnerability Disclosure (CVD): You are legally required to maintain a public, structured channel (such as an RFC 9116
security.txtfile) allowing security researchers to report flaws. - Enterprise procurement screening: European buyers are actively freezing vendor contracts that cannot produce a documented CRA incident response workflow and signed legal proof of CRA readiness.
How It Works: Two Parts
Part 1: Find your gaps
You complete two structured self-assessments and walk the findings through a 30-minute strategy session:
- Vulnerability Management Gap Audit: Line-by-line evaluation of your update mechanism, patch-distribution channels and vulnerability-intake channels against the CRA’s vulnerability-handling requirements (Annex I Part II), the manufacturer’s diligence and support-period duties (Article 13), and the reporting duty (Article 14).
- SBOM Review: An evaluation of your open-source and third-party component tracking, built around one hard question: if a critical vulnerability dropped in a component today, could you identify the affected products fast enough to meet the reporting clock?
- 30-Minute CTO Strategy Session: A direct debrief with an EU tech legal architect to review your findings, sequence the fixes, and confirm how the execution pack closes each gap.
Part 2: Deploy the execution pack
Five ready-to-use technical and legal assets:
Developer Security and Patching Ticket Pack: Nine Markdown tickets ready to import into Jira or GitHub, covering SBOM generation, patch-distribution SLAs, secure update distribution and the Article 14 reporting hook — each mapped to a specific CRA obligation.
ENISA 24-Hour & 72-Hour Incident Response SOP: A step-by-step procedure defining roles, triage triggers and statutory escalation paths for notifying ENISA and the national CSIRT within 24 hours (early warning) and 72 hours (full notification), through ENISA’s Single Reporting Platform.
Pre-Formatted ENISA & CSIRT Intake Forms: Fill-in-the-blank early-warning, notification and final-report templates, with a standing-information block you complete once so your team fills only the event-specific fields while the clock runs.
CVD Policy & security.txt Pack: Ready-to-publish coordinated vulnerability disclosure policy text (with safe-harbour clause) and a repository-ready RFC 9116 security.txt file, satisfying the CRA’s disclosure-policy and reporting-contact requirements (Annex I Part II, points 5–6).
Why This Is the Right Basis, Not a Generic Checklist
The CRA’s vulnerability-handling and SBOM obligations live in Annex I Part II; the manufacturer’s diligence and support-period duties in Article 13; the reporting cadence in Article 14.
Every asset in this kit is built to those provisions, with the relevant legal text quoted in each so your engineers and your lawyer can see exactly what’s being satisfied. Nothing here is grounded in the wrong article, that’s the difference between a kit that survives scrutiny and one that doesn’t.
The September CRA Deadline, Plainly
11 September 2026 is not the full CRA. It’s the reporting obligation — the 24-hour early warning, the 72-hour notification, the final report — landing 15 months ahead of everything else, and applying to products you’ve already shipped.
A team that has rehearsed the procedure files calmly. A team that hasn’t spends the first of its 24 hours working out who’s even allowed to click submit. This kit is the difference between those two teams.
Who This Is For
- Software and hardware manufacturers placing connected products on the EU market.
- CTOs and heads of engineering who own incident response.
- Security leads standing up a coordinated vulnerability disclosure programme.
- Companies whose products are already shipped and in the field — the reporting duty reaches you too.
- Teams who’d rather rehearse the 24-hour procedure now than improvise it during a live exploit.
What’s Included in the Price
Includes twelve months of updates as ENISA’s Single Reporting Platform, the Commission guidance and the harmonised standards develop.
A specialist firm building an incident-response procedure, CVD framework and reporting readiness from scratch will typically run €6,000–15,000. The kit is the same readiness at a fraction of the cost, with a strategy session included so you leave knowing what to do first.
If you need more input from our team, let’s discuss – go ahead and book a scoping call.
What this pack is not (Important)
This is not legal advice, and it’s not a certificate of compliance. It’s an assessment-and-execution kit that your security team and a qualified lawyer should adapt to your platform before you rely on it. The assessments are self-assessments; the strategy session reviews your findings, it doesn’t independently verify your systems.
Submission is always made through ENISA’s official Single Reporting Platform, whose own fields govern. The intake forms prepare your content but don’t replace the submission.
FAQ about CRA Vulnerability Reporting
When does this obligation start, and why before the rest of the CRA?
The reporting duty applies from 11 September 2026, twenty-one months after the Act entered into force and well ahead of full application on 11 December 2027. Most of the Cyber Resilience Act — CE marking, conformity assessment, the technical file — arrives in December 2027. The reporting obligation is carved out early and runs on its own clock, which is why you need to be ready for it separately and sooner.
Who does CRA vulnerability reporting obligation apply to?
Manufacturers of products with digital elements made available on the EU market. Critically, these obligations apply to all products already on the EU market, not only new products placed after the deadline. If you have a connected product in the field, this reaches it. Open-source software stewards report too, where a steward is involved in developing the affected product.
What actually has to be reported?
Two things, and only two: actively exploited vulnerabilities and severe incidents affecting the security of your product. Vulnerabilities you find and fix before exploitation are not reportable — they are managed through your ordinary vulnerability-handling process. The trigger is evidence of exploitation in the wild, not the mere existence of a flaw.
What are the actual CRA Vulnerability Reporting deadlines?
It is a staged chain, not a single filing. For an actively exploited vulnerability: an early warning within 24 hours of becoming aware, a full notification within 72 hours, and a final report no later than 14 days after a corrective measure is available. For a severe incident, the final report is due within one month of the 72-hour notification instead. The early-warning and notification steps are identical for both; only the final-report window differs.
When does the clock start?
From awareness, and nothing pauses it. The clock starts from when the manufacturer becomes aware of active exploitation — not from when the vulnerability is confirmed or fully analysed. There is no assessment grace period; the clock runs from first credible awareness. This is the trap: the duty to notify in 24 hours is not a duty to have finished the analysis in 24 hours.
Do I have to have the whole investigation done in 24 hours?
No. The 24-hour obligation is to notify, not to have completed the analysis. The early warning only needs to indicate active exploitation and the Member States where your product is available. The detailed technical analysis goes in the 72-hour notification — the regulation is designed so you notify first and investigate in parallel. Neither stream requires CVE IDs or CVSS scores at the early-warning stage.
Who do I report to — is it 27 separate filings?
No. One filing, one platform. You notify the CSIRT designated as coordinator and ENISA simultaneously, through the single reporting platform established under Article 16. You report once via ENISA’s Single Reporting Platform; the receiving CSIRT then disseminates to the rest of the CSIRT network.
You do not file 27 times. Your coordinating CSIRT follows your main establishment in the Union, or your authorised representative’s if you are not established in the EU.
Does reporting to ENISA replace telling my users?
No — they are separate and concurrent duties. Notifying affected users under Article 14(4) is separate from and in addition to reporting to ENISA. Reporting to ENISA does not substitute for notifying users, and notifying users does not substitute for reporting to ENISA.
When a vulnerability is actively exploited, you must notify affected users without undue delay, with information sufficient for them to take protective action, including mitigating measures available before a patch is released.
What if the reporting platform is down when my clock is running?
The outage does not pause your duty. Tooling problems do not remove the 24-hour duty. Keep a time-stamped record of the outage, your attempted submission, and any alternative contact used. This is exactly why readiness means having the process and the evidence trail in place before an incident, not improvising during one.
What does it cost to get CRA vulnerability reporting wrong?
There is a genuine discrepancy in how sources characterise the tier, so treat this as the one figure to confirm against the Official Journal before relying on it. One reading places Article 14 breaches in the Tier 2 band: up to €10 million or 2% of worldwide annual turnover, whichever is higher. Another places serious breaches in the higher band of up to €15 million or 2.5% of global turnover. The safe planning assumption is the higher ceiling. Either way, market surveillance authorities can also order corrective action or force a product off the market.
What does “ready” actually look like?
It is a workflow problem, not a paperwork problem. This is a detection-to-disclosure workflow, and the ones who succeed will have practised it before September. Concretely, the recurring readiness gaps are: no designated reporter and no escalation path — who actually files, who is the backup when they are away, and who has the authority to decide a signal qualifies as “actively exploited.”
Note also that ENISA has said no platform API will be provided at this stage, so plan for submission through the platform itself rather than automation from your own tooling.