Anforderungen des Cyber Resilience Act im Detail

Die große Mehrheit aller vernetzten Produkte fällt in diese Kategorie. Wer hier landet, kann das Konformitätsbewertungsverfahren selbst durchführen. Das bedeutet: Es ist keine externe Prüfstelle erforderlich, aber alle grundlegenden Sicherheitsanforderungen aus Anhang I des CRA müssen dennoch vollständig erfüllt werden.

Beispiele: Vernetzte Haushaltsgeräte, einfache IoT-Sensoren, Software ohne sicherheitskritische Funktionen

Klasse-I-Produkte haben ein erhöhtes Risikopotenzial, weil ihre Kompromittierung weitreichende Folgen haben kann. Hier sind die Anforderungen strenger. Hersteller können die Konformität selbst bewerten – aber nur dann, wenn sie harmonisierte europäische Normen vollständig anwenden. Liegen keine solchen Normen vor oder werden sie nicht angewendet, ist eine benannte Stelle einzubeziehen.

Typische Produkte der Klasse I:

• Identitätsmanagementsysteme und Zugangskontrollgeräte
• Passwortmanager
• Browser (eigenständig und eingebettet)
• VPN-Produkte und Fernzugriffssoftware
• Netz- und Konfigurationsmanagementsysteme
• Software für Updates und Patch-Management
• Smart-Home-Produkte mit Sicherheitsfunktionen (z. B. vernetzte Türschlösser, Kameras)
• Betriebssysteme für allgemeine Nutzung

Produkte der Klasse II gelten als besonders sicherheitssensibel. Sie betreffen oft kritische Infrastrukturen oder spielen eine zentrale Rolle in der IT-Sicherheit. Hier ist eine externe Konformitätsbewertung durch eine benannte Stelle verpflichtend – eine Selbstbewertung ist nicht ausreichend.

Typische Produkte der Klasse II:

• Hypervisoren und Container-Runtime-Systeme
• Firewalls und Intrusion-Detection-Systeme
• Manipulationssichere Mikroprozessoren und Mikrocontroller

Das Kernprinzip des CRA ist, Cybersicherheit nicht nachträglich aufzusetzen, sondern es von Anfang an als Teil des Entwicklungsprozesses zu integrieren – über den gesamten Lebenszyklus eines Produkts hinweg: Von der Planung über die Entwicklung und Herstellung bis hin zu Lieferung, Wartung und Außerbetriebnahme.

Was das konkret bedeutet:

• Risikobewertung in der Entwicklung: Bereits in der Planungs- und Konzeptionsphase müssen Cybersicherheitsrisiken systematisch identifiziert und bewertet werden. Die Ergebnisse dieser Bewertung müssen in alle weiteren Phasen einfließen und wenn nötig bei Änderungen am Produkt angepasst und neu bewertet werden.
• Minimale Angriffsfläche: Das Produkt soll nur die Funktionen bereitstellen, die tatsächlich benötigt werden. Nicht benötigte Schnittstellen, Dienste oder Funktionen sind zu deaktivieren oder gar nicht erst zu integrieren.
• Datenschutz und Verschlüsselung: Gespeicherte und übertragene Daten müssen angemessen geschützt werden – in der Regel durch Verschlüsselung nach aktuellem Stand der Technik.
• Integrität und Authentizität: Mechanismen zur Überprüfung der Softwareintegrität und zur Authentifizierung von Nutzern und Komponenten müssen eingebaut sein.
• Software Bill of Materials (SBOM): Anforderung des CRA ist die Erstellung einer SBOM – vergleichbar mit einem Zutatenverzeichnis für Software. Sie listet alle verwendeten Bibliotheken und Komponenten auf und ist Grundlage für ein effektives Schwachstellenmanagement.

Produkte müssen so ausgeliefert werden, dass Nutzer ohne zusätzliche Konfiguration bereits sicher unterwegs sind:

Keine schwachen Standardpasswörter: Voreingestellte Passwörter müssen stark sein oder beim ersten Login geändert werden müssen.

Automatische Sicherheitsupdates: Wo technisch möglich und sinnvoll, sollten Updates standardmäßig automatisch eingespielt werden.

Minimale Datenerhebung: Nur die für den Betrieb tatsächlich notwendigen Daten dürfen in der Standardkonfiguration erhoben werden.

Ein zentrales Element des CRA ist das aktive und kontinuierliche Schwachstellenmanagement über die gesamte Produktlebensdauer hinweg. Folgende Aspekte müssen im Prozess des Schwachstellenmanagements enthalten sein:

• Identifikation und Dokumentation: Hersteller müssen aktiv nach Schwachstellen suchen und diese systematisch dokumentieren.
• Koordinierte Offenlegung: Es muss eine Strategie für die koordinierte Offenlegung von Schwachstellen (Coordinated Vulnerability Disclosure, CVD) vorliegen. Eine zentrale Kontaktstelle für Schwachstellenmeldungen muss benannt und öffentlich zugänglich sein.
• Komponenten-Weitermeldung: Wird eine Schwachstelle in einer integrierten Komponente (z. B. einer Open-Source-Bibliothek) festgestellt, muss diese an die verantwortliche Person oder Organisation gemeldet werden.
• Kostenlose Sicherheitsupdates: Patches und Updates zur Behebung von Schwachstellen müssen rechtzeitig und ohne zusätzliche Kosten für die Nutzer bereitgestellt werden.

Für aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle gelten klar definierte Meldefristen:

Transparenz ist ein tragendes Prinzip des CRA. Sowohl gegenüber Behörden als auch gegenüber Nutzern bestehen umfangreiche Informationspflichten.

Die technische Dokumentation muss vor dem Inverkehrbringen erstellt und über den gesamten Supportzeitraum aktuell gehalten werden. Sie enthält unter anderem:

• Beschreibung der Systemarchitektur und der Sicherheitsfunktionen
• Ergebnisse der Risikobewertung und der Sicherheitsanalysen
• Festgelegte Verfahren zur Erkennung und Behebung von Schwachstellen
• Angaben zur SBOM (Software Bill of Materials)
• Dokumentation von Entwicklungs- und Build-Prozessen
• Kontaktadresse für Schwachstellenmeldungen

Nutzer müssen klar und verständlich informiert werden über:

• Sicherheitsmerkmale des Produkts und deren Funktionsweise
• Anleitung zur sicheren Installation, Konfiguration und Nutzung
• Hinweise auf bekannte Risiken und empfohlene Sicherheitseinstellungen
• Erwartete Produktlebensdauer und Dauer des Sicherheits-Supports
• Kontaktmöglichkeit zur Meldung von Schwachstellen
• Informationen über verfügbare Updates und wie sie eingespielt werden

Diese Informationen müssen dem Produkt entweder physisch oder in elektronischer Form beigefügt sein – und in der jeweiligen Landessprache des Zielmarkts.

Ohne CE-Kennzeichnung darf kein Produkt mit digitalen Elementen ab dem 11. Dezember 2027 auf dem EU-Markt in Verkehr gebracht werden. Der Weg dorthin hängt von der Produktklasse ab.

Der Ablauf im Überblick:

1. Produktklasse bestimmen: In welche Risikoklasse fällt das Produkt?
2. Risikobewertung durchführen: Für alle Klassen verpflichtend.
3. Sicherheitsanforderungen umsetzen: Alle grundlegenden Anforderungen aus Anhang I erfüllen.
4. Konformitätsbewertungsverfahren durchlaufen: Je nach Klasse selbst oder mit benannter Stelle.
5. Technische Dokumentation erstellen: Vollständig und aktuell.
6. EU-Konformitätserklärung ausstellen.
7. CE-Kennzeichnung anbringen: Gut sichtbar, leserlich und dauerhaft. Am Produkt selbst, auf der Verpackung oder (bei Software) in der Benutzeroberfläche oder Dokumentation.

Die Übergangsfristen mögen auf den ersten Blick großzügig wirken – aber die Umsetzung der CRA-Anforderungen ist kein kurzfristiges Projekt. Risikobewertungen, SBOM-Erstellung, Anpassung von Entwicklungsprozessen, Aufbau eines Schwachstellenmanagements und die Erstellung umfangreicher technischer Dokumentation brauchen Zeit.

Wer heute beginnt, hat die Möglichkeit, Cybersicherheit als echten Wettbewerbsvorteil zu etablieren – und ist für den 11. September 2026 (Meldepflichten) sowie den 11. Dezember 2027 (vollständige Anwendbarkeit) gut aufgestellt.

Und das Beste: Du musst das nicht alleine stemmen. CRAVEN wurde speziell für Hersteller von Produkten mit digitalen Elementen entwickelt und unterstützt dich bei den zentralen CRA-Prozessen: Vom geführten Produkt-Check zur Risikoklassifizierung über automatisiertes Schwachstellen-Monitoring mit SBOM-Abgleich und integriertem Incident-Response-Workflow bis hin zur zentralen Dokumentationsverwaltung und einer standardkonformen Plattform für externe Schwachstellenmeldungen.