Cyber Resilience Act

CRA-Check für Software, Hardware und Produkte mit digitalen Elementen

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.

  • 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 11.09.2026 für Meldepflichten und 11.12.2027 für CRA-Hauptpflichten.
  • 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 ab 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 ab 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, ENISA-Meldeformate 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.09.2026CRA-Meldepflichten für aktiv ausgenutzte Schwachstellen und schwere Sicherheitsvorfälle werden praktisch relevant.VDP, PSIRT, Incident-Runbook, Beweissicherung, Eskalation und Meldewege vorbereiten.Kein Prozess für Vulnerability Intake, CVE-Bewertung oder Kundenkommunikation.
12.09.2026Data-Act-by-design für neue vernetzte Produkte und verbundene Dienste kann parallel relevant werden.Produktdaten, Schnittstellen, Geschäftsgeheimnisse und DSGVO-Gates zusammen mit CRA-Architektur planen.Connected Product ohne Datenzugangs- und Security-by-design-Konzept.
09.12.2026Neue Produkthaftungsregeln sind für Software, KI, Updates und Cybersecurity-Risiken einzuplanen.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.

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.