security.txt für KMU: Der Sicherheitskontakt, den fast niemand hat

Anfang August 2026 zeigte eine Auswertung: Gerade einmal 1,8 % der deutschen Websites hinterlegen eine standardisierte security.txt-Datei, über die Sicherheitsforscher Schwachstellen melden können. Für die überwiegende Mehrheit der Unternehmen bedeutet das: Wer eine Lücke in ihrer Website, ihrem Kundenportal oder ihrem Webshop findet, hat keinen offiziellen Weg, das diskret zu melden – und greift im Zweifel zu Twitter/X, LinkedIn oder direkt zur Presse. Für KMU in Dresden und Sachsen ist das eine leicht zu schließende Lücke mit überschaubarem Aufwand und spürbarem Nutzen.

Was ist security.txt überhaupt?

security.txt ist ein 2022 als RFC 9116 standardisiertes Textformat, das Unternehmen unter /.well-known/security.txt auf ihrer Domain hinterlegen. Die Datei beantwortet eine einzige, aber wichtige Frage: “Wie erreiche ich jemanden bei euch, wenn ich eine Sicherheitslücke gefunden habe?” Sie enthält typischerweise:

• Eine Kontakt-E-Mail-Adresse oder einen Link zu einem Meldeformular
• Eine Angabe, wie lange die Angabe gültig ist (Expires)
• Optional einen Link zu einer Responsible-Disclosure-Policy
• Optional einen PGP-Key für verschlüsselte Meldungen
• Optional Angaben zu Bug-Bounty-Programmen, falls vorhanden

Das Format ist bewusst simpel gehalten – ein Klartext-File, keine komplexe Infrastruktur, kein Portal, keine Software.

Warum das für KMU relevant ist, nicht nur für Konzerne

security.txt wird oft als Thema für große Tech-Unternehmen mit eigenem Security-Team abgetan. Das greift zu kurz. Gerade kleinere Unternehmen haben:

• Keinen etablierten Meldeweg: Ein Sicherheitsforscher, der eine Lücke im Kundenlogin oder in der Buchungsstrecke eines Handwerksbetriebs findet, weiß oft nicht, wen er kontaktieren soll – die allgemeine info@-Adresse landet häufig im Vertriebsposteingang und wird ignoriert oder zu spät gelesen.
• Ein reales Reputationsrisiko: Wird eine Lücke nicht gemeldet, sondern öffentlich auf Social Media gepostet, weil kein anderer Weg gefunden wurde, ist der Schaden meist deutlich größer als bei einer stillen, koordinierten Meldung.
• Eine wachsende regulatorische Erwartung: Im Rahmen von NIS2 und allgemeinen Sorgfaltspflichten wird zunehmend erwartet, dass Unternehmen einen dokumentierten Prozess für den Umgang mit gemeldeten Schwachstellen haben. Eine security.txt ist dafür ein einfacher, sichtbarer erster Baustein.

Was ohne security.txt konkret passiert

Ohne definierten Meldeweg bleibt Sicherheitsforschern und aufmerksamen Nutzern nur wenig: die allgemeine Kontaktadresse, ein Kontaktformular, das für Support gedacht ist, oder eben der öffentliche Weg über soziale Netzwerke. Viele verantwortungsvolle Melder versuchen es zunächst intern – wenn nach mehreren Tagen keine Reaktion kommt, wird aus einer stillen Meldung schnell ein öffentlicher Thread mit Screenshots. Für ein KMU bedeutet das nicht nur Imageschaden, sondern oft auch, dass die Lücke bereits öffentlich beschrieben ist, bevor sie geschlossen werden konnte – ein Zeitfenster, das auch andere Angreifer nutzen können.

Praxis: security.txt in wenigen Schritten einrichten

1. Zuständigkeit klären

Bevor die Datei erstellt wird, muss feststehen: Wer liest die eingehenden Meldungen tatsächlich, und wie schnell? Eine security.txt, die auf eine nie gelesene Adresse verweist, ist schlimmer als keine – sie täuscht einen funktionierenden Prozess nur vor. Sinnvoll ist eine dedizierte Adresse wie security@ihredomain.de, die auf eine reale Person oder ein kleines Team im Unternehmen bzw. beim IT-Dienstleister geroutet wird.

2. Inhalt der Datei festlegen

Eine minimale, aber wirksame security.txt enthält mindestens:

Contact: mailto:security@ihredomain.de
Expires: 2027-08-07T00:00:00.000Z
Preferred-Languages: de, en

Wer mehr Struktur will, ergänzt eine Policy-URL mit klaren Regeln: Welche Systeme dürfen getestet werden, welche nicht, wie lange hat das Unternehmen Zeit zur Behebung, gibt es eine Belohnung.

3. Datei an der richtigen Stelle ablegen

Die Datei gehört exakt nach https://ihredomain.de/.well-known/security.txt. Viele Content-Management-Systeme und Static-Site-Generatoren erlauben es, Dateien direkt in den .well-known-Ordner des Web-Root zu legen – bei den meisten Webservern (Nginx, Apache) reicht das Kopieren einer einzelnen Textdatei.

4. Intern einen Mini-Prozess definieren

Es braucht keinen vollständigen Incident-Response-Plan, aber mindestens: Wer prüft eingehende Meldungen, wer entscheidet über Priorität, wer informiert den Melder über den Stand. Schon eine einfache Checkliste verhindert, dass eine Meldung im Postfach untergeht.

5. Datum regelmäßig aktualisieren

Das Expires-Feld sollte nicht zu weit in der Zukunft liegen und muss regelmäßig verlängert werden – sonst gilt die Datei als veraltet, und manche automatisierten Scanner von Sicherheitsforschern ignorieren sie dann.

Kein Ersatz für aktives Schwachstellenmanagement

security.txt ersetzt keinen Schwachstellenscanner, kein Patch-Management und kein IT-Sicherheitsaudit – sie ist der letzte, aber wichtige Baustein: der Kanal, über den externe Hinweise überhaupt erst bei der richtigen Person ankommen. Wer ohnehin bereits an Themen wie Web Application Firewall, sicherer Webserver-Konfiguration oder allgemeiner IT-Sicherheit arbeitet, sollte security.txt als kleinen, schnell erledigten Zusatzschritt mit einplanen.

Sie möchten für Ihre Website, Ihren Webshop oder Ihr Kundenportal einen sauberen Meldeweg für Sicherheitslücken einrichten, wissen aber nicht, wie das technisch und organisatorisch am besten funktioniert? Rexoma unterstützt KMU in Dresden und Sachsen dabei, security.txt korrekt einzurichten und in einen funktionierenden internen Prozess einzubetten.

FAQ

Ist security.txt gesetzlich vorgeschrieben? Nein, es handelt sich um einen freiwilligen Standard (RFC 9116). Im Kontext von NIS2 und allgemeinen Sorgfaltspflichten wird ein dokumentierter Meldeweg für Schwachstellen aber zunehmend erwartet, gerade bei Unternehmen mit Kundenportalen oder Online-Diensten.

Wie lange dauert die Einrichtung? Für die reine Textdatei reichen wenige Minuten. Der eigentliche Aufwand liegt darin, intern festzulegen, wer eingehende Meldungen bearbeitet und wie schnell reagiert wird.

Muss ich einen PGP-Key anbieten? Nein, das ist optional. Eine funktionierende, regelmäßig geprüfte Kontaktadresse ist wichtiger als eine vollständige Verschlüsselungsinfrastruktur, die dann niemand nutzt.

Was passiert, wenn ich die Datei einrichte, aber niemand auf Meldungen reagiert? Das ist schlechter als keine security.txt: Ein nicht beantworteter Meldeversuch führt bei vielen Forschern schneller zur öffentlichen Veröffentlichung als ganz ohne Kontaktmöglichkeit. Ohne internen Reaktionsprozess sollte die Datei nicht live gehen.

Reicht die allgemeine info@-Adresse als Kontakt in der security.txt? Technisch ja, praktisch nicht empfehlenswert. Sicherheitsmeldungen landen dort erfahrungsgemäß zwischen Angeboten und Kundenanfragen unter und werden zu spät oder gar nicht bearbeitet. Eine dedizierte, überwachte Adresse ist deutlich zuverlässiger.