← Zurück zu News 12.10.2026

Wer eine Lücke findet, braucht eine Adresse

Eine Sicherheitsforscherin findet eine Schwachstelle in Ihrem Produkt und sucht einen Kontakt. Sie findet das Impressum, info@ und einen Chatbot. Der Cyber Resilience Act verlangt ab Dezember 2027 eine Kontaktadresse für Schwachstellenmeldungen und ein Konzept zur koordinierten Offenlegung. Die security.txt nach RFC 9116 ist der Ort, an dem Forscher zuerst nachsehen, und sie veraltet still.

Eine Sicherheitsforscherin findet eine Schwachstelle im Kundenportal eines Herstellers. Sie will sie melden, bevor jemand anderes sie ausnutzt. Sie sucht einen Kontakt und findet das Impressum, eine Adresse info@, ein Kontaktformular mit dem Hinweis auf fünf bis sieben Werktage Bearbeitungszeit und einen Chatbot.

Sie schreibt an info@. Die Mail landet im Vertrieb, wird als Werbung einsortiert und nach drei Wochen gelöscht. Die Forscherin hört nichts, wartet und veröffentlicht nach neunzig Tagen. Der Hersteller erfährt von seiner Schwachstelle aus der Fachpresse.

Was der Cyber Resilience Act verlangt

Seit dem 11. September 2026 gilt Artikel 14 des Cyber Resilience Act. Ein Hersteller meldet jede aktiv ausgenutzte Schwachstelle in seinem Produkt, „von der er Kenntnis erlangt“, dem zuständigen CSIRT und der ENISA, mit einer Frühwarnung innerhalb von 24 Stunden. Was das an Vorbereitung verlangt, stand in Warum die 24-Stunden-Meldepflicht Vorbereitung erzwingt. Die Frist beginnt mit der Kenntnis. Wer keinen Meldeweg hat, erfährt später und von schlechteren Quellen.

Ab dem 11. Dezember 2027 kommen die Anforderungen an die Behandlung von Schwachstellen in Anhang I Teil II hinzu. Nummer 5 verlangt, der Hersteller müsse

„eine Strategie für die koordinierte Offenlegung von Schwachstellen aufstellen und umsetzen“

und Nummer 6, er müsse den Austausch von Informationen über Schwachstellen erleichtern, „und dazu u. a. eine Kontaktadresse für die Meldung der in dem Produkt mit digitalen Elementen entdeckten Schwachstellen angeben“. Artikel 13 Absatz 17 ergänzt eine zentrale Anlaufstelle, die „von den Nutzern leicht ermittelt werden kann“ und deren Kommunikationsmittel „nicht auf automatisierte Instrumente beschränkt werden dürfen“. Der Chatbot allein reicht also nicht.

Was der CRA nicht vorgibt: wie schnell der Hersteller einer Forscherin antworten muss. Die Reaktionszeiten gegenüber dem Melder legt der Hersteller in seiner Richtlinie selbst fest. Wer sie nennt, muss sie einhalten.

Wo Forscher zuerst nachsehen

Für die Kontaktadresse gibt es seit 2022 einen Standard: RFC 9116 beschreibt eine Textdatei unter /.well-known/security.txt auf der eigenen Domain. Zwei Felder sind Pflicht. Contact nennt den Meldeweg, als E-Mail-Adresse, Telefonnummer oder Webseite, und muss laut RFC „always be present“. Expires nennt das Datum, nach dem die Angaben als veraltet gelten, genau einmal. Das RFC empfiehlt, es weniger als ein Jahr in die Zukunft zu legen.

Die Datei ist in zehn Minuten geschrieben. Das Problem ist, was danach passiert:

  • Sie verschwindet. Beim Relaunch der Website zieht die Agentur auf ein neues System um. Der Ordner .well-known kommt nicht mit, niemand merkt es.
  • Sie läuft ab. Das Expires-Datum war vor einem Jahr eine gute Idee. Heute ist die Datei nach RFC nicht mehr zu verwenden, und kein Monitoring schlägt an, weil die Seite weiter mit 200 antwortet.
  • Sie zeigt ins Leere. Contact nennt die Adresse des Kollegen, der das Thema vor zwei Jahren aufgebaut hat und inzwischen gegangen ist.

In allen drei Fällen gibt es die Kontaktadresse auf dem Papier, aber nicht für die Forscherin.

Wie isidaten das abbildet

In der Schwachstellen-Meldestelle entsteht die Offenlegungsrichtlinie aus einer Vorlagenbibliothek und durchläuft Entwurf, Prüfung und Freigabe, bevor sie veröffentlicht wird. isidaten erzeugt die security.txt und ruft sie standardmäßig jeden Morgen auf den hinterlegten Domains ab: Fehlt sie, weicht Contact oder die Richtlinienadresse ab, oder ist Expires überschritten, werden die Verantwortlichen benachrichtigt, einmal je Zustandswechsel statt jeden Tag. Meldungen über das öffentliche Formular werden zur Fallakte, deren Fristen für Eingangsbestätigung, erste Einschätzung und Veröffentlichung am Eingang aus der Richtlinie festgeschrieben werden. Bei einer anonymen Meldung werden personenbezogene Angaben verworfen, auch wenn sie im Formular standen.

Die Prüffrage

Rufen Sie heute https://<Ihre Domain>/.well-known/security.txt auf. Gibt es die Datei, wann läuft sie ab, und liest jemand das Postfach, das darin steht?

Wenn nicht, erfährt die Forscherin das vor Ihnen.

Quellen

Verordnung (EU) 2024/2847 (Cyber Resilience Act), Artikel 13 Absatz 17, Artikel 14, Artikel 71 Absatz 2 und Anhang I Teil II Nummer 5 und 6.

RFC 9116: A File Format to Aid in Security Vulnerability Disclosure, Abschnitte 2.5.3, 2.5.5 und 3.

Passende Lösung isidaten für Cyber Resilience Act

Fragen zu dieser Neuerung?

Sprechen Sie mit uns – wir zeigen Ihnen die Funktion gern in einer Demo.