Der Cyber Resilience Act: Produkte mit digitalen Elementen

Problem in der Praxis

Viele Unternehmen behandeln den CRA als reines Kennzeichnungsthema und unterschätzen, dass er tief in Produktentwicklung, Lieferkette und Betrieb eingreift; Cybersicherheit wird von einer freiwilligen Eigenschaft zur Voraussetzung für die CE-Kennzeichnung. Oft fehlt schon die Grundlage: Welche eigenen Produkte sind überhaupt Produkte mit digitalen Elementen, welche Drittkomponenten und Open-Source-Bestandteile stecken darin, gibt es eine belastbare Software-Stückliste (SBOM), und wie lange wird ein Produkt nach dem Verkauf von wem mit Updates versorgt?

Hinzu kommt die Rollenfrage in der Lieferkette. Hersteller tragen die Hauptlast, doch auch Einführer (Importeure) und Händler haben Prüf- und Sorgfaltspflichten. Wer ein bestehendes Produkt wesentlich verändert, kann selbst zum Hersteller im Sinne der Verordnung werden und dessen volle Pflichten übernehmen.

CISO-Einordnung

Der CRA verschiebt Sicherheitsverantwortung nach vorne in den Produktlebenszyklus und ist für den CISO kein isoliertes Rechtsthema, sondern ein Steuerungsthema zwischen Produktmanagement, Entwicklung, Einkauf und Recht.

Die Verordnung fordert zweierlei. Erstens Produkteigenschaften: Nach Anhang I Teil I Nummer 1 sind Produkte so zu konzipieren, zu entwickeln und herzustellen, dass sie angesichts der Risiken ein angemessenes Cybersicherheitsniveau gewährleisten. Die Einzeleigenschaften nach Anhang I Teil I Nummer 2, darunter Auslieferung ohne bekannte ausnutzbare Schwachstellen, sichere Standardkonfiguration, Schutz von Vertraulichkeit, Integrität und Verfügbarkeit, Beschränkung der Datenverarbeitung auf das erforderliche Maß, möglichst geringe Angriffsflächen und Sicherheitsaktualisierungen zur Behebung von Schwachstellen, gelten auf der Grundlage der Bewertung der Cybersicherheitsrisiken nach Artikel 13 Absatz 2 und nur, soweit zutreffend; für die sichere Standardkonfiguration lässt Buchstabe b bei einem maßgeschneiderten Produkt eine abweichende Vereinbarung zwischen Hersteller und gewerblichem Nutzer zu. Zweitens Schwachstellenbehandlung über den Lebenszyklus: Komponenten und Schwachstellen dokumentieren (inklusive SBOM), zeitnah patchen, regelmäßig testen, eine Coordinated-Vulnerability-Disclosure-Politik und Kontaktstelle vorhalten und Updates über den Unterstützungszeitraum bereitstellen. Hierfür etablieren Hersteller typischerweise ein Product Security Incident Response Team (PSIRT).

Die zentrale Steuerungslogik liegt in den Produktklassen; sie bestimmen, wie streng die Konformität nachzuweisen ist:

• Standardprodukte (nicht gelistet): in der Regel Selbstbewertung durch interne Kontrolle.
• Wichtige Produkte, Klasse I (z. B. Passwortmanager, VPN, Betriebssysteme): Selbstbewertung nur bei vollständiger Anwendung harmonisierter Normen, gemeinsamer Spezifikationen oder eines nach Artikel 27 Absatz 9 ausgewiesenen europäischen Cybersicherheits-Zertifizierungsschemas mit einem Zertifikat mindestens der Vertrauenswürdigkeitsstufe „mittel“, sonst Prüfung durch eine notifizierte Stelle; für freie und quelloffene Software der Anhang-III-Kategorien gilt die Ausnahme nach Artikel 32 Absatz 5.
• Wichtige Produkte, Klasse II (z. B. Firewalls, IDS/IPS, Hypervisoren): verpflichtende Drittprüfung, ersetzbar allein durch ein nach Artikel 27 Absatz 9 CRA ausgewiesenes Zertifizierungsschema, soweit verfügbar und anwendbar, mit einem Zertifikat mindestens der Vertrauenswürdigkeitsstufe „mittel“. Reine Selbstbewertung reicht nicht. Eine Ausnahme gilt nach Artikel 32 Absatz 5 CRA für Produkte, die als freie und quelloffene Software gelten und in eine der in Anhang III aufgeführten Kategorien fallen: Deren Hersteller können die Konformität anhand eines der in Artikel 32 Absatz 1 genannten Verfahren nachweisen, also auch per Selbstbewertung durch interne Kontrolle (Modul A), sofern die technische Dokumentation nach Artikel 31 zum Zeitpunkt des Inverkehrbringens der Öffentlichkeit zugänglich gemacht wird. Die Ausnahme erfasst nur Anhang III, nicht die kritischen Produkte nach Anhang IV.
• Kritische Produkte (z. B. Hardware-Sicherheitsmodule, Smartcards): höchste Stufe. Schreibt die Kommission nach Artikel 8 Absatz 1 CRA eine europäische Cybersicherheitszertifizierung vor, ist das der Weg; sonst gelten nach Artikel 32 Absatz 4 die Verfahren der Klasse II. Eine reine Selbstbewertung steht in keinem Fall offen.

Welches Produkt in welche Klasse fällt, ergibt sich aus den Anhängen der Verordnung und kann durch Rechtsakte der Kommission präzisiert werden; die Einstufung ist daher pro Produkt am Original zu prüfen.

Umsetzungsperspektive

Der Termin-Kalender ist der Taktgeber. Inkrafttreten war am 10.12.2024; ab dem 11.06.2026 gelten die Regeln zur Notifizierung der Konformitätsbewertungsstellen, ab dem 11.09.2026 die Meldepflichten der Hersteller. Die Vollanwendung der übrigen Hauptpflichten inklusive Konformitätsbewertung und CE-Kennzeichnung folgt am 11.12.2027.

Die Meldepflichten sind dreistufig und gelten bei aktiv ausgenutzten Schwachstellen und schwerwiegenden Vorfällen. Gemeldet wird an das zuständige nationale CSIRT und an ENISA über die zentrale Meldeplattform: jeweils unverzüglich und gerechnet ab Kenntniserlangung eine Frühwarnung in jedem Fall binnen 24 Stunden, eine ausführlichere Meldung binnen 72 Stunden und, soweit die Angaben nicht bereits vorgelegt wurden, ein Abschlussbericht bei aktiv ausgenutzten Schwachstellen spätestens 14 Tage, nachdem eine Korrektur- oder Risikominderungsmaßnahme zur Verfügung steht, und bei schwerwiegenden Sicherheitsvorfällen binnen eines Monats nach Übermittlung der 72-Stunden-Meldung. Mit dem Abschlussbericht endet die Pflichtenkette nicht: Nach Artikel 14 Absatz 8 informiert der Hersteller zusätzlich die betroffenen Nutzer, gegebenenfalls alle Nutzer, über die aktiv ausgenutzte Schwachstelle oder den schwerwiegenden Vorfall und erforderlichenfalls über Risikominderungs- und Korrekturmaßnahmen, die die Nutzer ergreifen können; versäumt er die rechtzeitige Information, können die als Koordinatoren benannten CSIRTs diese Informationen den Nutzern zur Verfügung stellen, wenn sie dies für verhältnismäßig und erforderlich halten. Wegen des früheren Meldetermins ist die Meldefähigkeit das erste Arbeitspaket mit harter Frist; Inventar, SBOM und Konformitätsbewertung folgen mit Blick auf Dezember 2027.

Typische Fehler

1. Den CRA als reines CE-Aufkleberthema behandeln statt als Eingriff in Entwicklung und Betrieb.
2. Kein vollständiges Inventar der Produkte mit digitalen Elementen und ihrer Bestandteile führen.
3. Die Produktklasse falsch oder gar nicht einstufen und das Konformitätsverfahren unterschätzen.
4. SBOM und Schwachstellenmanagement zu spät aufsetzen, obwohl die Meldepflichten früher greifen.
5. Die eigene Rolle in der Lieferkette verkennen, etwa nach wesentlicher Veränderung eines Zukaufprodukts.

Risiken und Trade-offs

Eine zu hohe Einstufung erzeugt unnötigen Prüfaufwand und verzögert Markteinführungen; eine zu niedrige führt zu fehlerhafter Konformität, im Ergebnis darf das Produkt dann nicht rechtskonform in Verkehr gebracht werden.

Beim Unterstützungszeitraum binden lange Update-Zusagen Entwicklungskapazität, kurze widersprechen der erwarteten Nutzungsdauer. Der CRA setzt nach Art. 13 Abs. 8 UAbs. 3 ein verbindliches Minimum von fünf Jahren; nur eine kürzere voraussichtliche Nutzungsdauer tritt an dessen Stelle. Die Festlegung ist nach Art. 13 Abs. 8 UAbs. 2 an Kriterien gebunden und keine freie Geschäftsentscheidung. Hinzu kommt die Abhängigkeit von harmonisierten Normen: solange diese nicht final vorliegen, ist die Vermutungswirkung für Klasse-I-Produkte noch nicht voll nutzbar.

Entscheidungspunkte

• Welche unserer Produkte sind Produkte mit digitalen Elementen, und in welche Klasse fallen sie nach den Anhängen der Verordnung?
• Fallen einzelne Produkte unter gleichwertige sektorspezifische EU-Regelungen (z. B. Medizinprodukte, bestimmte Kfz-Typgenehmigung, zivile Luftfahrt) und sind dadurch vom CRA ausgenommen?
• Welche Rolle nehmen wir je Produkt ein: Hersteller, Bevollmächtigter, Einführer oder Händler?
• Wie lang ist der Unterstützungszeitraum je Produkt, und wer verantwortet Updates über diesen Zeitraum?
• Ist unsere Fähigkeit, Schwachstellen und Vorfälle fristgerecht zu melden, seit dem 11.09.2026 tatsächlich einsatzbereit?
• Bauen wir Konformität auf harmonisierte Normen, gemeinsame Spezifikationen oder ein ausgewiesenes Zertifizierungsschema auf, oder planen wir früh eine Prüfung durch eine notifizierte Stelle?

Praktische Empfehlungen

1. Erstellen Sie zuerst ein Produktinventar mit Klassifizierung und Rollenzuordnung in der Lieferkette.
2. Etablieren Sie SBOM, Schwachstellenmanagement und CVD-Kontaktstelle als Dauerbetrieb, nicht als Projekt.
3. Stellen Sie sicher, dass die seit dem 11.09.2026 geltende Meldefähigkeit steht, und üben Sie die 24-/72-Stunden-Abläufe.
4. Verankern Sie Security-by-Design und sichere Update-Mechanismen im regulären Entwicklungsprozess.
5. Leiten Sie verbindliche Detailpflichten stets aus der Verordnung selbst ab und beobachten Sie den Stand der harmonisierten Normen.

Relevante Normreferenzen

• Verordnung (EU) 2024/2847 (Cyber Resilience Act): primäre, verbindliche Rechtsquelle; EU-Recht, mit Quellenangabe frei zitierbar.
• IEC 62443: wichtiger Kandidat für harmonisierte Normen (Produktentwicklungslebenszyklus, Komponenten); Referenz, kein Volltext.
• ISO/IEC 27001 / 27002: organisatorische Referenz für sichere Entwicklung und Schwachstellenbehandlung; reference-only, keine Control-Nummern-Listen.
• NIST SSDF (SP 800-218): prozessuale Referenz für sichere Softwareentwicklung und SBOM; in den USA gemeinfrei, ausserhalb der USA mit weltweitem, verguetungsfreiem Nachdruck- und Bearbeitungsrecht.
• BSI TR-03183: frei zugängliche Orientierungshilfe zum CRA, nicht rechtsverbindlich, ohne Vermutungswirkung.