Gesetz zur Cyber-Resilienz für IT & Software
Kryptografie und PKI für Produkte von „ Software “ mit digitalen Elementen
| Region | Weltweit (gilt für jedes Produkt, das in der EU in Verkehr gebracht wird, unabhängig vom Standort des Herstellers oder Herausgebers) |
| Anwendbarkeit | Software Hersteller und Herausgeber: eigenständige software, SaaS-Komponenten mit einer digitalen Komponente sowie eingebettete software , die in die EU verkauft werden Open-Source Verantwortliche: Organisationen , die open-source software mit digitalen Komponenten unter den in der Verordnung festgelegten Bedingungen kommerziell vertreiben Importeure und Vertreiber: müssen die Einhaltung der Vorschriften durch den Hersteller überprüfen, bevor sie software auf dem EU-Markt bereitstellen |
| Relevante Abschnitte | Anhang I, Teil I: Wesentliche Anforderungen an die Cybersicherheit (Entwurf und Standardkonfiguration) Anhang I, Teil II: Anforderungen an den Umgang mit Sicherheitslücken während der gesamten Supportdauer Anhänge III und IV: Wichtige und kritische Produktkategorien, die einer strengeren Konformitätsbewertung unterliegen |
Übersicht
Das Gesetz zur Cyber-Resilienz (CRA), Verordnung (EU) 2024/2847, ist das erste horizontale Gesetz der EU, das eine „Secure-by-Design“-Cybersicherheit für Produkte vorschreibt, die ein digitales Element aufweisen oder enthalten, vernetzt sind hardware, software, oder eine Datenverarbeitung aus der Ferne ermöglichen und in der EU in Verkehr gebracht werden, wobei die Einhaltung der Vorschriften direkt an die CE-Kennzeichnung geknüpft ist. Die Verordnung unterteilt die Verpflichtungen in Anforderungen an die Produktsicherheit bei der Konzeption (Anhang I, Teil I) und Anforderungen an den Umgang mit Sicherheitslücken während des Lebenszyklus (Anhang I, Teil II).
Insbesondere für „ software “ müssen Hersteller Produkte ausliefern, bei denen der kryptografische Schutz für die Vertraulichkeit und Integrität der Daten standardmäßig aktiviert ist, die über kryptografisch verifizierte software -Updates verfügen und einen sicheren Identitäts- und Authentifizierungsmechanismus aufweisen – all dies muss durch eine produktspezifische Cybersicherheits-Risikobewertung und nicht durch eine festgelegte Checkliste begründet sein. Zu den wichtigen Kategorien (Klasse I und II) gehören Identitätsmanagementsysteme und VPN- software, die beide eindeutig zur IT- und software -Branche gehören.
Warum das wichtig ist
Die CRA gilt im Wesentlichen für alle in der EU verkauften vernetzten Produkte software . Für die Produktkategorien „Wichtig“ und „Kritisch“ sowie für Identitätsmanagementsysteme, VPN- software und ähnliche sicherheitsrelevante software gelten strengere Konformitätsbewertungspflichten als für die Standardkategorie.
Die wesentlichen Anforderungen müssen bis zum 11. Dezember 2027 vollständig umgesetzt sein, wobei die Meldepflichten für Sicherheitslücken und aktive Ausnutzung bereits früher, nämlich ab September 2026, gelten. Die Strafen belaufen sich auf 15 Millionen Euro oder 2,5 % des weltweiten Gesamtumsatzes, je nachdem, welcher Betrag höher ist, und nicht konforme software verlieren das für den Zugang zum EU-Markt erforderliche CE-Zeichen, wodurch dies ebenso sehr eine Frage des Marktzugangs wie der Sicherheit ist.
Wie sich dies auf die Kryptografie auswirkt
Das EU-Gesetz zur Cyberresilienz befasst sich mit Kryptografie anhand mehrerer miteinander verknüpfter Kontrollbereiche. Die wichtigsten Bereiche mit direkten Auswirkungen auf die Kryptografie sind:
| Abschnitt | Funktion | Was dort steht | Unterstützung für „ Keyfactor “-Produkte |
| Anhang I, Teil I, § 2 Buchstabe e | Vertraulichkeit von gespeicherten und übertragenen Daten | Verschlüsseln Sie relevante Daten im Ruhezustand und während der Übertragung mithilfe modernster Verfahren, gestützt durch die PKI, die Sitzungs- und Dienstzertifikate ausstellt. | Command / EJBCA |
| Anhang I, Teil I, § 2 Buchstabe f | Integrität von Daten, Befehlen und Konfiguration | Schützen Sie Befehle, Konfigurationen und den Anwendungsstatus vor unbefugten Manipulationen, in der Regel durch signierte Konfigurationen und authentifizierte Kanäle. | EJBCA |
| Anhang I, Teil I, § 2 Buchstabe b und § 2 Buchstabe d | Standardmäßige Sicherheitskonfiguration und Identität | Wird mit einer sicheren Standardkonfiguration und identitätsbasierter Zugriffskontrolle bereitgestellt, d. h. bei der Bereitstellung wird eine eindeutige Dienst- oder Instanzidentität zugewiesen, anstatt gemeinsamer Standard-Anmeldedaten zu verwenden. | Keyfactor Command |
| Anhang I, Teil I, § 2 Buchstabe c; Anhang I, Teil II, § 7 | Mechanismus für sichere Updates | software -Updates kryptografisch signieren und diese während des gesamten vorgeschriebenen Supportzeitraums unverzüglich und kostenlos bereitstellen. | SignServer / Signum |
| Im Rahmen der vorgeschriebenen Risikobewertung impliziert; im künftigen Anhang K als Zulassungsliste vorgesehen | Sichtbarkeit kryptografischer Komponenten | Identifizieren und verfolgen Sie eingebettete kryptografische Bibliotheken und Algorithmen im gesamten „ software “ und dessen Abhängigkeiten, um Risiken zu bewerten und Abhilfemaßnahmen zu unterstützen. | Command / AgileSec |
| Anhang I, Teil I, § 2 Buchstabe m | Sichere Datenlöschung | Unterstützung der sicheren und dauerhaften Löschung von Daten und Einstellungen, einschließlich der Vernichtung kryptografischer Schlüssel, im Rahmen der Abmeldung von Mandanten oder der Stilllegung. | EJBCA |
Prüfungsbereitschaft
Bewertungen und Prüfungen – unabhängig davon, ob sie intern durchgeführt, von einer Aufsichtsbehörde vorgenommen oder von einem unabhängigen Gutachter überprüft werden – konzentrieren sich auf nachgewiesene Fakten und nicht allein auf Grundsatzerklärungen. Zu den wichtigsten Bereichen, die Prüfer und Gutachter üblicherweise untersuchen, gehören:
- Dokumentation der Risikobewertung: Hat die Organisation eine produktspezifische Cybersicherheits-Risikobewertung durchgeführt und dokumentiert, die ihre Entscheidungen hinsichtlich des kryptografischen Designs begründet?
- Bereitstellung von Identitäten für Dienste und Instanzen: Wird jedem Dienst, jeder Instanz oder jedem Mandanten eine eindeutige kryptografische Identität zugewiesen, anstatt auf gemeinsam genutzte oder Standard-Anmeldedaten zurückzugreifen?
- Signierte Update-Pipeline: Kann die Organisation nachweisen, dass Updates von „ software “ vor der Installation kryptografisch signiert und verifiziert werden, wobei automatische Updates standardmäßig aktiviert sind?
- Bestandsaufnahme der kryptografischen Komponenten: Führt die Organisation eine Bestandsaufnahme aller in der „ software “ eingebetteten kryptografischen Bibliotheken und Algorithmen, einschließlich der aus „ open-source “ übernommenen Abhängigkeiten?
- Sicheres Löschen und Schlüsselvernichtung: Unterstützt das Produkt das sichere Löschen von Daten, einschließlich der Vernichtung kryptografischer Schlüssel, im Rahmen der Abmeldung von Mandanten oder der Außerbetriebnahme?
- Verpflichtungen hinsichtlich des Supportzeitraums: Ist der vorgeschriebene Supportzeitraum für Sicherheitsupdates – mindestens fünf Jahre oder die erwartete Lebensdauer des Produkts, falls diese kürzer ist – dokumentiert und den Benutzern mitgeteilt worden?
LEITEN SIE DIES AN DIE GESCHÄFTSFÜHRUNG WEITER
Die CRA macht Cybersicherheit zu einer Voraussetzung für den Marktzugang für software , genau wie für hardware: Ohne CE-Kennzeichnung kein Zugang zum EU-Markt, dazu Geldstrafen von bis zu 15 Millionen Euro oder 2,5 % unseres weltweiten Gesamtumsatzes. Jedes vernetzte Produkt unter software , das wir ausliefern, benötigt eine echte Service-Identität, signierte Updates und standardmäßig aktivierte Verschlüsselung, gestützt durch Unterlagen, die belegen, dass wir das Risiko bewertet und das Produkt entsprechend konzipiert haben.
Wir haben bis Dezember 2027 Zeit, um die Vorschriften vollständig zu erfüllen, doch die Frist für die Meldung von Sicherheitslücken beginnt bereits im September 2026 – und diese Zeit vergeht schnell, wenn man die Nachrüstung von Produkten berücksichtigt, die ursprünglich weder mit einer Signatur-Pipeline noch mit einer mandantenbezogenen Identität entwickelt wurden. Wenn wir für ein Produkt kein kryptografisches Inventar erstellen können, das auch seine Abhängigkeiten von „ open-source “ umfasst, können wir weder einer Aufsichtsbehörde noch uns selbst mitteilen, was tatsächlich gefährdet ist, wenn die nächste Sicherheitslücke auftritt.


