Zum Inhalt springen
DEEN

Cyber Resilience Act

CRA-Check für Software, Hardware und vernetzte Produkte

Dieser interaktive Check unterstützt Unternehmen, Hersteller, Importeure, Händler, Softwareanbieter, Komponentenlieferanten und Open-Source-Strukturen bei der ersten Einordnung, ob der Cyber Resilience Act relevant sein kann und welche nächsten Schritte für Security, Konformität, SBOM, Vulnerability Handling und Produktdokumentation naheliegen.

Check starten

  • Produkte mit digitalen Elementen
  • Secure-by-design
  • SBOM und OSS
  • VDP, PSIRT und Meldelogik
  • CE- und Konformitätsakte

Was Sie als Ergebnis erhalten

Der CRA-Check liefert eine vorläufige Risikostufe, eine wahrscheinliche Rollen- und Produkteeinordnung, typische Gründe, priorisierte Prüfpunkte, vorzubereitende Unterlagen und einen kopierbaren Kurzüberblick für eine strukturierte Anfrage.

  • Berücksichtigung von Hersteller-, Importeur-, Händler-, Reseller-, Komponenten- und OSS-Konstellationen.
  • Einordnung der Fristen: Meldepflichten nach Art. 14 CRA gelten seit 11.09.2026, die Vorschriften über Konformitätsbewertungsstellen seit 11.06.2026, die CRA-Hauptpflichten ab 11.12.2027.
  • Schnittstellen zu NIS2/BSIG, Data Act, GPSR, Produkthaftung, DSGVO, Open Source und Softwareverträgen.

Interaktive Visualisierung

CRA-Produkt-Security-Kompass

Der Cyber Resilience Act verlangt keine isolierte Checkliste, sondern ein belastbares Produkt-Sicherheitsmodell. Klicken Sie auf ein Prüfmodul, um zu sehen, welcher Nachweis im CRA-Projekt typischerweise aufgebaut werden muss.

CRA Produktakte Security + Konformität Scope Rolle Secure Design SBOM OSS VDP PSIRT CE Doku Update Support Meldelogik seit 11.09.2026 Hauptpflichten ab 11.12.2027
Scope & Rolle Startpunkt ist die Abgrenzung des Produkts mit digitalen Elementen: Hersteller, Importeur, Händler, wesentlicher Änderer, Komponentenlieferant oder Open-Source-Steward. Ohne diese Einordnung lässt sich der CRA-Pflichtenpfad nicht belastbar bestimmen.

Orientierung in fünf Schritten

1
Produktgrenze klärenSoftware, Hardware, Remote-Komponente, Firmware, SDK, Bibliothek, Cloud-Funktion oder rein interner Dienst müssen sauber abgegrenzt werden.
2
Rolle bestimmenHersteller, Importeur, Händler, wesentlicher Änderer, Komponentenlieferant, Open-Source-Steward oder Käufer haben unterschiedliche Pflichten und Nachweispunkte.
3
Kategorie und Konformität prüfenWichtige oder kritische Produktkategorien können das Konformitätsverfahren und die Anforderungen an Nachweise verschärfen.
4
Security-Lifecycle aufbauenThreat Modeling, Secure-by-design, SBOM, Vulnerability Handling, Security Updates, Supportzeitraum und technische Dokumentation sollten zusammen gedacht werden.
5
Fristen und Schnittstellen steuernMeldepflichten seit 11.09.2026, Hauptpflichten ab 11.12.2027 sowie NIS2, Data Act, GPSR, Produkthaftung, DSGVO und Open Source sollten in einer Roadmap zusammengeführt werden.

Was dieser Check leistet

Der CRA-Check ist eine strukturierte Erstorientierung. Er ersetzt keine Einzelfallprüfung, hilft aber dabei, den Prüfgegenstand, die wahrscheinlich relevante Rolle, typische Readiness-Lücken und die nächsten Unterlagen für eine anwaltliche oder interne Compliance-Prüfung zu sortieren.

Wann ist der CRA typischerweise relevant?

Der CRA ist typischerweise relevant, wenn Software, Hardware, vernetzte Produkte, eingebettete Systeme, Firmware, Komponenten oder digitale Funktionen auf dem EU-Markt bereitgestellt werden. Entscheidend sind Produktgrenze, Marktbereitstellung, Rolle des Unternehmens und mögliche Ausnahmen.

Welche Pflichten stehen im Mittelpunkt?

Im Mittelpunkt stehen Cybersicherheitsanforderungen über Design, Entwicklung, Produktion, Auslieferung und Wartung, Schwachstellenmanagement, Security Updates, Supportzeitraum, technische Dokumentation, EU-Konformitätserklärung, CE-/Kennzeichnungsthemen und Meldeprozesse für aktiv ausgenutzte Schwachstellen oder schwere Sicherheitsvorfälle.

Was sind die Grenzen des Checks?

Der Check kann keine verbindliche Produktklassifizierung, keine technische Prüfung und keine finale Konformitätsbewertung ersetzen. Spezialrecht, Open-Source-Sonderregeln, Drittbewertung, harmonisierte Normen, Meldungen über die ENISA Single Reporting Platform, die technischen Beschreibungen der Produktkategorien (Durchführungsverordnung (EU) 2025/2392), die Leitlinien der Kommission C(2026) 5252 und konkrete Produktkategorien müssen im Einzelfall geprüft werden.

Interaktiver Fragebogen

CRA-Betroffenheit und Readiness einschätzen

Beantworten Sie die folgenden Fragen so konkret wie möglich. Das Ergebnis wird aus Rollen-, Produkt-, Kategorie-, Readiness- und Dringlichkeitssignalen berechnet.

Schritt 1 von 6
1. Welche Rolle hat Ihr Unternehmen?

Wählen Sie die Rolle, die dem Produkt am nächsten kommt.

2. Um welches Produkt geht es?

Der CRA knüpft an Produkte mit digitalen Elementen an. Die Produktgrenze ist oft der wichtigste Prüfpunkt.

3. Wie wird das Produkt bereitgestellt?

Marktbereitstellung, EU-Bezug und mögliche Spezialregelungen beeinflussen die Einordnung stark.

4. Welche CRA-Kategorie könnte betroffen sein?

Wenn die Kategorie noch nicht geprüft wurde, wählen Sie „unklar“.

5. Welche CRA-Readiness-Bausteine gibt es bereits?

Markieren Sie alles, was belastbar dokumentiert oder bereits operativ umgesetzt ist.

6. Gibt es Handlungsdruck oder Schnittstellen?

Wählen Sie alle Signale aus, die für das Produkt oder die Organisation relevant sind.

Typische Fristen, Risiken und Maßnahmen

Datum / AnlassRelevanzTypische MaßnahmeRisikosignal
10.12.2024Cyber Resilience Act in Kraft.Produkt- und Rollenmapping starten, Produktportfolio gegen CRA-Scope prüfen.Keine Zuständigkeit für CRA im Unternehmen definiert.
11.06.2026Vorschriften über die Notifizierung von Konformitätsbewertungsstellen (Kapitel IV CRA) gelten.Bei wichtigen Produkten der Klasse II und kritischen Produkten Verfügbarkeit benannter Stellen und Zeitbedarf der Drittbewertung früh klären.Drittbewertung erforderlich, aber kein Termin bei einer benannten Stelle eingeplant.
11.09.2026Seit diesem Tag gelten die Meldepflichten nach Art. 14 CRA für aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle, auch für Bestandsprodukte (Art. 69 Abs. 3 CRA). Gemeldet wird über die ENISA Single Reporting Platform an das koordinierende CSIRT, in Deutschland CERT-Bund beim BSI: Frühwarnung binnen 24 Stunden, Meldung binnen 72 Stunden, Abschlussbericht nach 14 Tagen bzw. einem Monat.VDP, PSIRT, Incident-Runbook, Beweissicherung, Eskalation und Meldewege vorbereiten.Kein Prozess für Vulnerability Intake, CVE-Bewertung oder Kundenkommunikation.
12.09.2026Seit diesem Tag gelten die Data-Act-Designpflichten (Art. 3 Abs. 1 Data Act) für danach in Verkehr gebrachte vernetzte Produkte und verbundene Dienste.Produktdaten, Schnittstellen, Geschäftsgeheimnisse und DSGVO-Gates zusammen mit CRA-Architektur planen.Connected Product ohne Datenzugangs- und Security-by-design-Konzept.
09.12.2026Neues Produkthaftungsrecht nach der Richtlinie (EU) 2024/2853 gilt für ab diesem Tag in Verkehr gebrachte Produkte, ausdrücklich auch Software und Updates; das deutsche Gesetz zur Modernisierung des Produkthaftungsrechts ist von Bundestag und Bundesrat verabschiedet.Release Notes, Security Patches, technische Dokumentation und Haftungsakte strukturieren.Security-Entscheidungen sind technisch vorhanden, aber nicht gerichtsfest dokumentiert.
11.12.2027CRA-Hauptpflichten werden anwendbar.Secure-by-design, technische Dokumentation, SBOM, CE-/Konformitätsakte, Supportzeitraum und Updatepolitik etablieren.Produkt wird weiter vertrieben, ohne Konformitätsstrategie und Nachweisführung.
EreignisabhängigAktiv ausgenutzte Schwachstelle, schwerer Sicherheitsvorfall, Rückruf, Kunden- oder Behördenanfrage.Incident Response, rechtliche Meldeprüfung, Kundenkommunikation, Patchplan und Beweissicherung koordinieren.Öffentlicher Exploit, kritischer CVE, kompromittierte Komponente oder fehlende SBOM.

Nächste sinnvolle Schritte

Verwandte ITMR-Checker und Anschlussprüfungen

NIS-2-CheckPrüft, ob Cybersecurity-, Leitungs-, Risikomanagement- und Meldepflichten für die Organisation parallel relevant sind. Open-Source-/SBOM-CheckHilft, Komponenten, OSS-Lizenzen, CVEs, Lieferkettenrisiken und SBOM-Nachweise CRA-tauglich zu strukturieren. Data-Act-CheckOrdnet Datenzugang, vernetzte Produkte, verbundene Dienste und Cloud-Switching als Schnittstelle zum CRA ein. Interaktive Risiko-Matrix / Risk CockpitPriorisiert CRA-, Security-, Produkt-, Datenschutz- und Lieferkettenrisiken nach Wirkung und Dringlichkeit. Regulatorik-ZeitstrahlZeigt relevante Fristen für CRA, Data Act, Produkthaftung, NIS2, AI Act und weitere Digitalregulierung im Überblick. Dokumenten-Dossier BuilderStrukturiert Produktakte, technische Dokumentation, Nachweise, Security Policies, Verträge und Audit-Unterlagen.

Vertiefung im ITMR-Blog

Der Check ordnet ein, die Beiträge erläutern die Rechtslage im Detail, mit Normbelegen und Rechtsstand.

Meldepflicht · Art. 14 CRA CRA-Meldepflicht seit 11.09.2026 Frühwarnung, 72-Stunden-Meldung, Abschlussbericht und Meldeplattform: was Hersteller jetzt bei aktiv ausgenutzten Schwachstellen und schwerwiegenden Vorfällen tun müssen. Zum Beitrag Ein Vorfall, mehrere Meldewege Cybervorfall melden nach NIS2, CRA, DSGVO und DORA Wenn Ihr Unternehmen zugleich Hersteller, Einrichtung und Verantwortlicher ist: die vier Meldeordnungen, ihre Fristen und Startpunkte im Vergleich. Zum Beitrag Open Source · Art. 24 CRA CRA und Open Source Hersteller, Verwalter oder außerhalb des Anwendungsbereichs: Sorgfalt beim Einbau von OSS-Komponenten und die Rolle des Open-Source-Software-Verwalters. Zum Beitrag

CRA-Betroffenheit strukturiert prüfen lassen

Bei Software, vernetzten Produkten, IoT, Embedded Devices, Security-Produkten, Komponenten oder Open-Source-Strukturen sollte die CRA-Prüfung früh in Produktroadmap, Security Engineering, Vertragsgestaltung und Nachweisdokumentation eingebunden werden.

Kontakt aufnehmen Softwareverträge prüfen

Rechtlicher Orientierungshinweis

Dieser CRA-Check dient der ersten Orientierung und ersetzt keine Rechtsberatung im Einzelfall. Ob der Cyber Resilience Act tatsächlich anwendbar ist, welche Rolle Ihr Unternehmen einnimmt, ob eine wichtige oder kritische Produktkategorie betroffen ist und welche Konformitäts-, Melde- oder Dokumentationspflichten bestehen, muss anhand des konkreten Produkts, der Lieferkette, der technischen Architektur, der Marktbereitstellung und der aktuellen Behörden- und Normenlage geprüft werden. Rechtsstand: 24.10.2026. Harmonisierte Normen zum CRA sind noch nicht im Amtsblatt veröffentlicht; das deutsche CRA-Durchführungsgesetz (BSI als Marktüberwachungsbehörde) ist vom Bundestag beschlossen, aber noch nicht verkündet; eine gemeinsame Meldestelle für mehrere Rechtsakte ist im Digital Omnibus erst vorgeschlagen. Wie wir Hersteller und Softwareanbieter bei der Umsetzung begleiten, lesen Sie im Bereich Cybersecurity; Haftungsfragen behandelt unsere Seite zum Produkthaftungsrecht.