Aus Anforderungen wird konkrete Arbeit
Sie entwickeln ein vernetztes Produkt und verkaufen es in Europa. Mit dem Cyber Resilience Act kommen Sicherheitsanforderungen hinzu, die Entwicklung, Produktmanagement und Support verbinden. Dafür braucht Ihr Team belastbare Nachweise aus dem tatsächlichen Produkt. Eine Checkliste hilft bei der Orientierung. Die Komponentenübersicht, die Bewertung einer Schwachstelle und eine sichere Aktualisierung müssen trotzdem erarbeitet werden.
Roja verbindet eine Plattform mit Ingenieuren, die diese Aufgaben mit Ihnen übernehmen. Wir beginnen bei Ihrem Build, prüfen die enthaltenen Komponenten und ordnen bekannte Schwachstellen ein. Daraus entstehen nachvollziehbare Entscheidungen, technische Unterlagen und nächste Schritte mit klaren Verantwortlichen. Sie behalten den Überblick über Leistungsumfang und Kosten. Die Verantwortung des Herstellers bleibt bei Ihnen.
Melden ist bereits Pflicht
Die Meldepflicht nach Artikel 14 gilt seit 11. September 2026. Bei einer aktiv ausgenutzten Schwachstelle oder einem schwerwiegenden Sicherheitsvorfall beginnen die Fristen mit der Kenntnis des Herstellers. Die Frühwarnung erfolgt unverzüglich, spätestens innerhalb von 24 Stunden. Die weitere Meldung folgt unverzüglich, spätestens innerhalb von 72 Stunden. Warten Sie mit dem Meldeprozess deshalb nicht bis zum Abschluss Ihres Dokumentationsprojekts.
Für den Abschlussbericht gelten zwei unterschiedliche Fristen. Bei Schwachstellen sind es höchstens 14 Tage nach Verfügbarkeit einer Korrektur- oder Abhilfemaßnahme. Bei schwerwiegenden Sicherheitsvorfällen ist es ein Monat nach der Meldung. Roja verfolgt die Fristen und bereitet Meldetexte vor. Sie prüfen die Entwürfe und reichen sie über die Single Reporting Platform von ENISA ein. Die Artikel-14-Seite erläutert den Ablauf und verweist auf die Primärquellen.
Mit einem Produkt anfangen
Der kostenlose CRA Snapshot schafft einen ersten Überblick. Wir vereinbaren zunächst die Unterlagen und den erlaubten Zugriff. Anschließend prüfen wir ein Produkt und eine bereitgestellte Version. Sie erhalten eine Komponentenübersicht, bekannte Schwachstellen nach Schweregrad, Treffer auf Listen aktiv ausgenutzter Schwachstellen, eine voraussichtliche Produktklasse und zehn priorisierte Lücken. Der Bericht umfasst acht bis zwölf Seiten. Die Bearbeitungszeit beginnt mit dem Eingang der vereinbarten Unterlagen.
Wenn Sie eine belastbarere Planung brauchen, folgt die CRA-Bereitschaftsanalyse. Sie verbindet eine validierte Software-Stückliste mit bewerteten Befunden, dem Abgleich gegen Anhang I und einer dokumentierten Einordnung des Konformitätsbewertungsverfahrens. Offene Fragen bleiben sichtbar. Ein Ergebnisgespräch klärt, welche Aufgaben zuerst in die Entwicklung gehören und welche externe Prüfung erfordern.
Im Umsetzungsprojekt arbeiten unsere Ingenieure mit Ihrem Team an Risikobewertung, Nutzerinformationen und technischer Dokumentation. Hinzu kommen eine Richtlinie zur koordinierten Offenlegung von Schwachstellen, eine Supporterklärung und der Entwurf einer EU-Konformitätserklärung. Vereinbarte Entwicklungsstunden helfen, Befunde im eigenen Code zu bearbeiten. Prüfstellen und benannte Stellen werden entsprechend dem erforderlichen Verfahren eingebunden.
Überwachung braucht eine technische Bewertung
Eine neue CVE ist zunächst ein Hinweis. Entscheidend ist, ob die betroffene Funktion in Ihrem Produkt enthalten und erreichbar ist. Unsere Ingenieure prüfen diese Fragen mit den Menschen, die Ihren Build kennen. Das Ergebnis wird mit Begründung und Versionsbezug festgehalten, etwa als VEX-Entscheidung. Ein automatischer Treffer wird dadurch zu einer nachvollziehbaren technischen Bewertung.
Roja Monitor überwacht die Software-Stücklisten unterstützter Versionen täglich. Hinweise auf aktive Ausnutzung werden innerhalb einer Stunde nach Erkennung weitergegeben. Die Zahl der enthaltenen Bewertungen richtet sich nach dem Tarif. Einrichtung, unterstützte Releases und Eskalationswege vereinbaren wir vor dem Start. Zusätzliche Entwicklung und das vollständige Umsetzungsprojekt sind eigene Leistungen. Die Preisseite zeigt Beträge und Grenzen nebeneinander.
Produktklasse vor Projektplan
Ein gewöhnlicher vernetzter Sensor kann grundsätzlich für eine Selbstbewertung infrage kommen. Sicherheitskameras, intelligente Türschlösser und Babyphones sind dagegen Beispiele für wichtige Produkte Klasse I. Dort hängt die Möglichkeit zur Selbstbewertung von den anwendbaren Voraussetzungen ab; andernfalls ist eine dritte Stelle einzubeziehen. Klasse II erfordert eine Bewertung durch Dritte. Kritische Produkte benötigen eine gesonderte Prüfung des anwendbaren Verfahrens.
Wir klären diese Einordnung vor einer größeren Beauftragung. Roja ist keine benannte Stelle und führt keine Penetrationstests durch. Entsprechende Prüfungen übernehmen geeignete Partnerlabore im gesondert vereinbarten Umfang. Sie erhalten technische Vorbereitung und Entwicklungsunterstützung mit klaren Grenzen. Welche Einordnung zu Ihrem Produkt passt, erläutern wir auf der Seite zu den Produktklassen.
Nachweise, die beim nächsten Release weiterhelfen
Eine Komponentenliste verliert ihren Wert, wenn niemand mehr weiß, zu welchem Build sie gehört. Deshalb verknüpfen wir Bestandsaufnahme, Befunde und Entscheidungen mit einer konkreten Produktversion. Dasselbe gilt für die technischen Unterlagen und den Supportzeitraum. Neue Releases und geänderte Abhängigkeiten lösen einen überprüfbaren Aktualisierungsschritt aus.
Benennen Sie einen Produktverantwortlichen und einen Kontakt für Sicherheitsmeldungen samt Vertretung. Bringen Sie zum ersten Gespräch eine Produktbeschreibung und Informationen zu Ihrem Build mit. Quellcode, Zugangsdaten und vertrauliche Artefakte gehören nicht in das Kontaktformular. Wir vereinbaren zuerst eine sichere Übergabe. Der CRA-Leitfaden zeigt den Gesamtzusammenhang, der Snapshot einen überschaubaren Einstieg.
Häufige Fragen
Gilt der CRA auch für Hersteller außerhalb der EU?
Ein Produkt kann bei der Bereitstellung auf dem EU-Markt in den Anwendungsbereich fallen. Der Sitz außerhalb der EU ersetzt keine Prüfung von Produkt und Wirtschaftsakteursrolle.
Welches SBOM-Format verwenden Sie?
Wir stimmen ein maschinenlesbares Format wie CycloneDX oder SPDX auf Ihren Build und den weiteren Prüfprozess ab. Die Datei wird gegen die tatsächlich ausgelieferte Version geprüft.
Gibt es eine allgemeine Ausnahme für kleine Unternehmen?
Nein. Die Ausnahme in Artikel 64 Absatz 10 betrifft nur Geldbußen für die Frühwarnung innerhalb von 24 Stunden bei Kleinst- und kleinen Unternehmen. Die Pflicht selbst und die weiteren Fristen bleiben bestehen.
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.