Cyber Resilience Act: Cybersicherheitspflichten für alle Produkte mit digitalen Elementen

Der Cyber Resilience Act (EU-Verordnung 2024/2847) führt verbindliche Cybersicherheitsanforderungen für alle Produkte mit digitalen Elementen ein, die in der EU auf den Markt gebracht werden. Software wird wie ein physisches Produkt behandelt: mit CE-Kennzeichnung, grundsätzlich mindestens fünf Jahren Sicherheits-Support und 24-Stunden-Frühwarnungen bei aktiv ausgenutzten Schwachstellen oder schwerwiegenden Sicherheitsvorfällen.

Die Verordnung ist am 10. Dezember 2024 in Kraft getreten. Die Meldepflichten gelten ab dem 11. September 2026. Die vollständige Geltung aller Bestimmungen beginnt am 11. Dezember 2027. Für Bestandsprodukte, die vor diesem Datum in Verkehr gebracht wurden, gelten die Meldepflichten ebenfalls ab dem 11. September 2026 (Art. 69 Abs. 3).

Wer ist betroffen? #

Hersteller von Produkten mit digitalen Elementen #

Das umfasst nahezu alle Software und vernetzten Geräte, die in der EU auf den Markt gebracht werden:

Desktop-Software, Server-Software, produktzugehörige Cloud-Anwendungen
Mobile Apps, etwa aus einem App-Store
Plugins und Erweiterungen
Spiele
Betriebssysteme
Vernetzte Geräte (IoT) - sowohl IT als auch OT
Firmware und Embedded Software

Entscheidend ist: Wenn Ihr Produkt digitale Elemente enthält und auf dem EU-Markt bereitgestellt wird, fallen Sie unter den CRA - unabhängig davon, ob Ihr Unternehmen in der EU sitzt.

Als Hersteller sind Sie verantwortlich, wenn Sie das Produkt unter Ihrem eigenen Namen oder Ihrer Marke vermarkten. Bei Auftragsentwicklung kann das Ihr Kunde sein; klären Sie deshalb, wer welche Sicherheitsaufgaben übernimmt.

Eine einfache Faustregel: Wenn sich das Gerät mit irgendeinem Netzwerk verbinden kann - ob WLAN, Bluetooth, Mobilfunk, Ethernet oder ein anderes Protokoll - fällt es grundsätzlich unter den CRA. Ausgenommen sind Bereiche, die bereits eigene Regelwerke haben, etwa regulierte Medizinprodukte. Und reine Cloud-Dienste ohne Bezug zu einem erfassten Produkt fallen nicht schon deshalb darunter, weil sie über ein Netz erreichbar sind - gehört der Dienst dagegen zu Ihrem Produkt, wird er mit erfasst.

Open-Source-Software #

Freie und quelloffene Software fällt nur dann in den Anwendungsbereich, wenn sie im Rahmen einer geschäftlichen Tätigkeit auf den Markt gebracht wird. Reine Entwicklung und Bereitstellung in öffentlichen Repositories reicht nicht aus (EWG 20). Individuelle Contributor außerhalb geschäftlicher Tätigkeit sind nicht betroffen (EWG 18). Wird Open-Source-Software jedoch als Teil eines kommerziellen Produkts integriert, trägt der Hersteller die volle Verantwortung (Art. 13 Abs. 5).

Open Source Steward - die neue CRA-Kategorie #

Der CRA führt eine völlig neue Rechtskategorie ein: den "Verwalter quelloffener Software" (Art. 3 Nr. 14). Ein Open Source Steward ist eine juristische Person, die kein Hersteller ist, aber systematisch und nachhaltig die Entwicklung von FOSS-Produkten unterstützt, die für kommerzielle Tätigkeiten bestimmt sind.

OTTRIA übernimmt diese Rolle für Projekte, die das wünschen - aufdrängen lässt sie sich nicht. Das ist keine Bequemlichkeit, sondern eine bewusste Verpflichtung. Denn als Steward hat OTTRIA in der Praxis mehr Pflichten als ein Nicht-Steward, der Open-Source-Komponenten lediglich nutzt:

Aktive Cybersicherheitsstrategie: OTTRIA muss eine dokumentierte Cybersicherheitsstrategie entwickeln und überprüfbar dokumentieren - nicht nur für das eigene Unternehmen, sondern für jedes betreute Projekt (Art. 24 Abs. 1)
Schwachstellenmanagement als Pflicht: Dokumentation, Behebung und Beseitigung von Schwachstellen müssen aktiv gefördert werden. OTTRIA verpflichtet sich, nicht nur zu melden, sondern Fixes zu koordinieren und selbst zu erstellen (Art. 24 Abs. 1)
Zusammenarbeit mit Behörden: Auf Verlangen der Marktaufsichtsbehörden muss OTTRIA alle Unterlagen übermitteln und bei der Risikominderung mitwirken (Art. 24 Abs. 2)
Meldepflichten: Aktiv ausgenutzte Schwachstellen melden, soweit OTTRIA an der Entwicklung beteiligt ist. Schwerwiegende Sicherheitsvorfälle melden, wenn sie von OTTRIA bereitgestellte Entwicklungssysteme beeinträchtigen (Art. 24 Abs. 3)
Frühzeitiger Zugang zu Sicherheitsmeldungen, wo betreute Projekte OTTRIA in ihre vertraulichen Meldeprozesse einbinden - damit kennen wir Schwachstellen, bevor sie öffentlich werden
Keine Bußgelder: Der CRA sieht keine finanziellen Sanktionen für Stewards vor (Art. 64 Abs. 10b). Das ändert aber nichts an der Ernsthaftigkeit der Pflichten - Behörden können jederzeit Korrekturmaßnahmen verlangen

Die Steward-Pflichten nach Art. 24 gelten ab dem 11. Dezember 2027.

Für Sie als Hersteller bedeutet das: Wenn Sie Open-Source-Komponenten integrieren, die von einem Steward betreut werden, erleichtert das Ihre Sorgfaltspflicht gemäß Art. 13 Abs. 5. Die freiwillige Sicherheitsbescheinigung nach Art. 25 kann diesen Nachweis weiter vereinfachen.

Was fordert der CRA? #

CE-Kennzeichnung für Software (Art. 29, 30) #

Jedes Produkt mit digitalen Elementen braucht künftig eine CE-Kennzeichnung. Bei Software wird diese auf der Konformitätserklärung oder der Website angebracht. Die CE-Kennzeichnung bestätigt, dass alle grundlegenden Cybersicherheitsanforderungen aus Anhang I erfüllt sind.

Freiheit von bekannten ausnutzbaren Schwachstellen (Anhang I Teil I Nr. 2a) #

Produkte müssen ohne bekannte ausnutzbare Schwachstellen auf den Markt gebracht werden. Für FOSS-Komponenten verlangt Art. 13 Abs. 5 die gebotene Sorgfalt. EWG 34 nennt dafür konkrete Prüfungen: Abgleich mit öffentlichen Schwachstellendatenbanken, Blick auf die Update-Historie des Projekts und eigene Sicherheitstests. Wie tief Sie prüfen, richtet sich nach dem Risiko der Komponente - dass Sie prüfen und das belegen können, steht nicht zur Wahl.

SBOM-Pflicht (Anhang I Teil II Nr. 1, Art. 13 Abs. 24) #

Hersteller müssen Schwachstellen und Komponenten ihrer Produkte ermitteln und dokumentieren - unter anderem durch eine SBOM in einem gängigen maschinenlesbaren Format, aus der zumindest die obersten Abhängigkeiten hervorgehen. Format und Elemente kann die Kommission später verbindlich festlegen (Art. 13 Abs. 24). Für Ihre Risikosteuerung reicht der gesetzliche Mindestumfang allerdings nicht: Die Schwachstellen sitzen überwiegend in den transitiven Abhängigkeiten.

Fünf Jahre Security-Support (Art. 13 Abs. 8) #

Hersteller müssen grundsätzlich für mindestens fünf Jahre Sicherheitsupdates bereitstellen. Bei längerer erwarteter Nutzungsdauer entsprechend länger; bei kürzerer erwarteter Nutzungsdauer für diese kürzere Dauer. Sicherheitsaktualisierungen müssen unverzüglich und grundsätzlich kostenlos bereitgestellt werden (Anhang I Teil II Nr. 8) und, soweit technisch machbar, getrennt von Funktionsupdates angeboten werden (Anhang I Teil II Nr. 2).

Nur bei maßgeschneiderten Produkten dürfen Hersteller und gewerbliche Nutzer von der Kostenfreiheit abweichen. Wenn Sie Individualsoftware einkaufen, gehört dieser Punkt in den Vertrag - sonst zahlen Sie später für Sicherheitsupdates, die Sie ohnehin brauchen.

Schwachstellenmanagement #

Schwachstellen unverzüglich behandeln und beheben (Anhang I Teil II Nr. 2)
Koordinierte Offenlegung von Schwachstellen (CVD-Policy) aufstellen und umsetzen (Anhang I Teil II Nr. 5)
Kontaktadresse für Schwachstellenmeldungen angeben (Anhang I Teil II Nr. 6)
Sichere Verbreitung von Updates gewährleisten (Anhang I Teil II Nr. 7)
Sicherheit regelmäßig und wirksam testen und überprüfen (Anhang I Teil II Nr. 3)

Meldepflichten (Art. 14) #

Frist	Pflicht
24 Stunden	Frühwarnung bei aktiv ausgenutzten Schwachstellen oder schwerwiegenden Vorfällen (Art. 14 Abs. 2)
72 Stunden	Meldung mit Bewertung (Art. 14 Abs. 2)
14 Tage	Ausgenutzte Schwachstelle: Abschlussbericht nach Verfügbarkeit einer Korrektur- oder Minderungsmaßnahme (Art. 14 Abs. 2)
1 Monat	Schwerwiegender Vorfall: Abschlussbericht nach der Vorfallsmeldung (Art. 14 Abs. 4)
Unverzüglich	Nutzer über die Schwachstelle und Abhilfemaßnahmen informieren (Art. 14 Abs. 8)

Diese Fristen gelten auch am Wochenende und an Feiertagen. Die Meldepflichten gelten bereits ab dem 11. September 2026 -auch für Bestandsprodukte.

Die 24- und 72-Stunden-Fristen laufen ab Kenntnisnahme. Bei noch laufenden schwerwiegenden Vorfällen ist zunächst ein Fortschrittsbericht nötig; der Abschlussbericht folgt binnen eines Monats nach der Bewältigung.

Sorgfaltspflicht bei FOSS-Integration (Art. 13 Abs. 5-6) #

Wenn Sie Open-Source-Komponenten in Ihr Produkt integrieren, müssen Sie die gebotene Sorgfalt walten lassen -auch bei Komponenten, die nicht auf dem Markt bereitgestellt wurden. Mögliche Sorgfaltsmaßnahmen laut EWG 34: CE-Kennzeichnung prüfen, Sicherheitsupdates vorhanden?, frei von bekannten Schwachstellen (EU-Datenbank)?, zusätzliche Sicherheitsprüfungen. Wenn Sie Schwachstellen in quelloffenen Komponenten entdecken, müssen Sie die verantwortliche Person oder Einrichtung informieren und den Sicherheits-Patch teilen (Art. 13 Abs. 6).

Konsequenzen bei Verstößen #

Bußgelder #

Stufe	Höhe	Rechtsgrundlage
Höchste Stufe	15 Mio. Euro oder 2,5 % weltweiter Jahresumsatz	Art. 64 Abs. 2 - Verstöße gegen grundlegende Cybersicherheitsanforderungen (Anhang I) und Herstellerpflichten (Art. 13, 14)
Mittlere Stufe	10 Mio. Euro oder 2 % Jahresumsatz	Art. 64 Abs. 3 - Pflichten für Bevollmächtigte, Einführer, Händler
Niedrigste Stufe	5 Mio. Euro oder 1 % Jahresumsatz	Art. 64 Abs. 4 - Falsche oder unvollständige Angaben
Open Source Steward	Keine Bußgelder	Art. 64 Abs. 10b - Explizite gesetzliche Ausnahme

EU-Marktverlust und Rückruf #

Die Marktaufsichtsbehörden können Marktentnahme und Rückruf anordnen (Art. 54, 56). Die Europäische Kommission kann einen EU-weiten Rückruf anordnen (Art. 56) -mit unmittelbarer Wirkung für den gesamten Binnenmarkt. Das ist per se öffentlich sichtbar.

Verbandsklagen #

Ab dem 11. Dezember 2027 sind Verbandsklagen nach der EU-Richtlinie 2020/1828 anwendbar (Art. 65 CRA). Verbraucherschutzorganisationen können kollektiv gegen Hersteller klagen.

Was OTTRIA übernimmt #

CRA-Pflicht	OTTRIA-Leistung
SBOM erstellen und pflegen (Anhang I Teil II Nr. 1)	SBOM-Auswertung und laufende Überwachung Ihrer SBOM im maschinenlesbaren Format
Schwachstellen behandeln und beheben (Anhang I Teil II Nr. 2)	Upstream-Fixes koordinieren oder selbst erstellen
Sicherheit testen und überprüfen (Anhang I Teil II Nr. 3)	Code-Reviews, Security-Tests, Regressionstests für OSS-Komponenten
CVD-Policy (Anhang I Teil II Nr. 5)	Disclosure-Management als Teil der Steward-Rolle
Sichere Update-Verbreitung (Anhang I Teil II Nr. 7)	Patch-Koordination und Backports
Sorgfaltspflicht bei FOSS (Art. 13 Abs. 5)	Dokumentierte Bewertung aller OSS-Abhängigkeiten gegen EU-Schwachstellendatenbank
Meldungen an Behörden (Art. 14)	Zuarbeit zu Ihren Meldungen mit technischen Details und Bewertungen
Post-Market-Surveillance	Laufende Überwachung aller SBOM-Komponenten nach Release
Steward-Bescheinigung (Art. 25)	Nachweis systematischer OSS-Governance für Ihre Sorgfaltspflicht

Was OTTRIA nicht übernimmt #

CE-Konformitätserklärung: Die Konformitätserklärung ist Ihre Pflicht als Hersteller (Art. 28). OTTRIA liefert die Grundlagen für die OSS-Komponenten, aber Sie erklären die Konformität.
Ihre Risikobewertung: Die Gesamtrisikobewertung Ihres Produkts gemäß Art. 13 Abs. 2 obliegt Ihnen.
Nicht-OSS-Komponenten: OTTRIA deckt ausschließlich Open-Source-Abhängigkeiten ab.
Ihre Systeme: OTTRIA arbeitet nicht in Ihren Systemen, sondern in der Open-Source-Welt.
Lösungszeit-Garantien: Wir reagieren schnellstmöglich und dokumentieren jeden Schritt. Lösungszeiten lassen sich nicht vorhersagen.

Was legen Sie dem Prüfer vor? #

OTTRIA liefert Ihnen #

SBOM-Auswertung und Risikoanalyse gemäß Anhang I Teil II Nr. 1 und Art. 13 Abs. 24
Schwachstellendokumentation pro OSS-Komponente
Patch-Historie mit Maßnahmenprotokollen
Steward-Bescheinigung als Nachweis systematischer OSS-Governance
Dokumentation der Sorgfaltspflicht bei FOSS-Integration gemäß Art. 13 Abs. 5
Laufende Post-Market-Surveillance-Berichte

Sie ergänzen #

CE-Konformitätserklärung gemäß Art. 28
Ihre Gesamtrisikobewertung gemäß Art. 13 Abs. 2
Konformitätsbewertung (bei FOSS: vereinfacht möglich nach Art. 32 Abs. 5, Modul A, wenn technische Dokumentation öffentlich)
Ihre internen Meldeprozesse gemäß Art. 14

Übergangsfristen (Art. 71) #

Datum	Was gilt
10. Dezember 2024	Inkrafttreten der Verordnung
11. Juni 2026	Notifizierung von Konformitätsbewertungsstellen
11. September 2026	Meldepflichten gelten (Art. 14) -auch für Bestandsprodukte
11. Dezember 2027	Vollständige Geltung aller Bestimmungen

Handeln Sie jetzt: Die Hersteller-Meldepflichten gelten seit dem

September 2026. Sie erfordern Prozesse, die Sie nicht über Nacht aufbauen können.

Umsetzung in Deutschland #

Der CRA ist eine EU-Verordnung und gilt direkt in allen Mitgliedstaaten -ohne nationale Umsetzung. Allerdings müssen die Mitgliedstaaten nationale Marktaufsichtsbehörden benennen, die die Einhaltung überwachen. In Deutschland wird dies voraussichtlich das Bundesamt für Sicherheit in der Informationstechnik (BSI) übernehmen, möglicherweise in Zusammenarbeit mit der Bundesnetzagentur.

Da der CRA direkt gilt, gibt es keine nationalen Abweichungen bei den Anforderungen. Unterschiede zwischen EU-Ländern können sich aber bei der Aufsichtspraxis und der Durchsetzung ergeben.

Die Meldepflichten gelten ab September 2026. Sind Sie vorbereitet? Prüfen Sie jetzt Ihre CRA-Readiness.

CRA-Readiness prüfen

CRA-Factsheet herunterladen (PDF)