Security vulnerabilities are often discovered by outsiders: researchers, customers, or professionals who stumble on a flaw by chance. Without a defined channel, such findings end up in the spam folder, are ignored, or are made public immediately, before an update exists. CVD creates a reliable process that protects finders, vendors, and users alike. The formerly common term responsible disclosure means essentially the same thing.
How does coordinated disclosure work?
- Report: The finder reports the vulnerability confidentially to the vendor's or operator's published point of contact.
- Acknowledgment and review: The recipient confirms receipt, reviews the finding, and keeps the reporter informed.
- Remediation: The vendor develops an update or a workaround.
- Publication: Both sides publish in a coordinated way, usually with a CVE identifier and a security advisory, and credit the finder on request.
The international standards ISO/IEC 29147 and ISO/IEC 30111 describe this path: 29147 covers external disclosure, 30111 the internal handling of reported vulnerabilities.
CVD in the EU and in Austria
In Art. 12, the NIS2 Directive requires each member state to designate a CSIRT as coordinator for coordinated disclosure. It acts as a trusted intermediary, negotiates disclosure timelines, and must enable anonymous reports on request. At the same time, ENISA operates a European vulnerability database, the EUVD. In Austria, CERT.at accepts vulnerability reports and mediates between the reporter and the vendor when needed; according to CERT.at, coordinated disclosure is one of the tasks of the national CSIRT under the NISG 2026 (Austrian Network and Information Systems Security Act 2026). Under the Cyber Resilience Act, manufacturers of connected products also need their own coordinated disclosure policy.
In practice for SMEs and municipalities
Even organizations that do not make software operate websites, portals, or online forms where someone may find a vulnerability. The following makes sense:
- A reporting address that is actually read, for example a dedicated mailbox for security reports.
- A security.txt file at
/.well-known/security.txt, as described in RFC 9116. Mandatory fields are a contact and an expiry date. - A short policy that explains how to report, how quickly you respond, and that good-faith reports are welcome.
- An internal process that defines who assesses a report, who involves the service provider, and who decides whether a security incident has occurred.
Risks and typical mistakes
- Reports go nowhere: If there is no contact, finders turn to the public or give up.
- Threats instead of thanks: If you respond to a good-faith report with legal action, you may be the last to hear about the next vulnerability.
- No end point: Without a deadline and feedback, a vulnerability remains open unnecessarily long.
How TOMORIS relates
With the free security.txt check in the TOMORIS Toolbox, you can check your file against RFC 9116 and create a new one directly in the browser. EXPERTS Cyber Security supports handling reported vulnerabilities by impact and urgency.