Der Cyber Resilience Act erklärt.

Der CRA gilt für Produkte mit digitalen Elementen: Software oder Hardware, deren bestimmungsgemäße oder vernünftigerweise vorhersehbare Verwendung eine direkte oder indirekte Datenverbindung zu einem Gerät oder Netz einschließt (Art. 2 Abs. 1, Art. 3 Nr. 1). Auch die Datenverarbeitung auf Distanz ist erfasst, wenn der Hersteller sie für das Produkt entworfen hat und das Produkt ohne sie eine seiner Funktionen nicht erfüllen könnte (Art. 3 Nr. 2).

Das Produkt muss im Rahmen einer gewerblichen Tätigkeit auf dem EU-Markt bereitgestellt werden, entgeltlich oder unentgeltlich (Art. 3 Nr. 22). Es geht also nicht nur um den Verkauf.

Nach den Leitlinien der Kommission von 2026 ist Software, die aus der Ferne läuft und die Sie nur im Browser aufrufen, nicht allein deshalb ein Produkt. Websites sind ebenfalls keine Produkte. Cloud-Dienste, die außerhalb der Verantwortung eines Produktherstellers entworfen und entwickelt wurden, fallen nicht unter den CRA (Erwägungsgrund 12); für sie gilt die NIS-2-Richtlinie. Cloud-Funktionen, die ein Hersteller baut, damit sein eigenes Produkt funktioniert, sind erfasst. Software, die Sie herunterladen oder installieren, einschließlich Browser-Erweiterungen, ist ein Produkt.

Sektoren mit eigenen Regeln sind ausgenommen: Medizinprodukte und In-vitro-Diagnostika, Kraftfahrzeuge, die Zivilluftfahrt und Schiffsausrüstung (Art. 2 Abs. 2 bis 4). Ebenfalls ausgenommen sind Produkte, die ausschließlich für die nationale Sicherheit oder Verteidigung entwickelt wurden (Art. 2 Abs. 7). Produkte, die eine öffentliche Verwaltung ausschließlich für den eigenen Gebrauch entwickelt oder ändert, werden nicht auf dem Markt bereitgestellt (Erwägungsgrund 16).

• Erfasst: Software, die Sie auf eigenen Geräten installieren oder betreiben, vernetzte Hardware und Cloud-Funktionen, die ein Hersteller baut, damit sein eigenes Produkt funktioniert.
• Meist nicht erfasst: Webanwendungen, die Sie nur über einen Browser nutzen, und Websites, die die Funktionen eines Produkts nicht unterstützen.
• Nach Sektor ausgenommen: Medizinprodukte, In-vitro-Diagnostika, Kraftfahrzeuge, Zivilluftfahrt, Schiffsausrüstung.
• Produkte, die vor dem 11. Dezember 2027 in Verkehr gebracht wurden, fallen erst nach einer wesentlichen Änderung unter den CRA (Art. 69 Abs. 2). Die Meldepflicht nach Art. 14 gilt dagegen für alle Produkte im Anwendungsbereich (Art. 69 Abs. 3).

Die meisten Pflichten tragen die Hersteller (Art. 13). Sie müssen Produkte nach Anhang I entwerfen, eine Risikobewertung der Cybersicherheit durchführen und dokumentieren und diese während des Support-Zeitraums aktuell halten.

Importeure und Händler prüfen vor der Bereitstellung eines Produkts, ob CE-Kennzeichnung, EU-Konformitätserklärung und Benutzerinformationen vorliegen (Art. 19, Art. 20). Wer unter eigenem Namen oder eigener Marke liefert oder ein Produkt wesentlich ändert, gilt als Hersteller (Art. 21 und 22).

Standardmäßig bewertet der Hersteller die Konformität selbst (interne Fertigungskontrolle, Art. 32 Abs. 1). Für wichtige Produkte (Anhang III) und kritische Produkte (Anhang IV) gelten strengere Verfahren. Klasse I, zum Beispiel Betriebssysteme, Passwortmanager, VPN-Produkte und Router, darf nur dann selbst bewertet werden, wenn harmonisierte Normen, gemeinsame Spezifikationen oder eine Zertifizierung vollständig angewendet werden. Klasse II, zum Beispiel Hypervisoren, Firewalls und Systeme zur Angriffserkennung, sowie kritische Produkte erfordern eine Bewertung oder Zertifizierung durch Dritte (Art. 32 Abs. 2 bis 4).

Verstöße gegen Art. 13 oder Art. 14 können mit Geldbußen von bis zu 15 Mio. EUR oder 2,5 % des weltweiten Jahresumsatzes geahndet werden, je nachdem, welcher Betrag höher ist (Art. 64 Abs. 2). Die Mitgliedstaaten legen die Sanktionsregeln fest und setzen sie durch.

• Sicher entworfen und sicher voreingestellt (Anhang I Teil I): keine bekannten ausnutzbaren Schwachstellen bei der Bereitstellung, sichere Standardkonfiguration, Schutz vor unbefugtem Zugriff, Schutz der Daten und die Möglichkeit von Sicherheitsupdates.
• Umgang mit Schwachstellen (Anhang I Teil II): eine Strategie zur koordinierten Offenlegung von Schwachstellen, eine Kontaktadresse für Meldungen, Schwachstellen unverzüglich beheben, eine SBOM (Software-Stückliste), die mindestens die Abhängigkeiten der obersten Ebene abdeckt, und kostenlose Sicherheitsupdates, sofern bei maßgeschneiderten Produkten nichts anderes vereinbart wurde (Nr. 8).
• Support-Zeitraum (Art. 13 Abs. 8): orientiert sich an der erwarteten Nutzungsdauer und beträgt mindestens fünf Jahre, es sei denn, das Produkt wird voraussichtlich kürzer genutzt. Das Enddatum, mindestens Monat und Jahr, wird beim Kauf klar angegeben (Art. 13 Abs. 19). Jedes Sicherheitsupdate bleibt mindestens 10 Jahre verfügbar, oder für den Rest des Support-Zeitraums, falls dieser länger ist (Art. 13 Abs. 9).
• Konformität: Konformitätsbewertung, technische Dokumentation, EU-Konformitätserklärung, CE-Kennzeichnung (Art. 13, 28 und 30) und Benutzerinformationen nach Anhang II.
• Meldepflicht (Art. 14), seit dem 11. September 2026: eine Frühwarnung innerhalb von 24 Stunden nach Kenntnisnahme, eine Meldung innerhalb von 72 Stunden und ein Abschlussbericht spätestens 14 Tage nach Verfügbarkeit einer Korrektur- oder Abhilfemaßnahme (Schwachstellen) bzw. innerhalb eines Monats nach der Vorfallmeldung (schwerwiegende Vorfälle). Die Meldungen gehen über die zentrale Meldeplattform gleichzeitig an das als Koordinator benannte CSIRT und an die ENISA. Außerdem informiert der Hersteller die betroffenen Nutzer (Art. 14 Abs. 8).

Ab dem 11. Dezember 2027 gelten die Pflichten aus dem vorigen Abschnitt für Produkte im Anwendungsbereich, die dann in Verkehr kommen. Sie gelten in der Regel nicht für SaaS, die Sie nur im Browser nutzen, und nicht für früher in Verkehr gebrachte Produkte, sofern diese nicht wesentlich geändert werden. Verwenden Sie die folgenden Punkte in Ausschreibungen, Fragebögen und Verträgen.

Die Meldepflicht gilt bereits seit dem 11. September 2026. Sie dürfen schon jetzt erwarten, dass Anbieter aktiv ausgenutzte Schwachstellen und schwerwiegende Vorfälle innerhalb der Fristen von Art. 14 melden, auch bei früher in Verkehr gebrachten Produkten. Der CRA hindert Sie nicht daran, in Ihrer eigenen Beschaffung zusätzliche Anforderungen an die Cybersicherheit zu stellen (Art. 5 Abs. 1, Erwägungsgrund 13).

• CE-Kennzeichnung: Trägt das Produkt sie, und wo? Bei Software steht sie auf der EU-Konformitätserklärung oder auf der Website, die zur Software gehört (Art. 30 Abs. 1).
• EU-Konformitätserklärung: Wo können Sie sie einsehen? Eine vereinfachte Erklärung muss die genaue Internetadresse der vollständigen Erklärung enthalten (Art. 13 Abs. 20).
• Support-Zeitraum: Wie lautet das Enddatum, mindestens Monat und Jahr, für die Version, die Sie kaufen? Es muss beim Kauf klar angegeben sein (Art. 13 Abs. 19). Das Minimum sind fünf Jahre, es sei denn, das Produkt wird voraussichtlich kürzer genutzt (Art. 13 Abs. 8).
• Sicherheitsupdates: Sind sie während des Support-Zeitraums kostenlos (sofern bei maßgeschneiderten Produkten nichts anderes vereinbart wurde), und wie werden sie bereitgestellt? (Anhang I Teil II, Nr. 7 und 8).
• Kontakt für Schwachstellen: Wer ist die zentrale Kontaktstelle, und wo steht die Strategie zur koordinierten Offenlegung von Schwachstellen? (Art. 13 Abs. 17, Anhang II).
• SBOM: Der Anbieter muss eine führen, die mindestens die Abhängigkeiten der obersten Ebene abdeckt, und übergibt sie auf begründete Anfrage an Behörden. Die Weitergabe an Kunden ist freiwillig (Anhang II Nr. 9). Fragen Sie deshalb ausdrücklich danach oder vereinbaren Sie es im Vertrag.
• Vorfälle: Informiert der Anbieter Sie über aktiv ausgenutzte Schwachstellen und schwerwiegende Vorfälle, und in welcher Form? (Art. 14 Abs. 8).
• Konformitätsverfahren: Welches Bewertungsverfahren wurde bei Produkten aus Anhang III oder IV angewendet? (Art. 32).

Freie und quelloffene Software ist nur erfasst, wenn sie im Rahmen einer gewerblichen Tätigkeit bereitgestellt wird. Software, mit der ihre Urheber kein Geld verdienen, ist es nicht (Erwägungsgrund 18). Finanzielle Unterstützung durch Hersteller oder regelmäßige Veröffentlichungen machen Software für sich genommen nicht gewerblich. Code lediglich in einem offenen Repository oder Paketmanager zu hosten, ist keine Bereitstellung auf dem Markt (Erwägungsgrund 20).

Gewerbliche Tätigkeit ist mehr als ein Preis. Erwägungsgrund 15 nennt: ein Entgelt für technischen Support, das über die Kostendeckung hinausgeht, die Absicht der Monetarisierung (etwa eine Plattform, über die andere Dienste monetarisiert werden), die Verarbeitung personenbezogener Daten als Nutzungsbedingung zu anderen Zwecken als Sicherheit, Kompatibilität oder Interoperabilität, und die Annahme von Spenden, die die Kosten übersteigen. Spenden ohne Gewinnabsicht sind keine gewerbliche Tätigkeit.

Ein Verwalter von Open-Source-Software (Open-Source-Software-Steward) ist eine juristische Person, die kein Hersteller ist und die systematisch und nachhaltig die Entwicklung von Open-Source-Produkten unterstützt, die für gewerbliche Tätigkeiten bestimmt sind (Art. 3 Nr. 14). Bestimmte Stiftungen und Einrichtungen, die Open Source im geschäftlichen Umfeld veröffentlichen, können Verwalter sein (Erwägungsgrund 19). Für Verwalter gilt eine leichtere Regelung (Art. 24).

Verwalter dürfen keine CE-Kennzeichnung anbringen (Erwägungsgrund 19) und unterliegen nicht den Geldbußen nach Art. 64 Abs. 3 bis 9 (Art. 64 Abs. 10 Buchst. b). Nach Angaben der ENISA gelten ihre Pflichten ab dem 11. Dezember 2027. Nach den Leitlinien der Kommission kann dieselbe Organisation für ein Projekt Verwalter und für ein anderes Hersteller sein. Hersteller, die Open-Source-Komponenten verwenden, müssen diese mit gebührender Sorgfalt prüfen (Art. 13 Abs. 5).

• Eine dokumentierte Cybersicherheitsstrategie, die sichere Entwicklung und wirksamen Umgang mit Schwachstellen fördert.
• Zusammenarbeit mit den Marktüberwachungsbehörden auf Verlangen.
• Meldung von Schwachstellen nach Art. 14, soweit der Verwalter an der Entwicklung beteiligt ist.

CRA und NIS-2 (Richtlinie (EU) 2022/2555) behandeln unterschiedliche Dinge. Der CRA stellt Anforderungen an Produkte und ihre Hersteller. NIS-2 betrifft die Dienste und das Risikomanagement wesentlicher und wichtiger Einrichtungen.

Der CRA stellt fest, dass das bestehende Unionsrecht zur Cybersicherheit, einschließlich NIS-2, verbindliche Sicherheitsanforderungen an Produkte mit digitalen Elementen nicht unmittelbar regelt (Erwägungsgrund 3). Er soll Anbietern digitaler Infrastruktur helfen, die Anforderungen an die Lieferkette nach NIS-2 zu erfüllen, indem die von ihnen genutzten Produkte sicher entwickelt werden und rechtzeitig Sicherheitsupdates erhalten (Erwägungsgrund 24). Lieferkettenmaßnahmen nach NIS-2 können strengere Anforderungen an Produkte stellen als der CRA (Erwägungsgrund 13).

Beide treffen sich bei den Meldungen: Der CRA nutzt die aus NIS-2 bekannten, als Koordinatoren benannten CSIRTs als Empfänger von Meldungen (Art. 14). Ob Ihre eigene Organisation unter NIS-2 fällt, ist eine eigene Frage, die diese Seite nicht beantwortet.

Derzeit dient diese Seite nur der Information. Der CRA ändert nichts an der Souveränitätsbewertung oder den Empfehlungen.

Als Pilot zeigen die Anbieter in der Kategorie CMS jetzt die CRA-Signale, die wir öffentlich gefunden haben, als Information neben den vorhandenen Daten und ohne Einfluss auf die Bewertung: eine security.txt, eine Seite zum Melden von Schwachstellen, eine Richtlinie zu unterstützten Versionen und bei Open Source die Organisation hinter dem Projekt. Jeder Link wurde auf der Website des Anbieters oder Projekts selbst geprüft. Ab dem 11. Dezember 2027 zeigen wir auch die EU-Konformitätserklärung (CE-Kennzeichnung), sobald ein Produkt eine hat.

Ein CRA-Signal sagt nichts darüber aus, wo ein Anbieter seinen Sitz hat oder wem er gehört. Digitale Souveränität und Produktsicherheit sind getrennte Fragen.