Keyfactor Days 2027 – Nehmen Sie an der „Trust Security Conference“ in San Diego teil Jetzt anmelden!

Gesetz zur Cyber-Resilienz für IT & Software

Kryptografie und PKI für Produkte von „ Software “ mit digitalen Elementen

Aktualisiert: August 24, 2026
RegionWeltweit (gilt für jedes Produkt, das in der EU in Verkehr gebracht wird, unabhängig vom Standort des Herstellers oder Herausgebers)
AnwendbarkeitSoftware 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 AbschnitteAnhang 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:

AbschnittFunktionWas dort stehtUnterstützung für „ Keyfactor “-Produkte
Anhang I, Teil I, § 2 Buchstabe eVertraulichkeit von gespeicherten und übertragenen DatenVerschlü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 fIntegrität von Daten, Befehlen und KonfigurationSchü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 dStandardmäßige Sicherheitskonfiguration und IdentitätWird 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, § 7Mechanismus für sichere Updatessoftware -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 vorgesehenSichtbarkeit kryptografischer KomponentenIdentifizieren 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 mSichere DatenlöschungUnterstü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?