CRA ist kein Schwachstellenscanner

Ein Hersteller, der den Cyber Resilience Act als „Firmware scannen und CVEs ablegen“ behandelt, scheitert an der Akte, auch mit einem guten Scanner. Die Verordnung (EU) 2024/2847 ist eine Produktsicherheitsregel für Produkte mit digitalen Elementen. Sie fragt, was Sie auf den Unionsmarkt bringen, welches Risiko Sie angenommen haben, woraus das Produkt besteht und wie Sie es im Supportzeitraum halten.

Schwachstellenbehandlung bleibt. Sie ist eine Pflicht in Anhang I Teil II und in der Uhr nach Artikel 14. Sie ist nicht das Produkt.

Warum die Scanner-Geschichte in jedem Gespräch zurückkommt

Ein Scanner hat eine Demo. Ein PDE-Katalog nicht. Eine Risikozelle an Anhang I hängt in fünf Minuten kein Dashboard an. Deshalb ist das erste Werkzeug im CRA-Gespräch oft das, das die Security schon bezahlt.

Dieses Werkzeug beantwortet eine enge Frage: welche bekannten Schwächen stecken in diesem Build. Der CRA fragt breiter: dürfen Sie dieses Produkt in Verkehr bringen, und halten Sie es, wenn eine Behörde oder ein CSIRT anruft. Das sind andere Akten.

Wenn das einzige CRA-Artefakt, das Sie exportieren können, ein Schwachstellenbericht ist, haben Sie kein CRA-System. Sie haben einen Scanner mit neuem Folientitel.

Zuerst die Produktkarte

Hauptadressat ist der Hersteller: wer ein Produkt mit digitalen Elementen unter eigenem Namen oder Zeichen auf den Unionsmarkt bringt. Das kann ein Gerät, eigenständige Software oder eine separat verkaufte Komponente sein. Importeure und Händler haben eigene Pflichten. Ein Scan sieht das nicht.

Bevor Sie über CVE-Warteschlangen sprechen, brauchen Sie einen Katalog. Name, Version, Typ, Märkte, Datum der Bereitstellung, Supportende mit Monat und Jahr. Der CRA gilt pro Produkt, nicht einmal für die ganze Firma. Eine wesentliche Änderung ist ein neues Inverkehrbringen.

Ohne diese Karte wissen Sie nicht, welche SBOM zu welcher SKU gehört, welche Lücken in Anhang I offen sind und welches CSIRT Sie benachrichtigen, wenn am 11. September 2026 Artikel 14 startet. Ein Scanner ohne Produktidentität scannt einen Blob.

Risiko hängt an Anhang I, nicht an einer CVSS-Farbe

Artikel 13 will eine Risikobewertung über den Lebenszyklus, keine Folie vor dem Launch. Anhang I hat zwei Teile.

Teil I sind Produkteigenschaften: angemessenes Cybersicherheitsniveau zum Risiko, keine bekannten ausnutzbaren Schwachstellen beim Inverkehrbringen, sichere Defaults, Updates (einschließlich automatischer mit klarem Opt-out), Zugangskontrolle, Integrität, Vertraulichkeit, kleinere Angriffsfläche, Datenminimierung.

Teil II ist Schwachstellenbehandlung: identifizieren und dokumentieren, einschließlich SBOM; Patches im Supportzeitraum; Tests; öffentliche Disclosure-Politik; koordinierte Offenlegung; Fixes ohne unnötige Verzögerung.

Ein Scanner kann Teil II speisen. Er entscheidet nicht, ob das Default-Passwort noch admin heißt, ob sich das Update verweigern lässt oder ob die Angriffsfläche nach der Ferndiagnose gewachsen ist. Eine Lücke in einem Extra-Excel ist keine Bewertung. Die Risikozelle muss auf die Anforderung zeigen, die sie verfehlt.

„Keine bekannten ausnutzbaren Schwachstellen beim Inverkehrbringen“ ist auch nicht „der letzte Scan am Freitag war sauber“. Es ist eine Aussage über das Produkt, das das Lager verlässt, mit der SBOM dieser Version und einem Eigentümer, der sie verteidigt.

Die SBOM ist Nachweis, kein PDF in der Schublade

Die Sorgfalt gegenüber Drittkomponenten bleibt an der Komponente. Die SBOM muss zur tatsächlich ausgelieferten Version passen. Store-Version und SBOM, die nach zwei Sprints auseinanderlaufen, sind der übliche Fehler.

Die SBOM speist die Schwachstellenwarteschlange. Ab 11. September 2026 gilt Artikel 14 für aktiv ausgenutzte Schwachstellen und schwerwiegende Vorfälle. Frühwarnung in 24 Stunden, vollständige Meldung in 72 Stunden, dann Abschlussbericht, über die einheitliche Plattform an das CSIRT der Hauptniederlassung und an ENISA.

Ein Scanner, der 400 CVEs in ein Sheet kippt, gibt Ihnen keinen 24-Stunden-Eigentümer. Er gibt Rauschen. Der operative Schnitt: was davon steckt in der ausgelieferten SBOM, was wird aktiv ausgenutzt, welches Produkt trifft es, wer reicht die Frühwarnung ein.

Die technische Akte ist das, was eine Behörde verlangen kann

Ab 11. Dezember 2027 muss ein in Verkehr gebrachtes Produkt Anhang I erfüllen, die Konformitätsbewertung durchlaufen, eine EU-Erklärung und die CE-Kennzeichnung tragen. Die Marktüberwachung kann die Akte Jahre später verlangen.

Das ist kein Schwachstellenbericht. Es ist Produktidentität, Risikobewertung, Nachweise zu Anhang I, SBOM, Supportzeitraum, Anleitungen, Erklärung und Kennzeichnung. Fehlt eines, ist der CE-Pfad nicht geschlossen.

Die meisten Produkte der Standardklasse bleiben bei Modul A. Modul A braucht diese Akte trotzdem. Ein besserer Scanner 2027 schreibt die Erklärung nicht.

Wofür der Scanner im CRA taugt

Behalten Sie den Scanner. Zielen Sie auf den Build, der zur SBOM passt. Öffnen Sie damit Teil-II-Punkte und frischen Sie die Warteschlange auf. Benutzen Sie ihn nicht als:

• Produktkatalog,
• Bewertung nach Artikel 13,
• Checkliste zu Anhang I,
• Register der Supportzeiträume,
• EU-Erklärung,
• Playbook zu Artikel 14.

Diese Objekte haben Eigentümer, Daten und Produktschlüssel. Ein Finding hat das nicht.

Was das System hält

Crado AI ist um diese Schleife gebaut, nur on-premise:

1. PDE-Katalog - was Sie in Verkehr bringen.
2. Risiko und Anhang I - welche Anforderungen erfüllt sind, welche nicht.
3. SBOM - eigene und fremde Bestandteile, an CVE gebunden.
4. Artikel 14 - die 24h-/72h-Uhr.
5. Technische Akte und CE - was Sie zeigen, bevor das Produkt das Lager verlässt.

Schwachstellenbehandlung bleibt. Sie ist nicht das Produkt. Ist Ihr CRA-Plan eine Scanner-Verlängerung und ein CE-Workshop 2027, ist der Plan die Folie, nicht die Akte.