Zwei Sätze fallen derzeit in fast jedem Gespräch über den Cyber Resilience Act. Der erste: „Ab September müssen wir jede Schwachstelle melden.” Der zweite: „Und alle CVEs in unseren Komponenten müssen wir dann beheben.” Beide sind falsch. Sie treiben Aufwand hoch, den die Verordnung nirgends verlangt, und lenken von dem ab, was bis zum 11. September 2026 stehen muss.
Das kommt daher, dass drei Dinge durcheinandergeraten. Der Cyber Resilience Act (Verordnung (EU) 2024/2847) verlangt von Herstellern von Produkten mit digitalen Elementen dreierlei, was im Sprachgebrauch alles unter „Schwachstellenmanagement” läuft: Sie müssen Angriffe an Behörden melden, Sie müssen Schwachstellen in Ihrem Produkt beheben, und Sie müssen fremde Quellen nach neuen Schwachstellen absuchen. Jede dieser drei Pflichten wird von etwas anderem ausgelöst und startet zu einem anderen Zeitpunkt. Sobald Sie sie auseinanderhalten, bleibt für den September 2026 wenig übrig: ein Zugang, eine zuständige Person, ein eingeübter Ablauf.
| Was der Auslöser ist | Was zu tun ist | Gilt ab | |
|---|---|---|---|
| Melden an CSIRT und ENISA | Sie erfahren von einer aktiv ausgenutzten Schwachstelle oder einem schwerwiegenden Sicherheitsvorfall | frühwarnen in 24 Stunden, melden in 72 Stunden, Abschlussbericht nachreichen, parallel die Nutzer informieren | 11. September 2026 |
| Schwachstellen im eigenen Produkt behandeln | Sie erfahren von einer Schwachstelle in Ihrem Produkt, gleich woher | prüfen, ob Ihr Produkt betroffen ist, Ausnutzbarkeit bewerten, risikoorientiert beheben, dokumentieren, veröffentlichen | 11. Dezember 2027 |
| Fremde Quellen überwachen (CVE-Monitoring) | laufend, ohne konkreten Anlass | öffentliche Datenbanken, eigene Tests und Meldungen von außen auswerten und auf Ihr Produkt beziehen | 11. Dezember 2027 |
Artikel 71 Absatz 2 setzt die Termine. Die Verordnung gilt ab dem 11. Dezember 2027, die Meldepflichten aus Artikel 14 schon ab dem 11. September 2026. Der zweite vorgezogene Termin, der 11. Juni 2026, betrifft die Notifizierung von Konformitätsbewertungsstellen und geht Hersteller nichts an. Wie sich die Termine insgesamt verteilen, zeigt unsere Übersicht zu den CRA-Übergangsfristen.
Ein Detail daraus überliest fast jeder, obwohl es ein Projekt anders zuschneidet. Nach Artikel 69 Absatz 2 gilt die Verordnung für Produkte, die Sie vor dem 11. Dezember 2027 in Verkehr gebracht haben, erst dann, wenn Sie sie danach wesentlich ändern. Für die Meldepflichten macht Artikel 69 Absatz 3 davon eine ausdrückliche Ausnahme. Für Ihren Bestand heißt das: melden ja, Schwachstellen behandeln nach Anhang I Teil II erst mit der nächsten wesentlichen Änderung. Wer seine Alt-Produkte gerade in ein CRA-Umsetzungsprojekt einplant, sollte das prüfen.
Gemeldet wird nur, was angegriffen wurde
Artikel 14 Absatz 1 knüpft die Meldepflicht an die „aktiv ausgenutzte Schwachstelle”. Artikel 3 Nummer 42 definiert sie als Schwachstelle, zu der verlässliche Nachweise vorliegen, dass ein böswilliger Akteur sie in einem System ohne Zustimmung des Systemeigners ausgenutzt hat. Sie brauchen also Belege, dass jemand wirklich angegriffen hat. Dass er es könnte, reicht nicht. Der zweite Auslöser ist der schwerwiegende Sicherheitsvorfall, der die Sicherheit des Produkts beeinträchtigt (Artikel 14 Absatz 3, Schwellen in Absatz 5).
Praktisch gibt es zwei Fälle. Entweder hat jemand Ihr Produkt beim Kunden angegriffen und eine Schwäche darin real ausgenutzt, und Sie haben belastbare Hinweise darauf. Oder jemand hat Ihre eigene Entwicklung, Herstellung oder Wartung angegriffen. Erwägungsgrund 68 beschreibt das als Vorfall, der diese Prozesse so beeinträchtigt, dass daraus ein erhöhtes Cybersicherheitsrisiko für die Nutzer entstehen könnte, und nennt ein Beispiel, das jeder Hersteller sofort versteht: Ein Angreifer hat Schadcode in den Freigabekanal eingeschleust, über den Sie Ihre Sicherheitsupdates verteilen.
Alles andere melden Sie nicht. Eine neue CVE in einer Bibliothek, die Sie verbauen, arbeiten Sie ab, solange niemand Belege für einen laufenden Angriff hat. Genauso einen Befund aus dem eigenen Penetrationstest oder den Hinweis eines Sicherheitsforschers auf eine Lücke, die noch keiner angegriffen hat. Erwägungsgrund 68 sagt für diese Gruppe sogar ausdrücklich, dass Schwachstellen nicht meldepflichtig sein sollten, wenn jemand sie ohne böswillige Absicht bei in gutem Glauben ausgeführten Tests, Untersuchungen, Korrekturen oder Offenlegungen findet.
Umgekehrt: Stammt die aktiv ausgenutzte Schwachstelle aus einer fremden Komponente, sitzt sie trotzdem in Ihrem Produkt. Sie melden das Produkt.
Ihre Nutzer zu informieren gehört zur Meldung
Was Hersteller am häufigsten übersehen, steht in Artikel 14 Absatz 8. Sobald Sie von dem Angriff wissen, sagen Sie Ihren betroffenen Kunden Bescheid, je nach Lage auch allen. Und wenn diese selbst etwas tun können, um die Folgen kleiner zu halten, schreiben Sie ihnen das dazu. Warten Sie zu lange, informieren die als Koordinatoren benannten CSIRTs Ihre Nutzer an Ihrer Stelle. Sie brauchen also neben dem Draht zur Behörde einen Verteiler zu Ihren Kunden und einen Textbaustein, den Sie im Ernstfall nicht erst schreiben müssen.
Für den 11. September 2026 brauchen Sie kein PSIRT
Hier liegt der Denkfehler, der die meiste Zeit kostet. Entscheidend ist, dass Sie von dem Angriff wissen. Wie Sie davon erfahren haben, steht in Artikel 14 nirgends.
Der Leitfaden der EU-Kommission zum CRA beschreibt, wann ein Hersteller als informiert gilt. Er legt die Verordnung nur aus und bindet niemanden rechtlich, zeigt aber, wie die Kommission sie liest. Entweder entdeckt der Hersteller selbst etwas Verdächtiges, oder ein Dritter macht ihn darauf aufmerksam: eine Privatperson, ein Kunde, eine Behörde, ein Medium. In beiden Fällen schaut er sich den Hinweis sofort an, und er gilt in dem Moment als informiert, in dem er danach mit hinreichender Sicherheit weiß, dass jemand angreift oder ein schwerwiegender Vorfall vorliegt. Ab da laufen die 24 Stunden.
Für den September 2026 müssen deshalb vier Dinge stehen, mehr nicht:
- Sie kommen auf die Meldeplattform. Die ENISA baut sie gerade auf, laufen soll sie zum 11. September 2026. Zugang einrichten, das für Sie zuständige CSIRT bestimmen, den Ablauf einmal durchspielen.
- Jemand darf melden und kann melden. Mit Vertretung, denn 24 Stunden laufen auch über ein Wochenende.
- Jemand schaut sich Hinweise sofort an und entscheidet. Wer das ist, wer im Zweifel entscheidet und wo festgehalten wird, ab wann Sie Bescheid wussten.
- Sie erreichen Ihre Nutzer. Verteiler und Textbaustein, damit die Information nicht am Formulieren scheitert.
Das ist eine überschaubare Organisationsaufgabe. Ein vollständig aufgesetztes Product Security Incident Response Team brauchen Sie dafür nicht. Sinnvoll ist es trotzdem, aber es zahlt auf die Pflichten ab Dezember 2027 ein, nicht auf den nahen Termin. Wer die Reihenfolge umdreht, baut anderthalb Jahre an einer Struktur und hat am Stichtag immer noch keinen Plattform-Zugang. Wie so ein Team zugeschnitten sein kann, beschreibt das FIRST PSIRT Services Framework.
Fremde Quellen zu überwachen ist die andere Baustelle
Ab dem 11. Dezember 2027 kommt die Pflicht dazu, die wirklich Arbeit macht. Artikel 13 Absatz 8 verlangt, dass Sie Schwachstellen Ihres Produkts einschließlich seiner Komponenten wirksam behandeln, wenn Sie es in Verkehr bringen und während der erwarteten Produktlebensdauer und des Unterstützungszeitraums. Dazu brauchen Sie Strategien und Verfahren für Schwachstellen, die aus internen oder externen Quellen gemeldet werden. Drei Kanäle also, aus denen etwas hereinkommt:
- Öffentliche Schwachstellendatenbanken. Eine Schwachstelle gilt als bekannt, sobald sie in einschlägigen öffentlich zugänglichen Datenbanken steht, etwa in der europäischen Schwachstellendatenbank, sagt der Leitfaden. Schon beim Auswählen fremder Komponenten nennt Erwägungsgrund 34 die Prüfung gegen solche Datenbanken als eine der möglichen Sorgfaltsmaßnahmen.
- Ihre eigenen Tests. Anhang I Teil II Nummer 3 verlangt, dass Sie die Sicherheit des Produkts regelmäßig und wirksam testen. „Regelmäßig” heißt nach dem Leitfaden nicht, dieselbe Testkampagne mechanisch zu wiederholen, sondern laufend zu prüfen, ob neue Bedrohungen oder Funde die Tests verändern, und dann entsprechend zu testen.
- Meldungen von außen. Anhang I Teil II Nummer 5 verlangt eine Strategie, wie Sie Schwachstellen koordiniert offenlegen, Nummer 6 Maßnahmen, die den Austausch darüber erleichtern, darunter eine Kontaktadresse. Wie das nach außen aussieht, beschreibt ISO/IEC 29147, wie Sie intern damit umgehen, ISO/IEC 30111.
Ohne Software-Stückliste (SBOM) nach Anhang I Teil II Nummer 1 können Sie keinen dieser Kanäle auf Ihr Produkt beziehen. Verlangt sind mindestens die obersten Abhängigkeiten, für einen belastbaren Abgleich reicht das selten. Die SBOM sagt Ihnen, ob eine Meldung Ihr Produkt trifft. Ob sie etwas bedeutet, sagt sie nicht.
Eine CVE in einer Komponente ist noch kein Befund
Der zweite Irrtum ist der teurere. Er lautet: Was in der Datenbank steht, muss weg.
Der CRA verlangt das nicht. Anhang I Teil I Nummer 2 Buchstabe a fordert, dass Sie Ihr Produkt „ohne bekannte ausnutzbare Schwachstellen” bereitstellen, soweit das auf Ihr Produkt zutrifft, und zwar auf Grundlage der Risikobewertung nach Artikel 13 Absatz 2. Ausnutzbar ist eine Schwachstelle nach Artikel 3 Nummer 41 dann, wenn ein unbefugter Dritter sie „unter praktischen Betriebsbedingungen” wirksam nutzen kann. Nicht jede Schwachstelle lässt sich unter praktischen Betriebsbedingungen ausnutzen, manche nur im Labor oder in der Simulation. Und dass jemand eine Schwachstelle gemeldet oder gefunden hat, heißt für sich genommen weder, dass sie sich in der Praxis ausnutzen lässt, noch dass sie Ihr Produkt überhaupt betrifft. Das müssen Sie untersuchen.
Ein Beispiel, wie es im Maschinenbau typisch ist. Auf einem Industrie-PC in einer Maschine läuft eine BusyBox-Version mit einer eingetragenen Schwachstelle, der Scanner meldet einen Treffer. Ob daraus ein Befund wird, hängt an einer Frage: Kommt im realen Betrieb irgendjemand oder irgendetwas an die verwundbare Funktion heran? Wenn kein regulärer Nutzer sie aufrufen kann und kein Skript sie so aufruft, dass die Schwäche zum Tragen kommt, läuft sie in diesem Produkt ins Leere. Sie steht dann in der Liste, sie steht in der Bewertung, und Sie patchen sie nicht.
Das ist keine Grauzone, die Sie sich zurechtlegen. Beim Inverkehrbringen ist die Pflicht ausdrücklich risikobasiert: Sie entscheiden auf Grundlage der Risikobewertung, ob Sie das Produkt sicher in Verkehr bringen können, und richten sich dabei nach Schweregrad, Ausnutzbarkeit und möglicher Auswirkung. Für das Produkt im Feld gilt dasselbe über Anhang I Teil II Nummer 2: Schwachstellen behandeln und beheben Sie dort „im Hinblick auf die Risiken” unverzüglich. Der Risikobezug steht im Normtext selbst.
Was aus der Bewertung folgt
Jede Meldung, die bei Ihnen eingeht, landet in einem von vier Ausgängen.
| Was die Prüfung ergibt | Was Sie tun |
|---|---|
| Komponente nicht verbaut oder Version nicht betroffen | nachvollziehbar festhalten, dass Sie geprüft haben, sonst nichts |
| verbaut, aber unter praktischen Betriebsbedingungen nicht ausnutzbar | Bewertung mit Begründung dokumentieren, nicht patchen, die Schwachstelle an den Hersteller oder Maintainer der Komponente melden |
| verbaut und ausnutzbar | risikoorientiert beheben, Update bereitstellen, danach veröffentlichen, was Sie behoben haben, und ebenfalls den Komponenten-Maintainer informieren |
| verbaut und aktiv ausgenutzt | zusätzlich an CSIRT und ENISA melden und die Nutzer informieren |
Dass Sie den Komponenten-Maintainer informieren, steht in Artikel 13 Absatz 6, und es gilt auch dann, wenn die Schwachstelle in Ihrem Produkt gar nicht ausnutzbar ist. Bei quelloffenen Komponenten geht die Meldung an das Projekt, nicht an eine Behörde.
Nach Artikel 13 Absatz 7 dokumentieren Sie außerdem alle relevanten Cybersicherheitsaspekte Ihres Produkts systematisch und risikoangemessen, einschließlich der Schwachstellen, von denen Sie erfahren. Wir lesen das so, dass auch das Nein dazugehört. Wer im Audit nicht zeigen kann, warum eine bekannte Schwachstelle folgenlos blieb, steht schlechter da als jemand, der gepatcht hat.
Werkzeuge liefern Treffer, keine Bewertung
Damit ist auch die Toolfrage geklärt, die in Projekten meist zuerst kommt. Scanner für die Software-Zusammensetzung, SBOM-Plattformen und Abgleichdienste beantworten genau eine Frage: Steckt diese Komponente in dieser Version bei Ihnen drin? Das können sie gut, und bei nennenswerter Produktvielfalt schaffen Sie es ohne sie nicht.
Weiter kommen sie nicht. Ob die betroffene Funktion in Ihrem Produkt erreichbar ist, ob ein Angreifer unter praktischen Betriebsbedingungen an sie herankommt und welches Risiko daraus folgt, weiß kein Werkzeug, das Ihr Produkt nicht kennt. Wer ein Tool kauft, bevor er weiß, wie er bewertet, bekommt eine lange Liste offener Punkte und kein Verfahren, sie abzuarbeiten. Erst legen Sie fest, wie Sie bewerten und dokumentieren. Dann automatisieren Sie, was sich automatisieren lässt.
Schwachstellenmanagement heißt trennen, bewerten, dokumentieren
Bis zum 11. September 2026 brauchen Sie wenig: einen Zugang zur Meldeplattform, jemanden, der melden darf, samt Vertretung, einen schnellen ersten Blick auf jeden Hinweis und einen Draht zu Ihren Nutzern. Woher ein Hinweis kommt, spielt dafür keine Rolle.
Die Arbeit kommt zum 11. Dezember 2027. Dann müssen die Quellen laufen, Sie müssen bewerten können, und die Nachweise müssen da sein. Für Produkte, die Sie vorher in Verkehr gebracht haben, greift diese Pflicht erst mit der nächsten wesentlichen Änderung.
Gemeldet wird, was angegriffen wurde. Behoben wird, was in Ihrem Produkt wirklich ausnutzbar ist. Alles andere bewerten und dokumentieren Sie.
Kommentar hinzufügen