Leitfaden zum EU Cyber Resilience Act (CRA) mit praktischen Tipps

Was für eine Veränderung! Während meiner Umgebung kaum Bewegung zu spüren war, als die Konsultationen zur Gesetzgebung liefen, summte das Web am Tag des Inkrafttretens der EU CRA vor Aktivität! Ich schreibe diesen Blogbeitrag als Gründer eines Unternehmens für Embedded-Software und kann Ihnen sagen, dass ich nie ein Unterstützer von Bürokraten war. Dennoch war eine solche Regulierung notwendig, und in diesem Fall ist es schwer, ihre Legitimität infrage zu stellen.

Sie wird nicht nur den EU-Markt, sondern auch den globalen Markt verändern. Die Festlegung von Standards ist eines der wenigen verbliebenen Alleinstellungsmerkmale der EU. Dennoch wird es irgendwann notwendig sein, eine Überregulierung zu vermeiden. Beispielsweise könnten Innovationen im Bereich medizinischer Geräte oder Drohnen in den USA entstehen und neue Produkte zuerst dort auf den Markt kommen.

Die Mehrheit der Projekte von Scythe betrifft Software für medizinische Geräte, die seit Langem strengen Anforderungen unterliegt. Obwohl die EU CRA solche Produkte nicht umfasst, rechtfertigt diese Tatsache meine Analyse dieses Themas. Scythe hatte bereits vor der Einführung dieser Regulierung durch die Europäische Union bewährte Verfahren für sicheres Design und Implementierung.

Was erwartet Sie in dieser Analyse?

Bereiten Sie sich auf einen umfangreichen Artikel und eine gehaltvolle, tiefgehende Analyse vor. Wir beginnen mit allgemeinen und formellen Aspekten, um einen soliden Hintergrund zu schaffen. Sie erhalten eine Definition der EU CRA und eine Beschreibung eines Produkts mit digitalen Komponenten und erfahren, ob Sie dieser Verordnung unterliegen.

Dann erörtern wir die Auswirkungen des Resilience Acts auf die Design- und Entwicklungsphase. Anschließend betrachten wir den Einfluss auf den Lebenszyklus des Produkts. Sie erfahren, worauf Sie zu Beginn, in der Mitte und nach der Markteinführung achten müssen.

Schließlich analysieren wir die tatsächlichen Anforderungen, die das Europäische Parlament an Hersteller stellt. Ich werde meine Interpretation in einfachem Deutsch präsentieren, ergänzt durch praktische Beispiele.
Holen Sie sich eine Tasse Ihres Lieblingsgetränks – Sie werden diesen Artikel wahrscheinlich mehr als einmal zur Hand nehmen.

Für wen ist dieser Artikel gedacht?

Ich stelle mir vor, dass Sie – die Person auf der anderen Seite des Bildschirms – irgendwie in die Entwicklung eines Produkts mit digitalen Elementen involviert sind. Sie könnten Gründer, CTO, Engineering Lead, Manager oder Entwickler sein. Alles, was ab diesem Punkt folgt, gilt für Sie unabhängig von Ihrer Rolle in der Entwicklungsphase. Ich bin kein Jurist, daher werde ich eine Sprache der Fakten und Beispiele verwenden.

Ich fasse diese Verordnung für Sie zusammen, um Ihnen Zeit zu sparen.

 

Was ist der EU Cyber Resilience Act (CRA)?

Der EU Cyber Resilience Act (CRA) ist eine Verordnung (konkret die Verordnung 2024/2847), die vom Europäischen Parlament eingeführt wurde, um die Cybersicherheit für digitale Produkte und Dienstleistungen zu stärken. Sie legt bestimmte Anforderungen und gesetzliche Verpflichtungen für Hardware- und Softwareprodukte während ihrer gesamten Entwicklungs- und Lebensdauer fest.

Der Text der Verordnung ist kein Geheimnis. Jeder kann den Cyber Resilience Act jederzeit im offiziellen Amtsblatt nachlesen. Praktisch ist, dass es hochwertige Übersetzungen gibt, sodass Sie ihn bequem in Ihrer Muttersprache lesen können.
Cyber Resilience Act auf Deutsch? Kein Problem. Sie finden ihn hier.

Wann immer es möglich ist, werde ich Verweise in Klammern auf den Originaltext in Englisch verwenden.

 

 

Produktsicherheit – Warum wurde die EU CRA eingeführt?

Cybersicherheit ist kein Klischee. In der Einleitung zur Verordnung (1) lesen wir, dass sie eine der zentralen Herausforderungen für die Union darstellt. Die Cyberbedrohung betrifft sowohl staatliche Organisationen als auch einzelne Verbraucher. Die Risiken reichen von nationaler Sicherheit und Diebstahl privater Daten bis hin zu tatsächlichem physischen Schaden für Menschen. Laut dieser Veröffentlichung beliefen sich die geschätzten weltweiten jährlichen Kosten durch Cyberkriminalität im Jahr 2021 auf 5,5 Billionen Euro!
Sehen wir uns einige Beispiele für Cyberangriffe an.

 

Beispiele erfolgreicher Cyberangriffe

Im Juli 2023 gab es in Polen, meiner Heimat, einen Angriff auf das Eisenbahnnetz. Die Züge stoppten. Eisenbahnen sind eine kritische Infrastruktur. Unter unseren Bedingungen werden sie beispielsweise genutzt, um militärische Nachschublieferungen von Westen nach Osten zu transportieren. Cyberangriffe durch ausgenutzte Schwachstellen können dazu führen, dass Lieferungen in einem entscheidenden Moment blockiert werden.

Nun ein jüngstes Beispiel für einen Cyberangriff, der Einzelpersonen betrifft. Im Januar 2025 bot das deutsche Unternehmen D-Trust eine e-Signatur-Lösung an, bei der Benutzerdaten gestohlen wurden. Dies ist bereits ein ernstes Problem. Laut dem betroffenen Unternehmen waren die endgültigen Auswirkungen nicht katastrophal, da die gestohlenen Daten gelöscht wurden. Aber stellen Sie sich das Chaos vor, wenn Angreifer die Funktionalität der Signaturen kompromittiert hätten.

Es ist eine große Herausforderung, alle Arten von Cyberangriffen zu listen und durch den Cyber Resilience Act angemessene Sicherheitsmaßnahmen durchzusetzen. Deshalb liegt es an den Herstellern von Hardware und Software, Risikobewertungen für ihre Produkte durchzuführen! Die Zahl erfolgreicher Cyberangriffe wird steigen, hoffentlich aber langsamer.

 

Wer muss die CRA einhalten?

Das Erste, was Hardware- und Softwarehersteller tun sollten, ist zu überprüfen, ob ihre Produkte unter den Cyber Resilience Act fallen. Werfen wir einen Blick auf den Originaltext.

EU-Verordnung 2024/2847 Artikel 2, Absatz 1

„1. Diese Verordnung gilt für Produkte mit digitalen Elementen, die auf dem Markt bereitgestellt werden und deren beabsichtigter Zweck oder vernünftigerweise vorhersehbare Nutzung eine direkte oder indirekte logische oder physische Datenverbindung zu einem Gerät oder Netzwerk umfasst.“

Die erste Frage lautet also: Was sind Produkte mit digitalen Elementen? Schauen wir erneut in den Text der CRA:

EU-Verordnung 2024/2847 Artikel 3

„(1) ‚Produkt mit digitalen Elementen‘ bezeichnet ein Software- oder Hardwareprodukt und dessen Remote-Datenverarbeitungslösungen, einschließlich Software- oder Hardwarekomponenten, die separat auf den Markt gebracht werden.“

Wie Sie sehen können, ist diese Definition ziemlich weit gefasst. Man kann hier zwischen folgenden Kategorien unterscheiden:

• Hardwareprodukte – Dies umfasst physische Geräte, sei es Wearables, Smart-Home-Produkte, Netzwerkausrüstung oder industrielle Maschinen mit digitalen Elementen. Grundsätzlich fallen alle Smart-Geräte unter diese Definition;

• Softwareprodukte – Dazu gehören Betriebssysteme, Sicherheitssoftware, Kommunikationssoftware, sogar Videospiele oder beliebige datenverarbeitende Anwendungen;

• Remote-Datenverarbeitungslösungen – Dies sind Lösungen, die auf eine Weise mit den oben genannten Hardware- und Softwareprodukten integriert sind, dass ihr Fehlen das digitale Produkt daran hindern würde, eine seiner Funktionen auszuführen (wie in 2024/2847 Präambel (11) dargelegt). Dies kann API, Datenbanken oder Dienste zur Durchführung von Berechnungen umfassen.

Trotz der Ausnahmen, die ich jetzt erklären werde, müssen sich wahrscheinlich über 90 % der auf dem EU-Markt erhältlichen Hardware- und Softwareprodukte an diese neue in der Europäischen Union eingeführte Verordnung halten.

 

Ausnahmen vom EU Cyber Resilience Act

Wie in der Präambel der Verordnung 2024/2847 (18) festgelegt, unterliegen Open-Source-Softwareprojekte nicht der EU CRA, solange diese Projekte nicht kommerziell genutzt werden oder von gemeinnützigen Organisationen entwickelt werden. Die Tatsache, dass ein Open-Source-Softwareentwickler finanzielle Unterstützung erhält oder seine Software regelmäßig veröffentlicht, bedeutet nicht unbedingt, dass es sich um eine kommerzielle Tätigkeit handelt.

Darüber hinaus fallen gemäß der Präambel 2024/2847 (12) Webseiten, die nicht zur Funktionalität von Produkten mit digitalen Elementen beitragen, sowie Cloud-Dienste, die unabhängig von der Verantwortung des Herstellers für solche Produkte entwickelt wurden, nicht in den Anwendungsbereich dieser Verordnung. Cloud-Dienste und ihre Bereitstellungsmodelle, einschließlich Software as a Service (SaaS), Platform as a Service (PaaS) und Infrastructure as a Service (IaaS), werden stattdessen durch die Richtlinie (EU) 2022/2555 geregelt.

Schließlich sind in der EU-Verordnung 2024/2847 Artikel 2, Absätze 2, 3 und 4 einige spezifische Richtlinien ausgeschlossen, da sie bereits strenge Anforderungen für bestimmte Produkte mit digitalen Elementen festlegen. Diese sind:

• Verordnung EU 2017/745 – Medizinprodukte-Verordnung (MDR). Ich habe bereits erwähnt, dass die Entwicklung von Software für medizinische Geräte mein Fachgebiet ist. Wenn Sie solche Geräte entwickeln und sich freuen, dass der Cyber Resilience Act Sie nicht betrifft, muss ich Sie leider enttäuschen und auf unseren Artikel zu Cybersecurity-Anforderungen für medizinische Geräte verweisen;

• Verordnung EU 2017/746 – Verordnung über In-vitro-Diagnostika (IVDR);

• Verordnung EU 2019/2144 – Allgemeine Fahrzeugsicherheitsverordnung (GSR);

• Verordnung EU 2018/1139 – Europäische Luftfahrtsicherheitsverordnung;

• Richtlinie 2014/90/EU – Richtlinie über Schiffsausrüstung (MED).

 

EU Cyber Resilience Act Ausnahmen

 

Klassen von Hardware- und Softwareprodukten

Produkte mit digitalen Elementen, die unter den EU Cyber Resilience Act fallen, werden je nach Wichtigkeit und potenziellem Schaden kategorisiert, sodass sich die Cybersicherheitsanforderungen für sie unterscheiden können. Ohne zu sehr ins Detail zu gehen, beginnen wir mit den kritischsten Produkten.

Kritische Klasse

Dies sind Produkte mit den strengsten Sicherheitsanforderungen. In Anhang IV der Verordnung 2024/2847 listet der Gesetzgeber einige Produkte namentlich auf. Um dies anschaulicher zu machen, gehören zu dieser Klasse beispielsweise:

 

• Hardware-Sicherheitsmodule – zur sicheren Verwaltung kryptografischer Schlüssel;
• Smart Meter Gateways – sichere Kommunikationsknoten für intelligente Stromzähler;
• Trusted Platform Modules – kryptografische Chips in Computern für sicheres Booten und Verschlüsselung;
• Sichere Elemente – eingebettete Sicherheitschips in Kreditkarten, SIM-Karten und Pässen;
• Kryptografische USB-Tokens – hardwarebasierte Authentifizierungsgeräte für sicheren Zugang (z. B. YubiKey).

Produkte der Kritischen Klasse müssen einer European Common Criteria (EUCC)-Zertifizierung unterzogen werden, die von einer akkreditierten Konformitätsbewertungsstelle durchgeführt wird.

 

Wichtige Klasse II

Dann gibt es weniger kritische, aber dennoch wichtige Produkte mit strengeren Sicherheitsanforderungen als die Standardklasse. Die sogenannte wichtige Klasse hat zwei Unterklassen (I und II) und umfasst Produkte mit digitalen Elementen, die ein erhebliches Risiko für die Gesundheit, Sicherheit oder den Schutz der Nutzer darstellen.

Die vollständige Liste der Klasse-II-Produkte finden Sie in Anhang III der Verordnung 2024/2847. Einige Beispiele sind:

 

• Hypervisoren für virtualisierte Umgebungen – wie VMware Tools oder VirtualBox;
• Netzwerksicherheits-Firewalls;
• Manipulationssichere Mikrocontroller;
• Manipulationssichere Mikroprozessoren.

Produkte der wichtigen Klasse II müssen einer Konformitätsbewertung durch Dritte unterzogen werden, unabhängig davon, ob sie harmonisierte Normen, gemeinsame Spezifikationen oder ein europäisches Cybersicherheitszertifizierungsschema einhalten.
Ich werde nicht näher auf diese Normen, Spezifikationen und Zertifizierungsprogramme eingehen – in diesem Artikel haben Sie ohnehin schon viel zu lesen.

 

Wichtige Klasse I

Diese Klasse umfasst weitere Arten von Geräten, die von Verbrauchern täglich genutzt werden. Die vollständige Liste ist ebenfalls in Anhang III der Verordnung 2024/2847 enthalten. Zu den wichtigsten Produkten zählen:

 

• Betriebssysteme;
• Webbrowser;
• Passwort-Manager;
• Virtuelle private Netzwerke (VPN);
• Boot-Manager;
• Smart-Home-Assistenten;
• Smart-Home-Sicherheitsprodukte wie Kameras oder Schlösser;
• Internetfähiges Spielzeug;
• Wearables mit Gesundheitsüberwachungsfunktionen;

Produkte dieser Klasse können eine Selbsteinschätzung durchführen, sofern sie eine der oben genannten Methoden anwenden können – nämlich harmonisierte Normen, gemeinsame Spezifikationen oder eine europäische Cybersicherheitszertifizierung.

 

Standardklasse

Alle anderen Produkte mit digitalen Elementen, die auf dem EU-Binnenmarkt verfügbar sind, fallen in die Standardklasse.
Ihr Produkt gehört höchstwahrscheinlich zu dieser Kategorie, wenn Sie vernetzte Geräte, Software-Apps, Videospiele oder andere Produkte entwickeln, die nicht in die vorherigen Klassen passen.

Die Standardklasse bedeutet jedoch nicht, dass die Cybersicherheitsanforderungen hier weniger streng sind. Ganz im Gegenteil – wahrscheinlich fallen 90 % aller Produkte in diese Kategorie.
Die wesentlichen Anforderungen werden später in diesem Artikel näher erläutert.

Hersteller von Software- und Hardwareprodukten in dieser Kategorie können die Einhaltung der wesentlichen EU-CRA-Anforderungen (wie in Anhang I der Verordnung 2024/2847 festgelegt) durch eine Selbsteinschätzung nach dem in Anhang VIII beschriebenen Protokoll nachweisen.

 

Klassen von Hardware- und Softwareprodukten

 

Ist die EU CRA in Kraft? Wichtige Termine für Softwarehersteller

Ja, aus rechtlicher Sicht ist die CRA bereits der aktuelle EU-Rechtsrahmen. Sie ist am 12. November 2024 in Kraft getreten.
Das bedeutet jedoch nicht, dass Ihre Produkte ab dem ersten Tag alle Anforderungen erfüllen müssen!
Die Gesetzgeber der Europäischen Union haben zwei wichtige Stichtage festgelegt. Werfen wir erneut einen Blick in den Originaltext.

EU-Verordnung 2024/2847 Präambel (126)

„(126) Wirtschaftsakteure sollten ausreichend Zeit erhalten, um sich an die in dieser Verordnung festgelegten Anforderungen anzupassen.
Diese Verordnung sollte ab dem 11. Dezember 2027 gelten, mit Ausnahme der Meldepflichten für aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle in Bezug auf Produkte mit digitalen Elementen. Diese Verpflichtungen sollten ab dem 11. September 2026 gelten, während die Vorschriften zur Notifizierung von Konformitätsbewertungsstellen ab dem 11. Juni 2026 gelten sollten.“

Daraus ergeben sich folgende Fristen:

 

• Ab dem 11. September 2026 müssen alle bekannten, ausnutzbaren Schwachstellen gemeldet werden.
• Ab dem 11. Dezember 2027 müssen alle Cybersicherheitsanforderungen erfüllt sein, einschließlich aller Bewertungs-, Design- und Implementierungsschritte sowie der Erstellung der technischen Dokumentation und der Konformitätsbewertung.

 

EU Cyber Resilience Act (CRA) Zeitplan

 

Wirtschaftliche Perspektive auf den EU Cyber Resilience Act

Erfahrene Software- und Hardwareentwickler werden zustimmen, dass der Entwicklungsprozess von Software anspruchsvoll und langwierig ist.
Wenn Sie es richtig machen wollen, dauert es seine Zeit, und es ist oft eine Herkulesaufgabe, den Prozess innerhalb des Budgets und der Zeitvorgaben abzuschließen.

Komplexe Produkte mit digitalen Elementen bestehen aus eingebetteten Geräten (oft aus mehreren Komponenten), internen, für den Nutzer unsichtbaren Softwarekomponenten, dazugehörigen Desktop- oder mobilen Apps, Cloud-Diensten und vielem mehr.
Oft kommen in all diesen Bereichen völlig unterschiedliche Technologien, Frameworks und Programmiersprachen zum Einsatz – ganz zu schweigen von Softwareabhängigkeiten in jeder einzelnen Komponente.
Die Entwicklung von Hard- und Softwareprodukten ist komplex und erfordert Fachwissen. Nun wird sie noch komplexer.

Warum sollten Hersteller sich kümmern?
Die Einführung neuer Geräte wird sicherlich schwieriger werden.
Die Umsetzung all dieser Cybersicherheitsregeln wird zeitaufwendiger sein, und viele Teams werden nicht über das erforderliche Fachwissen verfügen. Dies wird zu höheren wirtschaftlichen Kosten für viele Unternehmen führen. Für einige könnte es sogar das Ende bedeuten.
Deshalb ist es wichtig, Artikel wie diesen zu schreiben, um das mangelnde Verständnis auszugleichen.

 

Ich empfinde auch großes Mitgefühl für Startups, die nicht über die erforderlichen Ressourcen, Fähigkeiten und das Know-how verfügen, um das eigentliche Produkt zu entwickeln – geschweige denn den Cybersicherheitsaspekt.
Meiner Meinung nach kann der Cyber Resilience Act, obwohl notwendig, Innovationen einschränken.

Strafen

Artikel 64 ist den Sanktionen für die Nichteinhaltung gewidmet.
Nachfolgend ein Zitat aus dem Originaltext. Falls das nicht abschreckend genug ist, weiß ich nicht, was es sonst sein könnte:

Cyber Resilience Act 2024/2847 Artikel 64

„2. Die Nichteinhaltung der grundlegenden Cybersicherheitsanforderungen gemäß Anhang I sowie der Verpflichtungen gemäß den Artikeln 13 und 14 unterliegt Verwaltungsgeldbußen von bis zu 15.000.000 EUR oder, falls der Täter ein Unternehmen ist, bis zu 2,5 % seines weltweiten Jahresumsatzes im vorangegangenen Geschäftsjahr – je nachdem, welcher Betrag höher ist.“

 

Auswirkungen auf die Design- und Entwicklungsphase – Planung und Dokumentation

Wie verändern die neuen Cybersicherheitsregeln die reguläre Entwicklungsphase?
Die tatsächlichen Cybersicherheitsanforderungen werden später erklärt. Hier konzentrieren wir uns auf festgelegte Punkte in der Agenda der EU CRA.

Risikobewertung

Wie in Artikel 13 („Verpflichtungen der Hersteller“) festgelegt, muss alles mit einer Risikobewertung beginnen.
Eine Risikobewertung ist der Prozess der Identifizierung von Bedrohungen, Cyberrisiken und deren potenziellen Auswirkungen speziell für Ihr Produkt mit digitalen Elementen.
Dabei sollten der beabsichtigte Zweck, die erwartete Nutzung des Produkts, seine Betriebsumgebung und die zu schützenden Vermögenswerte berücksichtigt werden.
Diese Bewertung sollte über die erwartete Lebensdauer des Produkts hinweg erfolgen.

Die Risikobewertung sollte mehr als einmal durchgeführt werden.
Während dieses Prozesses sollten Sie bestimmen, ob eine bestimmte Anforderung für Ihr Produkt sinnvoll ist oder nicht.

Technische Spezifikationen

Bevor ein Produkt auf den Markt gebracht wird, müssen Hersteller eine technische Spezifikation erstellen, die die ergriffenen Maßnahmen zur Einhaltung der Vorschriften beschreibt.
Je nach Klassifizierung des Produkts kann es erforderlich sein, diese Dokumentation einer benannten Stelle vorzulegen.
Die Dokumentation sollte während des gesamten Unterstützungszeitraums regelmäßig aktualisiert werden, falls sich Änderungen ergeben.

Weitere Informationen zum erwarteten Inhalt der technischen Spezifikationen finden Sie in Anhang VII der EU-Verordnung 2024/2847.

 

Auswirkungen auf den Produktlebenszyklus – Unterstützungszeitraum

Eine der wichtigsten Änderungen für den Produktlebenszyklus ist die Verpflichtung, eine Unterstützungsdauer festzulegen, die der erwarteten Lebensdauer des Produkts entspricht.
Bei der Festlegung dieses Zeitraums sollten Hersteller die Erwartungen der Nutzer, die Art des Produkts und die einschlägigen EU-Vorschriften berücksichtigen (EU-Verordnung 2024/2847 Präambel (59)).
Der nächste Punkt besagt, dass dieser Zeitraum mindestens 5 Jahre betragen sollte – er hängt jedoch von der erwarteten Nutzungsdauer des Produkts ab.

Die Präambel, Punkt 61, schlägt vor, dass Hersteller den Quellcode nach Ablauf des Unterstützungszeitraums mit anderen Parteien teilen, falls sie das Produkt nicht mehr warten möchten.
Dies sollte so erfolgen, dass geistiges Eigentum und geschäftliche Interessen geschützt bleiben.
Das ist eine völlig neue Anforderung.

Falls ein Softwareprodukt über eine grafische Benutzeroberfläche verfügt, sollte es Informationen zum Ende des Unterstützungszeitraums anzeigen (EU-Verordnung 2024/2847 Präambel (56)).

 

 

Grundlegende EU-CRA-Anforderungen – Praktische Tipps für Cyber-Resilienz

Jetzt wird es spannend:
Die Idee dieser Verordnung ist es, einen einheitlichen Cybersicherheitsrahmen zu schaffen, der sowohl kritische als auch gewöhnliche elektronische Produkte abdeckt.
Daher gibt es eine Reihe von Anforderungen, die ich Ihnen (oder zumindest versuche) in einer für Softwareentwickler verständlichen Sprache erklären werde.

Die vollständige Liste der Anforderungen an Softwarekomponenten finden Sie im Originaltext aus dem Amtsblatt – insbesondere in EU-Verordnung 2024/2847 Anhang I: Grundlegende Cybersicherheitsanforderungen.
Ich werde Teil I dieses Anhangs zitieren. Teil II behandelt den Umgang mit entdeckten Schwachstellen – dies werde ich nur in meinem YouTube-Video zur EU CRA erklären, an dem ich derzeit arbeite.

Die folgende Erklärung basiert auf meinem Verständnis des Originaltexts und auf Beispielen, die ich online gefunden habe.
Ich garantiere nicht die vollständige Abdeckung aller Cybersicherheitsanforderungen.
Einige der Anforderungen werden mehr oder weniger offensichtlich erscheinen, aber ich werde versuchen, sie alle zu erklären und praktische Tipps zu geben.

 

Grundlegende EU-CRA-Anforderungen

 

1. Sicherheit durch Design

„(1) Produkte mit digitalen Elementen müssen so gestaltet, entwickelt und produziert werden, dass sie ein angemessenes Maß an Cybersicherheit gewährleisten, das auf den Risiken basiert.“

Sie sollten mit einer Risikobewertung beginnen, um die Sicherheitsanforderungen des Produkts zu definieren.
Dann sollten Sie eine geeignete Architektur entwerfen, die diese Anforderungen erfüllt.
Scythe Studio arbeitet häufig an medizinischen Softwareprojekten, bei denen es Standard ist, eine Software Requirements Specification (SRS) zu erstellen, die auch Cybersicherheitsanforderungen enthält.
Danach folgt die Software Detailed Design (SDD), die die Architektur der Lösung beschreibt.

Viele Projekte starten mit der Denkweise „Das bekommen wir schon irgendwie hin.“
Die Europäische Union hingegen fordert, dass Sicherheit von Anfang an berücksichtigt wird.

 

2. Keine bekannten Schwachstellen

„[…] Produkte mit digitalen Elementen müssen:
a) ohne bekannte ausnutzbare Schwachstellen auf den Markt gebracht werden;“

Das ist selbsterklärend.
Sie dürfen kein Produkt veröffentlichen, wenn es bekannte Sicherheitslücken aufweist, die ausgenutzt werden könnten und das System oder den Benutzer gefährden.
Bevor es auf den Markt kommt, müssen Sie das gesamte System auf Schwachstellen prüfen – einschließlich aller Abhängigkeiten, die in Ihrer Software Bill of Materials (SBoM) aufgelistet sind.
Falls eine Schwachstelle gefunden wird, muss sie behoben werden.

 

3. Sichere Standardkonfiguration

„[…] Produkte mit digitalen Elementen müssen:
b) mit einer sicheren Standardkonfiguration auf den Markt gebracht werden, sofern nicht anders zwischen Hersteller und gewerblichem Nutzer für ein maßgeschneidertes Produkt mit digitalen Elementen vereinbart, einschließlich der Möglichkeit, das Produkt auf den ursprünglichen Zustand zurückzusetzen;“

Wenn Ihr Produkt Schutzmechanismen enthält, sollten diese standardmäßig aktiviert sein.
Zum Beispiel sollte die Zwei-Faktor-Authentifizierung (2FA) standardmäßig eingeschaltet sein, wenn sie erforderlich ist.

Außerdem sollte, wenn Ihre Hardware- oder Softwareprodukte lokale Benutzerdaten speichern (z. B. Sicherheitseinstellungen oder Geheimnisse), eine Möglichkeit bestehen, das System auf seinen ursprünglichen Werkszustand zurückzusetzen.

 

4. Sicherheitsupdates

„[…] Produkte mit digitalen Elementen müssen:
c) gewährleisten, dass Schwachstellen durch Sicherheitsupdates behoben werden können, einschließlich – wo zutreffend – automatischer Sicherheitsupdates, die innerhalb eines angemessenen Zeitraums installiert werden und standardmäßig aktiviert sind, mit einer klaren und einfach zu bedienenden Opt-out-Option, durch Benachrichtigungen über verfügbare Updates für Benutzer sowie durch die Möglichkeit, diese vorübergehend zu verschieben;“

Sie müssen eine Möglichkeit implementieren, alle Softwarekomponenten Ihres Systems zu aktualisieren, sodass ein potenzieller Angreifer keine Updates fälschen kann.
Dazu ist ein System erforderlich, das die Authentizität jedes Updates überprüft.

Die Cyber Resilience Act gibt nicht vor, ob Ihre Updates per USB-Stick (immer noch weit verbreitet) oder über das Internet erfolgen sollen.
Sie verlangt jedoch, dass sobald ein Sicherheitsupdate verfügbar ist, es auch bereitgestellt wird.

Falls ein Gerät mit dem Internet verbunden ist, kann eine regelmäßige Prüfung auf Updates sinnvoll sein.
Wenn Sie ein Wearable-Gerät entwickeln, das nur über Bluetooth mit einem Smartphone verbunden ist, sollte auch die mobile App periodisch oder bei Verbindung nach Updates suchen.

 

5. Schutz vor unbefugtem Zugriff und Meldung

„[…] Produkte mit digitalen Elementen müssen:
d) Schutz vor unbefugtem Zugriff durch geeignete Kontrollmechanismen gewährleisten, einschließlich, aber nicht beschränkt auf Authentifizierungs-, Identitäts- oder Zugangsverwaltungssysteme, und über möglichen unbefugten Zugriff Bericht erstatten;“

Implementieren Sie eine starke Authentifizierung und Zugangskontrollen, um unbefugten Zugriff zu verhindern.
Dazu gehören Passwortrichtlinien, Multi-Faktor-Authentifizierung (MFA) und rollenbasierte Zugriffskontrolle (RBAC).
Jeder unbefugte Zugriffsversuch sollte protokolliert und gemeldet werden.
Überlegen Sie sich besonders strenge Kontrollmechanismen für Rollen mit erweiterten Berechtigungen, wie Techniker oder Entwickler.

 

6. Schutz der Datenvertraulichkeit

„[…] Produkte mit digitalen Elementen müssen:
e) die Vertraulichkeit gespeicherter, übertragener oder anderweitig verarbeiteter Daten, persönlicher oder anderer, durch moderne Verschlüsselungsmechanismen und andere technische Mittel schützen;“

Die Cyber Resilience Act schreibt vor, dass alle gespeicherten oder übertragenen Daten verschlüsselt werden müssen.
Dabei sollen moderne Verschlüsselungsverfahren verwendet werden, z. B. AES-256 für gespeicherte Daten und TLS 1.2+ für die Übertragung.

Falls Sie Daten lokal auf einer Festplatte speichern, sollten diese ebenfalls verschlüsselt werden, da jemand das Gehäuse gewaltsam öffnen, die Festplatte entfernen und die Daten auslesen könnte.
Viele Systeme ermöglichen eine automatische Festplattenverschlüsselung, die hier hilfreich wäre.

Die Verschlüsselung von persönlichen und betrieblichen Daten verhindert Lauschangriffe und unbefugten Zugriff.
Beispielsweise sollten medizinische Bildgebungssysteme Scans verschlüsseln, bevor sie über das Netzwerk gesendet werden.

 

7. Integrität des Systems

„[…] Produkte mit digitalen Elementen müssen:
f) die Integrität gespeicherter, übertragener oder anderweitig verarbeiteter Daten, Befehle, Programme und Konfigurationen gegen jede Manipulation oder nicht autorisierte Modifikation schützen und über mögliche Korruptionen Bericht erstatten;“

Hier geht es darum sicherzustellen, dass keine unbefugten Änderungen am System vorgenommen wurden.
Hersteller sollten nicht nur einen sicheren Boot-Prozess implementieren, sondern auch Mechanismen zur Verifizierung der Systemintegrität bereitstellen.
Dies kann durch Checksummen, Verschlüsselung und Authentifizierungsverfahren erfolgen.
Falls eine Manipulation festgestellt wird, sollte das Gerät nicht weiter booten oder arbeiten.

Für IoT-Geräte, die über ein Netzwerk kommunizieren, ist es besonders wichtig, eine Verifizierungsmethode einzusetzen, um sicherzustellen, dass die andere Partei autorisiert ist, an der Datenübertragung teilzunehmen.

 

8. Datenminimierung

„[…] Produkte mit digitalen Elementen müssen:
g) nur Daten verarbeiten, die angemessen, relevant und auf das notwendige Maß im Hinblick auf den vorgesehenen Zweck des Produkts mit digitalen Elementen beschränkt sind (Datenminimierung);“

Sie sollten nur die Daten verarbeiten und speichern, die für den Betrieb des Systems unbedingt erforderlich sind.
Dieser Punkt ist besonders interessant in Bezug auf Datenanalysen.
Einige Softwareprodukte erfassen Benutzerverhalten, um die Benutzererfahrung zu verbessern.
Selbst wenn die Daten anonymisiert werden, handelt es sich dabei um gesammelte Informationen, die sorgfältig geprüft werden sollten.

 

9. Schutz kritischer und grundlegender Funktionen

„[…] Produkte mit digitalen Elementen müssen:
h) die Verfügbarkeit wesentlicher und grundlegender Funktionen schützen, auch nach einem Vorfall, einschließlich durch Resilienz- und Abhilfemaßnahmen gegen Denial-of-Service-Angriffe;“

Ihr Hardware- oder Softwareprodukt sollte so gestaltet sein, dass kritische Funktionen zusätzlich gesichert und isoliert sind, selbst wenn das System kompromittiert wird.
Dies ist keine einfache Aufgabe, aber eine Microservices-Architektur kann hier hilfreich sein.
Dabei werden verschiedene Funktionen als separate, voneinander unabhängige Dienste implementiert.
Der Teil des Systems, der für eine kritische Funktion verantwortlich ist (z. B. Steuerung eines Fahrzeugs oder einer industriellen Maschine), sollte von den Diensten mit Zugriff auf externe Schnittstellen strikt getrennt sein.

Falls Sie ein industrielles Robotersystem entwickeln, könnte ein Backup-Steuerungssystem implementiert werden, das im Notfall automatisch übernimmt, ohne dass die Produktion unterbrochen wird.

 

10. Minimierung negativer Auswirkungen

„[…] Produkte mit digitalen Elementen müssen:
i) die negativen Auswirkungen der Produkte selbst oder angeschlossener Geräte auf die Verfügbarkeit von Diensten anderer Geräte oder Netzwerke minimieren;“

Die EU CRA verlangt, dass vernetzte Geräte die Leistung, Verfügbarkeit oder Sicherheit anderer Geräte oder Netzwerke nicht beeinträchtigen.
Wie kann das in der Praxis umgesetzt werden?

Wenn Sie beispielsweise eine Flotte von vernetzten Drohnen in einer Fabrik betreiben, sollten Sie sicherstellen, dass keine unnötig große Datenmenge in hoher Frequenz an die zentrale Steuerung gesendet wird.
Übertragen Sie nur die tatsächlich erforderlichen Daten und fassen Sie, wenn möglich, mehrere Informationen zusammen, bevor sie gesendet werden.
Protokolle wie MQTT, OPC UA oder DDS ermöglichen es, nur bestimmte Nachrichten-Themen zu abonnieren, anstatt den gesamten Datenverkehr zu verarbeiten.

 

11. Begrenzung der Angriffsfläche

„[…] Produkte mit digitalen Elementen müssen:
j) so konzipiert, entwickelt und produziert sein, dass die Angriffsflächen, einschließlich externer Schnittstellen, begrenzt werden;“

Falls Ihr Gerät eine Platine mit zahlreichen physischen Schnittstellen hat, sollten diese entweder systemseitig deaktiviert oder softwareseitig blockiert werden.
Ein Beispiel aus meiner Praxis: In einem unserer medizinischen Projekte konnten Benutzer CT-Scans über einen USB-Stick hochladen.
Da der USB-Port nur für diesen Zweck benötigt wurde, war er standardmäßig deaktiviert und wurde nur bei der expliziten Nutzung freigeschaltet.

Ein weiteres Beispiel betrifft den Fernzugriff auf Maschinen.
Einige Hersteller implementieren eine Fernwartungsfunktion.
Dieser Fernzugriff sollte jedoch nur aktiviert sein, wenn er absichtlich vom Benutzer eingeschaltet und authentifiziert wurde.

Mein Tipp:
Bleiben Sie minimalistisch.
Vermeiden Sie unnötige Funktionen, die potenzielle Angriffsvektoren für Cyberangriffe darstellen könnten.

 

12. Minderung der Folgen von Angriffen

„[…] Produkte mit digitalen Elementen müssen:
k) so konzipiert, entwickelt und produziert sein, dass sie die Auswirkungen eines Vorfalls durch geeignete Abhilfemaßnahmen und Exploit-Mitigationsmechanismen verringern;“

Hardware- und Softwarehersteller sollten Cyberangriffe als unvermeidbar betrachten.
Selbst die am besten geschützten digitalen Systeme können eine unentdeckte Schwachstelle aufweisen.
Der Schlüssel ist, die Auswirkungen solcher Angriffe zu minimieren, um Betriebsunterbrechungen, Datenverluste oder Sicherheitsrisiken zu vermeiden.

Ihr System sollte eine Möglichkeit zur sicheren Wiederherstellung des letzten bekannten stabilen Zustands bieten.
Wenn z. B. ein Firmware-Update fehlschlägt oder eine Anomalie erkannt wird, sollte das System automatisch zur vorherigen Version zurückkehren.

Auch hier kann eine Microservices-Architektur von Vorteil sein.
Falls ein einzelner Dienst kompromittiert wird, verhindert diese Architektur, dass sich Malware auf das gesamte System ausbreitet.

 

13. Protokollierung und Überwachung

„[…] Produkte mit digitalen Elementen müssen:
l) sicherheitsrelevante Informationen bereitstellen, indem sie relevante interne Aktivitäten aufzeichnen und überwachen, einschließlich des Zugriffs auf oder der Modifikation von Daten, Diensten oder Funktionen, mit einer Opt-out-Option für den Nutzer;“

Zur weiteren Reduzierung von Cyberangriffen schreibt der Gesetzgeber vor, dass Protokollierung und Überwachung sicherheitsrelevanter Aktivitäten implementiert werden müssen.
Dazu gehören beispielsweise der Zugriff auf Daten, Änderungen an Systemkonfigurationen und Anmeldeversuche.
Diese Logs sollten manipulationssicher und sicher gespeichert werden.

 

14. Datenlöschung

„[…] Produkte mit digitalen Elementen müssen:
m) eine sichere und einfache Möglichkeit für Benutzer bieten, alle Daten und Einstellungen dauerhaft zu löschen, und wenn solche Daten auf andere Produkte oder Systeme übertragen werden können, sicherstellen, dass dies auf sichere Weise geschieht.“

Ihr Hardware- oder Softwareprodukt sollte eine Funktion enthalten, mit der alle gespeicherten Benutzerdaten dauerhaft gelöscht werden können.
Dies umfasst nicht nur persönliche Daten, sondern auch lokal gespeicherte Einstellungen.

Es sollte zudem möglich sein, alle Benutzerinformationen von entfernten Cloud-Diensten oder verbundenen Geräten zu entfernen.

Falls Ihr Produkt die Möglichkeit bietet, Daten zu exportieren oder auf ein anderes System oder Gerät zu übertragen (z. B. eine neue Version des gleichen Produkts), muss dieser Prozess sicher erfolgen.

 

Sichere Hardware- und Softwarelösungen – Gemeinsam eine sicherere Zukunft gestalten

Dies ist wahrscheinlich der längste und formellste Artikel, den ich jemals geschrieben habe – aber dennoch enthält er viele technische Tipps.
Falls Ihr Unternehmen sich mit diesem Thema auseinandersetzt, sollten Sie erwägen, uns zu engagieren, um sicherzustellen, dass Ihre Software den Cyber Resilience Act (CRA)-Standards entspricht.

Unsere umfassende Erfahrung in der stark regulierten Medizintechnikbranche garantiert robuste Cybersicherheit, Compliance und Risikominimierung – unabhängig von Ihrer Branche.
Bleiben Sie der sich wandelnden Gesetzeslage einen Schritt voraus – arbeiten Sie mit uns zusammen, um sichere, zukunftssichere Softwarelösungen zu entwickeln.
Gemeinsam schaffen wir Widerstandsfähigkeit!