Context card
Receiving vulnerability reports under BSI TR-03183-3: report, notification, advisory
What does BSI TR-03183-3 expect a manufacturer to have in place before the first vulnerability report arrives?
The short answer
A public, findable way in and a process behind it: a signed security.txt under /.well-known/, a PSIRT and a CSIRT with functional mailboxes and OpenPGP keys, an anonymous web form, a central web page for vulnerability reports and a published CVD policy with response times. The guideline also separates three things that are often mixed up: the confidential vulnerability report a manufacturer receives, the non-public notification it sends to a CSIRT or ENISA, and the public security advisory for users.
For: Product security teams (PSIRT), web and IT teams, compliance managers and technical writers responsible for security information
Key points
- Three terms, three directions: a vulnerability report comes in (confidential, often with a proof of concept), a vulnerability notification goes to a national CSIRT or ENISA (non-public, tentative CVSS score), a security advisory goes to users (public, preferably in CSAF).
- security.txt per RFC 9116 under /.well-known/, over HTTPS, OpenPGP-signed, with PSIRT, CSIRT and web page as contacts, English among the preferred languages, an expiry date at most a year ahead, checked at least quarterly.
- Two roles, PSIRT for products and CSIRT for the manufacturer's infrastructure, held by different people unless the manufacturer is a microenterprise; reports must at least be receivable and processable in English.
- The CVD policy promises a non-automated first response within five working days and detailed feedback within ten, and public disclosure of validated and verified vulnerabilities within 90 days, extendable once by 90 days with the national CSIRT, at least in the European Vulnerability Database.
- These are requirements for conforming to the guideline; the CRA's own reporting obligations under Article 14 apply in parallel and are not replaced by them.
The context
Why the intake comes first
Part 3 of BSI TR-03183 starts from a plain observation: vulnerabilities cannot be avoided, and few are found before a product reaches the market. Every coordinated vulnerability disclosure (CVD) process therefore starts with someone being able to report one. The guideline sets minimum requirements for that intake and asks manufacturers to react positively to reports and not to threaten legal action where no criminal intent is apparent.
Report, notification, advisory
| Direction | Audience | Content | |
|---|---|---|---|
| Vulnerability report | to the manufacturer, from researchers or CSIRTs | confidential | identification, exploitation, reproduction, often a proof of concept |
| Vulnerability notification | from the manufacturer to a national CSIRT or ENISA | non-public | product concerned, initial assessment, tentative CVSS base score |
| Security advisory | from the manufacturer to all users | public, preferably CSAF | reviewed CVSS score, remediation and mitigation |
Keeping the three apart matters in documentation: a release note or a public page is never the place for the details of an incoming report.
The way in
- Website: security information is public, without login or paywall, in a language users and market surveillance authorities understand.
- security.txt (RFC 9116): at
/.well-known/security.txt, over HTTPS, plain text, with canonical URI, contacts (PSIRT mailbox first, CSIRT mailbox second, then the web page for reports), OpenPGP keys, preferred languages including English, the CVD policy, optionally the CSAF provider metadata, an expiry date and an OpenPGP signature. It is checked at least quarterly and must stay reachable for crawlers. - Roles: a PSIRT for the products and a CSIRT for the infrastructure, with functional mailboxes such as psirt@ and csirt@ and dedicated keys.
- Web form and web page: an anonymous web form without third-party components or tracking, and a central page for vulnerability reports reachable from the home page without JavaScript.
The CVD policy
The published policy states the manufacturer's assurances and the rules for both sides: a first, non-automated response within five working days, detailed feedback within ten, a clear statement that anonymous reports may be processed only in part, public disclosure of validated and verified vulnerabilities within 90 days (extendable once by 90 days in consultation with the corresponding national CSIRT), disclosure at least in the European Vulnerability Database, and the conditions under which a CVD case is closed.
What the guideline does not replace
These MUSTs are requirements for conforming to the guideline. The Cyber Resilience Act adds its own obligations — for instance, reporting actively exploited vulnerabilities and severe incidents through ENISA's single reporting platform under Article 14 — which apply in parallel. A working intake is a precondition for vulnerability management and vulnerability disclosure, not proof of CRA compliance.
Questions readers ask next
- Is a security.txt required by the CRA?
- The CRA requires a contact address for reporting vulnerabilities and a CVD policy; it does not name security.txt. TR-03183-3 makes a signed security.txt per RFC 9116 a requirement for conforming to the guideline.
- Can a manufacturer refuse anonymous reports?
- Not under the guideline: an easy-to-find anonymous option is required, preferably the web form. The manufacturer must state clearly that anonymous reports may only be processed in part, because follow-up questions are impossible.
Sources
- Technical Guideline TR-03183-3: Cyber Resilience Requirements for Manufacturers and Products, Part 3: Vulnerability Reports and Notifications, version 1.0.0 — Federal Office for Information Security (BSI), August 20, 2025
- RFC 9116: A File Format to Aid in Security Vulnerability Disclosure — IETF, April 1, 2022
- Regulation (EU) 2024/2847 (Cyber Resilience Act) — Official Journal of the European Union, November 20, 2024
- BSI TR-03183: overview of the four parts — CyberKlartext, August 13, 2026
Review log and changes
Every context card is checked against its sources before it is published, and again whenever it changes; the date under the byline is the last review. Corrections (something was wrong) and additions (something was missing) are logged below with date and time (Berlin time). Typos, formatting and link fixes are not listed.
Reviewed
No corrections or additions since publication.