Sie dient ausschließlich als erste Orientierung. Sie ersetzt weder eine rechtliche Beratung noch eine vollständige technische oder regulatorische Konformitätsbewertung. Eine ausführliche Einordnung der CRA-Begriffe und Fristen finden Sie im ersten Beitrag unserer Serie: „Cyber Resilience Act in der Praxis: Fristen, Pflichten und erste Schritte“. 

Warum eine Selbstprüfung jetzt sinnvoll ist 

Die Meldepflichten nach Artikel 14 CRA gelten ab dem 11. September 2026. Die vollständige Anwendung folgt am 11. Dezember 2027. 

Verzögerungen entstehen häufig nicht nur durch technische Fragen, sondern auch durch unklare Zuständigkeiten, fehlende Dokumentation oder unvollständige Informationen aus der Lieferkette. Eine strukturierte Selbstprüfung kann dabei helfen, solche Punkte frühzeitig zu erkennen. 

Die Checkliste bündelt zentrale Anforderungen und Umsetzungsfragen in vier praxisnahen Bereichen. 

Block 1: Security by Design und Risikobewertung 

Dieser Block prüft, ob Cybersicherheit bereits in Architektur und Entwicklung berücksichtigt wird, statt erst nachträglich ergänzt zu werden.

• Fernzugriffe und Wartungsschnittstellen sind geschützt und nicht mit Standardpasswörtern erreichbar.
• Für das Produkt liegt eine dokumentierte Cybersicherheitsrisikobewertung vor.
• Angriffsflächen, relevante Bedrohungen und geeignete Gegenmaßnahmen sind nachvollziehbar beschrieben.
• Sicherheitsrelevante Designentscheidungen sind Teil der technischen Dokumentation.
• Das Produkt wird mit sicheren Standardeinstellungen ausgeliefert.
• Neue Produktvarianten und möglicherweise wesentliche Änderungen werden vor dem Inverkehrbringen erneut sicherheitstechnisch bewertet. 

Sind mehrere Punkte offen, sollte geprüft werden, ob die Risikobewertung vollständig dokumentiert und auf dem aktuellen Produktstand ist. Sie bildet die Grundlage für weitere technische und organisatorische Maßnahmen. 

Block 2: SBOM und Schwachstellenmanagement 

Eine aktuelle Software Bill of Materials, kurz SBOM, hilft dabei, betroffene Produkte und Softwarestände nach Bekanntwerden einer Schwachstelle schnell zu identifizieren.

• Für das Produkt existiert eine SBOM in einem gängigen maschinenlesbaren Format, beispielsweise CycloneDX oder SPDX.
• Die SBOM ist eindeutig einem Produkt- und Release-Stand zugeordnet.
• Sie wird bei relevanten Änderungen aktualisiert und nicht nur einmalig beim Produktstart erstellt.
• Drittanbieter- und Open-Source-Komponenten sind mindestens auf Ebene der direkten Abhängigkeiten erfasst.
• Neue Schwachstellenmeldungen werden systematisch mit den eingesetzten Komponenten abgeglichen.
• Die SBOM ist Teil der technischen Dokumentation und kann einer Marktüberwachungsbehörde auf Anfrage bereitgestellt werden. 

Eine automatisierte Erstellung für jeden ausgelieferten Softwarestand ist nicht ausdrücklich vom CRA vorgeschrieben, kann in geeigneten Entwicklungsumgebungen jedoch sinnvoll sein. Entscheidend ist, dass die SBOM aktuell ist und den tatsächlichen Produktstand abbildet. 

Block 3: Updatefähigkeit und Supportzeitraum 

Dieser Block bewertet, ob Sicherheitsupdates während des festgelegten Supportzeitraums technisch und organisatorisch bereitgestellt werden können.

• Für das Produkt besteht ein praktikabler und sicherer Update-Prozess – remote oder vor Ort.  
• Updates werden authentifiziert und vor Manipulation geschützt.  
• Test- und Freigabeprozesse sowie geeignete Rollback- oder Wiederherstellungsmechanismen für Sicherheitsupdates sind definiert.
• Der Supportzeitraum ist anhand der erwarteten Nutzungsdauer, der Produktart und der Erwartungen der Nutzer festgelegt.  
• Der Supportzeitraum wird dokumentiert und gegenüber den Nutzern transparent kommuniziert.
• Für sicherheitsrelevante Komponenten liegen Informationen zu Support, Updates und Schwachstellenkommunikation der Lieferanten vor.  
• Es ist geregelt, wie Kunden über das Ende des Supportzeitraums informiert werden.  

Besonderer Handlungsbedarf kann entstehen, wenn Betriebssysteme, Module oder sicherheitsrelevante Drittkomponenten deutlich früher aus dem Support fallen als das Endprodukt. 

Kritische Informationen und Supportzusagen von Lieferanten sollten deshalb möglichst frühzeitig eingeholt und dokumentiert werden. 

Block 4: Meldeprozess und Lieferantenmanagement 

Ab September 2026 müssen Hersteller bei einer aktiv ausgenutzten Schwachstelle oder einem schwerwiegenden Sicherheitsvorfall innerhalb von 24 Stunden eine Frühwarnung abgeben können.

• Es ist geregelt, wer einen Vorfall bewertet und über eine Meldung entscheidet.  
• Ein PSIRT oder eine vergleichbare verantwortliche Funktion ist benannt.  
• Für zeitkritische Vorfälle bestehen klare Eskalations- und Vertretungswege.  
• Der Meldeprozess wurde anhand eines fiktiven Vorfalls getestet.  
• Relevante Produkt-, Versions- und Kundeninformationen können kurzfristig zusammengeführt werden.  
• Lieferanten informieren über Schwachstellen in ihren Komponenten über definierte Meldewege.  
• Benötigte Informationen wie SBOM-Daten, Supportzeiträume und Sicherheitsmeldungen können von Lieferanten eingeholt werden.  
• Soweit für ein zugekauftes Produkt erforderlich, sind relevante Konformitätsnachweise verfügbar.  

Nicht jede intern entdeckte Schwachstelle löst eine CRA-Meldepflicht aus. Aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle müssen jedoch innerhalb der gesetzlichen Fristen bewertet und gemeldet werden. 

Ein dokumentierter Prozess allein genügt nicht unbedingt. Erst eine interne Übung zeigt, ob Zuständigkeiten, Datenzugriff und Kommunikation im Ernstfall funktionieren. 

Auswertung: Wo besteht Handlungsbedarf? 

Nicht jeder Prüfpunkt hat dasselbe regulatorische oder technische Gewicht. Die Checkliste sollte deshalb nicht ausschließlich anhand der Anzahl offener Punkte bewertet werden. 

Grün: Die wesentlichen Prozesse sind vorhanden, dokumentiert und praktisch umsetzbar. Einzelne Optimierungen bleiben offen. 

Gelb: Mindestens ein zentraler Prozess ist nur teilweise umgesetzt oder nicht ausreichend dokumentiert. 

Rot: Grundlegende Voraussetzungen fehlen, beispielsweise eine Risikobewertung, Updatefähigkeit, ein Schwachstellenprozess oder eine klare Meldeverantwortung. 

Besonders kritisch ist eine Kombination aus fehlender Updatefähigkeit und unklarem Meldeprozess. In diesem Fall kann ein Unternehmen weder strukturiert auf eine Schwachstelle reagieren noch Behörden und Kunden rechtzeitig informieren. 

Die Checkliste bietet eine erste Orientierung, in welchen Bereichen eine vertiefte Prüfung durch entsprechend qualifizierte interne oder externe Fachstellen sinnvoll sein kann. 

Wie es nach der Selbstprüfung weitergeht 

Offene Punkte sollten den zuständigen internen Bereichen zugeordnet und nach Priorität bearbeitet werden. Je nach Thema kann zusätzlich die Unterstützung durch spezialisierte Rechts-, Cybersecurity- oder Zertifizierungsexperten sinnvoll sein. 

Aaronn Electronic unterstützt Kunden auf der technischen Systemebene – von der Auswahl geeigneter Embedded-Plattformen über das Design-in bis zu Lifecycle-Management und Updatefähigkeit. Damit schaffen wir eine belastbare technische Grundlage für langfristig wartbare Systeme. 

Aaronn beim Elektronik Solutions Day 

Beim Elektronik Solutions Day im September 2026 zeigt Geschäftsführer Florian Haidn gemeinsam mit unserem Technologiepartner congatec, welche Rolle modulare Systemarchitekturen bei Updatefähigkeit, Plattformpflege und langfristigem Lifecycle-Management in Embedded-Systemen spielen können (15:30 Uhr, 30 Minuten). 

Quellen 

1. Verordnung (EU) 2024/2847 – Cyber Resilience Act
2. Europäische Kommission: Cyber Resilience Act – Reporting obligations
3. Europäische Kommission: Cyber Resilience Act – Manufacturers
4. ENISA: Single Reporting Platform
5. Bundesamt für Sicherheit in der Informationstechnik: BSI TR-03183-2
6. OWASP Foundation: CycloneDX
7. SPDX Project, Linux Foundation