CRA und Pentests: Was der Cyber Resilience Act an Sicherheitstests verlangt

Der Cyber Resilience Act (CRA), die Verordnung (EU) 2024/2847, ist seit Dezember 2024 in Kraft und gilt ab dem 11. Dezember 2027 vollständig; die Meldepflicht nach Artikel 14 greift am 11. September 2026. Dieser Beitrag behandelt die Pflicht mit dem größten operativen Aufwand: regelmäßige Sicherheitstests. Wer sie ernst nimmt, landet beim Pentest, und wer eine deutsche Umsetzungshilfe sucht, bei der BSI TR-03183.

Die Testpflicht in Anhang I des CRA

Anhang I der Verordnung (EU) 2024/2847 definiert in Teil I die Produktanforderungen (Secure by Design, sichere Standardkonfiguration, Zugriffsschutz) und in Teil II die Schwachstellenbehandlung über den Produktlebenszyklus. Dort steht die zentrale Vorgabe in Nummer 3: Hersteller müssen „die Sicherheit des Produkts mit digitalen Elementen regelmäßig und wirksam testen und überprüfen".

Eine Methode schreibt der CRA nicht vor. Er ist risikobasiert: Nach Artikel 13 Absatz 3 leitet sich die Testtiefe aus der Risikobewertung ab, die auf Zweckbestimmung und vernünftigerweise vorhersehbarer Verwendung des Produkts beruht. Minimalismus deckt das aber nicht: Anhang VII Nummer 6 verlangt in der technischen Dokumentation ausdrücklich Berichte über die Tests, mit denen die Konformität mit Anhang I geprüft wurde, und die Marktüberwachungsbehörde kann diese anfordern. Verstöße gegen Anhang I oder die Artikel 13 und 14 kosten nach Artikel 64 bis zu 15 Millionen Euro oder 2,5 Prozent des weltweiten Jahresumsatzes.

BSI TR-03183: die deutsche Konkretisierung

Solange harmonisierte europäische Normen fehlen, ist die TR-03183 die konkreteste Auslegung der CRA-Pflichten, auch wenn sie keine Konformitätsvermutung begründet. Ihr Gewicht wächst, weil der Entwurf des CRA-Durchführungsgesetzes (Kabinettsbeschluss April 2026) das BSI als Marktüberwachungsbehörde vorsieht. Die vier Teile:

• Teil 1 (General Requirements), v1.0.0 vom 31. Juli 2026: übersetzt Anhang I, II und VII in prüfbare Controls samt Testaktionen, inklusive risikobasierter Maßnahmenauswahl und OSCAL-Format
• Teil 2 (SBOM), v2.1.0: Pflichtfelder der Software-Stückliste, gemappt auf CycloneDX und SPDX
• Teil 3 (Vulnerability Reports), v1.0.0: Umgang mit eingehenden Schwachstellenmeldungen
• Teil H, v1.1.0: Konformitätsbewertung nach Modul H über ein ISMS nach ISO/IEC 27001

Teil 1 ist als Prüfkatalog aufgebaut: mit unparteiischem Evaluator, PASS/FAIL-Urteil je Control und einem Assessment Report nach den Dokumentationspflichten aus Artikel 31 CRA.

Die Rolle des Pentests

Die TR-03183-1 verlangt in der Risikobehandlung explizit die Angreiferperspektive und nennt dafür wörtlich „penetration testers or other cybersecurity experts". Zugriffsschutz, Datenintegrität und Härtung der Angriffsfläche aus Anhang I Teil I lassen sich durch Scanner und Codereviews allein nicht belegen; es braucht den kontrollierten Angriff auf das reale Produkt. Der Pentest-Bericht ist zugleich genau das Artefakt, das Anhang VII Nummer 6 fordert, und ein externer Tester bringt die vom BSI geforderte Unabhängigkeit des Prüfers per Definition mit.

In der Praxis heißt das: ein vollständiger Pentest der Auslieferungskonfiguration vor dem Inverkehrbringen, danach risikobasierte Retests über den Unterstützungszeitraum, der nach Artikel 13 Absatz 8 mindestens fünf Jahre beträgt. Auslöser sind Major Releases, neue Schnittstellen oder geänderte Authentisierung, nicht der Kalender. Der Scope folgt der Risikobewertung und umfasst beim vernetzten Gerät auch Firmware, Update-Mechanismus, Cloud-Backend und Companion-App, denn Remote Data Processing Solutions zählen nach Artikel 3 zum Produkt. Zu jedem Test gehört der Retest als Nachweis, dass Findings geschlossen wurden.

Fazit

Der CRA schreibt keinen Pentest vor, verlangt aber dokumentierte, wirksame und regelmäßige Sicherheitstests, die sich ohne Pentests kaum nachweisen lassen. Die TR-03183 macht daraus einen prüfbaren Katalog, und das BSI wird die Einhaltung als Marktüberwachungsbehörde kontrollieren. Bis Dezember 2027 bleibt Zeit, das Testprogramm aufzusetzen; wer erst kurz vor dem Stichtag beginnt, testet unter Zeitdruck und ohne die Chance, Findings designseitig zu beheben.