CRA Compliance Software auswählen: acht Kriterien

01Kurz gesagt

• Der CRA verlangt nicht, eine Software zu kaufen. Er verlangt Ergebnisse: eine SBOM, Schwachstellenbehandlung, technische Dokumentation, Meldungen nach Artikel 14 und Sicherheitsupdates während des gesamten Unterstützungszeitraums.
• Bei Embedded-Produkten ist das erste Kriterium, ob die Software Komponenten in Ihrem eigenen Firmware-Image findet und klar sagt, was sie nicht gefunden hat.
• Eine einzige Schwachstellenquelle reicht nicht. Artikel 14 wird durch Nachweise aktiver Ausnutzung ausgelöst, nicht durch einen Wahrscheinlichkeitswert.
• Eine Fundliste allein genügt nicht. Ihre Entscheidung zu jedem Fund muss als VEX und die technische Dokumentation je Version aufbewahrt werden.
• Keine Software macht ein Produkt allein CRA-konform; die Konformität wird für das Produkt bewertet.

02Zuerst den eigenen Bedarf aufschreiben

Beginnen Sie die Auswahl mit einer Liste der Aufgaben, die der CRA für Ihre Produkte mit sich bringt. Für einen Hersteller, der Produkte auf dem EU-Markt in Verkehr bringt, sind das im Kern:

• Schwachstellenbehandlung (Anhang I Teil II): Komponenten ermitteln, eine SBOM erstellen, die zumindest die obersten Abhängigkeiten erfasst, Schwachstellen unverzüglich beheben und Sicherheitsupdates verteilen.
• Technische Dokumentation (Anhang VII): Risikobewertung, Nachweis, wie jede Anforderung aus Anhang I erfüllt wird, SBOM und Testnachweise. Technische Dokumentation und EU-Konformitätserklärung werden mindestens zehn Jahre nach dem Inverkehrbringen oder für den Unterstützungszeitraum aufbewahrt, je nachdem, welcher Zeitraum länger ist (Artikel 13 Absatz 13).
• Meldungen (Artikel 14): aktiv ausgenutzte Schwachstellen und schwerwiegende Vorfälle über die Single Reporting Platform (SRP) der ENISA innerhalb der Fristen von 24 Stunden, 72 Stunden und für den Abschlussbericht melden. Diese Pflicht gilt seit dem 11. September 2026.
• Unterstützungszeitraum (Artikel 13 Absatz 8): Schwachstellen während eines Unterstützungszeitraums überwachen und beheben, der der erwarteten Nutzungsdauer des Produkts entspricht.

Legen Sie fest, was Ihr eigenes Team übernimmt, was eine Software leisten soll und wofür Sie externe Unterstützung brauchen. Wenn Sie die Produktklasse noch nicht kennen, beginnen Sie mit dem CRA-Klassencheck; die Klasse bestimmt das Konformitätsbewertungsverfahren und wie viel externe Unterstützung Sie voraussichtlich brauchen.

03Acht Auswahlkriterien

1. SBOM aus der Firmware

Bei Embedded-Produkten fehlt die SBOM selten ganz; meist ist sie unvollständig. Statisch gelinkte Bibliotheken, das RTOS und das SDK des Chipherstellers sowie Komponenten, die Zulieferer als Binärdateien liefern, tauchen in der Liste des Build-Systems oft nicht auf. Mehr dazu in Was ist eine SBOM?.

• Öffnet die Software Ihre Image-Formate (Rohbinärdatei, Dateisystem, Intel HEX, ELF)?
• Sagt sie klar, welche Komponenten sie nicht gefunden oder keiner Version zuordnen konnte?
• Kann sie die SBOM Ihres Build-Systems importieren und mit dem Image abgleichen?
• Exportiert sie das Ergebnis als CycloneDX und SPDX?

2. Schwachstellenquellen

Ein Abgleich gegen eine einzige Datenbank übersieht Schwachstellen. Die NVD ergänzt nicht jeden Eintrag um Produktkennungen (CPE), und Schwachstellen in Embedded-Bibliotheken und Chip-SDKs erscheinen oft zuerst in den Sicherheitshinweisen des Projekts oder Herstellers.

• Welche Quellen werden genutzt: NVD, OSV, Einträge des CVE-Programms, Herstellerhinweise?
• Ist jeder Fund mit seiner Quelle verlinkt?
• Wie oft werden die Quellen aktualisiert, und meldet die Software, wenn eine Quelle nicht aktualisiert werden konnte?

3. Nachweis aktiver Ausnutzung

Die 24-Stunden-Frist nach Artikel 14 beginnt, sobald Sie Kenntnis davon erlangen, dass eine Schwachstelle aktiv ausgenutzt wird. Die Software sollte Ausnutzungsnachweise (der CISA-KEV-Katalog, die Liste ausgenutzter Schwachstellen in der EUVD der ENISA) daher von Wahrscheinlichkeitswerten trennen. FIRST EPSS schätzt, wie wahrscheinlich die Ausnutzung einer Schwachstelle ist; das hilft bei der Priorisierung, ist aber kein Nachweis einer Ausnutzung.

• Werden Funde mit Ausnutzungsnachweis gesondert markiert?
• Wer entscheidet über einen Fund, der eine Meldung nach Artikel 14 auslösen könnte?

4. VEX und Analystenentscheidungen

Ein Teil der Schwachstellen in einem Embedded-Image betrifft Code, der im Produkt nicht kompiliert wird oder nie läuft. Das zu unterscheiden ist eine Analystenentscheidung und sollte mit Begründung festgehalten werden. VEX (Vulnerability Exploitability eXchange) gibt maschinenlesbar an, ob eine Schwachstelle das Produkt betrifft.

• Wird zu jedem Fund eine Entscheidung mit Begründung festgehalten, samt wer wann entschieden hat?
• Werden CSAF-VEX- oder OpenVEX-Dokumente erzeugt und gegen das offizielle Schema validiert?
• Werden frühere Entscheidungen korrekt in eine neue Firmware-Version übernommen?

5. Technische Dokumentation

Die technische Dokumentation kann eine Marktüberwachungsbehörde anfordern. Was die Software erzeugt, sollte kein Bericht sein, sondern eine Dokumentation, die der Struktur von Anhang VII folgt und an eine Produktversion gebunden ist.

• Werden zu jeder Anforderung aus Anhang I Status, Entscheidung und Nachweis festgehalten?
• Erzeugt sie die technische Dokumentation und einen Entwurf der EU-Konformitätserklärung?
• Lässt sich die Dokumentation zu einem Stichtag einfrieren (Signatur, Zeitstempel) und in Formaten exportieren, die auch in Jahren noch lesbar sind (PDF, JSON)?

6. Meldungen nach Artikel 14

Meldungen erfolgen über die Single Reporting Platform (SRP) der ENISA. Die erste Version der Plattform hat keine API; Meldungen werden über die Weboberfläche eingegeben (SRP-Leitfaden). Eine Software kann eine Meldung also nicht für Sie absenden; sie kann die Fristen überwachen und das Formular vorbereiten.

• Werden die Fristen von 24 Stunden, 72 Stunden und für den Abschlussbericht ab dem Zeitpunkt der Kenntnis überwacht?
• Werden die Formularfelder in der Reihenfolge der SRP vorbereitet, und gibt es Hilfe bei der Wahl des koordinierenden CSIRT nach Artikel 14 Absatz 7?
• Wird jede abgesendete Meldung mit Datum aufbewahrt?

7. Hosting und Daten

Der CRA schreibt nicht vor, dass Daten in der EU gespeichert werden. Firmware-Images und nicht behobene Schwachstellen sind aber als Geschäftsgeheimnisse und für die Sicherheit Ihre sensibelsten Daten; Vorfallsunterlagen und Gerätetelemetrie können zudem personenbezogene Daten enthalten. Deshalb fragen Ihre Kunden, wo die Daten verarbeitet werden; für die Teile mit personenbezogenen Daten sind außerdem die Regeln von DSGVO und KVKK zur Übermittlung ins Ausland zu prüfen.

• In welchem Land liegt das Rechenzentrum, und wer sind die Unterauftragsverarbeiter?
• Wie werden die Daten verschiedener Kunden voneinander getrennt?
• In welchem Format und wie schnell werden Ihre Daten bei Vertragsende herausgegeben und gelöscht?

8. Versionen und Unterstützungszeitraum

Die Pflichten aus dem CRA enden nicht mit der Auslieferung. Die Software sollte jede Firmware-Version getrennt führen, die Komponenten ausgelieferter Versionen weiter auf neue Schwachstellen überwachen und an das Ende des Unterstützungszeitraums erinnern.

04Arten von Software und für wen sie passen

Die Lösungen am Markt lassen sich grob in drei Gruppen einteilen. Die Grenzen sind nicht scharf, und ein Produkt kann mehrere Gruppen abdecken. Die Tabelle zeigt allgemeine Tendenzen, kein bestimmtes Produkt.

Die meisten Hersteller kombinieren: Sie bauen Prozesse mit einer Beratung auf und überlassen die Daueraufgaben (SBOM, Schwachstellenüberwachung, Entscheidungen, Dokumente, Meldefristen) einer Software. Achten Sie bei der Auswahl weniger auf die Art als darauf, welche der oben genannten Kriterien erfüllt sind.

05Fragen an Anbieter

1. Können wir mit unserem eigenen Firmware-Image testen und sehen, welche Komponenten nicht gefunden wurden?
2. Welche Schwachstellenquellen nutzen Sie, und wie sehen wir die Quelle eines Fundes?
3. Wie trennen Sie Nachweise aktiver Ausnutzung von Wahrscheinlichkeitswerten wie EPSS?
4. In welchem Format liegt Ihr VEX vor, und welchen Validator besteht es?
5. Welche Teile von Anhang VII deckt die technische Dokumentation ab, und welche schreiben wir selbst?
6. Ab welchem Zeitpunkt laufen bei Ihnen die Fristen nach Artikel 14, und welche Felder des Meldeformulars bereiten Sie vor?
7. In welchem Land werden unsere Daten gespeichert, und wer sind Ihre Unterauftragsverarbeiter?
8. In welchem Format erhalten wir unsere Daten und Dokumente bei Vertragsende?
9. Wie trennen Sie Funktionen auf der Roadmap von Funktionen, die in Betrieb sind?

06Aussagen, die Sie genau lesen sollten

• „CRA-zertifizierte Software“: Der CRA genehmigt oder zertifiziert keine Compliance-Software. Die Konformität wird für das Produkt bewertet, durch den Hersteller oder eine notifizierte Stelle.
• „Automatische Konformität“: Software sammelt Nachweise und bereitet Dokumente vor; Risikoentscheidungen, Schwachstellenentscheidungen und die Konformitätserklärung liegen beim Hersteller.
• „Automatische Übermittlung an die SRP“: Die erste Version der SRP hat keine API. Ändert sich das, kündigt die ENISA es an; vergleichen Sie die Aussage mit der Seite der ENISA.
• Ein Qualitätswert ist keine Konformität: Eine SBOM mit allen Feldern ist nicht automatisch korrekt.

07Unser Ansatz

Wir haben TegmenSoft entlang dieser Kriterien aufgebaut. Heute in Betrieb auf der Plattform:

• SBOM aus der Firmware: öffnet Rohbinärdateien, Dateisysteme, Intel HEX, S-Record und ELF und nennt klar, was nicht gefunden wurde; importiert die CycloneDX- oder SPDX-SBOM Ihres Build-Systems und gleicht sie mit der Analyse ab.
• Quellen: NVD, OSV, Einträge des CVE-Programms und Herstellerhinweise; jeder Fund ist mit seiner Quelle verlinkt, eine nicht aktualisierte Quelle wird mit Datum gemeldet.
• Ausnutzungsnachweis: Schwachstellen, die laut CISA KEV oder ENISA EUVD ausgenutzt werden, werden vorgezogen und als Kandidaten für Artikel 14 markiert; EPSS dient nur der Reihenfolge. Die Entscheidung bleibt bei Ihnen.
• VEX: Analystenentscheidungen werden mit Begründung festgehalten; CSAF-VEX- und OpenVEX-Dokumente bestehen den offiziellen Validator.
• Technische Dokumentation: Anforderungskarten zu Anhang I, Risikobewertung und Entwurf der EU-Konformitätserklärung; die technische Dokumentation nach Anhang VII wird als PDF und JSON signiert und mit einem RFC-3161-Zeitstempel eingefroren.
• Artikel 14: Die Fristen von 24 Stunden, 72 Stunden und für den Abschlussbericht werden überwacht, das SRP-Formular wird vorbereitet und ein koordinierendes CSIRT nach Artikel 14 Absatz 7 vorgeschlagen; jede Übermittlung wird signiert und mit Zeitstempel archiviert.
• Hosting: Die Plattform läuft in einem Rechenzentrum in Deutschland, und jede Abfrage ist auf Ihren Mandanten beschränkt.
• Unterstützungszeitraum: Der Unterstützungszeitraum jedes Produkts wird erfasst, mit einer Warnung vor dem Ende.

Manches machen wir nicht: Wir führen keine Konformitätsbewertung durch, ersetzen keine notifizierte Stelle und ersetzen keine Beratung beim ersten Aufbau Ihrer Prozesse. Eine SBOM können Sie im kostenlosen SBOM-Checker testen, oder Sie bewerben sich mit Ihrer eigenen Firmware für das Pilotprogramm.

08Häufige Fragen