Cyber Resilience Act: Der Überblick für den Mittelstand

Der Cyber Resilience Act (CRA, Verordnung (EU) 2024/2847) verpflichtet Hersteller von Produkten mit digitalen Elementen – also Hardware und Software – zu Cybersicherheit über den gesamten Lebenszyklus. Er gilt seit dem 10. Dezember 2024, entfaltet seine Pflichten aber gestaffelt: Regeln für Konformitätsbewertungsstellen ab 11. Juni 2026, Meldepflichten ab 11. September 2026 und alle übrigen Pflichten ab 11. Dezember 2027.

Für den Mittelstand heißt das: Wer Software, Firmware oder vernetzte Geräte in der EU vertreibt, braucht in wenigen Monaten einen funktionierenden Meldeprozess und bis Ende 2027 eine belastbare technische Dokumentation samt CE-Kennzeichnung.

Was ist der Cyber Resilience Act?

Der CRA ist eine EU-Verordnung und gilt damit unmittelbar in allen Mitgliedstaaten. Er folgt der Logik des europäischen Produktrechts (New Legislative Framework): Wer ein Produkt in Verkehr bringt, muss nachweisen, dass es wesentliche Anforderungen erfüllt, und bestätigt das mit einer EU-Konformitätserklärung und dem CE-Kennzeichen.

Geltungsbereich: Produkte mit digitalen Elementen

Erfasst sind Produkte, deren bestimmungsgemäße Verwendung eine direkte oder indirekte Datenverbindung zu einem Gerät oder Netz einschließt. Das umfasst klassische Standardsoftware, Apps, Firmware, IoT-Geräte, Industriesteuerungen mit Netzwerkschnittstelle und Komponenten, die separat vertrieben werden. Auch Datenfernverarbeitungslösungen, ohne die ein Produkt eine seiner Funktionen nicht erfüllen kann, zählen zum Produkt.

Ausnahmen

• Produkte, die bereits sektorspezifisch geregelt sind, etwa Medizinprodukte, In-vitro-Diagnostika, Kraftfahrzeuge und bestimmte Luftfahrtausrüstung.
• Reine Software-as-a-Service ohne Bezug zu einem Produkt fällt grundsätzlich unter NIS2, nicht unter den CRA.
• Freie und quelloffene Software, die nicht im Rahmen einer Geschäftstätigkeit bereitgestellt wird.

Die drei Stichtage

Hersteller, Importeur, Händler

Die meisten Pflichten treffen den Hersteller – also denjenigen, der ein Produkt entwickelt oder entwickeln lässt und unter eigenem Namen oder eigener Marke vermarktet. Importeure müssen prüfen, dass der Hersteller außerhalb der EU seine Pflichten erfüllt hat. Händler prüfen CE-Kennzeichen und Unterlagen. Wer ein Produkt unter eigenem Namen vertreibt oder wesentlich verändert, wird selbst zum Hersteller.

Wesentliche Anforderungen nach Annex I

Annex I gliedert sich in zwei Teile: Anforderungen an die Produkteigenschaften und Anforderungen an das Schwachstellenmanagement.

• Teil I – Produkt: Auslieferung ohne bekannte ausnutzbare Schwachstellen, sichere Standardkonfiguration, Schutz vor unbefugtem Zugriff, Vertraulichkeit und Integrität von Daten, Datenminimierung, Angriffsflächen reduzieren, Sicherheitsupdates ermöglichen.
• Teil II – Schwachstellenbehandlung: Software-Stückliste (SBOM) führen, Schwachstellen unverzüglich beheben, regelmäßig testen, behobene Schwachstellen offenlegen, eine Richtlinie zur koordinierten Offenlegung (CVD) veröffentlichen, Updates sicher verteilen.

Dazu kommen Pflichten aus Art. 13: eine dokumentierte Cybersicherheits-Risikobewertung, ein Supportzeitraum von in der Regel mindestens fünf Jahren (kürzer nur, wenn die erwartete Nutzungsdauer kürzer ist) und die technische Dokumentation nach Annex VII.

Sanktionen

Art. 64 sieht drei Bußgeldstufen vor. Maßgeblich ist jeweils der höhere Betrag aus Festbetrag und Anteil am weltweiten Jahresumsatz.

Hinzu kommen marktbezogene Maßnahmen: Behörden können Rücknahmen oder Rückrufe anordnen. Für Kleinst- und Kleinunternehmen gibt es eine Erleichterung – bei verpasster 24-Stunden-Frist für die Frühwarnung wird kein Bußgeld verhängt.

Erste Schritte

1. Produktinventar anlegen: Welche Produkte und Versionen mit digitalen Elementen sind am Markt, und wer ist jeweils Hersteller?
2. Meldefähigkeit herstellen: Verantwortliche benennen, Eskalationswege definieren, Kontaktstelle für Schwachstellenmeldungen veröffentlichen.
3. SBOM aufbauen: Abhängigkeiten maschinenlesbar erfassen – das ist die Basis, um betroffene Produkte schnell zu identifizieren.
4. Produktkategorie prüfen: Standard, wichtig (Klasse I/II) oder kritisch? Davon hängt das Konformitätsbewertungsverfahren ab.
5. Dokumentation planen: Risikobewertung, Supportzeitraum und technische Dokumentation bis Ende 2027 aufbauen.

Praxisbeispiele aus dem Mittelstand

Maschinenbauer mit Fernwartung

Ein Hersteller von Verpackungsmaschinen liefert Anlagen mit einer Steuerung, einem HMI-Panel und einem Fernwartungsmodul aus. Die Maschine selbst ist über die Maschinenverordnung geregelt, die digitalen Elemente fallen zusätzlich unter den CRA. Der Hersteller braucht deshalb für Steuerungssoftware, Panel-Firmware und Fernwartungsclient eine Risikobewertung, eine SBOM und einen Update-Prozess – und ab September 2026 einen Meldeweg, falls etwa eine im Fernwartungsmodul enthaltene Bibliothek aktiv ausgenutzt wird.

Softwarehaus mit On-Premise-Produkt

Ein Softwarehaus vertreibt eine ERP-Erweiterung, die Kunden auf eigenen Servern installieren. Das ist ein klassisches Produkt mit digitalen Elementen. Relevant sind vor allem der Supportzeitraum – Kunden nutzen solche Systeme oft deutlich länger als fünf Jahre –, sichere Standardeinstellungen bei der Installation und ein Weg, Sicherheitsupdates getrennt von Funktionsupdates auszuliefern.

Agentur mit White-Label-App

Eine Digitalagentur baut für einen Händler eine App, die unter dessen Marke erscheint. Hersteller ist in der Regel der Händler; die Agentur liefert aber die Nachweise, von denen die Konformität abhängt. Wer diese Rollen früh vertraglich klärt, vermeidet Streit im Ernstfall.

CRA, NIS2 und Maschinenverordnung im Vergleich

Viele Unternehmen sind von mehreren Regelwerken gleichzeitig betroffen. Ein Maschinenbauer kann als Hersteller unter den CRA fallen und zugleich als Betreiber unter NIS2. Es lohnt sich, Nachweise so zu organisieren, dass sie für mehrere Regelwerke wiederverwendbar sind.

Wie Nuowei unterstützt

Nuowei ist eine CRA-Compliance-Plattform von hafencity.dev aus Hamburg, die sich derzeit in der Beta befindet. Sie verbindet sich mit Ihren Repositories, erzeugt SBOMs, gleicht Schwachstellen ab und sammelt Nachweise für Ihre technische Dokumentation. Der Launch ist für November 2026 geplant – über die Warteliste sichern Sie sich frühen Zugang.