Jahrelang spielte die Kryptografie in der Entwicklung von „ software “ nur eine untergeordnete Rolle – ein Detail, über das Teams außerhalb von Sicherheitsüberprüfungen kaum sprachen. Das EU-Gesetz zur Cyberresilienz (CRA)rückt sie nun in den Mittelpunkt der Produktregulierung. Nach dem CRA entscheiden die kryptografischen Entscheidungen in Ihrem „ software “ nun mit darüber, ob es rechtmäßig auf den europäischen Markt gelangen darf.
Der Mechanismus ist das CE-Zeichen. Dieselbe Kennzeichnung, die die physische und elektrische Sicherheit von EU-Produkten regelt, gilt nun auch für die Cybersicherheit aller Produkte mit einer digitalen Komponente. Werden die grundlegenden Anforderungen der CRA nicht erfüllt, darf Ihr Produkt das CE-Zeichen nicht tragen.
Ohne die CE-Kennzeichnung darf das Produkt nicht verkauft werden. Dies gilt für jeden Hersteller, der ein Produkt mit digitalen Elementen auf dem EU-Markt in Verkehr bringt, unabhängig davon, wo das Unternehmen seinen Sitz hat.
Was das Gesetz zur Cyber-Resilienz tatsächlich vorschreibt
Das Gesetz zur Cyber-Resilienz, offiziell Verordnung (EU) 2024/2847, ist das erste branchenübergreifende „Secure-by-Design“-Gesetz der EU für Produkte mit digitalen Elementen. „Branchenübergreifend“ bedeutet, dass es sich nicht auf einen bestimmten Sektor bezieht, sondern branchenübergreifend gilt. „Secure-by-Design“ bedeutet, dass die Sicherheit von Anfang an in das Produkt integriert sein muss und nicht erst später hinzugefügt wird.
Die Verordnung unterteilt die Verpflichtungen in zwei Teile. Anhang I, Teil I befasst sich mit der Produktsicherheit bei der Entwicklung: den Eigenschaften, die ein Produkt bei seiner Auslieferung aufweisen muss. Anhang I, Teil II befasst sich mit dem Umgang mit Sicherheitslücken während des Lebenszyklus: wie Sicherheitslücken nach der Markteinführung des Produkts erkannt, behoben und kommuniziert werden. Die Einhaltung der CRA bedeutet, beide Anforderungen zu erfüllen, nicht nur die erste Version abzusichern.
Wer fällt in den Geltungsbereich?
Die CRA deckt ein breites Spektrum an Funktionen entlang der gesamten Lieferkette der „ software “ ab:
- Software Produzenten und Herausgeber, darunter eigenständige software und eingebettete software.
- Lösungen zur Ferndatenverarbeitung, die integraler Bestandteil eines Produkts sind, d. h., das Produkt kann ohne sie seine Funktion nicht erfüllen.
- Open-source Anbieter, die ihre „ software “ kommerziell vertreiben.
- Importeure und Händler, die sich vergewissern müssen, dass der Hersteller eines Produkts seinen Verpflichtungen nachgekommen ist.
Wenn Sie „ software “ entwickeln, verpacken oder weiterverkaufen, die in die EU gelangen, tragen Sie mit ziemlicher Sicherheit eine gewisse Verantwortung gemäß dem CRA.
Kategorien „Standard“, „Wichtig“ und „Kritisch“
Die CRA stuft Produkte nach ihrem Risiko ein. Die meisten Produkte fallen in die Kategorie „Standard“. Darüber liegen die Klassen „Wichtig“ (Klasse I und Klasse II) sowie die Kategorie „Kritisch“, für die strengere Konformitätsbewertungspflichten gelten. Zahlreiche Beispiele für „Wichtige“ Produkte finden sich im IT-Bereich und unter software, darunter Identitätsmanagementsysteme, VPNs software und Firewalls. Wenn Ihr Produkt eine Sicherheitsfunktion wie diese erfüllt, müssen Sie mit höheren Anforderungen an den Nachweis rechnen. In einigen Fällen bedeutet dies eine Prüfung durch eine benannte Stelle anstelle einer Selbsterklärung.
Warum das wichtig ist: CE-Kennzeichnung, Fristen und Sanktionen
Die wirtschaftliche Logik ist klar. Nicht konforme software verlieren die für den Zugang zum EU-Markt erforderliche CE-Kennzeichnung. Eine Lücke in der CRA stellt daher nicht nur ein Sicherheitsproblem dar, sondern auch ein Problem hinsichtlich Umsatz und Vertrieb.
Die Sanktionen unterstreichen dies noch. Die Geldbußen betragen bis zu 15 Millionen Euro oder 2,5 Prozent des weltweiten Jahresumsatzes, je nachdem, welcher Betrag höher ist. Diese Obergrenze gilt für Verstöße gegen die grundlegenden Anforderungen des Anhangs I sowie gegen die Verpflichtungen aus den Artikeln 13 und 14; für andere Verpflichtungen gelten niedrigere Obergrenzen.
Wie sich das CRA auf Kryptografie und PKI bezieht
Die CRA behandelt das Thema Kryptografie anhand mehrerer miteinander verknüpfter Kontrollbereiche in Anhang I. Jeder dieser Bereiche bezeichnet eine Sicherheitseigenschaft, und hinter den meisten davon steht eine Public-Key-Infrastruktur (PKI), die es ermöglicht, diese Eigenschaft in großem Maßstab praktisch umzusetzen. Und so hängen die einzelnen Teile zusammen.
Vertraulichkeit von gespeicherten und übertragenen Daten
Anhang I, Teil I, Abschnitt 2 Buchstabe e schreibt vor, dass Produkte die Vertraulichkeit relevanter Daten sowohl im Ruhezustand als auch während der Übertragung mithilfe modernster Verschlüsselungstechniken schützen müssen. In der Praxis beruht dieser Schutz auf einer PKI, die die Sitzungs- und Dienstzertifikate ausstellt, die zum Aufbau verschlüsselter Kanäle und zum Schutz gespeicherter Daten verwendet werden.
Integrität von Daten, Befehlen und Konfiguration
Anhang I, Teil I, Abschnitt 2(f) schreibt vor, dass die Integrität von gespeicherten, übertragenen und verarbeiteten Daten, Befehlen, Programmen und Konfigurationen vor nicht vom Benutzer autorisierten Manipulationen geschützt werden muss und dass Beschädigungen gemeldet werden müssen. Signierte Konfigurationen und authentifizierte, zertifikatsgestützte Kanäle bieten Ihnen die Möglichkeit nachzuweisen, dass ein „ command “ oder eine Einstellung aus einer vertrauenswürdigen Quelle stammt und unverändert angekommen ist.
Standardmäßig sichere Konfiguration und Identität
Anhang I, Teil I, Abschnitte 2(b) und 2(d) schreiben sichere Standardeinstellungen und eine identitätsbasierte Zugriffskontrolle vor. Punkt 2(b) schreibt zudem vor, dass das Produkt in seinen ursprünglichen Zustand zurückgesetzt werden kann, und Punkt 2(d) verlangt die Meldung möglicher unbefugter Zugriffe. Das praktische Ziel ist eine eindeutige Dienst- oder Instanzidentität, die bei der Bereitstellung zugewiesen wird, anstatt gemeinsamer Standard-Anmeldedaten, die mit jeder Kopie ausgeliefert werden. Zertifikatsbasierte Identitäten ermöglichen es jeder Workload, sich selbst zu authentifizieren.
Sicherer Aktualisierungsmechanismus
Anhang I, Teil I, Abschnitt 2 Buchstabe c in Verbindung mit Anhang I, Teil II, Nummern 7 und 8 schreibt einen sicheren Aktualisierungsmechanismus vor. Aktualisierungen müssen während des gesamten vorgeschriebenen Supportzeitraums unverzüglich und kostenlos bereitgestellt werden. Außerdem müssen sie kryptografisch signiert sein, damit die Empfänger die Echtheit vor der Installation überprüfen können. Die Codesignierung ist die Kontrollmaßnahme, die dies überprüfbar macht.
Sichtbarkeit kryptografischer Komponenten
Für die Komponentenverfolgung gibt es einen expliziten Ansatzpunkt. Anhang I, Teil II, Punkt (1) verpflichtet Hersteller dazu, Schwachstellen und Komponenten zu identifizieren und zu dokumentieren, einschließlich einer „ software “-Stückliste in einem maschinenlesbaren Format, die zumindest die Abhängigkeiten auf oberster Ebene abdeckt. Kryptografiespezifische Anforderungen werden durch Anhang K festgelegt, einen branchenübergreifenden Anhang, der derzeit im Rahmen der ETSI-CYBER-EUSR-Standards entwickelt wird, die durch den Normungsantrag M/606 vorgeschrieben sind. Dieser Anhang soll voraussichtlich eine Zulassungsliste für kryptografische Mechanismen definieren, die auf den Leitlinien der ENISA basiert. Es wird erwartet, dass Sie die kryptografischen Bibliotheken und Algorithmen identifizieren können, die in Ihrer „ software “ und deren Abhängigkeiten eingebettet sind. Auf diese Weise können Sie das Risiko bewerten und schnell Abhilfemaßnahmen ergreifen, wenn eine Komponente als anfällig identifiziert wird.
Sichere Datenlöschung
Anhang I, Teil I, Abschnitt 2(m) schreibt die Unterstützung einer sicheren, dauerhaften Löschung von Daten und Einstellungen vor. Für „ software “, die Mandanten- oder Kundenumgebungen verwalten, umfasst dies die Vernichtung kryptografischer Schlüssel beim Offboarding oder bei der Außerbetriebnahme, sodass ausgemusterte Daten nicht wiederhergestellt werden können.
Vorbereitung auf die Prüfung: Fragen, die die Prüfer stellen werden
Bei CRA-Konformitätsbewertungen – unabhängig davon, ob sie selbst erklärt oder von einer benannten Stelle überprüft werden – stehen nachweisbare Fakten im Vordergrund und nicht politische Erklärungen. Eine schriftliche Absichtserklärung zur Verschlüsselung von Daten hat wenig Gewicht, wenn nicht nachgewiesen wird, dass der entsprechende Mechanismus vorhanden ist und funktioniert. Nutzen Sie die folgenden Prüfbereiche als Checkliste für Ihre Selbstbewertung:
- Dokumentation zur Risikobewertung, die Ihre Entscheidungen hinsichtlich des kryptografischen Designs begründet.
- Eine eindeutige kryptografische Identität für jeden Dienst, jede Instanz oder jeden Mandanten.
- Eine signierte Update-Pipeline, die Signaturen vor der Installation überprüft und bei der automatische Updates standardmäßig aktiviert sind.
- Ein Verzeichnis der kryptografischen Komponenten, das die übernommenen Abhängigkeiten von „ open-source “ abdeckt.
- Verfahren zur sicheren Löschung und Vernichtung von Schlüsseln im Rahmen der Personalabmeldung oder Außerbetriebnahme.
- Dokumentierte und mitgeteilte Verpflichtungen hinsichtlich der Supportdauer. Fünf Jahre sind die Mindestlaufzeit; sie ist länger, wenn das Produkt länger genutzt wird, und kürzer nur dann, wenn die erwartete Nutzungsdauer unter fünf Jahren liegt.
Wo soll man anfangen: Ein praktischer Weg zur Vorbereitung
Man muss nicht jede Anforderung auf einmal lösen, aber die Reihenfolge ist entscheidend. Eine sinnvolle Reihenfolge sieht folgendermaßen aus:
- Stellen Sie sicher, dass Ihr Meldeverfahren gemäß Artikel 14 in Betrieb ist. Das bedeutet: einen benannten Verantwortlichen, einen Erfassungsprozess für Hinweise auf Schwachstellen und Vorfälle sowie die Möglichkeit, über die zentrale Meldeplattform der ENISA und Ihr koordinierendes CSIRT eine Frühwarnung innerhalb von 24 Stunden, eine Meldung innerhalb von 72 Stunden und einen Abschlussbericht einzureichen.
- Verschaffen Sie sich einen Überblick über Ihre kryptografischen Vermögenswerte, denn was Sie nicht sehen können, können Sie auch nicht schützen oder rechtfertigen.
- Weisen Sie Diensten und Instanzen eindeutige Identitäten zu, um gemeinsam genutzte Standardwerte zu ersetzen.
- Richten Sie eine signierte Update-Pipeline mit Überprüfung vor der Installation ein.
- Erstellen Sie ein Verzeichnis der kryptografischen Komponenten, das auch die Abhängigkeiten von „ open-source “ enthält.
- Dokumentieren Sie die risikobasierten Entwurfsentscheidungen, die jeder einzelnen Wahl zugrunde liegen.
Fangen Sie frühzeitig an. Die wesentlichen Anforderungen treten im Dezember 2027 in Kraft, die Verpflichtungen zur Meldung von Sicherheitslücken jedoch bereits im September 2026. Die oben genannten Designänderungen erfordern Zeit für die Planung, das Testen und die Einführung in einem auslieferungsreifen Produkt.
Wie Keyfactor helfen Keyfactor
Keyfactor bietet „ software “-Anbietern einen konkreten Weg von den CRA-Anforderungen bis zur Umsetzung und ordnet jeden Kontrollbereich einer Funktion zu, die Sie einsetzen können.
Keyfactor AgileSec befasst sich mit der Transparenz kryptografischer Komponenten. Die Lösung ermittelt und erfasst kryptografische Bibliotheken, Algorithmen, Schlüssel und Protokolle in Ihrem Code, auf Ihren Endpunkten, in Ihren Cloud-Workloads und in Ihren Abhängigkeiten. Anschließend bewertet sie die Risiken, sodass Sie Abhilfemaßnahmen priorisieren und Ihre Sicherheitsrisiken gegenüber einem Prüfer nachweisen können.
EJBCA bildet die PKI-Grundlage für Vertraulichkeit, Integrität und standardmäßig sichere Identitäten. Es stellt die Zertifikate aus, die Daten sowohl während der Übertragung als auch im Ruhezustand schützen. Es vergibt eindeutige Service- und Instanz-Identitäten anstelle gemeinsam genutzter Anmeldedaten und unterstützt die Vernichtung kryptografischer Schlüssel für ein sauberes Offboarding und eine ordnungsgemäße Außerbetriebnahme.
Keyfactor SignServer, zusammen mit Keyfactor Signumbietet den sicheren Update-Mechanismus. Beide signieren „ software “-Updates und Release-Artefakte kryptografisch mit durch „ hardware “ geschützten Schlüsseln und signierten Prüfprotokollen, sodass Empfänger die Authentizität während des gesamten Supportzeitraums überprüfen können.
Keyfactor Command verbindet alles operativ miteinander. Es automatisiert den Zertifikatslebenszyklus hinter diesen Identitäten und Kanälen und bietet Sicherheitsteams so kontinuierliche Transparenz, automatisierte Verlängerung und zentralisierte Steuerung in allen Umgebungen.
Einzeln betrachtet erfüllen diese Produkte spezifische CRA-Kontrollanforderungen. Zusammen bilden sie die „Trust Control Plane“ v Keyfactor. Es handelt sich um ein einziges System zur Überwachung Ihrer kryptografischen Infrastruktur, zur Risikoanalyse, zur Bereitstellung vertrauenswürdiger Identitäten, zur Koordinierung von Maßnahmen und zur Steuerung aller Prozesse gemäß den Richtlinien. Dies entspricht genau dem kontinuierlichen Kreislauf, dessen Nachweis die CRA von Ihnen verlangt – vom ersten Entwurf bis zum Ende des gesamten Supportzeitraums.
Sind Sie bereit, Ihre CRA-Verpflichtungen in einen Plan zur Betriebsbereitschaft umzusetzen? Fordern Sie eine Demo an.
Haben Sie Fragen zum „Cyber Resilience Act“? Wir haben die Antworten.
Was ist das EU-Gesetz zur Cyber-Resilienz?
Das Gesetz zur Cyber-Resilienz (Verordnung (EU) 2024/2847) ist das erste horizontale Gesetz der EU, das eine „Secure-by-Design“-Cybersicherheit für Produkte mit digitalen Elementen vorschreibt, d. h. für Produkte, die „ software “ oder „ hardware “ sind, sowie für deren Lösungen zur Fernverarbeitung von Daten. Es verknüpft die Einhaltung der Vorschriften direkt mit der CE-Kennzeichnung und unterteilt die Verpflichtungen in die Bereiche „Produktsicherheitsdesign“ und „Umgang mit Schwachstellen während des Lebenszyklus“.
Gilt die CRA auch für Unternehmen außerhalb der EU, die „ software “ anbieten?
Ja. Sie gilt für jeden Hersteller, der ein Produkt mit digitalen Elementen auf dem EU-Markt in Verkehr bringt, unabhängig davon, wo das Unternehmen seinen Sitz hat. Software Hersteller, open-source Betreiber, die Produkte kommerziell vertreiben, sowie Importeure und Händler unterliegen alle bestimmten Verpflichtungen.
Wann treten die CRA-Anforderungen in Kraft?
Die Meldepflichten gemäß Artikel 14 gelten seit dem 11. September 2026 und beziehen sich auf Produkte, die bereits auf dem EU-Markt sind. Die Bestimmungen zu den benannten Stellen gelten seit dem 11. Juni 2026. Die grundlegenden Anforderungen, die Konformitätsbewertung und die CE-Kennzeichnung gelten ab dem 11. Dezember 2027.
Welche Sanktionen drohen bei Nichteinhaltung?
Die Sanktionenbelaufen sich auf bis zu 15 Millionen Euro oder 2,5 Prozent des weltweiten Jahresumsatzes – je nachdem, welcher Betrag höher ist. Nicht konforme software verlieren zudem die für den Zugang zum EU-Markt erforderliche CE-Kennzeichnung, sodass es sich hierbei nicht nur um ein Sicherheitsproblem, sondern auch um ein Problem des Marktzugangs handelt.
Welche kryptografischen Kontrollmaßnahmen schreibt die CRA vor?
Die CRA behandelt das Thema Kryptografie in mehreren Kontrollbereichen des Anhangs I. Diese umfassen die Vertraulichkeit und Integrität von Daten, eine von Haus aus sichere Konfiguration und Identitätsprüfung, signierte Updates, die Sichtbarkeit kryptografischer Komponenten sowie die sichere Datenlöschung einschließlich der Vernichtung von Schlüsseln. Jede Entscheidung muss durch eine produktspezifische Risikobewertung begründet werden.
Was ist ein Bestandsverzeichnis kryptografischer Komponenten und warum ist es wichtig?
Es handelt sich um eine Auflistung aller kryptografischen Bibliotheken und Algorithmen, die in Ihrem software eingebettet sind, einschließlich der vererbten open-source Abhängigkeiten. Prüfer erwarten dies, und ohne ein solches Verzeichnis können Sie nicht schnell feststellen, welche Risiken bestehen, wenn eine Schwachstelle in einer Komponente bekannt wird.
Für welche Produkte gelten strengere CRA-Verpflichtungen?
Für die Kategorien „Wichtig“ (Klasse I und II) und „Kritisch“ gelten strengere Konformitätsbewertungsverpflichtungen als für die Standardkategorie. Im Bereich IT und software gehören dazu Identitätsmanagementsysteme und VPN- software.
Wie unterstützt PKI die Einhaltung der CRA-Vorgaben?
PKI bildet die Grundlage für die zentralen kryptografischen Anforderungen der CRA. Zertifikate verschlüsseln Daten sowohl während der Übertragung als auch im Ruhezustand und weisen Diensten und Geräten eindeutige Identitäten zu. Außerdem werden damit „ software “-Updates signiert, sodass Empfänger die Authentizität während des gesamten Supportzeitraums überprüfen können.
