← Back to news 12.10.2026

Whoever finds a flaw needs an address

A security researcher finds a vulnerability in your product and looks for a contact. She finds the legal notice, info@ and a chatbot. From December 2027, the Cyber Resilience Act requires a contact address for vulnerability reports and a policy on coordinated disclosure. The security.txt per RFC 9116 is where researchers look first, and it goes stale silently.

A security researcher finds a vulnerability in a manufacturer's customer portal. She wants to report it before someone else exploits it. She looks for a contact and finds the legal notice, an info@ address, a contact form that promises a reply within five to seven working days, and a chatbot.

She writes to info@. The mail lands in sales, is filed as advertising and deleted after three weeks. The researcher hears nothing, waits and publishes after ninety days. The manufacturer learns about its vulnerability from the trade press.

What the Cyber Resilience Act requires

Article 14 of the Cyber Resilience Act has applied since 11 September 2026. A manufacturer reports any actively exploited vulnerability in its product "that it becomes aware of" to the competent CSIRT and to ENISA, with an early warning within 24 hours. What that demands in preparation was covered in Why the 24-hour reporting obligation forces preparation. The clock starts with awareness. Without a reporting channel, you learn later and from worse sources.

From 11 December 2027, the vulnerability handling requirements in Annex I Part II are added. Point 5 requires the manufacturer to

"put in place and enforce a policy on coordinated vulnerability disclosure"

and point 6 to facilitate the sharing of information about vulnerabilities, "including by providing a contact address for the reporting of the vulnerabilities discovered in the product with digital elements". Article 13(17) adds a single point of contact that is "easily identifiable by the users" and whose means of communication shall not be limited to automated tools. A chatbot alone is therefore not enough.

What the CRA does not prescribe: how quickly the manufacturer has to answer a researcher. The response times towards the reporter are set by the manufacturer in its own policy. Whoever states them has to meet them.

Where researchers look first

Since 2022, there has been a standard for the contact address: RFC 9116 describes a text file at /.well-known/security.txt on your own domain. Two fields are mandatory. Contact names the reporting channel, as an email address, phone number or web page, and according to the RFC "MUST always be present". Expires states the date after which the information is considered stale, exactly once. The RFC recommends setting it less than a year into the future.

The file takes ten minutes to write. The problem is what happens afterwards:

It disappears. During the website relaunch, the agency moves to a new system. The .well-known folder does not come along, and nobody notices.
It expires. The Expires date was a good idea a year ago. Today the file is stale under the RFC, and no monitoring fires because the page still answers with 200.
It points nowhere. Contact names the address of the colleague who set it up two years ago and has since left.

In all three cases, the contact address exists on paper, but not for the researcher.

How isidaten handles this

In the vulnerability disclosure module, the disclosure policy is built from a template library and passes through draft, review and approval before it is published. isidaten generates the security.txt and, by default, fetches it from the registered domains every morning: if it is missing, if Contact or the policy address deviates, or if Expires has passed, the responsible people are notified, once per change of state rather than every day. Reports via the public form become a case file whose deadlines for acknowledgement, initial assessment and disclosure are fixed from the policy on receipt. For an anonymous report, personal details are discarded, even if they were entered in the form.