CRA technisch umsetzen: SBOM, Patch-Prozess, Meldung in 24 Stunden

Was der CRA von der Entwicklung verlangt

Die Verordnung (EU) 2024/2847 richtet sich an Hersteller von Produkten mit digitalen Elementen, die in der EU in Verkehr gebracht werden. Die grundlegenden Anforderungen stehen in Anhang I. Teil I beschreibt Eigenschaften des Produkts: keine bekannten ausnutzbaren Schwachstellen bei Auslieferung, sichere Standardkonfiguration, Schutz von Daten, Protokollierung. Teil II beschreibt den Umgang mit Schwachstellen über den gesamten Supportzeitraum: Komponenten kennen, Lücken unverzüglich beheben, Updates sicher verteilen, eine Richtlinie zur koordinierten Offenlegung führen.

Juristen klären, ob und in welcher Kategorie ein Produkt betroffen ist und wie die Konformitätsbewertung läuft. Fast alles andere ist Technik. Die harmonisierten Normen, die später beschreiben, wie ein Nachweis aussieht, sind noch nicht fertig. Die Anforderungen selbst ändern sich dadurch nicht. Dieser Artikel ist keine Rechtsberatung. Die rechtliche Bewertung bleibt bei Ihren Juristen. Er beschreibt, was ein Team technisch einrichten kann, ohne auf die Normen zu warten.

Zur Einordnung: Wer gegen Anhang I oder die Pflichten aus Artikel 13 und 14 verstößt, riskiert nach Artikel 64 Geldbußen bis 15 Millionen Euro oder 2,5 Prozent des weltweiten Jahresumsatzes. Es gilt der höhere Betrag.

Standard, wichtig oder kritisch: welche Klasse gilt?

Der CRA kennt drei Stufen: die Standardkategorie, in die die meisten Produkte fallen, wichtige Produkte nach Anhang III (unterteilt in Klasse I und Klasse II) und kritische Produkte nach Anhang IV. Maßgeblich ist nach Artikel 7 die Kernfunktion des Produkts: Wichtig ist nur, was selbst eine der gelisteten Funktionen erfüllt. Eine Maschine wird nicht zum wichtigen Produkt, weil ein Betriebssystem oder ein Router darin verbaut ist. Die Durchführungsverordnung (EU) 2025/2392 vom November 2025 beschreibt die Kategorien technisch genauer.

Klasse I umfasst unter anderem Identitäts- und Zugriffsmanagement, Browser, Passwort-Manager, VPN-Funktionen, Netzmanagement, SIEM, Bootmanager, PKI, Netzschnittstellen, Betriebssysteme, Router, Modems und Switches, Mikroprozessoren, Mikrocontroller, ASICs und FPGAs mit sicherheitsrelevanten Funktionen sowie bestimmte Smart-Home-Produkte, vernetztes Spielzeug und Gesundheits-Wearables. Klasse II: Hypervisoren und Container-Laufzeiten, Firewalls, Intrusion-Detection- und Intrusion-Prevention-Systeme, manipulationssichere Mikroprozessoren und Mikrocontroller. Kritisch nach Anhang IV sind Hardware mit Sicherheitsboxen, Smart-Meter-Gateways und andere Geräte für sichere kryptografische Verarbeitung sowie Chipkarten und Secure Elements.

Für den Maschinen- und Anlagenbau und für die meiste Geschäftssoftware heißt das: Steuerungen, HMIs, SCADA-Systeme und industrielle Automatisierungssysteme stehen nicht in der endgültigen Fassung der Anhänge. Der Kommissionsentwurf von 2022 führte sie noch als Klasse II. Sie fallen in die Standardkategorie. Anders kann es aussehen, wenn Sie eine Komponente mit eigener Sicherheitsfunktion separat in Verkehr bringen, etwa ein Router-Modul, ein Betriebssystem oder einen Mikrocontroller mit Sicherheitsfunktionen. Branchenverbände wie der VDMA stellen ihren Mitgliedern Einstufungshilfen bereit. Die Einordnung selbst bleibt eine rechtliche Bewertung.

Warum die Klasse technisch zählt: Sie entscheidet über das Konformitätsbewertungsverfahren nach Artikel 32. Standardprodukte bewertet der Hersteller selbst (interne Kontrolle, Modul A). Bei Klasse I ist die Selbstbewertung nur möglich, wenn harmonisierte Normen, gemeinsame Spezifikationen oder ein europäisches Zertifizierungsschema vollständig angewendet werden. Sonst ist eine notifizierte Stelle nötig (Modul B und C oder Modul H). Klasse II braucht immer eine notifizierte Stelle oder ein europäisches Schema mindestens der Vertrauenswürdigkeitsstufe "mittel". Für kritische Produkte kann die Kommission per delegiertem Rechtsakt eine europäische Zertifizierung vorschreiben. Bis dahin gilt das Verfahren der Klasse II. Wer eine notifizierte Stelle braucht, sollte früh planen: Die Stellen werden erst benannt, und die Nachfrage steigt zum Stichtag.

• Je Produkt die Kernfunktion in einem Satz festhalten und gegen Anhang III und IV sowie die technischen Beschreibungen der Durchführungsverordnung 2025/2392 prüfen
• Das Ergebnis mit Begründung in die technische Dokumentation aufnehmen, auch die Einstufung als Standardprodukt
• Bei Klasse I früh festlegen, welche harmonisierten Normen angewendet werden, sobald sie veröffentlicht sind. Das entscheidet über Selbstbewertung oder notifizierte Stelle
• Separat vermarktete Komponenten mit eigener Sicherheitsfunktion gesondert einstufen

SBOM automatisch in der Pipeline erzeugen

Anhang I Teil II Nr. 1 verlangt, die Komponenten des Produkts zu erfassen und zu dokumentieren. Dazu gehört eine Software Bill of Materials (SBOM) in einem gängigen, maschinenlesbaren Format, die mindestens die Top-Level-Abhängigkeiten abdeckt. Zwei Formate haben sich etabliert: CycloneDX von der OWASP Foundation und SPDX von der Linux Foundation. Beide werden von den gängigen Werkzeugen gelesen und geschrieben. Das BSI konkretisiert in der Technischen Richtlinie TR-03183 Teil 2, welche Felder eine SBOM enthalten sollte. Sie ersetzt die Verordnung nicht, ist aber eine brauchbare Checkliste.

Eine SBOM, die jemand von Hand pflegt, ist nach dem nächsten Release veraltet. Sie gehört deshalb in die Build-Pipeline: Jeder Release-Build erzeugt sie aus dem tatsächlich ausgelieferten Artefakt, nicht aus dem Quellcode allein. Werkzeuge dafür sind beispielsweise Syft oder Trivy für Container-Images und Dateisysteme sowie die CycloneDX-Plugins für Maven, Gradle, npm, .NET oder Python. Die SBOM wird mit Versionsnummer und Commit verknüpft und zusammen mit dem Artefakt archiviert.

Top-Level-Abhängigkeiten sind das Minimum. Für die Schwachstellenbewertung zählen die transitiven Abhängigkeiten, weil viele der kritischen Lücken der letzten Jahre in Bibliotheken steckten, die kein Entwickler direkt eingebunden hatte. Erzeugen Sie die SBOM also vollständig und entscheiden Sie erst bei der Weitergabe, welche Tiefe der Empfänger braucht.

• Format festlegen (CycloneDX oder SPDX, als JSON) und im Repository dokumentieren
• SBOM je Release-Build aus dem Artefakt erzeugen, nicht manuell pflegen
• Mit Version, Commit und Build-Datum verknüpfen und über den Supportzeitraum archivieren
• Pflichtfelder nach TR-03183 Teil 2 abgleichen, etwa Ersteller, Zeitstempel, Komponentenname, Version, Abhängigkeiten, Lizenz und Hash

Schwachstellen laufend bewerten

Eine SBOM ist zunächst nur ein Inventar. Ihr Nutzen entsteht, wenn sie regelmäßig gegen Schwachstellendatenbanken geprüft wird, nicht nur beim Build, sondern täglich für jede unterstützte Version im Feld. Eine Bibliothek, die beim Release sauber war, kann drei Monate später eine kritische Lücke haben. Scanner wie Trivy oder Grype prüfen eine gespeicherte SBOM, ohne das Produkt neu zu bauen. Plattformen wie Dependency-Track nehmen SBOMs entgegen und melden neue Treffer.

Jeder Treffer braucht eine Triage: Ist die betroffene Funktion im Produkt erreichbar? Gibt es einen öffentlichen Exploit? Welche Versionen im Feld sind betroffen? Das Ergebnis wird mit Begründung festgehalten, auch ein begründetes Nicht betroffen. CycloneDX unterstützt dafür das VEX-Format, mit dem sich die Bewertung maschinenlesbar an die SBOM hängen lässt.

Die Verordnung nennt für die Behebung keine Tage, sondern verlangt, Schwachstellen unverzüglich zu beheben. Legen Sie deshalb interne Fristen fest, die zur Kritikalität passen, etwa Bewertung innerhalb eines Arbeitstags und Behebung kritischer Lücken innerhalb weniger Tage. Ein dokumentierter Prozess mit messbaren Fristen ist der Nachweis, dass unverzüglich mehr ist als eine Absichtserklärung.

Der 24-Stunden-Prozess: Erkennen, Bewerten, Melden

Seit dem 11. September 2026 gilt Artikel 14. Wird eine aktiv ausgenutzte Schwachstelle im Produkt oder ein schwerwiegender Sicherheitsvorfall bekannt, ist innerhalb von 24 Stunden eine Frühwarnung fällig. Innerhalb von 72 Stunden folgt eine Meldung mit erster Bewertung. Bei Schwachstellen ist spätestens 14 Tage nach Verfügbarkeit einer Abhilfe ein Abschlussbericht fällig. Gemeldet wird über die zentrale Meldeplattform an das zuständige CSIRT und die ENISA.

Die 24 Stunden beginnen mit der Kenntnisnahme, nicht am nächsten Arbeitstag. Das verlangt drei Dinge. Erstens einen Eingangskanal, über den Hinweise von außen zuverlässig ankommen: eine Security-Adresse und eine security.txt, die tatsächlich überwacht werden. Zweitens eine Bereitschaft: Wer entscheidet am Wochenende, ob ein Fall meldepflichtig ist, und wer setzt die Meldung ab? Drittens Vorlagen: Die Frühwarnung braucht wenig Inhalt, aber die Felder müssen vorher bekannt sein, damit nachts um zwei niemand recherchiert, was hineingehört.

• Rollen benennen: Erkennen (Monitoring, Support), Bewerten (Technik), Melden (eine benannte Person plus Vertretung)
• Entscheidungskriterien schriftlich festhalten: Was gilt als aktiv ausgenutzt, was als schwerwiegender Vorfall. Im Zweifel Juristen einbinden
• Vorlagen für Frühwarnung, Meldung und Abschlussbericht im Repository ablegen und einmal im Jahr durchspielen
• Zugang zur Meldeplattform vorab einrichten und testen, nicht erst im Ernstfall

Patch-Prozess: Hotfix, Signatur, Auslieferung

Anhang I Teil II verlangt, Schwachstellen unverzüglich zu beheben, Sicherheitsupdates wo technisch möglich getrennt von Funktionsupdates bereitzustellen und sie über einen sicheren Mechanismus zu verteilen. Technisch heißt das: Sie brauchen einen Release-Pfad, der in Stunden statt Wochen durchläuft.

Ein Hotfix darf nicht am vollen manuellen Regressionstest hängen. Das gelingt nur, wenn die automatisierten Tests belastbar genug sind, dass ein Build mit grüner Pipeline ausgeliefert werden kann. Wer das heute nicht hat, findet hier den größten Hebel. Dazu kommen Wartungszweige je unterstützter Version, damit der Fix für 2.3 nicht alle Änderungen aus 3.0 mitbringt.

Updates werden signiert, und der Empfänger prüft die Signatur vor der Installation. Cosign für Container-Images oder klassische GPG-Signaturen für Pakete sind etabliert. Wichtiger als das Werkzeug ist, dass private Schlüssel nicht im Klartext in der Pipeline liegen, sondern in einem Secret-Store oder einem HSM.

Nach der Auslieferung folgt die Verifikation: Welche Installationen haben das Update erhalten? Die SBOM der neuen Version belegt, dass die verwundbare Komponente nicht mehr enthalten ist, und ein Advisory informiert die Nutzer über die behobene Lücke, wie Anhang I Teil II Nr. 4 und 8 es verlangen. Das alles muss über den Supportzeitraum funktionieren: in der Regel mindestens fünf Jahre, und jedes Sicherheitsupdate bleibt danach mindestens zehn Jahre verfügbar.

Nachweise: was die Dokumentation aus der Pipeline bekommt

Die technische Dokumentation nach Anhang VII beschreibt Produkt, Risikobewertung und die Umsetzung der Anforderungen. Vieles davon kann die Pipeline liefern, wenn sie es erzeugt und aufbewahrt: SBOM je Version, Scan-Ergebnisse mit Zeitstempel, Triage-Entscheidungen, Build-Protokolle, Signaturen und Provenance-Daten, Release Notes mit Sicherheitshinweisen. Entscheidend ist, dass diese Artefakte versioniert und über den Supportzeitraum auffindbar bleiben, nicht in einer Pipeline-Historie, die nach 90 Tagen gelöscht wird.

Die SBOM selbst ist Teil dieser Dokumentation. Veröffentlichen müssen Sie sie nicht. Erwägungsgrund 77 stellt das klar. Marktüberwachungsbehörden können sie anfordern, und Kunden fragen zunehmend danach. Legen Sie fest, wer sie auf Anfrage herausgibt und in welcher Tiefe.

• SBOM und Signatur je Release
• Scan-Berichte und Triage-Protokoll mit Datum
• Nachweis, wann welche Version an welche Kunden ausgeliefert wurde
• Richtlinie zur koordinierten Offenlegung (Anhang I Teil II Nr. 5) und Kontaktstelle für Meldungen

Reihenfolge für ein kleines Team

Ein Team mit fünf Entwicklern hat keine Security-Abteilung. Die Reihenfolge entscheidet deshalb, ob der CRA ein abgeschlossenes Projekt bleibt oder zur Dauerlast wird. Die folgende Abfolge, grob in Monaten, halte ich für ein kleines Team für realistisch.

Wer damit Anfang 2027 beginnt, hat bis Dezember 2027 noch Luft für Produktspezifisches und für die harmonisierten Normen, sobald sie vorliegen. Eine erste Standortbestimmung liefert der CRA-Selbstcheck auf dieser Website: wenige Fragen zu SBOM, Schwachstellenprozess, Updates und Meldung, mit einer Einschätzung, wo die größten Lücken liegen.

• Monat 1: Meldeprozess aufsetzen, weil er bereits gilt. Rollen, Bereitschaft, Vorlagen, Kontaktadresse, Zugang zur Meldeplattform.
• Monat 1 bis 2: SBOM in der Pipeline für jedes Produkt, archiviert je Version.
• Monat 2 bis 3: Scanning gegen die SBOM, Triage-Regeln, interne Fristen. Erste Altlasten abbauen.
• Monat 3 bis 6: Release-Pfad für Hotfixes verkürzen, Signierung, Wartungszweige, Testabdeckung dort erhöhen, wo sie den Hotfix blockiert.
• Monat 6 bis 9: Dokumentation aus der Pipeline zusammenführen, Richtlinie zur koordinierten Offenlegung, Supportzeitraum je Produkt festlegen und kommunizieren.