Digital Business & Future 23.03.2026

7 Min. Lesezeit

Der EU Cyber Resilience Act (CRA) ist seit Dezember 2024 in Kraft und betrifft jeden Hersteller, der Produkte mit digitalen Elementen auf den europäischen Markt bringt. Ab September 2026 greifen die ersten Meldepflichten, ab Dezember 2027 müssen alle Produkte die neuen Cybersicherheitsanforderungen erfüllen. Für den produzierenden Mittelstand bedeutet das: Jeder vernetzte Sensor, jede Maschinensteuerung und jede Software-Komponente fällt unter die Verordnung. Die Zeit zum Handeln wird knapp.

Das Wichtigste in Kürze

Was der CRA reguliert und wen er betrifft

Der Cyber Resilience Act ist die erste EU-Verordnung, die verbindliche Cybersicherheitsanforderungen für alle Produkte mit digitalen Elementen einführt. Der Geltungsbereich ist bewusst breit: Er umfasst vernetzte Hardware wie Router, Smart-Home-Geräte und industrielle IoT-Sensoren ebenso wie reine Software, darunter Apps, Betriebssysteme und Firewalls.

Für den produzierenden Mittelstand hat das weitreichende Konsequenzen. Jede Maschinensteuerung mit Netzwerkanbindung, jeder Sensor mit Firmware-Update-Funktion und jedes Embedded System in einer Produktionsanlage fällt unter die Verordnung.

Besonders relevant für den Mittelstand: Auch Importeure und Distributoren, die Produkte in der EU in Verkehr bringen, tragen eigene Pflichten. Wer ein chinesisches IoT-Modul importiert und unter eigenem Label verkauft, gilt als Hersteller und muss die volle CRA-Compliance nachweisen. Das betrifft zahlreiche Maschinenbauer und Systemintegratoren, die Komponenten aus Drittstaaten in eigene Lösungen einbauen.

Auch wer diese Produkte nicht selbst herstellt, sondern in eigene Lösungen integriert, trägt als Integrator Compliance-Pflichten.

Ausgenommen sind wenige Kategorien: Medizinprodukte (bereits durch MDR reguliert), Kraftfahrzeuge (UNECE-Regulierung), Luftfahrttechnik und bestimmte nationale Sicherheitsprodukte. Open-Source-Software ist nur dann betroffen, wenn sie kommerziell vertrieben wird.

„Der CRA stellt sicher, dass Hardware- und Softwareprodukte mit weniger Schwachstellen auf den Markt kommen und dass die Hersteller die Sicherheit über den gesamten Lebenszyklus eines Produkts ernst nehmen.“
– Europäische Kommission, Pressemitteilung zum CRA, September 2022

Die drei Fristen: Was wann gilt

Der CRA trat am 10. Dezember 2024 in Kraft und wird in drei Stufen wirksam. Die erste Frist kommt schneller als viele Unternehmen erwarten.

11. Juni 2026: Die Notifizierung von Konformitätsbewertungsstellen wird wirksam. Ab diesem Datum müssen die nationalen Behörden die Prüfstellen benannt haben, die Hochrisiko-Produkte (Kategorie I und II) bewerten dürfen.

11. September 2026: Die Meldepflichten für Schwachstellen und Sicherheitsvorfälle beginnen. Hersteller müssen aktiv ausgenutzte Schwachstellen innerhalb von 24 Stunden an die ENISA melden. Für schwere Sicherheitsvorfälle gilt eine Meldefrist von 72 Stunden. Diese Pflicht greift sechs Monate vor der vollständigen Anwendung und ist für viele Unternehmen die erste harte Deadline.

11. Dezember 2027: Vollständige Anwendung aller Anforderungen. Ab diesem Datum dürfen nur noch CRA-konforme Produkte mit CE-Kennzeichnung auf dem EU-Markt vertrieben werden. Produkte, die bereits vor diesem Datum auf dem Markt waren und nicht wesentlich verändert wurden, genießen Bestandsschutz.

Produktkategorien: Standard, Wichtig, Kritisch

Der CRA teilt Produkte in drei Risikoklassen ein, die bestimmen, wie die Konformitätsbewertung ablaufen muss. Die Einstufung hat direkte Auswirkungen auf Aufwand und Kosten.

Standardprodukte (ca. 90 Prozent aller Produkte): Dazu gehören einfache IoT-Sensoren, Smart-Home-Geräte ohne Sicherheitsfunktion, Consumer-Software und Bürogeräte. Hersteller können die Konformität durch eine Selbstbewertung nachweisen. Kein externer Prüfer nötig.

Wichtige Produkte (Kategorie I): Betriebssysteme, Firewalls, Router, VPN-Software, Netzwerkmanagement-Systeme. Hier ist entweder eine Bewertung nach harmonisierten Normen oder eine Drittpartei-Prüfung erforderlich.

Kritische Produkte (Kategorie II): Hardware-Sicherheitsmodule, Smart-Meter-Gateways, industrielle Steuerungssysteme und Public-Key-Infrastruktur. Hier ist eine Drittpartei-Konformitätsbewertung durch eine benannte Stelle zwingend vorgeschrieben.

Was Hersteller konkret umsetzen müssen

Die CRA-Anforderungen lassen sich in drei Bereiche gliedern: sichere Entwicklung, Schwachstellenmanagement und Dokumentation.

Security by Design: Produkte müssen von der Konzeption an nach dem Prinzip „Secure by Default“ entwickelt werden. Das bedeutet: minimale Angriffsfläche, verschlüsselte Kommunikation, keine hartcodierten Passwörter und sichere Update-Mechanismen. Hersteller müssen nachweisen, dass Sicherheit nicht nachträglich hinzugefügt, sondern von Anfang an integriert wurde.

Schwachstellenmanagement: Hersteller müssen über den gesamten Produktlebenszyklus hinweg, mindestens aber fünf Jahre nach Markteinführung, Sicherheitsupdates bereitstellen. Aktiv ausgenutzte Schwachstellen müssen innerhalb von 24 Stunden an die ENISA gemeldet werden. Das erfordert einen funktionierenden PSIRT-Prozess (Product Security Incident Response Team).

Technische Dokumentation: Für jedes Produkt muss eine umfassende Dokumentation vorliegen: Risikoanalyse, Beschreibung der Sicherheitsarchitektur, Testberichte, SBOM (Software Bill of Materials) und eine EU-Konformitätserklärung.

Ein Punkt wird dabei oft unterschätzt: Die Verpflichtung zur kostenlosen Bereitstellung von Sicherheitsupdates über mindestens fünf Jahre. Für Hersteller von Industriekomponenten mit Lebenszyklen von zehn bis zwanzig Jahren bedeutet das eine erhebliche Langzeitverpflichtung. Wer heute ein vernetztes Steuerungsmodul ausliefert, muss garantieren, dass es 2032 noch sicher gepatcht werden kann. Das erfordert eine nachhaltige Softwarearchitektur und funktionierende Update-Infrastruktur, die weit über den typischen Produktzyklus hinausgeht.

In der Praxis bedeutet das auch: Hersteller müssen ihre Lieferantenbeziehungen überdenken. Wenn eine Open-Source-Bibliothek, die in einem Produkt steckt, nicht mehr gepflegt wird, muss der Hersteller entweder selbst Patches entwickeln oder die Komponente ersetzen. Die SBOM wird hier zum Frühwarnsystem: Sie zeigt, welche Abhängigkeiten bestehen und wo Risiken schlummern.

Die SBOM ist besonders relevant, weil sie sämtliche Software-Komponenten einschließlich Open-Source-Bibliotheken auflisten muss.

SBOM: Warum die Software-Stückliste zum Gamechanger wird

Die Software Bill of Materials ist eines der zentralen neuen Instrumente des CRA. In der Praxis ist sie vergleichbar mit einer Zutatenliste auf einem Lebensmittel: Sie listet jede Software-Komponente auf, die in einem Produkt steckt. Für viele Mittelständler wird das zur Herausforderung, weil die Abhängigkeiten in modernen Software-Stacks komplex sind.

Ein typisches eingebettetes System in einer Maschinensteuerung enthält ein Echtzeitbetriebssystem, Kommunikationsbibliotheken, Kryptografie-Module und Dutzende weitere Komponenten, die oft als Open Source eingebunden sind. Jede dieser Komponenten kann Schwachstellen enthalten, die der Hersteller kennen und im Griff haben muss.

Die gute Nachricht: Es gibt etablierte Standards und Werkzeuge. CycloneDX und SPDX sind die beiden führenden SBOM-Formate. Build-Tools wie Syft oder Grype generieren SBOMs automatisch aus dem Code-Repository. Für Unternehmen, die bereits CI/CD-Pipelines nutzen, lässt sich die SBOM-Erstellung in den bestehenden Build-Prozess integrieren, ohne den Entwicklungsworkflow zu stören.

Für Unternehmen ohne eigene Softwareentwicklung, die Komponenten von Zulieferern beziehen, gilt: Fordern Sie von Ihren Lieferanten eine SBOM an. Der CRA verlagert die Verantwortung entlang der Lieferkette. Wer Komponenten ohne SBOM in eigene Produkte integriert, haftet selbst für unbekannte Schwachstellen.

Was der CRA für den Mittelstand konkret kostet

Die Compliance-Kosten hängen stark von der Produktkategorie und dem Reifegrad der bestehenden Sicherheitsprozesse ab. Für Standardprodukte mit Selbstbewertung rechnen Branchenexperten mit einmaligen Aufwänden von 20.000 bis 50.000 Euro pro Produktlinie, hauptsächlich für Dokumentation, Risikoanalyse und SBOM-Erstellung.

Für Produkte der Kategorie I und II, die eine externe Prüfung erfordern, steigen die Kosten auf 80.000 bis 200.000 Euro. Hinzu kommen laufende Kosten für das Schwachstellenmanagement: Ein dedizierter PSIRT-Prozess mit Monitoring, Patch-Entwicklung und ENISA-Meldungen erfordert mindestens eine halbe Vollzeitstelle, in der Praxis oft mehr.

Die Gegenrechnung: Die durchschnittlichen Kosten eines Cybersecurity-Vorfalls liegen laut BSI im Mittelstand bei 500.000 Euro. Ein einziger schwerwiegender Vorfall übersteigt die Compliance-Kosten für mehrere Jahre. Hinzu kommt der Marktzugangsvorteil: Wer CRA-konform ist, kann europaweit ohne Einschränkungen vertreiben, während nicht konforme Wettbewerber vom Markt ausgeschlossen werden.

CRA, NIS2 und AI Act: Die Regulierungs-Trias

Der CRA existiert nicht isoliert. Zusammen mit NIS2 (Netz- und Informationssicherheit) und dem AI Act bildet er eine Regulierungs-Trias, die europäische Unternehmen gleichzeitig treffen. Für den Mittelstand bedeutet das: Überlappungen erkennen und Synergien nutzen.

NIS2 verpflichtet Betreiber kritischer und wichtiger Infrastrukturen zu Risikomanagement und Vorfallmeldung. Der CRA verpflichtet Hersteller der Produkte, die diese Betreiber einsetzen. Wer also IoT-Sensoren für Energieversorger oder Steuerungssoftware für Wasserwerke herstellt, muss sowohl den CRA für seine Produkte als auch die NIS2-Anforderungen seiner Kunden berücksichtigen.

Die gute Nachricht: Viele Anforderungen überlappen sich. Wer bereits ein Informationssicherheits-Managementsystem nach ISO 27001 betreibt, hat einen Großteil der organisatorischen Anforderungen abgedeckt. Die SBOM-Anforderung des CRA ergänzt sich mit den Transparenzpflichten des AI Act für KI-Komponenten in Produkten.

Checkliste: Fünf Schritte zur CRA-Compliance

Der Dezember 2027 klingt weit weg, aber die Meldepflichten ab September 2026 sind in sechs Monaten fällig. Eine pragmatische Roadmap.

1. Produktinventar erstellen. Welche Produkte mit digitalen Elementen vertreibt das Unternehmen? Welche davon haben Netzwerkanbindung, Firmware oder Software-Komponenten? Die Bestandsaufnahme ist die Grundlage für die Risikoklassifizierung.

2. Risikoklasse bestimmen. Für jedes Produkt prüfen: Standard, Kategorie I oder Kategorie II? Die Einstufung bestimmt, ob eine Selbstbewertung ausreicht oder ein externer Prüfer benötigt wird.

3. PSIRT-Prozess aufbauen. Ab September 2026 müssen Schwachstellen innerhalb von 24 Stunden gemeldet werden. Dafür braucht es einen funktionierenden Incident-Response-Prozess mit klaren Verantwortlichkeiten, Kontaktdaten zur ENISA und einem dokumentierten Meldeverfahren.

4. SBOM erstellen. Für jedes Produkt eine Software Bill of Materials anlegen, die alle Software-Komponenten einschließlich Versionen und Lizenzen auflistet. Tools wie CycloneDX oder SPDX automatisieren diesen Prozess.

5. Secure Development Lifecycle implementieren. Security by Design muss in den Entwicklungsprozess integriert werden. Das umfasst Bedrohungsmodellierung, Code-Reviews, Penetrationstests und sichere Update-Mechanismen.

Praxisbeispiel: Ein Mittelständler auf dem Weg zur CRA-Compliance

Ein Sensorhersteller aus Schwaben mit 80 Mitarbeitern produziert Temperatur- und Feuchtigkeitssensoren für die Lebensmittelindustrie. Die Sensoren haben WLAN-Anbindung, senden Messdaten an eine Cloud-Plattform und empfangen Firmware-Updates over-the-air. Bisher gab es kein strukturiertes Schwachstellenmanagement und keine SBOM.

Schritt eins: Produktinventar. Das Unternehmen identifiziert drei Produktlinien mit digitalen Elementen, alle mit Standardrisiko (Selbstbewertung möglich). Schritt zwei: SBOM-Erstellung. Ein externer Dienstleister analysiert den Firmware-Code und erstellt eine CycloneDX-SBOM. Ergebnis: 47 Software-Komponenten, davon 12 Open-Source-Bibliotheken, von denen drei seit über einem Jahr nicht mehr gepflegt werden. Diese drei müssen ersetzt oder selbst gepatcht werden.

Schritt drei: PSIRT aufbauen. Der Leiter der Softwareentwicklung übernimmt die Rolle des Security-Verantwortlichen. Ein einfacher Prozess wird definiert: Schwachstellen-Monitoring über die National Vulnerability Database (NVD), Bewertung innerhalb von 48 Stunden, Meldung an ENISA innerhalb von 24 Stunden bei aktiver Ausnutzung. Schritt vier: Dokumentation. Risikoanalyse, Sicherheitsarchitektur und Testberichte werden erstellt. Gesamtaufwand: rund 35.000 Euro und drei Monate Projektlaufzeit.

Fazit

Der Cyber Resilience Act wird die Produktentwicklung in Europa nachhaltig verändern. Für den produzierenden Mittelstand ist er keine optionale Empfehlung, sondern eine verbindliche Marktzugangsvoraussetzung. Wer vernetzte Produkte in der EU verkaufen will, muss ab Dezember 2027 CRA-konform sein.

Die erste harte Deadline ist aber nicht der Dezember 2027, sondern der September 2026: Ab dann müssen Schwachstellen gemeldet werden. Sechs Monate sind nicht viel Zeit, um einen PSIRT-Prozess aufzubauen, wenn noch keiner existiert. Wer jetzt startet, schafft es. Wer abwartet, wird unter Zeitdruck nacharbeiten müssen. Die Investition in CRA-Compliance ist keine reine Kostenstelle. Sie ist eine Investition in Produktqualität, Kundensicherheit und langfristigen Marktzugang in einem Europa, das Cybersicherheit zur Grundvoraussetzung macht.

Häufige Fragen

Bin ich als Software-Entwickler vom CRA betroffen?

Ja, wenn Ihre Software kommerziell vertrieben wird. Der CRA gilt für alle Produkte mit digitalen Elementen, einschließlich reiner Software. Ausgenommen ist nur nicht-kommerzielle Open-Source-Software.

Was ist eine SBOM?

Eine Software Bill of Materials ist eine vollständige Liste aller Software-Komponenten in einem Produkt, einschließlich Open-Source-Bibliotheken, Versionen und Lizenzen. Der CRA verlangt eine SBOM als Teil der technischen Dokumentation.

Wie lange muss ich Sicherheitsupdates bereitstellen?

Mindestens fünf Jahre nach Markteinführung oder über die erwartete Produktlebensdauer, je nachdem welcher Zeitraum kürzer ist. Updates müssen kostenlos und zeitnah bereitgestellt werden.

Brauche ich eine externe Prüfstelle?

Nur für Produkte der Kategorie II (kritisch), etwa Smart-Meter-Gateways oder industrielle Steuerungssysteme. Standardprodukte (ca. 90 Prozent) können durch Selbstbewertung des Herstellers nachgewiesen werden.

Was passiert bei einem Verstoß?

Bußgelder bis 15 Millionen Euro oder 2,5 Prozent des globalen Jahresumsatzes. Zusätzlich können Behörden den Marktzugang verweigern: Nicht konforme Produkte dürfen nicht mehr in der EU verkauft werden.

Wie unterscheidet sich der CRA von NIS2?

NIS2 reguliert Betreiber von Infrastrukturen und Diensten, der CRA reguliert Hersteller von Produkten. Wenn Ihr Unternehmen vernetzte Produkte herstellt, müssen Sie den CRA erfüllen. Wenn Sie diese Produkte einsetzen, greifen die NIS2-Pflichten.

Weiterführende Lektüre

AI Act ab August 2026: Hochrisiko-KI im Mittelstand

GlassWorm Supply-Chain-Angriff: 400+ Tools kompromittiert – SecurityToday

Container Supply Chain Security: Docker und SBOM – cloudmagazin

Quelle Titelbild: Anete Lusina / Pexels