Cyber Resilience Act:
CE-Kennzeichnung für Software,
Fristen und Auswirkungen auf KMU

Was der Cyber Resilience Act ist

Der Cyber Resilience Act ist die EU-Verordnung 2024/2847, am 20. November 2024 im Amtsblatt der Europäischen Union veröffentlicht und am 10. Dezember 2024 formell in Kraft getreten. Erstmals führt die EU verbindliche Sicherheitsanforderungen für alle „Produkte mit digitalen Elementen“ (PDE) ein, die auf dem europäischen Markt in Verkehr gebracht werden: eigenständige Software, Betriebssysteme, Firmware, Consumer- und Industrie-IoT-Geräte, Netzwerk-Hardware, kryptografische Hardware, Sicherheitslösungen. Es ist das fehlende Stück im EU-Cyber-Regulierungspuzzle: Er ergänzt die NIS2-Richtlinie (Sicherheit der Erbringer wesentlicher Dienste) und den AI Act (künstliche Intelligenz) und schließt den Kreis auf der anderen Seite der Gleichung: die Sicherheit der Produkte, die diese Erbringer für ihre Dienstleistungen einsetzen.

Die Logik ist dieselbe, die im Laufe der Jahre die CE-Kennzeichnung auf Waschmaschinen, Spielzeug und Medizinprodukten geprägt hat: Wer ein Produkt auf dem EU-Markt in Verkehr bringt, muss in eigener Verantwortung nachweisen, dass es die in der Verordnung festgelegten wesentlichen Anforderungen erfüllt. Mit dem CRA umfasst die CE-Kennzeichnung erstmals auch die Cybersicherheit. Für Käufer wird die Kennzeichnung zur Voraussetzung für den Marktzugang — genau wie heute für ein Spielzeug oder ein Netzteil.

Die zwei kritischen Fristen, die in den Kalender gehören

Der CRA tritt nicht auf einen Schlag in Kraft: Die EU hat eine schrittweise Anwendung mit zwei operativen Etappen vorgesehen, die jetzt in den IT-Plan europäischer KMU gehören.

• 111. September 2026 — Schwachstellen-Meldung an ENISA in 24 Stunden. Hersteller von Produkten mit digitalen Elementen müssen aktiv ausgenutzte Schwachstellen ihres Produkts über eine europäische Single Reporting Platform innerhalb von 24 Stunden nach der Entdeckung oder der Bestätigung der Ausnutzung an ENISA melden. Die Logik ähnelt der NIS2-Vorfallsmeldung, ist aber auf den Produktlebenszyklus angewandt und wird zentral auf EU-Ebene verwaltet.
• 211. Dezember 2027 — vollständige Anwendung des CRA. Ab diesem Datum muss jedes Produkt mit digitalen Elementen, das auf dem EU-Markt in Verkehr gebracht wird, den Anforderungen der Verordnung entsprechen und die CE-Kennzeichnung tragen, die dies bestätigt. Keine CE-Kennzeichnung, kein Inverkehrbringen. Für Käufer bedeutet das: Ab diesem Datum muss jede neue Software und jedes vernetzte Gerät, das ins Unternehmen kommt, mit CRA-Dokumentation geliefert werden.

Zwischen den beiden Fristen liegt ein 15-monatiges Zeitfenster, in dem sich der Markt anpasst. In diesem Zeitfenster wird die Partie für europäische KMU entschieden: Die strukturierteren IT-Lieferanten richten ihre Produkte bereits aus, andere kommen spät oder gar nicht. Zu wissen, wo jeder Lieferant auf dieser Kurve steht, ist bereits eine konkrete Maßnahme im Vendor Risk Management.

Die drei Produktklassen des CRA

Nicht alle Produkte folgen demselben Konformitätspfad. Der CRA führt eine dreistufige Klassifizierung ein, mit strengeren Regeln, je größer das systemische Risiko ist:

• Standardklasse — die große Mehrheit der Produkte fällt hierher: Geschäftsanwendungen, Utilities, Produktivitätssoftware, nicht kritische Consumer-IoT-Geräte. Die Konformität wird vom Hersteller per Selbstbewertung (Self-Assessment) und Konformitätserklärung in eigener Verantwortung nachgewiesen.
• Klasse I — wichtige Produkte — eine Zwischenkategorie für Produkte, deren Fehlfunktion erhebliche Auswirkungen haben kann: Passwort-Manager, Antivirus, Consumer-VPN, Smart-Home-Geräte mit Sicherheitsfunktionen, IoT-Mikrocontroller. Die Konformitätsbewertung kann weiterhin per Selbstbewertung erfolgen, der Hersteller muss jedoch strengere Verfahren zur Dokumentation und Schwachstellenverwaltung einhalten.
• Klasse II — wichtige kritische Produkte — die anspruchsvollste Klasse, die eine Konformitätsbewertung durch eine notifizierte Stelle eines Drittanbieters erfordert. Dazu zählen unter anderem: Allzweck-Betriebssysteme, Hypervisoren, industrielle Firewalls und Netzwerk-Firewalls, Public Key Infrastructures (PKI), kryptografische Hardware, Smartcards. Es sind die Produkte, die das „Vertrauenssubstrat“ der digitalen Infrastruktur bilden: Für sie reicht die Selbstbewertung nicht aus.

Für Käufer ist das Wissen um die Klasse eines Produkts der erste Schritt, um seine Dokumentation zu lesen: Es zeigt, wie streng die Prüfung war und wie verlässlich die Konformitätserklärung einzuschätzen ist.

Die technischen Pflichten des CRA in fünf Punkten

Unter dem Etikett „CE-Kennzeichnung“ verlangt der CRA von den Herstellern fünf konkrete Dinge, die die Qualität der in Unternehmen eingehenden Software dauerhaft verändern:

• 1Security by Design und by Default — das Produkt muss so konzipiert sein, dass es in seinen Anfangskonfigurationen sicher ist. Keine geteilten Standardpasswörter mehr, keine unnötig offenen Ports, keine aktiven Dienste, die niemand braucht. Sicherheit ist keine optionale Funktion mehr.
• 2SBOM (Software Bill of Materials) — der Hersteller muss die strukturierte Liste aller Software-Komponenten des Produkts in einem standardisierten, interoperablen Format pflegen und bereitstellen. Die beiden Referenzformate sind SPDX (standardisiert als ISO/IEC 5962:2021) und CycloneDX (von OWASP). Der SBOM ermöglicht es, in Stunden — nicht in Wochen — die Frage zu beantworten: „Enthält dieses Produkt die Bibliothek X mit der neuen Schwachstelle Y?“.
• 3Sicherheitsunterstützung für mindestens 5 Jahre — der Hersteller muss Sicherheits-Patches und -Updates für mindestens 5 Jahre garantieren, oder für die erwartete Nutzungsdauer des Produkts, falls länger. Das Ende von End-of-Life-Software, die so verkauft wird, als wäre sie noch unterstützt. Für Käufer wird der vertragliche Unterstützungshorizont zu einer klaren und überprüfbaren Größe.
• 4Coordinated Vulnerability Disclosure — der Hersteller muss einen öffentlichen, dokumentierten Kanal haben, um Schwachstellen-Meldungen von Forschern und Kunden anzunehmen, strukturierte Prozesse zu deren Bearbeitung sowie definierte Zeiten für die Patch-Veröffentlichung. Transparenz über Schwachstellen wird zur Regel, nicht zur Ausnahme.
• 5Meldung aktiv ausgenutzter Schwachstellen an ENISA in 24 Stunden — wenn eine Schwachstelle des Produkts in realen Vorfällen aktiv ausgenutzt wird, hat der Hersteller 24 Stunden Zeit, sie an die von ENISA betriebene europäische Single Reporting Platform zu melden. Es ist dieselbe Stoppuhr wie bei der NIS2-Vorabbenachrichtigung, jedoch auf den Produktlebenszyklus angewandt.

Was europäische KMU tun sollten, die Software einkaufen

Für das durchschnittliche europäische KMU — Fertigung, Dienstleistung, strukturierte Kanzleien — fordert der CRA nicht, ein Software-Hersteller zu werden. Er fordert, eingekaufte Software anders zu verwalten. Vier konkrete Maßnahmen für die Roadmap der nächsten 18 Monate:

• 1Audit des im Einsatz befindlichen Software-Portfolios — ein aktuelles Inventar der digitalen Produkte im Unternehmen aufbauen, jeweils mit: Lieferant, Version, erwartete CRA-Klasse, geplantes Anpassungsdatum, aktuelles Ablaufdatum der Unterstützung. Das ist das „Grundbuch“ der Software, das in KMU heute oft fehlt. Ohne diesen Schritt sind die nächsten drei Maßnahmen nicht möglich.
• 2Vertragsklauseln in den Verlängerungen 2026-2027 — jeder neue Software-Vertrag oder jede Verlängerung muss vier Elemente enthalten: CRA-Konformitätserklärung mit der Produktklasse, Lieferung des SBOM im SPDX- oder CycloneDX-Format, ausdrückliche SLA für die Veröffentlichungszeiten von Sicherheits-Patches, garantierte Dauer der Sicherheitsunterstützung (≥ 5 Jahre), Verfahren zur Schwachstellen-Offenlegung gegenüber dem Lieferanten. KMU, die diese Klauseln frühzeitig fordern, finden einen Markt vor, der besser reagiert als erwartet.
• 3Erweitertes Vendor Risk Management — der CRA addiert sich zu NIS2 (Artikel 21, Sicherheit der ICT-Lieferkette) und zur Kontrolle A.5.21 von ISO/IEC 27001:2022 zur Verwaltung der Sicherheit in der Lieferkette. Für KMU, die bereits auf dem NIS2-Pfad unterwegs sind, fügt der CRA keinen zweiten parallelen Strang hinzu: Er reichert denselben Lieferantenbewertungsprozess mit präziseren Kriterien zu den eingekauften Produkten an. Für KMU außerhalb des NIS2-Geltungsbereichs ist es die Gelegenheit, einen ersten, einfachen strukturierten Prozess einzuführen.
• 4Einkaufsschulung — wer Software-Verträge verhandelt, muss SBOMs, CE-Kennzeichnung, Produktklassen und Unterstützungsklauseln erkennen können. Es ist eine kurze, aber wirkungsstarke Aufgabe: ein halber Tag gezielter Schulung für drei oder vier Personen, einmal, verhindert Jahre schlecht abgesicherter Einkäufe.

Wie AtWorkStudio den CRA-Weg unterstützt

AtWorkStudio begleitet europäische KMU auf dem Weg zur Einhaltung der EU-Cybersicherheitsverordnungen — NIS2, DORA, AI Act und nun CRA — mit einem operativen Ansatz. Wir starten mit einem Audit des Software-Portfolios des Kunden, gehen dann zur Lieferanten-Mapping und zur Überprüfung der Vertragsklauseln (in Abstimmung mit dem Rechtsteam des Unternehmens) über und begleiten die schrittweise Anpassung, während sich der Markt neu ausrichtet. Unsere Erfahrung mit der Umsetzung der Kontrolle A.5.21 von ISO/IEC 27001:2022 — Sicherheit der ICT-Lieferkette — ist die natürliche Grundlage für den CRA-Teil der Arbeit.

Wir sind seit 2000 von Piacenza, Italien aus tätig. Wir sind nach ISO/IEC 27001, 27017, 27018 und ISO 9001 zertifiziert, mit ACN-Qualifikation für SaaS-Cloud-Dienste (QC1-Qualifikation für Email Security Gateway und Microsoft 365 Backup), Mitglieder des Clusit (Italienischer Verband für Informationssicherheit) und assoziiert mit Confindustria Piacenza im RICT-Cluster. Für KMU, die die Investition prüfen, können Assessment- und Anpassungsmaßnahmen unter die förderfähigen Ausgaben des MIMIT Cloud- und Cybersecurity-Vouchers fallen.