CRA Software Readiness

Ein Festpreisprojekt ab 4.900 €, in dem ich Ihre Softwareentwicklung mit den technischen Anforderungen des Cyber Resilience Act abgleiche: Release-Prozesse, Abhängigkeiten, Software Bill of Materials, Schwachstellenmanagement, Update- und Patch-Prozesse und Nachweisführung. Ergebnis sind eine Gap-Analyse, eine priorisierte Roadmap und eine Aufwandseinschätzung für Ihr Team. Einen ersten Eindruck, wo Ihre Entwicklung steht, gibt der CRA-Selbstcheck mit acht Fragen, ohne Anmeldung.

Der CRA gilt für Produkte mit digitalen Elementen, die in der EU in Verkehr gebracht werden, also für die meiste kommerzielle Software und vernetzte Hardware. Ausgenommen sind Produkte mit eigener EU-Regulierung, etwa Medizinprodukte nach MDR, Fahrzeuge und Luftfahrt. Die technische Einordnung Ihres Produkts ist Teil der Analyse, die rechtliche Bewertung bleibt bei Ihren Juristen.

Der CRA unterscheidet Standardprodukte, wichtige Produkte der Klassen I und II (Anhang III) und kritische Produkte (Anhang IV), eingestuft nach der Kernfunktion. Die meisten Softwareprodukte und Maschinen sind Standardprodukte und werden vom Hersteller selbst bewertet; Steuerungen, HMIs und SCADA stehen nicht in den Anhängen. Wichtige Produkte wie Betriebssysteme, Router, Firewalls oder Mikrocontroller mit Sicherheitsfunktionen brauchen je nach Klasse harmonisierte Normen oder eine notifizierte Stelle. Die rechtliche Einstufung bleibt bei Ihren Juristen; die Analyse hält die technische Kernfunktion und ihre Konsequenzen für Verfahren und Aufwand fest. Eine Übersicht der Klassen steht im Artikel CRA technisch umsetzen.

Seit dem 11. September 2026 gelten die Meldepflichten für aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle. Ab dem 11. Dezember 2027 gelten alle übrigen Anforderungen der Verordnung (EU) 2024/2847 einschließlich CE-Kennzeichnung für Produkte, die dann in Verkehr gebracht werden.

Seit dem 11. September 2026 müssen Hersteller aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle melden: eine Frühwarnung innerhalb von 24 Stunden, eine Meldung innerhalb von 72 Stunden und einen Abschlussbericht, bei Schwachstellen spätestens 14 Tage nach Verfügbarkeit einer Abhilfe. Gemeldet wird über die zentrale Meldeplattform an das zuständige CSIRT und die ENISA. Dafür braucht es einen Prozess, der Schwachstellen erkennt, bewertet und eine Meldung innerhalb eines Tages möglich macht, auch am Wochenende. Wie weit Sie davon entfernt sind, zeigt die Gap-Analyse.

Ja, unter dem CRA schon. Hersteller müssen die Komponenten ihres Produkts kennen und eine SBOM in einem gängigen, maschinenlesbaren Format führen, die mindestens die direkten Abhängigkeiten abdeckt. Ohne diesen Überblick lässt sich bei einer neu bekannten Schwachstelle nicht schnell sagen, ob Ihr Produkt betroffen ist. Eine automatisch in der Pipeline erzeugte SBOM ist meist einer der ersten Punkte der Roadmap.

Über den gesamten Supportzeitraum, der sich an der erwarteten Nutzungsdauer des Produkts orientiert und in der Regel mindestens fünf Jahre beträgt. Jedes Sicherheitsupdate muss danach mindestens zehn Jahre verfügbar bleiben. Das ist nur mit einem Release-Prozess bezahlbar, der Updates schnell und verlässlich ausliefert. Deshalb gehören Build, Tests und Auslieferung zur Analyse.

Eine Konformitätserklärung ist erst möglich, wenn alle Anforderungen erfüllt sind. Vorweisen können Sie aber einen dokumentierten Stand und einen Plan: die Gap-Analyse, die priorisierte Roadmap und, sobald umgesetzt, eine SBOM und einen beschriebenen Prozess für Schwachstellen und Updates. Das beantwortet die meisten Fragen aus Einkauf und Ausschreibungen sachlich.

Verantwortlich ist der Hersteller, also das Unternehmen als Ganzes. Praktisch betrifft der CRA Entwicklung, Qualitätssicherung, Produktmanagement und Recht zugleich, und genau deshalb fühlt sich oft niemand zuständig. Die Roadmap ordnet jede Maßnahme einer Rolle zu, damit klar ist, wer was bis wann umsetzt.

Besser nicht. Die grundlegenden Anforderungen stehen in Anhang I der Verordnung und ändern sich nicht mehr; die Normen beschreiben nur, wie man sie nachweisbar erfüllt. Änderungen an Entwicklungs- und Release-Prozessen brauchen Zeit, und die Meldepflichten gelten bereits. Wer jetzt die technischen Grundlagen schafft, muss später nur noch an die Normen angleichen.

Nein. Die Analyse ist technisch: Sie zeigt, was in Entwicklung, Build, Lieferkette und Betrieb zu tun ist. Rechtliche Einordnung, Konformitätsbewertung und Zertifizierung bleiben bei Ihren Juristen und, falls nötig, einer benannten Stelle. Die Ergebnisse sind so aufgebaut, dass sie dort als Grundlage verwendbar sind.

Ja, auf Wunsch. Typische Folgearbeiten sind SBOM-Erzeugung in der Pipeline, automatisiertes Schwachstellen-Scanning, signierte Updates und ein dokumentierter Patch-Prozess, etwa in GitLab CI/CD oder GitHub Actions. Dafür erhalten Sie ein eigenes Festpreisangebot auf Basis der Roadmap.

Ja, in zwei Schritten mit je einem Festpreis. Erst die Gap-Analyse mit Roadmap und Aufwandsschätzung ab 4.900 €, dann auf dieser Grundlage ein Angebot für die technische Umsetzung in Ihrer Pipeline. Ein Pauschalpreis vor der Analyse wäre unseriös, weil der Umfang vom Stand Ihrer Entwicklung abhängt. Rechtliche Bewertung und Konformitätsbewertung bleiben bei Ihren Juristen oder einer benannten Stelle.