Technische CRA-Readiness für digitale Produkte.
Entwicklung, Security und regulatorische Dokumentation zusammenführen, mit einer technischen Gap-Analyse als Start.
Die Meldepflichten gelten bereits.
Seit dem 11.09.2026 müssen Hersteller aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle melden. Die übrigen Anforderungen gelten ab dem 11.12.2027.
-
Inkrafttreten der Verordnung (EU) 2024/2847.
-
Gilt bereits
Meldepflichten: Frühwarnung binnen 24 Stunden, Meldung binnen 72 Stunden, Abschlussbericht. Gemeldet wird über die zentrale Meldeplattform an CSIRT und ENISA.
-
Alle übrigen Pflichten, insbesondere grundlegende Cybersicherheitsanforderungen, Konformitätsbewertung und CE-Kennzeichnung.
Stand Oktober 2026. Primärquelle: Verordnung (EU) 2024/2847 auf EUR-Lex. Ausführlich im Beitrag CRA-Meldepflichten seit September 2026.
Wen der CRA betrifft
Der Cyber Resilience Act gilt für Produkte mit digitalen Elementen, die auf dem EU-Markt bereitgestellt werden und eine direkte oder indirekte Datenverbindung zu einem Gerät oder Netz haben. Das umfasst Hardware mit Firmware ebenso wie eigenständige Software.
Pflichten treffen vor allem Hersteller, in abgestufter Form auch Importeure und Händler. Für einige Produktgruppen gelten sektorale Sonderregeln, etwa für Medizinprodukte oder Kraftfahrzeuge.
Erst der Scope, dann die Lücken.
Die wichtigste technische Vorarbeit ist eine saubere Abgrenzung. Diese Fragen sollten Sie beantworten können:
Zur vollständigen ChecklisteWelche Produkte und Varianten stellen Sie auf dem EU-Markt bereit?
Jede Variante kann eigene Komponenten und damit eigene Lücken haben.
Welche Firmware-, Software- und Cloud-Komponenten gehören dazu?
Remote-Datenverarbeitung, ohne die das Produkt nicht funktioniert, kann Teil des Produkts sein.
Welche Drittanbieter- und Open-Source-Komponenten sind enthalten?
Ohne SBOM lässt sich nicht beurteilen, ob eine bekannte Schwachstelle Ihr Produkt betrifft.
Ist ein Produkt „wichtig“ oder „kritisch“ im Sinne des CRA?
Die Kategorie bestimmt den Weg der Konformitätsbewertung. Die Einordnung ist rechtlich zu prüfen.
Wie lange liefern Sie Sicherheitsupdates?
Der Supportzeitraum muss festgelegt und begründet sein, in der Regel an der erwarteten Nutzungsdauer.
Was die Pflichten für Entwicklung und Betrieb bedeuten
Security by Design und by Default
Risikobewertung als Grundlage, sichere Standardkonfiguration, minimale Angriffsfläche, Schutz von Daten und Schnittstellen.
Umgang mit Schwachstellen
Komponenten kennen (SBOM), Schwachstellen bewerten und beheben, eine Kontaktstelle für Meldungen und eine Richtlinie zur koordinierten Offenlegung.
Sicherheitsupdates über den Supportzeitraum
Ein festgelegter, begründeter Supportzeitraum und ein Prozess, Updates zügig und sicher auszuliefern.
Technische Dokumentation und Konformität
Dokumentation, die Anforderungen, Maßnahmen und Tests verknüpft. Sie ist die Grundlage für Konformitätsbewertung, EU-Konformitätserklärung und CE-Kennzeichnung.
So sieht eine Evidence Map aus
Jede Anforderung wird mit Risiko, Maßnahme und Nachweis verknüpft. So bleibt nachvollziehbar, warum ein Produkt so gebaut ist, wie es ist.
| Anforderung | Risiko | Maßnahme | Nachweis |
|---|---|---|---|
| Sichere Standardkonfiguration | Standardpasswort bleibt nach der Inbetriebnahme aktiv | Passwortwechsel bei Erstinbetriebnahme erzwingen | Automatisierter Test im Release-Build, Ergebnis am Release archiviert |
| Integrität von Updates | Manipuliertes Firmware-Image wird eingespielt | Signierte Updates, Prüfung auf dem Gerät | Signaturprüfung in der Pipeline, Testfall mit manipuliertem Image |
| Umgang mit Schwachstellen | Bekannte Schwachstelle in einer Bibliothek bleibt unbemerkt | SBOM pro Release, täglicher Abgleich mit Schwachstellendatenbanken | SBOM-Archiv, Bewertungsprotokoll je Fund |
Beispielhafte Einträge zur Veranschaulichung.
Häufige Fragen
Ist das eine juristische Prüfung?
Nein. Der Schwerpunkt liegt auf technischer Prozess-, Produkt- und Entwicklungsberatung. Rechtsfragen müssen rechtlich qualifiziert geklärt werden.
Gilt der CRA schon?
Meldepflichten für aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle gelten seit dem 11.09.2026, die wesentlichen übrigen Anforderungen ab dem 11.12.2027. Die individuelle Anwendbarkeit ist zu prüfen.
Kann devgineers Konformität garantieren?
Nein. Wir unterstützen technisch und organisatorisch. Verantwortung und formale Konformitätsbewertung verbleiben beim Hersteller bzw. den zuständigen Stellen.
Womit fangen wir am besten an?
Mit einer Bestandsaufnahme von Scope, Prozessen und vorhandenen Nachweisen. Dafür ist unser CRA Gap Assessment gedacht.
Erst verstehen. Dann bauen.
Beschreiben Sie kurz Ausgangslage und Ziel. Sie bekommen eine persönliche Antwort mit den Fragen, die für einen sinnvollen Scope wichtig sind.