Macht der Cyber Resilience Act Penetrationstests zur Pflicht?

Nein — und trotzdem kommt kaum ein Hersteller ohne strukturierte Sicherheitstests aus. Warum beides gleichzeitig stimmt, und welche Frage wirklich zählt.

„Schreibt der Cyber Resilience Act jetzt Penetrationstests vor?“ — diese Frage bekommen wir seit Monaten. Die ehrliche Antwort ist: Nein. Und trotzdem führt für die meisten Hersteller kein Weg an strukturierten Sicherheitstests vorbei. Beides stimmt gleichzeitig — und genau in diesem scheinbaren Widerspruch liegt der Punkt, den viele Unternehmen 2026 noch unterschätzen.

Was der CRA tatsächlich verlangt

Vier Verankerungen im Verordnungstext sind hier entscheidend:

Zusammengenommen ergibt sich daraus keine namentliche Pentest-Pflicht, wohl aber eine klare Testverpflichtung mit Nachweischarakter. Art. 64 setzt dahinter ein spürbares Bußgeldregime: bis zu 15 Mio. € oder 2,5 % des weltweiten Jahresumsatzes.

„Faktische Pflicht“: warum der Nachweis ohne Tests kaum gelingt

Der CRA sagt nicht „Penetrationstest = Konformitätsnachweis“. Er verlangt geeignete Tests und deren Dokumentation — und welche Testtiefe sowie welche Methoden angemessen sind, ergibt sich risikobasiert aus Produkt, Architektur, Bedrohungslage, Produktklasse und den angewandten technischen Spezifikationen.

Für viele Produkte lässt sich ein belastbarer Nachweis ohne technische Sicherheitstests — einschließlich risikogerechter Penetrationstests — kaum überzeugend führen.

Das ist die faktische Pflicht: nicht wörtlich im Gesetz, aber praktisch unausweichlich, sobald man den geforderten Nachweis ernst nimmt. Ein Penetrationstest ist dabei ein wesentliches Nachweismittel — nicht das einzige und nicht das per Gesetz vorgeschriebene, aber eines der aussagekräftigsten.

Um die angemessene Testtiefe zu bestimmen, ist ein offensives Threat Modelling (offensive Bedrohungsanalyse) unverzichtbar. Dabei werden aus der Perspektive eines Angreifers produktspezifische Bedrohungsvektoren, Angriffspfade und potenzielle Schwachstellen systematisch identifiziert und bewertet. Anders als eine rein defensive Risikoanalyse fragt das offensive Threat Modelling nicht nur „Was könnte passieren?“, sondern „Wie würde ein Angreifer dieses Produkt konkret kompromittieren?“ – und liefert damit die Grundlage für einen risikobasierten, zielgerichteten Testansatz, der vor Marktüberwachungsbehörden und im Haftungsfall belastbar ist.

Fällt Ihr Produkt überhaupt unter den CRA?

Der CRA gilt für Produkte mit digitalen Elementen — Hardware und Software, die direkt oder indirekt mit einem Netzwerk verbunden werden können. Das ist bewusst breit gefasst. Wichtige Abgrenzungen:

Reine SaaS-/Cloud-Dienste fallen nicht automatisch unter den CRA — sie können unter NIS2 fallen. CRA-relevant werden sie, wenn sie als „remote data processing solution“ integraler Bestandteil eines Produkts sind (z. B. die Cloud-Anbindung eines Smart-Home-Geräts).

Open-Source-Software ist differenziert geregelt: Nicht-kommerzielle Entwicklung bleibt außen vor; „Open-Source-Steward“-Pflichten gelten für Stiftungen/Projekte mit kommerziellem Bezug.

Bereits regulierte Produkte (Medizinprodukte, Kfz, Luftfahrt) sind vom CRA ausgenommen, soweit sektorale Regeln gleichwertige Anforderungen stellen.

Auch beim Konformitätsverfahren gibt es Abstufungen: Die meisten Standardprodukte lassen sich über eine interne Selbstbewertung nachweisen. Für wichtige und kritische Produktklassen gelten strengere Verfahren — bis hin zur Drittstellenbewertung. In welche Kategorie ein Produkt fällt, entscheidet mit über die nötige Testtiefe.

CRA-Umsetzung: NSIDE ATTACK LOGIC & RSM EbnerStolz – gemeinsam von der Analyse bis zur Konformitätserklärung

Der CRA verlangt weit mehr als nur einen Sicherheitstest – er fordert einen vollständigen, dokumentierten Konformitätsprozess: von der Betroffenheitsanalyse über die Risikobewertung und technische Sicherheitsprüfung bis hin zur CE-Kennzeichnung. Genau hier setzt die Partnerschaft zwischen RSM EbnerStolz und NSIDE ATTACK LOGIC an.

RSM EbnerStolz – eine der führenden Wirtschaftsprüfungs- und Beratungsgesellschaften Deutschlands – leitet das gesamte CRA-Projekt methodisch: Betroffenheitsanalyse, regulatorische Einordnung (in Zusammenarbeit mit Rechtsberatern, soweit erforderlich), Anpassung von Prozessen und Dokumentationen, Aufbau der geforderten Melde- und Schwachstellenmanagementprozesse sowie die Begleitung der Konformitätsbewertung bis zur CE-Kennzeichnung. Eine kompakte Übersicht des EbnerStolz-CRA-Angebots finden Sie auf der EbnerStolz-Website.

NSIDE ATTACK LOGIC unterstützt in allen technischen Bereichen der CRA-Umsetzung: Durchführung der produktbezogenen Cybersicherheits-Risikoanalyse, Security-by-Design-Beratung, technische Sicherheitstests (risikobasierte Penetrationstests, Code-Reviews, Architekturanalysen), Erstellung der technischen Dokumentation (Testergebnisse, SBOM, Schwachstellenmanagement) sowie die offensive Bedrohungsanalyse (Threat Modelling) zur Identifikation produktspezifischer Angriffsvektoren.

Fristen und Sanktionen

Der Zeitplan ist enger, als viele annehmen:

Bei Bußgeldern gilt: bis zu 15 Mio. € oder 2,5 % des weltweiten Jahresumsatzes für Verstöße gegen Anhang-I-Anforderungen; für andere Pflichtverletzungen gelten niedrigere Staffeln (10 Mio. €/2 %; 5 Mio. €/1 %). Zusätzlich drohen Marktrücknahmen und Vertriebsverbote durch die Marktaufsicht.

Die richtige Frage ist nicht „Pentest — ja oder nein?“

Die Diskussion „Brauchen wir einen Pentest?“ führt in die Irre, weil sie eine Ja/Nein-Antwort suggeriert, die der CRA bewusst nicht gibt. Die eigentlich relevante — und für Hersteller deutlich schwerer selbst zu beantwortende — Frage lautet:

Welche Tests, in welcher Tiefe, braucht Ihr konkretes Produkt, um einen belastbaren CRA-Nachweis zu führen?

Das hängt von Architektur, Angriffsfläche, Produktklasse, eingesetzten Komponenten und Ihrem bestehenden Reifegrad ab. Wer DevSecOps und regelmäßige Sicherheitstests ohnehin lebt, hat den größten Teil der Strecke hinter sich. Wer bislang punktuell prüft, sollte den Prozess jetzt aufsetzen — eingebettet in Entwicklung und Qualitätssicherung, nicht als Nacharbeit kurz vor Markteinführung.

Häufig gestellte Fragen