Vulnerability Disclosure Deutschland: Rechtslage 2026

Letzte Aktualisierung: 23. März 2026

Vulnerability Disclosure in Deutschland bewegt sich in einer rechtlichen Grauzone zwischen Strafrecht (§202a StGB) und dem Wunsch nach mehr IT-Sicherheit. Wer eine Sicherheitslücke meldet, handelt nicht automatisch rechtswidrig, hat aber außerhalb sauberer Prozesse oft keinen belastbaren Safe Harbor. Genau deshalb werden Coordinated Vulnerability Disclosure, BSI-Koordinierung und ab dem 11. September 2026 auch die CRA-Meldepflicht so wichtig.

Die kurze Einordnung vorweg: In Deutschland gibt es 2026 kein allgemeines Gesetz, das Sicherheitsforschende pauschal privilegiert. Gleichzeitig verlangen europäische und nationale Sicherheitsregime mehr geordnete Schwachstellenmeldungen statt Schweigen. Praktisch heißt das: Responsible Disclosure ist möglich, aber nur dann wirklich belastbar, wenn Scope, Methode, Dokumentation, Kontaktweg und Timing stimmen. Wenn Sie den arbeitsrechtlichen und melderechtlichen Nachbarkontext vertiefen möchten, lesen Sie auch unseren Beitrag zum Hinweisgeberschutz in der Cybersecurity, den Überblick zu Bug-Bounty-Programmen in Deutschland sowie die Einordnung zum Cyber Resilience Act.

Was ist Coordinated Vulnerability Disclosure (CVD)?

Coordinated Vulnerability Disclosure ist die kontrollierte Offenlegung einer Sicherheitslücke über einen abgestimmten Prozess zwischen meldender Person, betroffenem Hersteller oder Betreiber und gegebenenfalls einer vermittelnden Stelle. Ziel ist nicht maximale Öffentlichkeit, sondern eine sichere Behebung vor oder parallel zur Veröffentlichung technischer Details.

Für Unternehmen ist dieser Unterschied zentral: CVD ist nicht dasselbe wie Full Disclosure. Bei Full Disclosure werden Schwachstellendetails sehr früh oder sofort veröffentlicht. Das kann Druck auf Hersteller erzeugen, erhöht aber zugleich das Risiko, dass Angreifer die Information vor der Behebung missbrauchen. CVD verfolgt deshalb eine Reihenfolge: melden, verifizieren, priorisieren, beheben, kommunizieren.

Responsible Disclosure wird im deutschen Sprachgebrauch häufig als Synonym verwendet. Praktisch meint Responsible Disclosure meist die Verhaltensnorm der meldenden Person, während CVD stärker den Prozess beschreibt. Rechtlich zählt vor allem, dass der Vorgang dokumentierbar, verhältnismäßig und auf Schadensvermeidung ausgerichtet ist.

Ein belastbarer CVD-Prozess enthält typischerweise diese Elemente:

einen klaren Meldekanal mit Kontaktadresse oder Formular,
Angaben zu erlaubten und unerwünschten Testmethoden,
Regeln zum Umgang mit personenbezogenen Daten und fremden Systemen,
Fristen für Empfangsbestätigung, Triage und Rückmeldung,
einen abgestimmten Veröffentlichungszeitpunkt,
einen begrenzten Safe-Harbor-Rahmen für gutgläubige Meldungen.

Für deutsche Unternehmen ist CVD damit weniger ein PR-Thema als ein Governance-Instrument. Wer Schwachstellenmeldungen geordnet bearbeitet, reduziert Eskalationen, Reputationsschäden und unnötige Konflikte mit Sicherheitsforschenden.

Aktuelle Rechtslage — §202a-c StGB als Hindernis

Die größte Rechtsunsicherheit in Deutschland liegt 2026 weiter im Strafrecht. Maßgeblich sind vor allem §202a StGB, §202b StGB und §202c StGB. Diese Normen sind nicht gegen seriöse Sicherheitsforschung geschrieben worden, können in der Praxis aber dennoch einschlägig werden, wenn Tests ohne Autorisierung oder über den vereinbarten Scope hinaus stattfinden.

§202a StGB erfasst das Ausspähen von Daten. Strafbar ist, wer sich unbefugt Zugang zu nicht für ihn bestimmten und besonders gesicherten Daten verschafft, indem er die Zugangssicherung überwindet. Für Vulnerability Disclosure heißt das: Schon der Nachweis einer Lücke kann problematisch werden, wenn dafür eine Authentifizierung, Zugriffssperre oder andere Schutzmaßnahme aktiv umgangen werden muss.

§202b StGB erfasst das Abfangen von Daten. Relevant wird die Norm vor allem dann, wenn Daten aus einer nichtöffentlichen Übermittlung oder aus elektromagnetischer Abstrahlung technisch abgegriffen werden. Klassische Web-Schwachstellenmeldungen berühren §202b StGB seltener als §202a StGB, aber etwa bei Traffic-Manipulation, Session-Abgriffen oder MITM-nahen Konstellationen kann die Norm schnell Bedeutung gewinnen.

§202c StGB verschärft die Unsicherheit zusätzlich. Die Vorschrift stellt bereits das Vorbereiten des Ausspähens und Abfangens von Daten unter Strafe, wenn Passwörter, Zugangscodes oder Programme beschafft, hergestellt oder weitergegeben werden, deren Zweck die Begehung einer Tat nach §202a oder §202b ist. In der Praxis wird §202c StGB häufig als "Hackerparagraph" diskutiert, auch wenn nicht jedes Sicherheitswerkzeug automatisch tatbestandsmäßig ist.

Die entscheidende juristische Konsequenz lautet deshalb: Gute Absichten allein schaffen keinen Rechtfertigungsgrund. Wer ohne Einwilligung scannt, Proof-of-Concept-Code gegen ein Fremdsystem einsetzt, Daten einsieht oder Schutzmechanismen umgeht, bewegt sich schneller im strafrechtlichen Risiko, als viele Responsible-Disclosure-Debatten vermuten lassen.

Gleichzeitig wäre es zu verkürzt, Vulnerability Disclosure pauschal als illegal darzustellen. Nicht jede Schwachstellenmeldung setzt einen strafbaren Vorakt voraus. Rein passive Erkenntnisse, Fehlkonfigurationen ohne Schutzumgehung, offengelegte Artefakte, versehentlich zugängliche Inhalte oder Funde innerhalb ausdrücklich freigegebener Testumgebungen sind anders zu bewerten als aktives Eindringen.

Für die Praxis hilft diese Faustregel:

Situation	Risiko nach deutschem Strafrecht	Praktische Bewertung
Meldung einer offenkundigen Fehlkonfiguration ohne Umgehung einer Schutzmaßnahme	Eher geringer	Häufig am ehesten vertretbar
Verifikation durch Login-Bypass oder Auslesen geschützter Daten	Hoch	§202a StGB kann berührt sein
Abfangen nichtöffentlicher Datenübertragungen	Hoch	§202b StGB kann einschlägig sein
Einsatz exploit-naher Tools gegen Drittsysteme ohne Freigabe	Mittel bis hoch	§202c StGB und Begleittatbestände mitdenken
Tests im Rahmen eines freigegebenen Bug-Bounty- oder Pentest-Scopes	Deutlich reduziert	Autorisierung ist der entscheidende Schutzfaktor

Unternehmen sollten daraus zwei Lehren ziehen. Erstens: Ohne eigene CVD-Policy überlassen Sie die Risikosteuerung dem Einzelfall. Zweitens: Sicherheitsforschende brauchen klare Kontaktwege und Scope-Informationen, damit aus einem Schutzimpuls nicht versehentlich ein Strafbarkeitsproblem wird.

BSI als nationale Koordinierungsstelle

Das BSI ist 2026 die wichtigste deutsche Anlaufstelle, wenn koordinierte Schwachstellenoffenlegung beim Hersteller stockt oder ein strukturierter Vermittler gebraucht wird. Die CVD-Richtlinie des BSI sagt ausdrücklich: Bei Produkten, Systemen oder Dienstleistungen außerhalb der Bundesverwaltung soll die Schwachstelle zunächst an Hersteller oder Produktverantwortliche gemeldet werden. Reagieren diese nicht oder droht der Abbruch des Verfahrens, können sich Sicherheitsforschende an das BSI wenden.

Besonders relevant ist, was das BSI im eigenen CVD-Prozess zusagt. Die Behörde verspricht unter anderem vertrauliche Behandlung, Rückmeldung auf Meldungen und keine strafrechtlichen Schritte, solange Richtlinie und Grundsätze eingehalten wurden und keine erkennbaren kriminellen Absichten verfolgt werden. Das ist wichtig, aber juristisch präzise zu lesen: Diese Zusage ist kein allgemeiner gesetzlicher Safe Harbor für ganz Deutschland, sondern ein verfahrensbezogenes Versprechen innerhalb des BSI-Rahmens.

Die BSI-Richtlinie verlangt im Gegenzug ebenfalls klare Grenzen. Erwartet wird insbesondere, dass die Schwachstelle nicht missbräuchlich ausgenutzt wurde, keine Schäden über den Nachweis hinaus verursacht wurden, keine Angriffe wie Social Engineering oder DoS durchgeführt wurden und keine Exploit-Tools zur Begehung von Straftaten verbreitet wurden. Damit zieht das BSI die Linie dort, wo Sicherheitsforschung in operative Angriffe kippt.

Das passt auch zur europäischen Rolle der CSIRTs. Schon NIS2 verlangt, dass Mitgliedstaaten einen CSIRT als Koordinator für koordinierte Offenlegung benennen. In Deutschland erfüllt das BSI diese Vermittlungsfunktion faktisch bereits heute. Der Mehrwert für Unternehmen liegt darin, dass CVD nicht mehr nur bilateral zwischen Finder und Hersteller ablaufen muss, sondern eine vertrauenswürdige dritte Instanz verfügbar ist.

Die Sichtbarkeit dieses Prozesses hat 2024 und 2025 deutlich zugenommen. Der BSI-Lagebericht 2024 beschreibt den CVD-Prozess als relevanter und sichtbarer, unter anderem durch Schwachstellenformular, Leitlinie und Hall of Fame. Das ist ein klares Signal: Deutschland bewegt sich regulatorisch und organisatorisch weg vom Zufall und hin zu formalisierter Offenlegung.

CRA-Meldepflicht ab September 2026 — Neue Spielregeln

Mit dem Cyber Resilience Act ändern sich die Spielregeln ab dem 11. September 2026 spürbar. Ab diesem Datum gilt Art. 14 der Verordnung (EU) 2024/2847, obwohl die Verordnung im Übrigen erst ab dem 11. Dezember 2027 breit anwendbar wird. Für Hersteller digitaler Produkte ist das die erste harte europäische Schwachstellenmeldepflicht in diesem Bereich.

Der Kernpunkt: Hersteller müssen jede aktiv ausgenutzte Schwachstelle, von der sie Kenntnis erlangen, gleichzeitig an den zuständigen CSIRT-Koordinator und an ENISA melden. Die erste Frühwarnung muss ohne schuldhaftes Zögern und spätestens binnen 24 Stunden nach Kenntniserlangung erfolgen. Zusätzlich verlangt der CRA abgestufte Folgemeldungen über die zentrale Single Reporting Platform.

Für die Praxis ist das aus drei Gründen relevant:

Der CRA schafft erstmals unionsweit einen Pflichtkanal für aktiv ausgenutzte Schwachstellen.
Der CRA verknüpft Hersteller direkt mit ENISA und den nationalen CSIRTs.
Der CRA macht Vulnerability Handling und CVD-Policy zu Compliance-Themen, nicht nur zu freiwilliger Security-Hygiene.

Hinzu kommt ein oft übersehener zweiter Baustein: Anhang I Teil II des CRA verlangt von Herstellern ausdrücklich, eine Policy zur koordinierten Offenlegung von Schwachstellen einzuführen und durchzusetzen. Unternehmen, die Produkte mit digitalen Elementen entwickeln oder vertreiben, brauchen deshalb nicht erst 2027 mit ihren Disclosure-Prozessen zu beginnen. Der operative Vorlauf startet 2026.

Wichtig ist die Abgrenzung: Der CRA schützt Sicherheitsforschende nicht automatisch vor deutschem Strafrecht. Er schafft Melde- und Prozesspflichten auf Herstellerseite. Mittelbar verbessert das aber die Lage, weil es klare Meldekanäle, Zuständigkeiten und Reaktionsfristen erzwingt. Je besser dieser Zielprozess funktioniert, desto seltener eskaliert eine Meldung in Streit über Zuständigkeit, Schweigen oder voreilige Veröffentlichung.

Wenn Sie die Fristen im Detail planen möchten, finden Sie die Timeline in unserem Beitrag zu den CRA-Fristen.

NIS2 und Vulnerability Disclosure Policies

NIS2 macht koordinierte Offenlegung von Schwachstellen zu einem europäischen Strukturprinzip. Art. 12 der Richtlinie (EU) 2022/2555 verpflichtet jeden Mitgliedstaat, einen CSIRT als Koordinator für Coordinated Vulnerability Disclosure zu benennen. Dieser CSIRT soll als vertrauenswürdiger Vermittler zwischen meldender Person und betroffenem Hersteller oder Anbieter agieren.

Für Unternehmen ist dabei weniger die Wortlautfrage entscheidend als die Governance-Folge: Vulnerability Disclosure wird unter NIS2 nicht als exotisches Spezialthema behandelt, sondern als Teil moderner Cybersicherheitsarchitektur. Mitgliedstaaten sollen Meldungen auch anonym ermöglichen, sorgfältig nachverfolgen und grenzüberschreitend mit anderen CSIRTs kooperieren.

Bemerkenswert ist zudem Erwägungsgrund 58 der NIS2-Richtlinie. Dort werden Mitgliedstaaten ausdrücklich ermutigt, im Rahmen ihrer nationalen CVD-Politik die Herausforderungen von Sicherheitsforschenden zu adressieren, einschließlich ihrer möglichen strafrechtlichen und zivilrechtlichen Risiken nach nationalem Recht. Genau hier liegt die Brücke zur deutschen Debatte um §202a-c StGB.

Deutschland hat die europäische Richtung damit nicht frei zur Disposition. Selbst wenn das nationale Recht keinen umfassenden gesetzlichen Safe Harbor schafft, steigt der regulatorische Druck, geordnete Disclosure-Prozesse zu ermöglichen. Für regulierte und kritische Unternehmen bedeutet das mindestens: Schwachstellenmeldungen müssen organisatorisch verarbeitet, eskaliert und dokumentiert werden können.

Der Stand der Umsetzung ist dabei wichtig. Die Europäische Kommission hat Deutschland am 7. Mai 2025 zu den Mitgliedstaaten gezählt, die die NIS2-Richtlinie noch nicht vollständig umgesetzt hatten. Unabhängig vom Stand einzelner nationaler Umsetzungsschritte bleibt die operative Erwartung aber stabil: Wer heute eine CVD-Policy aufsetzt, handelt nicht verfrüht, sondern schließt eine erkennbare Governance-Lücke.

Responsible Disclosure — Best Practices für Unternehmen

Unternehmen sollten Responsible Disclosure nicht als Einladung zu unkontrollierten Tests verstehen, sondern als geregeltes Sicherheitsventil. Ein guter Prozess schützt beide Seiten: den meldenden Finder vor unnötiger Eskalation und das Unternehmen vor Ad-hoc-Kommunikation, Rechtsstreit und öffentlichem Druck.

Die wichtigsten Best Practices sind organisatorisch erstaunlich schlicht:

Veröffentlichen Sie einen sichtbaren Meldekanal mit Funktionsadresse oder Formular.
Benennen Sie Scope und No-Go-Bereiche so konkret wie möglich.
Bestätigen Sie Eingänge schnell und dokumentieren Sie Ticket-Nummern.
Regeln Sie interne Zuständigkeiten zwischen Security, Legal, Produkt und Kommunikation.
Arbeiten Sie mit Disclosure-Fristen, die realistisch und begründbar sind.
Definieren Sie, wann das BSI oder ein externer CSIRT eingebunden wird.
Dokumentieren Sie jede Entscheidung für Priorisierung, Fix und Veröffentlichung.

Der häufigste Fehler ist Schweigen. Wenn Hersteller oder Betreiber tagelang nicht reagieren, steigt der Druck auf Sicherheitsforschende und damit die Wahrscheinlichkeit einer unkoordinierten Offenlegung. Der zweitgrößte Fehler ist ein zu aggressiver Legal-Reflex. Pauschale Drohungen verschlechtern regelmäßig die Sicherheitslage, weil sie Meldungen künftig eher verhindern als verbessern.

Ebenso wichtig ist eine saubere Differenzierung zwischen "willkommenen Meldungen" und "erlaubten Tests". Wenn Ihr Unternehmen keinen generellen Test-Scope freigeben will, sollte die Policy das klar sagen. CVD ist kein stillschweigendes Pentest-Mandat. Genau diese Klarheit reduziert Missverständnisse rund um §202a-c StGB.

CVD-Policy erstellen — Template und Leitfaden

Eine brauchbare CVD-Policy ist kurz, konkret und juristisch defensiv formuliert. Sie braucht keinen großen Theorieblock, sondern klare Handlungsregeln. Für KMU genügt meist eine Seite, solange Zuständigkeiten, Scope und Reaktionslogik sauber beschrieben sind.

Dieses Minimal-Template ist ein belastbarer Startpunkt:

Coordinated Vulnerability Disclosure Policy

1. Meldekanal
Schwachstellenmeldungen senden Sie bitte an [security@unternehmen.de] oder über [Formular-Link].

2. Gewünschte Inhalte
Bitte übermitteln Sie betroffene URL/Systeme, Reproduktionsschritte, Zeitpunkt des Funds, mögliche Auswirkungen und, wenn möglich, Vorschläge zur Behebung.

3. Erwünschtes Verhalten
Wir begrüßen gutgläubige Meldungen, die auf Schadensvermeidung gerichtet sind.

4. Nicht erlaubte Handlungen
Nicht gestattet sind insbesondere Datenexfiltration, dauerhafte Persistenz, Social Engineering, DoS, Brute Force, physische Angriffe, Ausweitung auf Drittsysteme und jede Nutzung über den Nachweis der Schwachstelle hinaus.

5. Kommunikation
Wir bestätigen den Eingang schnellstmöglich, halten Sie über den Status informiert und stimmen Veröffentlichungszeitpunkte koordiniert ab.

6. Offenlegung
Eine Veröffentlichung technischer Details erfolgt grundsätzlich erst nach Behebung oder abgestimmter Übergangslösung.

7. Eskalation
Wenn eine Koordination mit uns nicht gelingt, kann eine vermittelnde Stelle wie das BSI eingebunden werden.

8. Rechtlicher Hinweis
Diese Policy ist keine allgemeine Freigabe zu beliebigen Sicherheitstests. Zulässig ist nur das in dieser Policy beschriebene Verhalten.

Für die praktische Einführung empfiehlt sich diese Reihenfolge:

Definieren Sie zuerst den Meldekanal und den internen Incident Owner.
Legen Sie dann Scope, No-Go-Bereiche und Eskalationspfade fest.
Stimmen Sie die Policy mit Legal, Datenschutz und IT-Security ab.
Hinterlegen Sie Antwortfristen und Standardbausteine für Kommunikation.
Testen Sie den Prozess an einem internen Tabletop-Fall.
Veröffentlichen Sie die Policy sichtbar im Footer, auf der Security-Seite oder im Impressumsumfeld.

Ein zweiter Vergleich hilft bei der internen Positionierung:

Modell	Vorteil	Nachteil	Für wen geeignet
Kein öffentlicher Prozess	Geringer Abstimmungsaufwand	Meldungen versanden, Eskalationsrisiko steigt	Praktisch für niemanden sinnvoll
Reine Kontaktadresse ohne Policy	Schnell eingeführt	Hohe Rechts- und Erwartungsunklarheit	Übergangslösung
CVD-Policy	Klare Governance, bessere Triage	Erfordert Pflege und Zuständigkeit	Für die meisten Unternehmen sinnvoll
Bug-Bounty-Programm	Starker Anreiz, hoher Zufluss	Höherer Steuerungsaufwand	Für reifere Organisationen
Full Disclosure ohne Koordination	Maximale Transparenz	Höchstes Missbrauchs- und Reputationsrisiko	Für Unternehmen regelmäßig ungeeignet

Häufig gestellte Fragen (FAQ)

Ist Vulnerability Disclosure in Deutschland legal?

Vulnerability Disclosure ist in Deutschland nicht pauschal illegal, aber auch nicht generell privilegiert. Entscheidend ist, ob für den Fund oder die Verifikation Schutzmaßnahmen umgangen, Daten abgefangen oder strafrechtlich relevante Vorbereitungshandlungen vorgenommen wurden. Ohne Autorisierung bleibt deshalb ein reales Risiko nach §202a-c StGB.

Was ändert der CRA an der Rechtslage?

Der CRA ändert vor allem die Pflichten der Hersteller. Ab dem 11. September 2026 gilt Art. 14 der Verordnung (EU) 2024/2847 und verlangt Meldungen aktiv ausgenutzter Schwachstellen an CSIRT-Koordinator und ENISA, inklusive Frühwarnung binnen 24 Stunden. Zusätzlich verlangt der CRA eine CVD-Policy auf Herstellerseite.

Brauchen KMU eine CVD-Policy?

Ja, in der Praxis fast immer. Eine CVD-Policy ist für KMU die einfachste Möglichkeit, Meldekanal, Scope, Reaktionszeiten und Eskalationswege verbindlich festzulegen. Ohne Policy steigt das Risiko, dass Meldungen verloren gehen oder in rechtlich unnötige Konflikte kippen.

Welche Rolle spielt das BSI?

Das BSI fungiert als nationale Koordinierungs- und Vermittlungsstelle für CVD-Fälle, insbesondere wenn Hersteller nicht reagieren oder das Verfahren stockt. Die BSI-Richtlinie verspricht Vertraulichkeit, Rückmeldung und innerhalb ihres Prozesses grundsätzlich keine strafrechtlichen Schritte bei regelkonformem Verhalten. Das ersetzt aber keinen allgemeinen gesetzlichen Safe Harbor.

Was ist der Unterschied zwischen Responsible und Full Disclosure?

Responsible beziehungsweise Coordinated Disclosure zielt auf Behebung vor oder parallel zur Veröffentlichung. Full Disclosure veröffentlicht technische Details deutlich früher oder sofort. Für Unternehmen ist CVD fast immer das sicherere Modell, weil es das Missbrauchsfenster verkleinert und die Kommunikation steuerbar macht.

Wie melde ich eine Sicherheitslücke rechtssicher?

Rechtssicherer wird eine Meldung, wenn Sie keine Schutzmaßnahmen weiter überwinden, keine Daten exfiltrieren, keine Persistenz aufbauen, jeden Schritt dokumentieren und zunächst den vorgesehenen Meldekanal des Herstellers oder ersatzweise das BSI nutzen. Absolute Rechtssicherheit gibt es ohne Autorisierung nicht, aber saubere Verhältnismäßigkeit reduziert das Risiko erheblich.

CTA: CVD in die AI-Governance integrieren

Vulnerability Disclosure ist kein Randthema der IT, sondern Teil belastbarer Governance. Wenn Ihr Unternehmen KI-Systeme, Softwareprodukte oder digitale Services einsetzt, sollten Schwachstellenmeldungen, Rollen, Eskalationen und Kommunikationspflichten ebenso klar geregelt sein wie Schulung und Dokumentation.

Wenn Sie Governance, Rollenverständnis und regulatorische Pflichten strukturiert aufbauen möchten, ist unsere EU AI Act Schulung der passende nächste Schritt. Sie verbinden damit Compliance-Verständnis, interne Zuständigkeiten und einen belastbaren Nachweis für Management, Fachbereiche und Sicherheitsorganisation.

Vulnerability Disclosure in Deutschland — Rechtslage 2026