Vulnerability disclosure for the Cyber Resilience Act
A public channel for security researchers to report what they find, and a register for everything your own team finds itself — triaged, deduplicated, and kept as evidence in one place.
What the Cyber Resilience Act requires
The Cyber Resilience Act requires manufacturers of products with digital elements to run a coordinated vulnerability disclosure policy and a contact point, so a security researcher who finds a flaw has somewhere credible to send it. Reporting duties for actively exploited vulnerabilities phase in from 11 September 2026 and apply across the EU, whatever the manufacturer's size.
Once an organisation becomes aware that a vulnerability in its product is being actively exploited, Article 14 sets out a sequence of notifications to ENISA and the relevant national CSIRT: an early warning, a fuller notification shortly after, and a final report once the picture is complete. Each stage asks for more than the last — the early warning is deliberately minimal, because at that point a manufacturer often knows only that exploitation is happening.
Most vulnerabilities are never reported in from outside. A manufacturer finds the majority itself, through a penetration test, an upstream dependency advisory, or a customer raising something odd — and the reporting duty applies the same way regardless of how the manufacturer found out.
The deadlines
The Cyber Resilience Act sets three deadlines for an actively exploited vulnerability — and not all of them run from the same starting point.
- 24 hoursEarly warning
An early warning to ENISA and the relevant national CSIRT, due within 24 hours of becoming aware the vulnerability is being actively exploited.
- 72 hoursNotification
A fuller notification adding your assessment and any mitigations already in place, due within 72 hours of the same moment.
- 14 daysFinal report
A final report covering root cause and remediation, due within 14 days after a corrective or mitigating measure is available — a later point than the one the first two deadlines run from.
How it works
- Set up your disclosure channel
Answer a short questionnaire and Klaruna publishes a bilingual CVD policy page and generates your security.txt file. You place the file on your own domain, and a placement check confirms it actually resolves there before your contact point counts as live.
- Reports arrive, or you log your own
A researcher submits anonymously or with attribution and gets a case key to follow up without an account. Vulnerabilities you find yourselves — a penetration test, an upstream advisory, a customer report — go into the same register.
- Your team triages
Promote a report into the register, link a second report of the same bug to one record, or decline one that doesn't hold up. Every decision lands on the vulnerability's own timeline.
- Evidence stays intact
Proof-of-concept code, crash dumps and packet captures are kept byte for byte and encrypted at rest, not re-encoded the way ordinary uploads are processed elsewhere — so the file that demonstrates the bug still demonstrates it.
- Keep a record you can show
Every intake, promotion, link and decline is written to an append-only audit trail, and the register can be exported as CSV whenever you need to show your work.
What's included
Your own disclosure channel
A public CVD policy page and a generated security.txt file, in English, Polish and Romanian, with a placement check that confirms the file is live on your domain before anything shows as compliant.
Anonymous or credited reports
A researcher chooses their own level of attribution and gets a case key to read replies and add detail later, without creating an account.
One register, every source
Reports from the public channel sit beside vulnerabilities your own team found, so there is one record rather than a register and a spreadsheet.
Triage without losing the thread
Promote a report to the register, link duplicates to a single record, or decline one with a recorded reason. A reporter never learns their report was linked to someone else's.
Attachments as the researcher sent them
Proof-of-concept code, crash dumps and packet captures are stored byte for byte and encrypted, not re-encoded, so the evidence a vulnerability needs is never damaged by the processing that keeps ordinary files safe. Attachments are served only through an authorised route, never from a public link.
A register your team can show
Filter the register by status, and export it as CSV whenever you need to show your work.
Data and security
Everything runs in EU data centres: the application, the database, file storage, backups and email delivery.
Report and vulnerability content is encrypted at rest, and every action, from intake through triage, is written to an append-only audit trail.
Attachments are the one place this product deliberately differs from the rest of Klaruna: a proof of concept is evidence, not an ordinary upload, so it is stored exactly as received rather than re-encoded, and served with headers that stop a browser from running it.
Where it applies
Applies across the EU.