Cyber Resilience Act: Was Hersteller jetzt wissen müssen 


Mit dem Cyber Resilience Act (CRA) schafft die Europäische Union erstmals einen verbindlichen Rechtsrahmen für die Cybersicherheit digitaler Produkte.

Ob smarte Kaffeemaschine, industrielle Steuerung oder Business-Software: Künftig müssen alle vernetzten Produkte über ihren gesamten Lebenszyklus hinweg bestimmte Sicherheitsanforderungen erfüllen. Ziel ist es, einheitliche Anforderungen an die Cybersicherheit von Hardware und Software zu schaffen. 
 
Für Entwickler bedeutet das: Jetzt ist der richtige Zeitpunkt, sich vorzubereiten.

In diesem Beitrag zeigen wir, welche Anforderungen der CRA konkret stellt, welche Produkte betroffen sind, welche Schritte Entwickler jetzt unternehmen sollten und welche Risiken bei Nichteinhaltung drohen. 
 
Mit einer Übergangsfrist von nur 36 Monaten ist der CRA ab Mitte 2027 verpflichtend. Die Produkte, die dann verkauft werden, werden bereits heute entwickelt. Wer also jetzt handelt, minimiert Risiken und verschafft sich Wettbewerbsvorteile. 
 
CSA unterstützt Unternehmen dabei, die Anforderungen des CRA frühzeitig und effizient umzusetzen. Von der Analyse betroffener Produkte über die technische Umsetzung bis hin zur Dokumentation und Begleitung bei Audits. 

 

Das Wichtigste in Kürze

  • Der CRA betrifft fast alle vernetzten Produkte, auch Embedded-Systeme.
  • Neben Produktsicherheit sind auch Prozesse entscheidend (z. B. Schwachstellenmanagement und Dokumentationen).
  • Die Einhaltung muss nachgewiesen werden, inkl. CE-Kennzeichnung.
  • Wer gegen den CRA verstösst, riskiert hohe Strafen.
  • Die Dokumentation, insbesondere die Risikoanalyse, ist nicht eine einmalige Sache und muss periodisch aktualisiert werden.

 

Was ist der Cyber Resilience Act (CRA)? 

Der Cyber Resilience Act (CRA) ist eine geplante EU-Verordnung, die erstmals verbindliche Cybersicherheitsanforderungen für Produkte mit digitalen Elementen festlegt. Also für fast alles, was Software enthält und mit anderen Geräten oder Netzwerken kommunizieren kann. 
 
Der CRA verfolgt drei Hauptziele:

  • Schutz der Verbraucher und Unternehmen vor unsicheren digitalen Produkten
  • Reduktion von Sicherheitslücken in Software und vernetzten Geräten über den gesamten Produktlebenszyklus hinweg
  • Stärkung des digitalen Binnenmarkts durch einheitliche Sicherheitsstandards in der EU 

 

Das bedeutet konkret: Hersteller (und Inverkehrbringer) müssen technische und organisatorische Massnahmen umsetzen, damit ihre Produkte sicher sind, ab Entwicklung bis zur Stilllegung.

Dazu gehören u. a.:

  • Secure-by-Design:
    Sicherheit bereits bei Entwicklung berücksichtigen
  • Schwachstellenmanagement:
    Prozesse zum Erkennen, Melden und Patchen von Sicherheitslücken etablieren
  • Technische Dokumentation:
    Risikobewertung, Sicherheitskonzepte und Updates nachweisen
  • Konformitätserklärung:
    Sicherheitsanforderungen müssen dokumentiert und allenfalls durch eine Benannte Stelle bestätigt werden

 

Welche Produkte fallen unter den CRA und welche nicht?

Der CRA gilt für „Produkte mit digitalen Elementen“, darunter fallen:

  • Software und Betriebssysteme
  • IoT-Geräte (z. B. Smart-Home, Wearables)
  • Industrielle Steuerungssysteme
  • Netzwerkgeräte (z. B. Router, Firewalls)
  • Anwendungen mit Netzwerkverbindung

Nicht betroffen sind:

  • Open-Source-Software, die nicht kommerziell vertrieben wird
  • Produkte, die bereits unter andere EU-Verordnungen mit gleichwertigen Anforderungen fallen (z. B. medizinische Geräte unter der MDR)

Die genaue Abgrenzung erfolgt über zwei Produktkategorien: 

 

Übersicht der Produktkategorien im Cyber Resilience Act (CRA): Einteilung in Standardkategorie, wichtige Produkte (Klasse I und II) und kritische Produkte mit jeweiligen Anforderungen an Konformitätsbewertung und Zertifizierung.

Quelle: https://www.tuvsud.com/de-de/dienstleistungen/produktpruefung-und-produktzertifizierung/cyber-resilience-act

 

Welche Konsequenzen drohen bei Nichteinhaltung?

Die EU setzt auf harte Durchsetzung:

  • Geldstrafen bis zu 15 Millionen Euro oder 2,5 % des weltweiten Jahresumsatzes. Je nachdem, welcher Betrag höher ist
  • Marktzugang kann untersagt werden, wenn die CE-Kennzeichnung fehlt oder Mängel bestehen
  • Haftung im Schadensfall, falls Sicherheitsmängel nachweislich nicht berücksichtigt wurden

Das bedeutet: Cybersicherheit wird zur zentralen Compliance-Aufgabe, auch für die Geschäftsführung.

 

Hersteller vs. Inverkehrbringer: Wer trägt die Verantwortung?

  • Hersteller:
    Hauptverantwortlich für Design, Entwicklung, Risikomanagement, Konformitätsbewertung

  • Inverkehrbringer (z. B. Distributoren, OEMs):
    Müssen sicherstellen, dass die gelieferten Produkte CRA-konform sind inkl. Dokumentation und CE-Kennzeichnung

Die Verantwortung lässt sich nicht vollständig outsourcen. Auch Inverkehrbringer haften, wenn sie unsichere Produkte in Umlauf bringen.

 

Folgende Punkte müssen Entwickler im Auge behalten 

  • Vulnerability Identification and Management 
    Ein zentrales Element des CRA ist die systematische Identifikation und das Management von Schwachstellen. Hersteller müssen sicherstellen, dass sie Schwachstellen frühzeitig erkennen, bewerten und beheben können, sowohl in selbst entwickeltem Code als auch in verwendeten Drittkomponenten. Dies schliesst die Einführung automatisierter Sicherheitsanalysen (z. B. statische und dynamische Codeanalysen) sowie die Erstellung und Pflege einer Software Bill of Materials (SBOM) ein. Besonders bei Embedded Systemen ist dies eine Herausforderung, da proprietäre Komponenten und eingeschränkte Ressourcen häufig eine lückenlose Überwachung erschweren.

  • Security Updates and Disclosure 
    Der CRA verpflichtet Hersteller dazu, über die gesamte vorgesehene Lebensdauer ihrer Produkte hinweg sicherheitsrelevante Updates bereitzustellen und diese auch so zu gestalten, dass Nutzer sie zuverlässig und sicher installieren können. Dies betrifft vor allem IoT- und Embedded-Geräte, bei denen Updates oft selten oder gar nicht erfolgen. Gleichzeitig müssen Sicherheitsupdates nachvollziehbar dokumentiert und öffentlich kommuniziert werden, etwa durch die Angabe behobener CVEs. Ein fehlendes oder unsicheres Update-Management kann künftig als schwerwiegende Compliance-Verletzung gewertet werden.

  • Vulnerability Reporting and Coordination 
    Die Meldung und Koordination von Schwachstellen gewinnt unter dem CRA neue Verbindlichkeit. Entdeckt ein Hersteller eine aktiv ausnutzbare Sicherheitslücke, ist er verpflichtet, diese innerhalb von 24 Stunden an die zuständigen Behörden bzw. an die ENISA zu melden. Zudem müssen klare Prozesse für die Annahme externer Schwachstellenmeldungen bereitgestellt werden.

  • Security Management 
    Sicherheit darf kein Add-on sein, sondern muss integraler Bestandteil des gesamten Produktentwicklungsprozesses sein. Der CRA verlangt daher ein strukturiertes Sicherheitsmanagement über den gesamten Produktlebenszyklus. Das umfasst Risikoanalysen, die Implementierung eines sicheren Entwicklungsprozesses (Secure SDLC), die klare Definition von Rollen und Verantwortlichkeiten sowie die lückenlose Dokumentation aller Sicherheitsmassnahmen. Organisationen müssen in der Lage sein, diese Massnahmen bei einer Prüfung nachzuweisen.

  • Data and Privacy Protection 
    Produkte mit digitalen Elementen müssen gemäss CRA so gestaltet sein, dass die Vertraulichkeit, Integrität und Verfügbarkeit personenbezogener sowie sensibler Daten gewährleistet ist. Die Anforderungen umfassen unter anderem den Einsatz starker Verschlüsselung, die Anwendung von „Privacy-by-Design“ und „Privacy-by-Default“-Prinzipien sowie den Schutz vor unbefugtem Zugriff oder unkontrollierter Datenweitergabe. Für eingebettete Systeme mit begrenztem Speicher und Rechenleistung stellt dies oft eine besondere Herausforderung dar – etwa bei der sicheren Speicherung und Verarbeitung personenbezogener Daten.

  • Access Control and Monitoring 
    Ein weiterer Schwerpunkt liegt auf dem Schutz vor unautorisiertem Zugriff. Der CRA fordert die Umsetzung robuster Zugriffskontrollen, darunter sichere Authentifizierungsmechanismen, Rollen- und Rechtemanagement sowie den Verzicht auf voreingestellte Standardpasswörter oder hardcodierte Zugangsdaten. Zusätzlich müssen Produkte die Möglichkeit bieten, sicherheitsrelevante Ereignisse zu protokollieren und im Bedarfsfall nachvollziehbar auszuwerten. Gerade in verteilten Systemen mit Embedded-Komponenten erfordert dies eine gezielte Architekturplanung.

  • Resilience and Incident Mitigation 
    Schliesslich verlangt der CRA, dass Produkte widerstandsfähig gegenüber Cyberangriffen sind – und im Ernstfall kontrolliert reagieren können. Das bedeutet: Sicherheitsfunktionen dürfen bei einem Angriff nicht vollständig ausfallen, sondern müssen Fehlertoleranz zeigen. Eingebaute Recovery-Mechanismen, wie z. B. Dual-Firmware-Strategien oder abgesicherte Bootloader, können hier entscheidend sein. Unternehmen müssen zudem in der Lage sein, auf Sicherheitsvorfälle schnell zu reagieren, deren Auswirkungen zu begrenzen und betroffene Nutzer umgehend zu informieren.

 

Wir helfen mit

Der CRA ist mehr als eine rechtliche Vorschrift, er ist ein Impuls, Sicherheit als festen Bestandteil der Produktentwicklung zu verankern.

Wer frühzeitig mit der Umsetzung beginnt, sichert sich langfristig Vertrauen, Rechtssicherheit und Marktchancen.

Wie gehen Sie mit dem CRA in Ihrem Unternehmen um? Haben Sie Fragen zur Umsetzung oder zur Einordnung Ihrer Produkte?

Kontaktieren Sie unser Expertenteam, wir begleiten Sie gerne auf dem Weg zur CRA-Compliance. 

Matthias Renner

Matthias Renner

BSc BFH in Mikrotechnik
Embedded Software Engineer

Über den Autor

Seit Anfang 2022 ist Matthias Renner als Embedded Software Entwickler bei der CSA Engineering AG tätig und unterstützt dort vor allem Kunden aus dem Bereich Medizintechnik bei der Entwicklung sicherer und leistungsfähiger Firmware in C/C++.

Sein besonderes Interesse gilt der Cybersicherheit im Embedded-Umfeld. Insbesondere den Herausforderungen, die sich durch regulatorische Anforderungen wie den Cyber Resilience Act ergeben. 

Kontaktiere uns