Der Artikel erläutert die Einstufung von Produkten mit digitalen Elementen gemäß Cyber Resilience Act und zeigt die Unterschiede zwischen allgemeinen, wichtigen und kritischen Produktkategorien.
Der Cyber Resilience Act (CRA) bringt eine systematische Einordnung von Produkten mit digitalen Elementen mit spürbaren Auswirkungen auf Hersteller, Integratoren und Betreiber. Der aktuelle Entwurf zur Durchführungsverordnung vom März 2025 enthält erstmals eine detaillierte Liste digitaler Produktkategorien, die als wichtig oder kritisch eingestuft werden. Dieser Beitrag gibt einen kompakten Überblick: Welche Produkte fallen darunter? Und was bedeutet das für alle anderen?
Ziel der Kategorisierung
Nicht alle vernetzten Produkte stellen das gleiche Risiko dar. Ziel der Kategorisierung ist es, digitale Produkte mit höherem Schadenspotenzial gezielt strengeren Anforderungen zu unterwerfen. Die Zuordnung erfolgt zu drei Klassen:
🟢 Sonstige Produkte: Allgemeine CRA-Pflichten
🟡 Wichtige Produkte (Annex III, Class I & II): Verschärfte Anforderungen, z. B. Benachrichtigung der Behörden
Vernetzte Spielzeuge mit Interaktion oder Ortungsfunktionen
Wearables mit Gesundheitsmonitoring (z. B. Fitness-Tracker, Kinderschutzgeräte)
Class II – Infrastruktur- und Plattformkomponenten
Diese Kategorie betrifft virtualisierungsnahe und netzwerkseitige Sicherheitskomponenten:
Hypervisoren und Container-Runtimes
Firewalls sowie Intrusion Detection/Prevention Systeme
Mikroprozessoren und -controller mit physischem Manipulationsschutz
Annex IV: Kritische Produkte
Produkte in dieser Klasse erfüllen besonders sicherheitskritische Funktionen, häufig im Zusammenhang mit kryptografischem Schutz oder physischer Zugriffssicherheit:
Hardware mit integrierter Sicherheitsbox (z. B. HSMs, Tachographen, Zahlungsterminals)
Smart-Meter-Gateways für Energieversorgung (inkl. Kryptoverarbeitung)
Sichere Elemente (TPMs, SIMs, Zahlungskarten, digitale Zugangssysteme)
Und die übrigen Produkte?
Produkte, die nicht explizit in Annex III oder IV genannt sind, gelten als sonstige Produkte mit digitalen Elementen. Für sie gelten die allgemeinen Anforderungen des CRA, z. B.:
Sicherheits-by-Design und -by-Default
Schwachstellenmanagement
Updatefähigkeit und Patch-Prozesse
Technische Dokumentation
CE-Kennzeichnung und Konformitätserklärung (Selbstbewertung möglich)
Empfehlungen für Hersteller
Produktportfolio prüfen: Gibt es Komponenten oder Varianten, die unter die gelisteten Kategorien fallen?
Zulieferabhängigkeiten beachten: Auch eingebettete Software oder Module von Dritten können zur Einstufung führen.
Klassifizierung dokumentieren: Die eigene Risikoeinordnung sollte nachvollziehbar begründet werden.
Aktuell bleiben: Die Liste ist nicht abschließend – spätere Ergänzungen durch die Kommission sind möglich.
Fazit
Die durch den CRA eingeführte Klassifizierung schafft Klarheit, bringt aber auch neue Anforderungen mit sich. Wer sicherheitsrelevante Produkte entwickelt oder integriert, sollte die neue Einordnung sorgfältig prüfen – und gegebenenfalls die internen Prozesse frühzeitig anpassen. Gleichzeitig bietet die transparente Einstufung eine Chance, die Produktsicherheit systematisch zu dokumentieren und das Vertrauen bei Kunden und Partnern zu stärken.
Wollen Sie mit der Prüfung loslegen, dann starten Sie mit unserem CRA Check.
Lars ist Solution Consultant und berät Unternehmen und Entwicklungsteams ganzheitlich bei der Umsetzung ihrer Softwareentwicklungsprojekte, von den Prozessen über die Anforderungen und Architekturen bis hin zu Umsetzung und Betrieb.
Ein Advisory am Freitagnachmittag, ein Schaltschrank voller Komponenten und eine einfache Frage: Welche Maschinen müssen wir prüfen? Wie Produktidentität die Antwort möglich macht.
BSI TR-03183-1 in Version 1.0.0, prEN 40000-1-3, prEN 50742 und die ENISA Single Reporting Platform machen die CRA-Vorbereitung prüfbarer. Der Beitrag zeigt, welche neuen Nachweise Hersteller daraus ableiten können.
Der Cyber Resilience Act schafft erstmals eine eigene Rolle für Open-Source-Verantwortliche. Dieser Artikel erklärt, wer als Open Source Steward gilt, welche Pflichten Art. 24 CRA tatsächlich fordert und was Hersteller beim Einsatz von Open Source beachten müssen.
Der Cyber Resilience Act schreibt je nach Produktkategorie unterschiedliche Konformitätsbewertungsverfahren vor. Dieser Artikel zeigt, welches Verfahren für welches Produkt gilt und wie Hersteller Schritt für Schritt zur CE-Kennzeichnung gelangen.
Unser Artikel in der dotnetpro 3/26 zeigt, warum der Cyber Resilience Act kein reines Compliance-Thema ist, sondern ein ehrlicher Reifegradtest für Softwareentwicklung und Produktverantwortung.
Der Cyber Resilience Act endet nicht an der eigenen Fabrikhalle: Dieser Artikel zeigt, was Hersteller aus Maschinenbau und Industrie von ihren Lieferanten fordern müssen und wie SBOM, Assessments und Vertragsklauseln die Lieferkette absichern.
Der CRA verlangt grundsätzlich ab dem 11. Dezember 2027 eine CVD-Policy und eine Kontaktstelle. Warum Hersteller beides bereits für die Meldepflichten ab September 2026 vorbereiten sollten.
Ab dem 11. September 2026 sind Hersteller verpflichtet, aktiv ausgenutzte Schwachstellen und Sicherheitsvorfälle innerhalb von 24 Stunden an ENISA zu melden – dieser Artikel zeigt, was konkret zu tun ist.
