CRA-Software für Meldefristen und Schwachstellen
Der Cyber Resilience Act verlangt eine Frühwarnung binnen 24 Stunden, sobald Sie von der aktiven Ausnutzung einer Schwachstelle in Ihrem Produkt erfahren. Unsere Plattform führt Ihre Produkte, Stücklisten und Schwachstellen so, dass Sie diese Frist halten und hinterher belegen können, dass Sie sie gehalten haben.
Die Uhr läuft ab Kenntnisnahme, nicht ab Bestätigung
Ein Kunde ruft am Freitagnachmittag an. Sein Gerät verhält sich seltsam, jemand ist offenbar drin. Ab diesem Moment laufen 24 Stunden — und niemand im Haus weiß auf Anhieb, welche Produkte dieselbe Komponente enthalten.
Drei Fristen, zwei Ereignisarten, ein Ansprechpartner
Frühwarnung nach 24 Stunden, Meldung nach 72, Abschlussbericht nach 14 Tagen oder einem Monat — je nachdem, ob es eine ausgenutzte Schwachstelle oder ein schwerwiegender Vorfall ist. In den meisten Betrieben hängt das an einer einzelnen Person, die auch noch die CE-Dokumentation macht.
Die Frage ist nicht die Schwachstelle, sondern die Reichweite
Eine Meldung betrifft nie nur ein Gerät. Steckt die betroffene Bibliothek in drei Produktlinien und sieben Varianten, muss das in der Meldung stehen. Wer das aus Gedächtnis und Excel zusammensucht, verliert die halbe Frist.
Bußgeld bis 15 Millionen Euro oder 2,5 Prozent
So hoch ist der Rahmen für Verstöße gegen die grundlegenden Anforderungen und die Melde- und Sorgfaltspflichten. Im Streitfall zählt nicht, dass Sie sorgfältig waren, sondern dass Sie es belegen können.
So sieht die Frist aus, wenn sie läuft
Ein Vorgang, drei Schritte, je eine Uhr. Der Meldetext ist bereits aus den erfassten Daten vorformuliert — Hersteller, Produkt, betroffene Versionen, Zeitpunkt der Kenntnisnahme, Rechtsgrundlage.
- Die Uhr startet mit dem Zeitpunkt, den Sie als Kenntnisnahme eintragen. Ein Vorgang darf rückdatiert erfasst werden; die Bewertung ist dann ehrlich rot.
- Jeder Schritt nennt seine Rechtsgrundlage und listet auf, was inhaltlich hineingehört.
- Sobald Sie die Abgabe bestätigen, ist der Text unveränderlich und liegt mit Zeitstempel im Protokoll.
Woher Sie erfahren, dass es Sie betrifft
Die Plattform gleicht die Komponenten aller Ihrer Releases täglich gegen öffentliche Schwachstellendatenbanken ab. Jeder Treffer nennt die betroffenen Produkte, nicht nur die betroffene Bibliothek.
- Der KEV-Katalog der CISA führt Schwachstellen, die nachweislich aktiv ausgenutzt werden. Ein Eintrag löst die Prüfung der Meldepflicht aus — er ist ein Indiz, keine Feststellung für Ihr Produkt.
- Jeder Befund braucht eine Entscheidung: betroffen, nicht betroffen mit Begründung, oder behoben. Die Begründungen folgen dem VEX-Standard.
- Aus einem Befund wird auf Knopfdruck ein Meldevorgang. Die betroffenen Produkte kommen aus den Stücklisten, nicht aus dem Gedächtnis.
Die Grundlage ist die Stückliste
Der CRA verlangt eine Software-Stückliste in einem gängigen maschinenlesbaren Format. Sie ist keine Fleißaufgabe für die Akte, sondern die Datenbasis: Ohne sie weiß niemand, welche Meldung welches Produkt betrifft.
- CycloneDX und SPDX werden gelesen, einschließlich Abhängigkeitsgraph — direkte und mitgezogene Komponenten sind unterscheidbar.
- Von jeder eingelesenen Datei bleibt eine SHA-256-Prüfsumme. Damit ist belegbar, welche Stückliste zu welchem Release gehört.
- Komponenten ohne Kennung werden als „nicht prüfbar" ausgewiesen statt stillschweigend als unauffällig.
Was die Plattform tut
Sechs Bausteine, die zusammen den Weg von der Produkteinordnung bis zum prüffesten Nachweis abdecken.
Produkte einordnen — und die Einordnung begründen
Jedes Produkt, je Variante, wird einer Kategorie aus Anhang III oder IV zugeordnet oder als Standardprodukt eingestuft. Daraus folgt der Bewertungsweg: Selbstbewertung, Selbstbewertung nur bei vollständiger Anwendung harmonisierter Normen, oder zwingend eine notifizierte Stelle. Die Begründung ist Pflichtfeld und wird protokolliert — im Streitfall ist genau sie die Frage.
Stücklisten je Release führen
CycloneDX und SPDX als JSON, mit Abhängigkeitsgraph. Gespeichert werden Prüfsumme, erzeugendes Werkzeug und Inhalt als Komponenten. Dieselbe Bibliothek in fünf Produkten ist eine Zeile im Register — und ein Treffer ist damit sofort für alle fünf sichtbar.
Schwachstellen automatisch abgleichen
Der Abgleich läuft gegen OSV.dev für Open-Source-Komponenten und gegen die NVD des NIST für Firmware-Bestandteile mit CPE. Dazu kommt der KEV-Katalog der CISA als Auslöser für die Prüfung der Meldepflicht. Fällt eine Quelle aus, läuft der Abgleich weiter und nennt den Ausfall im Protokoll — statt still keine Treffer zu melden.
Triage, die Bestand hat
Jeder Befund bekommt einen Status nach dem VEX-Standard: in Prüfung, betroffen, nicht betroffen mit Begründungscode, behoben. Eine einmal getroffene Entscheidung überlebt jeden weiteren Abgleich. Sonst wäre die Arbeit eines Monats nach einem Knopfdruck weg.
Fristen führen und Meldetexte vorbereiten
Für aktiv ausgenutzte Schwachstellen und für schwerwiegende Sicherheitsvorfälle je drei Schritte mit eigener Frist. Der Meldetext entsteht aus den Vorgangsdaten und nennt die Rechtsgrundlage. Fehlende Angaben stehen sichtbar als Lücke im Text, damit Sie sehen, was der Behörde fehlen würde.
Nachweisen, dass die Frist gehalten wurde
Jede Handlung landet in einem Protokoll, in dem jeder Eintrag den Hash seines Vorgängers trägt. Abgegebene Meldungen sind unveränderlich und liegen im Wortlaut im Protokoll. Eine nachträgliche Änderung reißt die Kette und ist auf Knopfdruck erkennbar.
Die Stichtage
Zwei Verordnungen, vier Termine. Die Plattform führt sie als Konfiguration, nicht als Programmcode — verschiebt der Gesetzgeber etwas, ist das eine geänderte Datei.
- 11.09.2026
Meldepflichten nach Art. 14 CRA
Ab diesem Tag gelten die 24- und 72-Stunden-Fristen. Sie greifen unabhängig davon, ob die übrigen Anforderungen schon anwendbar sind.
- 20.01.2027
Maschinenverordnung (EU) 2023/1230
Ohne Übergangsfrist: Maschinen, die ab diesem Tag in Verkehr gebracht werden, müssen ihr entsprechen. Vorher in Verkehr gebrachte bleiben unter der alten Richtlinie.
- 11.12.2027
CRA vollständig anwendbar
Grundlegende Anforderungen nach Anhang I, Konformitätsbewertung, technische Dokumentation, CE-Kennzeichnung.
- laufend
Unterstützungszeitraum
Mindestens fünf Jahre, kürzer nur bei nachweislich kürzerer erwarteter Nutzungsdauer. Sicherheitsaktualisierungen bleiben mindestens zehn Jahre verfügbar.
Für wen wir das gebaut haben
Der Filter ist nicht die Branche, sondern die Struktur: Sie bringen ein Produkt mit digitalen Elementen in Verkehr, haben zwischen 30 und 500 Mitarbeiter, führen zwischen 5 und 100 aktive Varianten — und keine eigene Produktsicherheitsabteilung.
Komponentenhersteller
Steuerungen, Gateways, Sensorik, Antriebstechnik. Industrielle Gateways und Netzwerkschnittstellen fallen häufig in Anhang III; bei Klasse II ist eine notifizierte Stelle zwingend.
Gebäude- und Sicherheitstechnik
Zutrittskontrolle, intelligente Türschlösser und Sicherheitskameras stehen namentlich in Anhang III. Dazu Steuerungen für Heizung, Lüftung und Aufzüge.
Sonder- und Anlagenbau mit SPS und HMI
Das Volumensegment. Die meisten Produkte sind Standardprodukte mit Selbstbewertung — dort trägt der Hersteller die Dokumentation vollständig selbst, und dort hilft Software am meisten.
Energie- und Ladeinfrastruktur
Wechselrichter, Ladepunkte, Batteriespeicher, Messtechnik. Vernetzt, langlebig, im Feld schwer zu aktualisieren — genau die Kombination, auf die der CRA zielt.
Softwareanbieter ohne CE-Routine
Wer Software als eigenständiges Produkt in Verkehr bringt, ist ebenfalls Hersteller im Sinne des CRA. Dieser Fall wird oft übersehen, weil es noch nie eine CE-Kennzeichnung gab.
Betriebe mit Maschinen und digitalen Elementen zugleich
Ab 20.01.2027 gilt die Maschinenverordnung ohne Übergangsfrist, mit erstmals eigenen Cybersicherheitsanforderungen. Dieselben Produkte, zwei Rechtsakte, zwei Fristen hintereinander.
Was die Plattform nicht ist
- Keine Rechtsberatung. Ob Ihr Produkt unter Anhang III fällt und ob eine Schwachstelle aktiv ausgenutzt wird, entscheiden Sie. Die Plattform bietet die Kategorien an, leitet daraus den Bewertungsweg ab und protokolliert Ihre Begründung.
- Keine automatische Übermittlung an die Behörde. Die zentrale Meldeplattform der ENISA hat bislang keine öffentliche Schnittstelle. Wir liefern Text, Frist und Nachweis; abgegeben wird die Meldung von Ihnen, und Sie bestätigen hier den Zeitpunkt.
- Kein Ersatz für ein Schwachstellenmanagement im Entwicklungsteam. Die Plattform findet und ordnet, sie behebt nicht. Wer keine Update-Infrastruktur hat, braucht zuerst die.
- Kein Werkzeug, das Ihnen die Einordnung abnimmt. Ein Programm, das Ihnen sagt, Ihr Gerät sei ein Standardprodukt, wäre im Zweifel wertlos — die Verantwortung bleibt beim Hersteller, also bleibt auch die Entscheidung dort.
Häufige Fragen
Ab wann müssen wir melden?
Die Meldepflichten nach Art. 14 CRA gelten ab dem 11. September 2026. Sobald Sie von der aktiven Ausnutzung einer Schwachstelle in Ihrem Produkt oder von einem schwerwiegenden Sicherheitsvorfall erfahren, haben Sie 24 Stunden für die Frühwarnung und 72 Stunden für die eigentliche Meldung. Der Abschlussbericht folgt 14 Tage nach Bereitstellung der Abhilfe beziehungsweise einen Monat nach der Vorfallmeldung.
Wann genau startet die 24-Stunden-Frist?
Mit der Kenntnisnahme, nicht mit der Bestätigung. Wer wartet, bis die Ausnutzung technisch zweifelsfrei belegt ist, hat die Frist meist schon verloren. Die Frühwarnung darf ausdrücklich vorläufig sein — sie ist eine Warnung, kein Abschlussbericht. Die Plattform ist so gebaut, dass ein Vorgang in zwei Minuten erfasst ist und der Rest nachgetragen wird.
Wir bauen Maschinen, keine Software. Betrifft uns der CRA?
Sobald ein Produkt digitale Elemente enthält und mit einem Gerät oder Netz verbunden werden kann, fällt es in den Anwendungsbereich. Eine Steuerung mit Ethernet-Schnittstelle ist ein Produkt mit digitalen Elementen, auch wenn Ihr Geschäft der Maschinenbau ist. Ab 20.01.2027 kommt zusätzlich die Maschinenverordnung mit eigenen Cybersicherheitsanforderungen.
Brauchen wir eine notifizierte Stelle?
Das hängt an der Einordnung. Standardprodukte, das ist die große Mehrheit, dürfen der Hersteller selbst bewerten. Bei wichtigen Produkten der Klasse I geht die Selbstbewertung nur, wenn harmonisierte Normen oder gemeinsame Spezifikationen vollständig angewendet werden. Bei Klasse II und bei kritischen Produkten nach Anhang IV ist eine notifizierte Stelle zwingend. Die Plattform zeigt Ihnen die Folge Ihrer Einordnung sofort an.
Was ist eine SBOM und brauchen wir wirklich eine?
Eine Software-Stückliste listet die Bestandteile Ihres Produkts mit Version und Herkunft. Der CRA verlangt sie in einem gängigen maschinenlesbaren Format als Teil der technischen Dokumentation; sie muss nicht veröffentlicht, aber der Marktüberwachung auf Verlangen vorgelegt werden. Praktisch ist sie die Voraussetzung dafür, überhaupt zu wissen, welche Meldung welches Produkt betrifft.
Woher kommen die Schwachstellendaten?
Aus OSV.dev für Komponenten aus Open-Source-Ökosystemen, aus der National Vulnerability Database des NIST für Bestandteile mit CPE-Kennung, und aus dem Katalog aktiv ausgenutzter Schwachstellen der CISA. Die europäische Schwachstellendatenbank der ENISA ist vorgemerkt, sobald ihre Schnittstelle dokumentiert ist. Alle Quellen sind austauschbar konfiguriert.
Können wir das nicht selbst bauen?
Technisch ja. In der Praxis scheitert es an drei Dingen: Der schwierige Teil ist nicht der Code, sondern die Einordnung und die Datenpflege. Ein eigener Abgleich erzeugt schnell zweihundert Meldungen am Tag und wird nach vier Wochen stummgeschaltet. Und Entwicklerzeit ist im Maschinenbau das knappste Gut — ein internes Compliance-Register verliert jede Priorisierung gegen umsatzbringende Features. Deshalb wird es meist nicht gebaut, sondern in Excel geführt.
Wo liegen unsere Daten?
Die Plattform läuft als eigene Instanz je Unternehmen — auf Wunsch im eigenen Rechenzentrum oder bei einem österreichischen beziehungsweise europäischen Hoster. Angaben zu Schwachstellen im eigenen Produkt sind vor der Meldung heikel; sie verlassen das Haus nur als Meldung, die Sie selbst abgeben.
Was passiert, wenn sich die Rechtslage ändert?
Alles Rechtslage-Abhängige liegt als deklarative Konfiguration vor: Fristen, Kategorien aus Anhang III und IV, Bewertungswege, Pflichtinhalte je Meldeschritt, Textvorlagen, Unterstützungszeitraum. Eine Änderung ist eine angepasste Datei und ein Neustart — kein Software-Release und keine Wartezeit auf einen Hersteller. Sobald die ENISA-Plattform Formularfelder vorgibt, richten wir die Vorlagen daran aus.
Ab wann lohnt sich das?
Rechnen Sie mit Ihren eigenen Zahlen. Marktübliche Schätzungen für die CRA-Bereitschaft eines Herstellers mit fünf Produktlinien liegen im mittleren fünfstelligen Bereich, allein die Update-Infrastruktur darüber. Laufend gehen zehn bis zwanzig Prozent des Entwicklungsbudgets ins Schwachstellenmanagement. Wer weniger als fünf Varianten führt, kommt mit einer sorgfältigen Tabelle weit. Ab etwa zehn gepflegten Varianten kippt die Rechnung.
Der beste Zeitpunkt ist vor dem ersten Anruf
Ein Meldevorgang lässt sich nicht vorbereiten, während die Uhr läuft. Was vorher steht, ist das Produktregister, die Stückliste und die Frage, wer im Haus die Meldung abgibt. Wir zeigen Ihnen die Plattform an Ihren eigenen Produkten: Betroffenheit klären, eine Stückliste einlesen, den ersten Abgleich laufen lassen.