security.txt: Damit Sicherheitsmeldungen an der richtigen Stelle ankommen

Nur 1,8 Prozent der deutschen Webseiten haben eine security.txt. Was die Datei leistet, wie sie aufgebaut ist und warum dafür zwei Zeilen Text genügen.

Stellen Sie sich vor, jemand entdeckt eine Schwachstelle auf Ihrer Website. Ein Sicherheitsforscher, ein aufmerksamer Kunde, vielleicht auch jemand, dem beim Ausfüllen eines Formulars etwas Merkwürdiges aufgefallen ist. Diese Person möchte Sie informieren – und findet auf Ihrer Seite ein Kontaktformular und eine info@-Adresse, die im Tagesgeschäft mitläuft.

In vielen Fällen passiert dann genau das: nichts. Der Hinweis landet zwischen Angebotsanfragen und Newslettern, wird als Spam aussortiert oder erreicht die richtige Person erst Wochen später. Für dieses Problem gibt es eine einfache Lösung.

Was ist security.txt?

security.txt ist eine schlichte Textdatei auf Ihrer Website, die beschreibt, an wen Sicherheitsmeldungen gehen sollen. Das Format ist in RFC 9116 beschrieben, und die Datei gehört an einen festgelegten Ort:

https://www.ihre-domain.de/.well-known/security.txt

Wer eine Schwachstelle melden möchte, muss also nicht raten und sich nicht durch das Impressum arbeiten, sondern weiß sofort, wohin.

Warum das für Unternehmen relevant ist

IT-Sicherheit wird meist mit Firewalls, Updates und Backups verbunden. Der Fall, dass trotzdem einmal etwas gefunden wird, bleibt dagegen häufig ungeregelt. Dabei entscheidet genau dieser Punkt darüber, ob Sie von einem Problem erfahren, bevor es jemand ausnutzt.

Eine feste Anlaufstelle sorgt dafür, dass Hinweise nicht im Sand verlaufen und schneller bei den Leuten landen, die etwas damit anfangen können. Gerade für Unternehmen mit Kundenportalen, Webanwendungen oder eigenen digitalen Produkten ist das ein kleiner Schritt mit spürbarer Wirkung.

Wie eine security.txt aussieht

Im einfachsten Fall sind es zwei Zeilen:

Contact: mailto:security@unternehmen.de
Expires: 2027-06-30T23:59:00.000Z

Beide Felder sind Pflicht. Contact ist der Weg, über den Meldungen eingehen sollen. Das muss keine E-Mail-Adresse sein: Erlaubt sind mailto:, tel: oder eine https://-URL – wer keine Adresse offen im Netz stehen haben will, verlinkt einfach auf eine Kontaktseite. Expires legt fest, wie lange die Angaben gültig sind; empfohlen ist ein Datum, das weniger als ein Jahr in der Zukunft liegt, damit niemand Jahre später an ein Postfach schreibt, das längst niemand mehr liest.

Optional lassen sich weitere Felder ergänzen, etwa eine Sicherheitsrichtlinie (Policy), ein Schlüssel für verschlüsselte Meldungen (Encryption) oder bevorzugte Sprachen (Preferred-Languages). Ausgeliefert werden muss die Datei über HTTPS und mit dem Content-Type text/plain.

Erstellt ist sie in wenigen Minuten

Über Dienste wie securitytxt.org lässt sich eine passende Datei erzeugen und anschließend im Verzeichnis /.well-known/ ablegen. Technisch war es das.

Der anspruchsvollere Teil ist der Prozess dahinter: Wer liest das Postfach? Wer bewertet eine Meldung fachlich? Und wer entscheidet, wie schnell reagiert wird? Ohne diese Zuständigkeiten bleibt auch eine korrekt hinterlegte Datei reine Dekoration – der RFC hält eine veraltete security.txt sogar ausdrücklich für schlechter als gar keine.

Warum das Thema gerade jetzt aufkommt

Das BSI hat am 6. August 2026 Messwerte aus dem Cyberdome-Projekt veröffentlicht: Nur 1,8 Prozent der Webseitenbetreiber in Deutschland stellen bislang eine security.txt bereit (Pressemitteilung des BSI).

Der Standard existiert seit Jahren, der Aufwand ist minimal – und trotzdem hat die große Mehrheit keine definierte Anlaufstelle für Sicherheitsmeldungen. Wer sie einrichtet, gehört also zu einer sehr kleinen Minderheit, bei einem Aufwand, der sich in Minuten misst.

Für Hersteller kommt ein regulatorischer Grund dazu

Wer Software oder vernetzte Produkte herstellt oder vertreibt, hat noch einen zweiten Anlass: den Cyber Resilience Act. Er verpflichtet Hersteller digitaler Produkte unter anderem dazu, eine Kontaktadresse für Schwachstellenmeldungen bereitzustellen. Ab dem 11. September 2026 gelten Meldepflichten für aktiv ausgenutzte Schwachstellen und schwere Sicherheitsvorfälle, ab Dezember 2027 gilt die Verordnung vollständig.

Eine security.txt ist dort nicht ausdrücklich vorgeschrieben. Sie ist aber die unkomplizierteste Art, so eine Kontaktadresse öffentlich und auffindbar zu machen – und damit ein sinnvoller erster Schritt, statt das Thema erst kurz vor der Frist anzugehen. Wer ausschließlich eine Website betreibt und keine digitalen Produkte in Verkehr bringt, ist vom CRA übrigens nicht betroffen. Ob ein konkretes Produkt unter die Verordnung fällt, ist am Ende eine juristische Frage – im Zweifel lohnt der Blick eines Fachanwalts.

Braucht das jede Website?

Das BSI und die Allianz für Cyber-Sicherheit rufen Webseitenbetreiber dazu auf, eine security.txt einzurichten – ohne Abstufung nach Unternehmensgröße oder Art der Website.

Die praktische Frage ist ohnehin eine andere: Wenn heute jemand eine Schwachstelle bei Ihnen findet – wüsste diese Person, an wen sie sich wendet? Und wüssten Sie, was dann passiert?

Unterm Strich

security.txt macht Ihre Website nicht sicherer und ersetzt kein Sicherheitskonzept. Sie sorgt lediglich dafür, dass Sie es mitbekommen, wenn etwas nicht stimmt. Das klingt unspektakulär, ist aber genau der Punkt, an dem viele Sicherheitskonzepte in der Praxis scheitern.

Die security.txt von StahlTech liegt unter www.stahltechsolutions.de/.well-known/security.txt.

Falls Sie keine feste Anlaufstelle für Sicherheitsmeldungen haben oder sich um Hosting, Absicherung und Sicherheitsprozesse generell nicht selbst kümmern möchten: Schreiben Sie mir. Für Ihre Anforderungen findet sich das passende Angebot.