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: Security-by-Design und Security-by-Default, sichere Standardkonfiguration, Schutz von Vertraulichkeit, Integrität und Verfügbarkeit, reduzierte Angriffsfläche und sichere Update-Mechanismen; die Auslieferung soll risikobasiert ohne bekannte ausnutzbare Schwachstellen erfolgen. 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 oder eines Zertifizierungsschemas, sonst Prüfung durch eine notifizierte Stelle.
• Wichtige Produkte, Klasse II (z. B. Firewalls, IDS/IPS, Hypervisoren): verpflichtende Drittprüfung, reine Selbstbewertung reicht nicht.
• Kritische Produkte (z. B. Hardware-Sicherheitsmodule, Smartcards): höchste Stufe mit möglicher verpflichtender europäischer Zertifizierung.

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: Frühwarnung binnen 24 Stunden, ausführlichere Meldung binnen 72 Stunden, Abschlussbericht bei Schwachstellen binnen 14 Tagen nach Verfügbarkeit der Abhilfe und bei schwerwiegenden Vorfällen binnen eines Monats. 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 nennt einen Richtwert von typischerweise mindestens fünf Jahren beziehungsweise der erwarteten Nutzungsdauer; die Festlegung bleibt eine Risiko- und Geschäftsentscheidung pro Produkt. 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?
• Wie erreichen wir bis zum 11.09.2026 die Fähigkeit, Schwachstellen und Vorfälle fristgerecht zu melden?
• Bauen wir Konformität auf harmonisierte Normen 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. Priorisieren Sie die Meldefähigkeit mit Blick auf den 11.09.2026 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; Public Domain.
• BSI TR-03183: frei zugängliche Orientierungshilfe zum CRA, nicht rechtsverbindlich, ohne Vermutungswirkung.