Nutzer informieren nach Artikel 14 Absatz 8: Was Hersteller mitteilen müssen

Nach Artikel 14 Absatz 8 der Verordnung (EU) 2024/2847 informiert der Hersteller die betroffenen Nutzer und gegebenenfalls alle Nutzer, sobald er Kenntnis von einer aktiv ausgenutzten Schwachstelle oder einem schwerwiegenden Sicherheitsvorfall hat. Erforderlichenfalls nennt er dabei Maßnahmen, mit denen die Nutzer die Auswirkungen mindern können. Eine Stundenfrist gibt es nicht; die Information muss rechtzeitig erfolgen, sonst können die koordinierenden CSIRTs sie selbst an die Nutzer geben. Die Pflicht gilt seit dem 11. September 2026. Die Pflichten zu Sicherheitsupdates und zur Veröffentlichung behobener Schwachstellen aus Artikel 13 und Anhang I gelten dagegen erst ab dem 11. Dezember 2027.

Was steht in Artikel 14 Absatz 8?

Nachdem der Hersteller Kenntnis von einer aktiv ausgenutzten Schwachstelle oder einem schwerwiegenden Sicherheitsvorfall ... erlangt hat, informiert er die betroffenen Nutzer des Produkts mit digitalen Elementen und gegebenenfalls alle Nutzer über diese Schwachstelle oder diesen schwerwiegenden Sicherheitsvorfall und erforderlichenfalls über jegliche Risikominderungsmaßnahmen und Korrekturmaßnahmen, die die Nutzer ergreifen können, um die Auswirkungen ... zu mindern, gegebenenfalls in einem strukturierten, maschinenlesbaren Format, das leicht automatisch zu verarbeiten ist. Versäumt es der Hersteller, die Nutzer ... rechtzeitig zu informieren, können die als Koordinatoren benannten CSIRTs diese Informationen den Nutzern zur Verfügung stellen, wenn sie dies für verhältnismäßig und erforderlich halten.

Artikel 14 Absatz 8 CRA

Der Absatz enthält sechs Bausteine, die jeder für sich eine Entscheidung verlangen:

• "Nachdem der Hersteller Kenntnis erlangt hat." Die Pflicht hängt am selben Zeitpunkt wie die Meldung an das CSIRT: am Abschluss der sofortigen Erstbewertung mit hinreichender Gewissheit. Mehr dazu im Leitfaden Ab wann läuft die 24-Stunden-Frist?.
• "Die betroffenen Nutzer." Die Nutzer der betroffenen Produkte und Versionen. Wer sie sind, muss der Hersteller selbst herausfinden: über Lizenz- und Kundendaten, Registrierungen, Vertriebspartner oder Hinweise im Produkt.
• "Gegebenenfalls alle Nutzer." Lassen sich Betroffene nicht eingrenzen oder rechtfertigt das Risiko es, geht die Information an alle, etwa über die Website.
• "Erforderlichenfalls über Risikominderungs- und Korrekturmaßnahmen." Gibt es etwas, das Nutzer tun können (Funktion abschalten, Port schließen, Update einspielen), gehört es in die Information.
• "Rechtzeitig." Keine Stundenfrist. Die 24 und 72 Stunden aus Artikel 14 Absatz 2 und 4 gelten nur für die Meldung an das CSIRT. Was rechtzeitig heißt, legt weder die Verordnung noch eine Behördenpraxis fest.
• "Die CSIRTs können diese Informationen den Nutzern zur Verfügung stellen." Wer nicht rechtzeitig informiert, verliert die Kontrolle über die Kommunikation: Das koordinierende CSIRT, in Deutschland CERT-Bund, darf dann selbst informieren.

Erwägungsgrund 67 ergänzt den Weg: Veröffentlichung auf der Website oder, wenn der Hersteller die Nutzer erreichen kann und das Risiko es rechtfertigt, direkte Kontaktaufnahme. Das Ziel ist, dass Nutzer rasch reagieren können.

Wie legt die Leitlinie der Kommission den Absatz aus?

Die Leitlinie C(2026) 5252 widmet dem Absatz drei Randnummern. Rn. 219 wiederholt den Grundsatz. Die beiden folgenden lösen das Dilemma, das jeden Hersteller trifft: Wer früh und öffentlich informiert, liefert Angreifern eine Anleitung, bevor ein Update bereitsteht.

• Rn. 220: risikobasiert und verhältnismäßig. Die Pflicht bedeutet nicht, dass Informationen öffentlich oder unterschiedslos verbreitet werden müssen. Der Hersteller darf Details auf die betroffenen Nutzer oder Kunden beschränken, besonders bei Produkten in sensiblen Umgebungen, in denen Details weitere Ausnutzung erleichtern könnten.
• Rn. 221: breitere Offenlegung nach Behebung. Sobald die Schwachstelle behoben ist, kann eine breitere Veröffentlichung angemessen sein, damit Nutzer prüfen können, ob sie noch betroffen sind. Umfang und Zeitpunkt bleiben verhältnismäßig. Ab dem 11. Dezember 2027 verlangt Anhang I Teil II Nummer 4 die Veröffentlichung behobener Schwachstellen ohnehin.

Daraus folgt ein zweistufiges Vorgehen: zuerst gezielt an die Betroffenen mit dem, was sie zum Schutz brauchen, ohne Exploit-Details; nach dem Update öffentlich mit vollständiger Beschreibung.

Was kommt ab dem 11. Dezember 2027 hinzu?

Nach Artikel 71 Absatz 2 gilt Artikel 14 seit dem 11. September 2026, die Pflichten aus Artikel 13 und Anhang I ab dem 11. Dezember 2027. Nach der Leitlinie (Rn. 210) gelten die Update-Pflichten zudem nur innerhalb des Unterstützungszeitraums.

Erwägungsgrund 56 beschreibt die gewünschte Praxis für Updates: automatische Benachrichtigung, Verteilung, Download und Installation, insbesondere bei Verbraucherprodukten, mit der Möglichkeit, sich mit einer klaren Erklärung abzumelden. Für Komponenten und professionelle Umgebungen, in denen Nutzer keine automatischen Updates erwarten, gilt das nicht. Wie lange der Unterstützungszeitraum im Einzelfall läuft, erklärt der Leitfaden Unterstützungszeitraum.

In welcher Form informieren: Website, Direktkontakt, CSAF?

Die Verordnung schreibt keine Form vor. Artikel 14 Absatz 8 nennt "gegebenenfalls" ein strukturiertes, maschinenlesbares Format, ohne es zu bestimmen. Stand der Technik für maschinenlesbare Sicherheitshinweise ist CSAF 2.0 (Common Security Advisory Framework), ein von OASIS veröffentlichtes und als ISO/IEC 20153:2025 genormtes Datenformat. Es enthält Produktbaum, CVE-Kennung (die öffentliche Nummer der Schwachstelle), CVSS-Wert (die übliche Zahl für die Schwere), Status (betroffen, behoben) und Abhilfen. Das BSI empfiehlt CSAF, stellt Werkzeuge bereit und verweist in der TR-03183-3 auf die Veröffentlichung in diesem Format. Ob CSAF über eine harmonisierte Norm oder einen Durchführungsrechtsakt faktisch zum Pflichtformat wird, ist offen; eine Pflicht besteht heute nicht.

Menschenlesbar bleibt in jedem Fall Pflicht: Anhang I Teil II Nummer 4 verlangt eindeutige und verständliche Informationen, Artikel 13 Absatz 18 leicht verständliche Nutzerinformationen. Für einen mittelständischen Hersteller ohne eigene Werkzeugkette reicht zum Start eine Seite mit Sicherheitshinweisen unter einer stabilen Adresse. Darauf stehen Produkt und Versionen, CVE-Kennung sofern vergeben, Schwere, Beschreibung, Übergangslösung, Version mit Behebung, Datum und Änderungshistorie. Wo die Hinweise zu finden sind, gehört in die security.txt des Herstellers.

Muster-Gliederung einer Kundeninformation

Die folgende Gliederung ist keine Vorlage mit Formulierungen, sondern die Reihenfolge der Punkte, die eine Information an betroffene Kunden abdecken sollte. Sie ist für die erste, gezielte Stufe gedacht. Exploit-Details gehören nicht hinein.

• Betreff und Einordnung. Produktname, betroffene Versionen, Datum und Kennung des Hinweises, Dringlichkeit in einem Satz.
• Was passiert ist. Art der Schwachstelle oder des Vorfalls in Alltagssprache, ohne Angriffsweg und Beispielcode. CVE-Kennung, sofern vergeben.
• Wer betroffen ist. Welche Produkte, Versionen und Konfigurationen betroffen sind, und welche nicht.
• Mögliche Auswirkung und Schwere. Was ein Angreifer erreichen könnte, und eine Einstufung der Schwere, etwa als CVSS-Wert.
• Sofortmaßnahmen. Was der Kunde jetzt tun kann, bevor ein Update vorliegt: Funktion abschalten, Zugang einschränken, Protokolle prüfen, mit den Einschränkungen, die das mit sich bringt.
• Behebung. Ob ein Sicherheitsupdate verfügbar ist, unter welcher Version, oder wann mit ihm zu rechnen ist.
• Nächste Information. Wann und wo der Kunde die nächste Mitteilung findet.
• Kontakt. Sicherheitsadresse für Rückfragen, Hinweis auf die Richtlinie zur koordinierten Offenlegung.

Nach dem Update folgt die zweite Stufe: die öffentliche Veröffentlichung mit vollständiger Beschreibung, betroffenen Produkten, Auswirkung, Schwere und Hilfestellung, gegebenenfalls als CSAF. Anhang I Teil II Nummer 4 schreibt sie ab Dezember 2027 vor. Wer wann wie informiert wurde, gehört ins Protokoll; die Marktüberwachung kann Nachweise verlangen.

Typische Fehler

• Erst mit dem Update informieren, obwohl eine Übergangslösung schon möglich wäre. Das verfehlt "rechtzeitig", und das CSIRT kann selbst informieren.
• Öffentliche Vollinformation mit Exploit-Details vor dem Update. Rn. 220 erlaubt die Beschränkung auf Betroffene; sie sollte genutzt werden.
• Hinweis nur per Newsletter ohne stabile Adresse, ohne Versionsangaben, ohne Datum. Nutzer können später nicht prüfen, ob sie noch betroffen sind.
• Nutzer nicht bekannt, deshalb niemanden informiert. Erwägungsgrund 67 sieht genau diesen Fall vor: Veröffentlichung auf der Website und Information der Vertriebskette.

Für die erste Stufe zählt vor allem, dass jemand die Information rechtzeitig auslöst, während die Fristen für die Meldung an das CSIRT parallel laufen. CRA Response Center führt die Fristen-Uhren, hält den Entwurf der Kundeninformation neben dem Entwurf der ENISA-Meldung bereit und protokolliert, wer wann informiert wurde; Inhalt und Versand entscheidet der Hersteller.

Häufige Fragen

Weiterlesen

• Frühwarnung, Meldung, AbschlussberichtDie Meldung an das CSIRT, die parallel zur Nutzerinformation läuft.
• UnterstützungszeitraumWie lange Sicherheitsupdates Pflicht sind und wie das Enddatum anzugeben ist.
• Richtlinie zur koordinierten OffenlegungWas in die CVD-Policy gehört, auf die die Kundeninformation verweist.
• Glossar: Nutzerinformation bei Schwachstellen und VorfällenDer Begriff in zwei Sätzen.

Quellen

• Verordnung (EU) 2024/2847, Artikel 13 Absatz 7 bis 11, 18 und 19, Artikel 14 Absatz 8, Artikel 71, Anhang I Teil I Nummer 2 und Teil II Nummer 2, 4, 7 und 8, Erwägungsgründe 56 und 67, EUR-Lex, 20. November 2024.
• Leitlinie der Kommission C(2026) 5252, Anhang, Rn. 210 und 219 bis 221, Europäische Kommission, 27. Juli 2026.
• Common Security Advisory Framework (CSAF), BSI, abgerufen 7. Oktober 2026.
• Common Security Advisory Framework Version 2.0, OASIS, 2022.
• BSI TR-03183-3 Vulnerability Reports and Notifications, Version 1.0.0, BSI, 20. August 2025.