Der Cyber Resilience Act (CRA) kennt keine Ausnahme — Sicherheit als Eintrittskarte in die Lieferkette

Seit Dezember 2024 gilt der Cyber Resilience Act, und anders als bei NIS2 gibt es keine Ausnahme für kleine Unternehmen. Wer Produkte mit digitalen Elementen herstellt, importiert oder verkauft, muss Sicherheit künftig nachweisen — mit Security-by-Design, einer Software-Stückliste und Meldefristen von 24 Stunden.

Ab dem 11. September 2026 greifen die Meldepflichten, ab dem 11. Dezember 2027 gilt der CRA vollständig, bei Bußgeldern bis zu 15 Millionen Euro . Damit wird Cybersicherheit zur Eintrittskarte in die Lieferkette — und die Frage, wo die hochsensiblen Sicherheitsunterlagen liegen, wird zur Souveränitätsfrage.

Die Regulierung, die kaum jemand auf dem Schirm hat — und die fast alle trifft

NIS2 und der EU AI Act beherrschen die Schlagzeilen. Der Cyber Resilience Act arbeitet leiser und greift dafür breiter: Er fragt nicht nach der Branche, sondern nach einer einzigen Eigenschaft des Produkts — kann es Daten austauschen? Sobald ein Produkt eine direkte oder indirekte Verbindung zu Geräten, Netzwerken, APIs oder Cloud-Diensten haben kann, fällt es unter den CRA.

Der entscheidende Unterschied zu NIS2: Es gibt keinerlei Größenausnahme. Das Fünf-Personen-Softwarehaus unterliegt denselben Grundpflichten wie der Konzern, und die Verantwortung ist persönlich, die Geschäftsführung haftet. In Deutschland überwacht das BSI den Markt und konkretisiert die Anforderungen.

Kriterium: „Produkt mit digitalen Elementen“

Der CRA erfasst vernetzte Hardware wie Router, Sensoren und Industriesteuerungen, klassische Softwareprodukte wie Betriebssysteme und Apps, einzeln vermarktete Komponenten wie Firmware und Module sowie Cloud-Funktionen, die für ein vernetztes Produkt erforderlich sind. In der Pflicht stehen Hersteller, Importeure, Händler und Private-Label-Anbieter.

Ein ehrlicher Abgrenzungshinweis: Reine SaaS-Dienste fallen zunächst unter NIS2. Sobald Software aber als Produkt auf dem EU-Markt bereitgestellt wird oder als Datenfernverarbeitung zu einem vernetzten Produkt gehört, wird sie CRA-relevant. Ausgenommen sind nur Bereiche mit eigenen Regelwerken wie Medizinprodukte, Kraftfahrzeuge oder Luftfahrt; nicht-kommerzielle Open-Source-Software ist privilegiert.

Was ab September 2026 konkret zu tun ist

Der CRA verlangt vier Dinge, die im Alltag echten Aufwand bedeuten:

• Security-by-Design: Sicherheit gehört von der ersten Architekturentscheidung an ins Produkt — bei Authentifizierung, Datenflusskontrolle und Mandantenfähigkeit.
• Software Bill of Materials (SBOM): eine vollständige Stückliste aus Eigenentwicklung, Open-Source-Bibliotheken, Cloud-Diensten und Drittkomponenten. Ohne diese Transparenz keine Compliance.
• Schwachstellenmanagement mit harten Meldefristen: Erstmeldung einer aktiv ausgenutzten Schwachstelle in 24 Stunden, Folgemeldung nach 72 Stunden, Abschlussbericht 14 Tage nach Verfügbarkeit einer Abhilfe.
• Konformität und CE-Kennzeichnung: für neue Produkte.

Die Zeitleiste ist eng: in Kraft seit dem 10.12.2024, Meldepflichten ab 11.09.2026, volle Anwendbarkeit für neue Produkte ab 11.12.2027. Bestandsprodukte sind von den vollen Anforderungen ausgenommen, die Meldepflichten gelten trotzdem. Der Preis für Nachlässigkeit: bis zu 15 Millionen Euro oder 2,5 Prozent des weltweiten Jahresumsatzes.

Der Haken: Compliance produziert genau die Daten, die geschützt werden müssen

Hier wird es für viele Unternehmen unangenehm. Alles, was der CRA verlangt, erzeugt hochsensible Artefakte: Quellcode, die vollständige SBOM der Lieferkette, detaillierte Schwachstellenberichte, Incident-Dokumentation. Genau diese Unterlagen sind die Landkarte der eigenen Angriffsfläche.

Wer diese Daten auf US-Hyperscalern ablegt und bearbeitet, löst ein Compliance-Problem und schafft zugleich ein neues: Souveränitäts- und CLOUD-Act-Risiko. Erschwerend kommt hinzu, dass die staatliche Unterstützung dünn ist — für die KMU-Hilfe zum CRA sind nur rund 1,28 Millionen Euro pro Jahr vorgesehen, während das EU-Programm SECURE 16,5 Millionen Euro für Risikoanalysen und Sicherheitsbewertungen bereitstellt. Wer wartet, verliert Zeit, die knapp ist.

Vom Kostenfaktor zur Eintrittskarte

Es gibt eine zweite Lesart, und die ist unternehmerisch die spannendere. CRA-Konformität wird zur Währung in der Lieferkette: Auftraggeber fordern nachweisbare Sicherheitsstandards, bevor sie einkaufen. Wer den Nachweis führt, wird zum bevorzugten Partner; wer ihn schuldig bleibt, verliert Aufträge.

Der CRA steht dabei nicht allein. Er greift ineinander mit NIS2, der DSGVO und dem EU AI Act — der gesamte Regulierungs-Stack zieht in dieselbe Richtung: nachweisbare, auditierbare und souveräne Infrastruktur. Wer diese Grundlage einmal sauber aufsetzt, erfüllt mehrere Anforderungen zugleich, statt für jede Regel ein eigenes Projekt zu starten.

Souveräne Infrastruktur als CRA-Fundament

Für Unternehmen in regulierten Branchen bietet sich eine souveräne, deutsche Infrastruktur als Grundlage an, auf der sich CRA-Pflichten erfüllen lassen, ohne neues Risiko zu erzeugen. SecureCloud liefert diese Ebene: souveräne Ablage und Zusammenarbeit für Quellcode, SBOMs und Schwachstellendokumentation, revisionssichere Prozesse für die knappen Meldefristen und mit SecureKI einen agentischen KI-Arbeitsplatz, der beim Erstellen und Pflegen von SBOMs, technischer Dokumentation und Meldeentwürfen unterstützt — vollständig auf europäischer Infrastruktur, ohne dass sensible Sicherheitsdaten das souveräne Fundament verlassen.