CRA-Check: Ist mein Unternehmen vom Cyber Resilience Act betroffen?

Mit diesem CRA-Check kannst du in wenigen Schritten einschätzen, ob dein Unternehmen den Cyber Resilience Act näher prüfen sollte. Der Check ersetzt keine rechtliche Einzelfallprüfung. Er hilft aber dabei, typische Fälle schnell zu sortieren und die richtigen nächsten Fragen zu stellen.

Bin ich vom Cyber Resilience Act betroffen?

Du solltest den CRA genauer prüfen, wenn dein Unternehmen Hardware oder Software gewerblich im EU-Markt bereitstellt und das Produkt direkt oder indirekt mit einem Gerät oder Netz verbunden werden kann. Besonders relevant ist die Prüfung, wenn ihr Produkte unter eigenem Namen oder eigener Marke verkauft, digitale Produkte aus Nicht-EU-Staaten importiert oder solche Produkte vertreibt.

Die folgenden Fragen bilden eine praktische Vorprüfung. Ein einzelnes „Ja“ bedeutet noch nicht automatisch, dass sämtliche Herstellerpflichten gelten. Mehrere „Ja“-Antworten zeigen aber schnell, wo eine vertiefte Einordnung nötig ist.

1. Bietet dein Unternehmen Software oder Hardware an?

Wenn ja, ist die CRA-Prüfung grundsätzlich sinnvoll. Der Produktbegriff ist breit und umfasst Software- und Hardwareprodukte sowie separat vermarktete Komponenten. Typische Beispiele sind Apps, Desktop-Programme, Netzwerkgeräte, IoT-Produkte, Steuerungen, Router, Sicherheitssoftware oder digitale Komponenten.

Wenn euer Unternehmen ausschließlich klassische Dienstleistungen anbietet und kein entsprechendes digitales Produkt auf dem Markt bereitstellt, ist der CRA häufig nicht der passende Rechtsrahmen. Andere Cybersicherheitsregeln können trotzdem relevant sein.

2. Kann das Produkt direkt oder indirekt mit einem Gerät oder Netz verbunden werden?

Wenn ja, passt das Produkt häufig in die Grunddefinition des CRA. Die Verbindung kann physisch oder logisch, direkt oder indirekt sein. Ein Router ist offensichtlich vernetzt. Eine App, die über eine API Daten mit einem Backend austauscht, kann ebenfalls erfasst sein.

Es muss nicht zwingend eine permanente Internetverbindung geben. Entscheidend ist, ob der bestimmungsgemäße oder vernünftigerweise vorhersehbare Gebrauch eine entsprechende Datenverbindung einschließt.

3. Wird das Produkt im Rahmen einer gewerblichen Tätigkeit auf dem EU-Markt bereitgestellt?

Wenn ja, spricht das für eine CRA-Relevanz. Produkte, die nicht im Rahmen einer gewerblichen Tätigkeit auf dem Markt bereitgestellt werden, fallen nicht allein durch ihre technische Beschaffenheit in den Anwendungsbereich.

Bei kostenlos bereitgestellter Software kann die Abgrenzung komplizierter sein. „Kostenlos“ bedeutet nicht automatisch „nicht kommerziell“. Freie und quelloffene Software besitzt im CRA eigene Regeln. Für kommerzielle Produkte, die Open-Source-Komponenten verwenden, bleibt die Verantwortung für das eigene Produkt bestehen.

4. Verkauft ihr das Produkt unter eigenem Namen oder eigener Marke?

Wenn ja, solltet ihr besonders genau prüfen, ob ihr als Hersteller gilt. Das kann auch der Fall sein, wenn ein Dritter die technische Entwicklung oder Fertigung übernimmt, ihr das Ergebnis aber unter eigener Marke in Verkehr bringt.

5. Importiert ihr digitale Produkte aus einem Staat außerhalb der EU?

Wenn ja, können Importeurspflichten entstehen. Der Importeur muss vor dem Inverkehrbringen unter anderem prüfen, ob der Hersteller definierte CRA-Voraussetzungen erfüllt hat. Dazu zählen etwa die vorgesehene Konformitätsbewertung, technische Dokumentation und CE-Kennzeichnung.

Für kleine Handelsunternehmen ist diese Frage besonders wichtig, weil Eigenimporte oft operativ wie normaler Einkauf behandelt werden. Regulatorisch kann die Rolle deutlich mehr Verantwortung auslösen.

6. Vertreibt ihr Produkte mit digitalen Elementen nur weiter?

Wenn ja, kommt eine Händlerrolle in Betracht. Händler müssen bestimmte Kennzeichnungen und Informationen prüfen und dürfen Produkte bei erkennbaren Konformitätsproblemen nicht einfach weiter bereitstellen. Wird das Produkt unter eigener Marke angeboten oder wesentlich verändert, kann sich die Rolle ändern.

Für reine Wiederverkäufer empfiehlt sich eine standardisierte Lieferantenprüfung: Welche CRA-Unterlagen werden bereitgestellt? Wer ist Hersteller oder Importeur? Wie werden Schwachstellen und Sicherheitsinformationen weitergegeben?

7. Gehört zum Produkt eine notwendige Cloud- oder Backend-Funktion?

Wenn ja, kann diese Funktion als Datenfernverarbeitungslösung Teil des CRA-relevanten Produkts sein. Das gilt insbesondere, wenn die Software vom Hersteller oder unter seiner Verantwortung entwickelt wurde und das Produkt ohne diese entfernte Verarbeitung eine Funktion nicht ausführen könnte.

Ein beliebiger Cloud-Dienst fällt dadurch nicht automatisch unter den CRA. Eine Website, die nur Marketinginformationen zeigt, ist etwas anderes als ein Hersteller-Backend, ohne das eine App oder ein Smart-Home-Gerät seine Funktion nicht bereitstellen kann.

8. Habt ihr einen Prozess für Schwachstellenmeldungen und Sicherheitsvorfälle?

Wenn nein und ihr Hersteller seid, besteht kurzfristiger Handlungsbedarf. Ab 11. September 2026 greifen die Meldepflichten nach Artikel 14. Dazu gehören grundsätzlich eine Frühwarnung innerhalb von 24 Stunden und eine weitergehende Meldung innerhalb von 72 Stunden, wenn ein meldepflichtiger Sachverhalt bekannt wird.

Ein guter Prozess beantwortet vorab: Wer nimmt externe Schwachstellenmeldungen an? Wer bewertet, ob eine Schwachstelle aktiv ausgenutzt wird? Wer entscheidet über Eskalation und Meldung? Wer kann auch außerhalb normaler Bürozeiten handeln?

9. Könnt ihr eure Software- und Hardwarekomponenten nachvollziehen?

Wenn nein, wird die CRA-Umsetzung schwieriger. Hersteller müssen Schwachstellen auch in integrierten Komponenten berücksichtigen. Wer nicht weiß, welche Bibliotheken, Frameworks, Firmwarestände oder Hardwarebausteine in einem Produkt stecken, kann Sicherheitsmeldungen nur schwer bewerten.

Die Bestandsaufnahme muss nicht mit einem komplexen Tool starten. Schon eine gepflegte Komponentenübersicht pro Produkt schafft eine belastbare Basis für spätere Prozesse.

10. Ist der Supportzeitraum für das Produkt festgelegt?

Wenn nein, sollte der Hersteller diese Entscheidung vorbereiten. Der CRA verlangt einen Unterstützungszeitraum, in dem Schwachstellen wirksam behandelt werden. Dieser Zeitraum beträgt grundsätzlich mindestens fünf Jahre, sofern die erwartete Nutzungsdauer nicht kürzer ist. Bei langlebigen Produkten kann eine längere Unterstützung erforderlich sein.

Die Entscheidung sollte nachvollziehbar begründet und dokumentiert werden. Auch Nutzer müssen die vorgesehenen Informationen zum Support erhalten.

11. Wisst ihr, welche Konformitätsbewertung für das Produkt gilt?

Wenn nein, ist das für die Vorbereitung bis 2027 ein wichtiger Punkt. Die meisten Standardprodukte können grundsätzlich über eine Selbstbewertung laufen. Für bestimmte wichtige oder kritische Produkte gelten strengere Verfahren; bei kritischen Kategorien ist eine notifizierte Stelle vorgesehen.

Deshalb sollte die Einordnung der Produktkategorie vor der Auswahl von Prüfdienstleistern oder Zertifizierungsangeboten stehen.

12. Gibt es bereits technische Dokumentation zur Cybersicherheit?

Wenn nein, sollte sie schrittweise mit dem Produktprozess aufgebaut werden. Die Dokumentation soll zeigen, welches Produkt bewertet wurde, welche Risiken bestehen, welche Anforderungen zutreffen und wie diese umgesetzt wurden. Für bereits etablierte Softwareprodukte können vorhandene Architektur-, Test-, Release- und Sicherheitsunterlagen oft weiterverwendet werden.

Wie ist das Ergebnis des CRA-Checks zu bewerten?

Es gibt keine offizielle Punktelogik des Gesetzgebers. Für eine erste Priorisierung kann folgende Einteilung trotzdem helfen:

Welche Fälle werden häufig falsch eingeschätzt?

„Wir sind zu klein für den CRA.“

Die Unternehmensgröße ist kein pauschaler Ausschluss. Kleinstunternehmen und KMU erhalten an verschiedenen Stellen Unterstützung und einzelne Erleichterungen, können aber grundsätzlich vom CRA betroffen sein.

„Wir verkaufen nur Software, keine Hardware.“

Auch eigenständige Software kann ein Produkt mit digitalen Elementen sein. Mobile Anwendungen, Desktop-Software oder Sicherheitssoftware gehören zu den typischen Beispielen.

„Unser Produkt gab es schon vor 2027.“

Für Produkte, die vor dem 11. Dezember 2027 bereits in Verkehr gebracht wurden, gelten Übergangsregeln. Die Meldepflichten können jedoch auch für bereits vorher bereitgestellte Produkte relevant sein. Wesentliche Änderungen ab dem vollständigen Geltungsbeginn können ebenfalls eine neue Prüfung auslösen.

„Wir nutzen nur Open Source.“

Das allein löst die Herstellerverantwortung für ein kommerziell angebotenes eigenes Produkt nicht auf. Die besondere Behandlung freier und quelloffener Software muss vom konkreten Vermarktungs- und Entwicklungsmodell getrennt betrachtet werden.

Was sollte nach dem CRA-Check passieren?

1. Produkte mit möglicher CRA-Relevanz in einer Liste erfassen.
2. Unternehmensrolle je Produkt festlegen und begründen.
3. Priorität auf Herstellerprodukte und kurzfristige Meldeprozesse legen.
4. Cybersicherheits-Risikobewertung und technische Dokumentation planen.
5. Support- und Schwachstellenprozesse anlegen oder vorhandene Prozesse anpassen.
6. Produktkategorie und Konformitätsweg für 2027 bestimmen.

Wenn die Rollen bereits feststehen, findest du die nächsten Aufgaben auf der Seite CRA-Pflichten für Unternehmen.

Wie sehen typische Ergebnisse des CRA-Checks aus?

Drei Beispiele zeigen, warum derselbe Unternehmensname „Softwarefirma“ oder „Händler“ zu unterschiedlichen Ergebnissen führen kann.

Fall A: Agentur entwickelt nur individuelle Websites

Eine Webagentur erstellt Kundenwebsites und betreibt keine eigene Software als Produkt. Allein die Nutzung von CMS, Hosting und Entwicklungswerkzeugen macht die Agentur nicht zum Hersteller dieser Produkte. Für die eigenen Leistungen kann der CRA daher deutlich weniger relevant sein als andere Datenschutz- oder Cybersicherheitsanforderungen. Anders kann es aussehen, wenn aus einem Projekt ein eigenes standardisiertes Softwareprodukt wird.

Fall B: Start-up verkauft eine eigene B2B-App

Das Start-up entwickelt eine App, verkauft Lizenzen und betreibt das notwendige Backend selbst. Hier sprechen mehrere Antworten klar für eine vertiefte CRA-Prüfung: eigenes Softwareprodukt, gewerbliche Bereitstellung, Herstellerrolle und notwendige Datenfernverarbeitung. Der Meldeprozess ab September 2026 und die vollständige Produktkonformität bis Ende 2027 sollten in die Roadmap aufgenommen werden.

Fall C: Kleiner Fachhändler importiert Router direkt

Der Fachhändler entwickelt nichts selbst, bestellt die Geräte aber direkt bei einem Hersteller außerhalb der EU und bringt sie in Deutschland in Verkehr. Damit kann er Importeur sein und eigene Kontrollpflichten bekommen. Wird zusätzlich eine Eigenmarke verwendet oder Firmware verändert, sollte geprüft werden, ob Herstellerpflichten entstehen.

Welche Unterlagen helfen bei einer vertieften CRA-Prüfung?

Wenn der Selbstcheck Handlungsbedarf zeigt, beschleunigen einige Unterlagen die weitere Einordnung. Dazu gehören eine Produktbeschreibung, Architekturübersicht, Liste zentraler Software- und Hardwarekomponenten, Beschreibung der Updatewege, vorhandene Sicherheits- und Penetrationstests, aktuelle CE- beziehungsweise Konformitätsunterlagen sowie Lieferanteninformationen.

Bei importierten Produkten sind Herstellerangaben, bestehende Konformitätserklärungen, Supportzusagen und Ansprechpartner für Schwachstellen besonders nützlich. Bei eigener Software helfen Releaseprozess, Dependency-Management, Security-Issue-Workflow und Dokumentation der eingesetzten Cloud- oder Backend-Funktionen.

Fehlt vieles davon, ist das noch kein Beweis für einen Verstoß. Es zeigt vor allem, wo die organisatorische Vorbereitung beginnen sollte. Die Unterlagen müssen zum tatsächlichen Produkt passen und dürfen nicht nur aus generischen Vorlagen bestehen.

Welche offizielle Stelle informiert in Deutschland zum CRA?

Das Bundesamt für Sicherheit in der Informationstechnik stellt eine eigene CRA-Übersicht mit Terminen und Hinweisen zum Anwendungsbereich bereit. Für konkrete Rechtsfragen bleibt der EU-Rechtstext maßgeblich.

CRA-Informationen des BSI