Cyber Resilience Act.

Der Cyber Resilience Act, kurz CRA oder Cyberresilienz-Verordnung, regelt die Cybersicherheit von Produkten. Die Verordnung (EU) 2024/2847 verbindet Anforderungen an den Entwurf mit Pflichten während des Produktlebenszyklus. Der Betrachtungsgegenstand ist das konkrete Produkt einschließlich relevanter Komponenten und zugehöriger Datenfernverarbeitung. Ein unternehmensweites Sicherheitsprogramm kann diese Arbeit unterstützen, beantwortet aber die produktspezifischen Fragen nicht allein.

Die CRA-Fristen gelten gestaffelt. Nach Art. 71 Abs. 2 CRA beginnen die allgemeinen Anforderungen am 11. Dezember 2027; Hersteller-Meldungen nach Art. 14 gelten bereits seit dem 11. September 2026. Kapitel IV über die Notifizierung von Konformitätsbewertungsstellen gilt seit dem 11. Juni 2026. Dieser institutionelle Termin ist kein vorgezogener allgemeiner CE-Stichtag für sämtliche Softwareprodukte.

Ältere Produkte sind nicht pauschal von Hersteller-Meldungen ausgenommen. Art. 69 Abs. 2 und 3 CRA unterscheidet die Übergangsregeln für die Produktkonformität von den Meldungen. Die Kommissionsleitlinien C(2026) 5252, Abschnitt 9.1, erläutern diese Trennung auch für vor Dezember 2027 in Verkehr gebrachte Produkte. Die Leitlinien sind eine nicht rechtsverbindliche Auslegungshilfe; maßgeblich bleibt die Verordnung.

Der CRA betrifft erfasste Hardware- und Softwareprodukte, die auf dem EU-Markt bereitgestellt werden und eine direkte oder indirekte Datenverbindung zu einem Gerät oder Netz vorsehen. Art. 2 und 3 CRA bestimmen Anwendungsbereich und Begriffe. Dazu können eigenständig angebotene Komponenten gehören. Prüfen Sie die tatsächliche Funktion und die gesetzlich vorgesehenen Ausnahmen, bevor Sie das gesamte Portfolio gleich einstufen.

Die Rolle des Unternehmens bestimmt seine Pflichten. Hersteller, Einführer und Händler haben unterschiedliche Aufgaben; die Herstellerrolle kann auch bei einer Vermarktung unter eigener Marke relevant sein. Für Open-Source-Software sind kommerzielle Bereitstellung, Beiträge einzelner Personen und die besondere Rolle des Open-Source-Stewards zu unterscheiden. Eine freie Lizenz befreit den Hersteller eines kommerziellen Produkts nicht pauschal von seiner Verantwortung.

Ein SaaS-Dienst fällt nicht allein wegen seiner Vertriebsbezeichnung unter den CRA oder aus ihm heraus. Entscheidend sind Produktgrenze und zugehörige Datenfernverarbeitung. Die Kommissionsleitlinien, Abschnitte 2 und 8, unterscheiden Softwareprodukte von entfernt bereitgestellten Dienstleistungen. Halten Sie die Begründung für die konkrete Architektur fest; ein allgemeiner Satz über sämtliche Cloudangebote wäre zu weit.

Der CRA-Nachweis ist eine produktbezogene Konformitätsbewertung. Die Kommission erläutert zu Art. 32 CRA, dass für die Standardkategorie eine interne Bewertung möglich ist. Für bestimmte wichtige oder kritische Produkte gelten strengere Verfahren mit einer notifizierten Stelle oder anderen jeweils zulässigen Nachweiswegen. Die tatsächliche Produktfunktion entscheidet über die Kategorie; ein werblicher Produktname genügt dafür nicht.

Die EU-Konformitätserklärung und CE-Kennzeichnung folgen dem anwendbaren Verfahren. Sie sind kein allgemeines Zertifikat für das gesamte Unternehmen und kein Versprechen, dass ein Produkt nie eine Schwachstelle haben wird. Eine einheitliche Zertifikatslaufzeit passt deshalb nicht als Beschreibung des CRA: Die Dokumentation, Schwachstellenbehandlung und jeweils geltenden Pflichten müssen über den maßgeblichen Lebenszyklus betrachtet werden.

ISO 27001 organisiert ein Informationssicherheitsmanagementsystem; ein entsprechendes Zertifikat bestätigt nicht allein die CRA-Konformität eines Produkts. NIS2 betrachtet betroffene Einrichtungen und ihre Sicherheitsorganisation. Die DSGVO schützt personenbezogene Daten, weshalb ein Produktereignis zusätzliche Datenschutzfragen auslösen kann. Verwandte Arbeitsabläufe lassen sich koordinieren, ihre rechtlichen Auslöser und Nachweise bleiben gesondert zu prüfen.

Secani enthält einen redaktionellen CRA-Arbeitskatalog mit Quellen, Prüffragen und Nachweisbeispielen. Das Unternehmensprofil erfasst unter anderem Rollen und Bewertungsdatum; ungeklärte Voraussetzungen bleiben als Prüfbedarf sichtbar. Die Arbeitshilfe unterstützt die Organisation der Prüfung, bestätigt aber weder die rechtliche Einstufung noch die Konformität eines Produkts.

Wählen Sie ein konkretes Produkt und klären Sie zunächst seine Grenze, die verantwortliche Rechtseinheit und die zuständigen Personen für Sicherheitsmeldungen. Prüfen Sie dann, welche heutigen und kommenden Pflichten dieses Produkt betreffen. Dieser Einstieg macht die Vorbereitung überschaubar und verhindert, dass ein allgemeines Compliance-Projekt die bereits erforderliche Meldebereitschaft verdeckt.