Die CRA-Bereitschaftsanalyse verbindet ein konkretes Produkt mit den Anforderungen der Verordnung. Sie zeigt vorhandene Nachweise, technische Lücken und offene Entscheidungen. Aus einer unübersichtlichen Aufgabe wird ein priorisierter Entwicklungsplan. Die Analyse dauert zwei Wochen im vereinbarten Umfang. Für Klasse-I-Kandidaten gilt ein eigener Einstiegspreis, weil das Bewertungsverfahren zusätzliche Prüfung benötigen kann.
Die Ergebnisse der Analyse
Wir prüfen Klassifizierung und Konformitätsbewertungsverfahren anhand der Produktfunktionen. Eine Software-Stückliste wird gegen das vereinbarte Release validiert. Bekannte Schwachstellen werden technisch eingeordnet, ergänzt um Entwürfe strukturierter VEX-Entscheidungen. Der Abgleich mit 21 Anforderungen aus Anhang I macht sichtbar, welche Nachweise bereits bestehen und welche Aufgaben Entwicklung oder Prozessarbeit erfordern.
Hinzu kommt eine Prüfung der Meldebereitschaft. Wer erhält einen Sicherheitshinweis? Wie wird die Kenntnis dokumentiert? Wer prüft und übermittelt eine Meldung? Die Meldepflicht nach Artikel 14 gilt seit 11. September 2026 und läuft deshalb parallel zur Vorbereitung der übrigen Pflichten. Der Ergebnisbericht verbindet diese Fragen mit einem Fahrplan bis Dezember 2027 und einem gemeinsamen Ergebnisgespräch.
Was Ihr Team vorbereitet
Benennen Sie Zuständige für Build, Release und Produktentscheidungen. Wir benötigen die vereinbarten Artefakte, vorhandene Sicherheitsunterlagen und einen technischen Ansprechpartner für Architekturfragen. Auch unvollständige Dokumente können nützlich sein, wenn ihr Status klar ist. Kennzeichnen Sie Annahmen, geplante Funktionen und Eigenschaften der aktuell ausgelieferten Version unterschiedlich.
Bei mehreren Produktvarianten klären wir vorab, welche davon denselben Bewertungsumfang teilen können. Eine gemeinsame Marke allein belegt noch keine einheitliche Produktfamilie. Unterscheidungen bei Hauptfunktion, Software oder vorgesehenem Einsatz können zusätzliche Arbeit auslösen. Der vereinbarte Umfang hält deshalb fest, welche Versionen und Varianten untersucht werden und welche ausdrücklich offenbleiben.
Von Befunden zu einer belastbaren Reihenfolge
Ein Scan liefert Treffer. Die Analyse prüft, ob die betroffene Funktion im Produkt enthalten und erreichbar ist und welche Schutzmaßnahmen bestehen. Zu jeder Entscheidung werden die Grundlage und die Grenze der Aussage dokumentiert. Die Priorisierung verbindet technische Auswirkung, notwendige Entwicklung und Abhängigkeiten zu externen Prüfungen. Ein einzelner Schweregrad ersetzt diese Prüfung nicht.
Der Fahrplan nennt überprüfbare Ergebnisse statt allgemeiner Fortschrittswerte. Dazu können ein validiertes Inventar, ein aktualisiertes Updatekonzept oder ein getesteter Meldeablauf gehören. Jedes Ergebnis bekommt einen Verantwortlichen und einen Termin. Im Ergebnisgespräch prüfen wir gemeinsam, welche Aufgaben Ihr Team übernehmen kann und wo zusätzliche Unterstützung sinnvoll ist.
Analyse und Umsetzung getrennt beauftragen
Die Bereitschaftsanalyse umfasst Bewertung und Empfehlungen. Änderungen am Produktcode und die vollständigen Umsetzungsunterlagen werden in einem gesonderten Projekt vereinbart. Sie entscheiden anhand des Ergebnisses über den nächsten Schritt. Wenn eine Aussage wegen fehlender Artefakte nicht möglich ist, wird das als offene Aufgabe festgehalten. Ein vollständig ausgefülltes Dokument ist kein Ersatz für einen technisch belegten Befund.
Von der Freigabe zum nutzbaren Ergebnis
Vor dem Start stimmen wir Produktgrenze, unterstützte Versionen und Zugriff ab. Benennen Sie einen technischen Ansprechpartner und eine Person, die Ergebnisse freigeben kann. Eine Modellbezeichnung allein genügt nicht, wenn mehrere Firmwarezweige, eine Begleit-App und notwendige Datenfernverarbeitung zusammenwirken. Die vereinbarte Grenze wird in Bestandsaufnahme, Bewertung und Dokumentation einheitlich verwendet.
Jeder bestätigte Befund erhält einen Versionsbezug und eine nachvollziehbare Begründung. Unvollständige Unterlagen bleiben als solche erkennbar. Wir dokumentieren, welche Schlussfolgerungen durch die vorhandenen Artefakte gedeckt sind und welche weiteren Prüfungen nötig werden. Ihr Entwicklungsteam kann damit erkennen, warum eine Aufgabe entsteht und wann sie als erledigt gelten kann.
Zum Abschluss besprechen wir Fakten, offene Fragen und nächste Maßnahmen. Jede Folgeaufgabe bekommt einen Verantwortlichen und einen Prüftermin. So bleibt die Arbeit nach einem Releasewechsel nutzbar. Der Hersteller verantwortet weiterhin Klassifizierung, Konformitätsentscheidungen, Meldungen und die Unterzeichnung der EU-Konformitätserklärung. Externe Unterstützung übernimmt konkrete Aufgaben innerhalb des vereinbarten Umfangs.
Leistungsumfang und Zusammenarbeit
Projekte werden zu 50 % im Voraus bezahlt. Die weiteren Zahlungen richten sich nach vereinbarten Meilensteinen. Rechnungen werden in Euro gestellt, zzgl. MwSt. Abonnementumfang und Abrechnung werden vor Aktivierung vereinbart. Labore und benannte Stellen haben eigene Aufgaben und gesonderte Kosten. Roja führt keine Penetrationstests durch und ist keine benannte Stelle.
Vorhandene Software-Stücklisten oder Build-Artefakte können als Einstieg dienen. Vollständiger Quellcodezugriff ist nicht automatisch erforderlich. Wenn die Unterlagen eine Aussage nicht tragen, benennen wir die Grenze und stimmen den nächsten Schritt ab. Senden Sie keine vertraulichen Artefakte über das Anfrageformular. Zuerst vereinbaren wir Freigabe und Übertragungsweg.
Wie sich diese Leistung in die Anforderungen einordnet, lesen Sie im CRA-Leitfaden. Relevant sind insbesondere die SBOM-Anforderungen und die Meldepflicht nach Artikel 14. Die Preisseite hilft, einmalige Vorbereitung und laufende Betreuung auseinanderzuhalten.
Häufige Fragen
Wer bleibt für die Konformität verantwortlich?
Der Hersteller verantwortet Klassifizierung, Konformitätsentscheidungen, Meldungen und die Unterschrift. Roja bereitet Nachweise und Entwürfe vor und unterstützt bei der technischen Arbeit.
Müssen wir sofort den vollständigen Quellcode bereitstellen?
Nein. Wir vereinbaren zuerst die erforderlichen Unterlagen. Eine vorhandene SBOM oder Build-Ausgabe kann genügen, um den Einstieg und erkennbare Grenzen zu klären.
Quellen
- Verordnung (EU) 2024/2847 – deutsche Fassung auf EUR-Lex
- ENISA: Fragen zur Single Reporting Platform
Allgemeine technische Informationen, geprüft am oben genannten Datum. Produktbezogene Auslegung, aktuelle Normen und das anwendbare Verfahren sind vor einer Konformitätsentscheidung gesondert zu prüfen.