In Kürze: Der Cyber Resilience Act (CRA) ist eine EU-Verordnung für Produkte mit digitalen Elementen. Er verpflichtet Hersteller, Importeure und Distributoren dazu, Cybersicherheit bereits in Entwicklung, Dokumentation, Updates und Produktbetrieb mitzudenken. Für Startups ist wichtig: Auch reine Software, B2B-Tools, Apps, Clients, Firmware oder vernetzte Produkte können betroffen sein.

Viele Gründer:innen schieben Security und Compliance auf später. Beim Cyber Resilience Act Software kann das teuer werden: Fehlende Produktdokumentation, ungeklärte Rollen und improvisierte Meldeprozesse können direkt zum Launch- oder Vertriebsproblem werden. In diesem Artikel zeigen wir, ob euer Produkt grundsätzlich in den CRA-Anwendungsbereich fallen kann, was für CRA Startups bei Fristen, Rollen, Meldungen und Support Period wichtig wird und welche 30/90-Tage-Schritte jetzt sinnvoll sind.

Der Cyber Resilience Act (CRA) ist eine EU-Verordnung, die verbindliche Cybersicherheitsanforderungen für Produkte mit digitalen Elementen festlegt. Er gilt für Hersteller, Importeure und Distributoren, die solche Produkte auf dem EU-Markt bereitstellen, unabhängig vom Unternehmenssitz. Die Hauptpflichten greifen ab dem 11. Dezember 2027.

Inhaltsverzeichnis

Was der Cyber Resilience Act in einfacher Sprache bedeutet

Der CRA ist eine EU-Verordnung, die Cybersicherheitsanforderungen für sogenannte Produkte mit digitalen Elementen festlegt. Laut EUR-Lex umfasst das Software- oder Hardware-Produkte und deren Datenfernverarbeitung, soweit diese für Produktfunktionen relevant ist. Kurz gesagt: Security wird nicht mehr nur ein Technikthema, sondern Teil von Produktentwicklung, Release-Prozess, Dokumentation, Update-Strategie und Marktzugang.

Das BSI betont ausdrücklich, dass der CRA alle Hersteller betrifft, die Produkte mit digitalen Elementen auf den EU-Markt bringen, unabhängig vom Sitz des Unternehmens. Auch Händler und Importeure haben eigene Pflichten. Besonders wichtig für Gründer:innen: Das BSI nennt B2B-Software und reine Softwareprodukte explizit als relevante Beispiele.

Für euch als Team bedeutet das: Security und Compliance gehören früh in Product Ops, QA und Release-Prozesse, nicht in ein hektisches Nachdokumentieren kurz vor Marktstart.

Was unter “Produkten mit digitalen Elementen” fällt und wo Startups sich oft verschätzen

Der Begriff klingt abstrakt, wird aber schnell konkret. Typische Produktarten im Anwendungsbereich sind:

  • Vernetzte Hardware mit Software oder Firmware
  • Reine Softwareprodukte, die auf dem Markt bereitgestellt werden
  • Produkte, deren Funktion von relevanter Datenfernverarbeitung abhängt
  • Mobile Apps, Clients, Embedded Software, Gerätesoftware

Vier typische Fehlannahmen begegnen uns immer wieder.

Fehlannahme 1: “Wir sind nur Software, also betrifft es uns nicht.” Falsch. BSI und EU-Kommission bestätigen eindeutig, dass reine Softwareprodukte im Anwendungsbereich liegen können.

Fehlannahme 2: “Wir hosten in der Cloud, also gibt es kein Produkt.” Datenfernverarbeitung kann CRA-relevant werden, wenn sie Teil der Produktfunktion ist. Das ist kein Freifahrtschein.

Fehlannahme 3: “Open Source entlastet uns komplett.” Freie und quelloffene Software ist nur dann typischerweise ausgenommen, wenn sie nicht im Rahmen einer kommerziellen Tätigkeit bereitgestellt wird. Wer Open-Source-Komponenten in ein vermarktetes Produkt einbettet, ändert die Lage nicht automatisch zu seinen Gunsten.

Fehlannahme 4: “White-Label heißt, die Verantwortung liegt beim Partner.” Die Herstellerrolle landet oft bei dem Unternehmen, das das Produkt unter eigenem Namen in Verkehr bringt. Outsourcing der Entwicklung verschiebt die Verantwortung nicht automatisch.

Ein einfaches Entscheidungsraster hilft euch bei der ersten Einordnung: Wird ein digitales Produkt unter eigener Marke bereitgestellt? Gibt es Software, App, Client, Firmware oder Gerätesoftware? Gibt es vernetzte Funktionen oder relevante Remote-Verarbeitung? Ist das Produkt Teil eines IoT- oder Hardware-Angebots? Wird es kommerziell auf dem EU-Markt bereitgestellt?

Visuelle CRA-Entscheidungshilfe für Software, SaaS, IoT und White-Label

CRA SaaS: Gilt der CRA für SaaS automatisch?

Klare Antwort: Nein. Standalone-SaaS oder reine Cloud-Lösungen sind nicht automatisch selbst Produkte mit digitalen Elementen. Aber es gibt ein wichtiges Aber.

Wenn Cloud- oder Datenfernverarbeitung Teil der Produktfunktion ist, kann sie im CRA-Kontext relevant werden. Außerdem muss die Risikobewertung das gesamte Produkt inklusive relevanter Remote-Verarbeitung abdecken. Das bestätigt die offizielle FAQ der EU-Kommission.

Konkret heißt das: Eine reine Browseranwendung ohne eigenes Endprodukt ist nicht pauschal gleichzusetzen mit einem CRA-pflichtigen Produkt. Ein SaaS-Angebot mit eigener App, lokalem Client, Edge-Komponente, Agent, Firmware-Anbindung oder eingebetteter Funktion in Hardware kann deutlich eher CRA-relevant sein. Entscheidend ist nicht das Schlagwort SaaS, sondern welche Produktbestandteile ihr vermarktet und welche digitalen Funktionen für den Betrieb notwendig sind.

Statt zu fragen “Gilt der CRA für unsere SaaS?” sollten Teams fragen: “Welche Komponenten unseres Angebots könnten ein Produkt mit digitalen Elementen sein?”

Rollen verstehen: Hersteller, Importeur, Distributor und Open-Source-Bezug

Der CRA unterscheidet drei Hauptrollen, die jeweils eigene Pflichten tragen. Der Hersteller bringt ein Produkt unter eigenem Namen oder eigener Marke auf den Markt. Der Importeur bringt ein Produkt aus einem Drittstaat in den EU-Markt. Der Distributor vertreibt ein Produkt weiter. Das stützen sowohl EUR-Lex als auch die EU-Kommissions-Zusammenfassung.

Für Startups bedeutet das konkret: Wer Entwicklung extern vergibt, bleibt oft trotzdem Hersteller. Wer White-Label-Software unter eigener Marke verkauft, kann Herstellerpflichten auslösen. Wer Hardware aus Asien bezieht und in der EU unter eigener Marke vertreibt, sollte Importeur- und Herstellerfragen sehr früh klären.

Bei Open Source gilt die bereits genannte Abgrenzung: Nicht-monetarisierte Open-Source-Software und reine Code-Beiträge fallen typischerweise nicht darunter. Kommerzielle Bereitstellung oder Einbettung in ein vermarktetes Produkt kann den CRA wieder relevant machen. Open-Source-Stewards haben ein spezielles, leichteres Regime, aber das entlastet nicht automatisch ein Startup, das ein kommerzielles Produkt anbietet.

Die CRA-Fristen, die Gründer:innen wirklich kennen müssen

Es gibt vier Stichtage, die ihr auf dem Radar haben solltet:

  • 10.12.2024: Inkrafttreten des CRA. Das Thema ist real und sollte in Produktplanung und Governance auftauchen.
  • 11.06.2026: Regeln zu Konformitätsbewertungsstellen werden anwendbar. Wer auf Drittprüfung angewiesen sein könnte, sollte jetzt Vorlauf einkalkulieren.
  • 11.09.2026: Berichtspflichten und Meldepflichten werden relevant. Ab diesem Datum müssen Hersteller aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle melden. Die Schwachstellenmeldung ENISA ist dann kein optionaler Prozess mehr.
  • 11.12.2027: Die Hauptpflichten des CRA werden anwendbar. Das eigentliche Pflichtenset muss tragfähig umgesetzt sein.

Eine wichtige Nuance: Produkte, die vor dem 11.12.2027 in Verkehr gebracht wurden, fallen grundsätzlich erst bei wesentlicher Änderung in den Vollanwendungsbereich. Berichtspflichten können aber früher relevant werden. Das ist kein Grund zur Entspannung, sondern ein Grund, frühzeitig zu starten.

Welche Pflichten kleine Teams praktisch aufbauen müssen

Das ist der Kernblock dieses Artikels. Hier geht es darum, was konkret zu tun ist, nicht nur was theoretisch gilt.

Risikobewertung

Vor dem Inverkehrbringen ist eine Risikobewertung nötig, die das gesamte Produkt inklusive relevanter Datenfernverarbeitung abdeckt. Die technische Dokumentation muss die Risikobewertung und die Begründung zentraler Annahmen enthalten. Als Startup-Minimum braucht ihr eine dokumentierte Übersicht zu Produktfunktionen, Angriffsflächen, Schadensszenarien, Nutzergruppen, Abhängigkeiten und Schutzmaßnahmen.

Cybersecurity by Design und by Default

Cybersecurity by Design bedeutet, Sicherheitsanforderungen von Anfang an in Architektur, Entwicklungsprozess und Standardkonfiguration einzubauen. Die EU-Kommission nennt konkrete Pflichtbausteine: Security by default, Zugriffskontrolle, Kryptografie, Updates und Pflege über die erwartete Nutzungsdauer hinweg. Für kleine Teams heißt das: sichere Default-Einstellungen, Rollen- und Rechtekonzept, Secrets-Handling, Update-Fähigkeit, Logging und klare Freigaben vor Releases.

Komponenten- und Dependency-Inventar

Jedes Team muss wissen, welche Bibliotheken, Open-Source-Pakete, SDKs, Container-Images, Firmware-Bausteine und Drittmodule im Produkt stecken. Die BSI TR-03183 Teil 2 SBOM zeigt praktisch, warum ein SBOM oder zumindest ein Dependency-Inventar für die CRA-Vorbereitung sinnvoll ist.

Vulnerability-Handling

Teams brauchen einen dokumentierten Prozess für Entdeckung, Bewertung, Priorisierung, Behebung und Kommunikation von Schwachstellen. Als Startup-Minimum: zentrale Mailbox, Severity-Schema, Zuständigkeiten, Fristen und ein Release-Pfad für Patches.

Schwachstellenmeldung ENISA

Ab 11.09.2026 gelten konkrete Meldefristen: Frühwarnung innerhalb von 24 Stunden, weitergehende Meldung innerhalb von 72 Stunden, Abschlussbericht spätestens 14 Tage nach Verfügbarkeit einer Abhilfemaßnahme bei Schwachstellen bzw. innerhalb eines Monats bei schweren Vorfällen. Gemeldet wird über die Single Reporting Platform an das zuständige CSIRT und zugleich an ENISA. Dieser Meldeprozess kann nicht improvisiert werden.

Support Period

Die Support Period ist der Zeitraum, in dem Sicherheitsupdates und Pflege bereitgestellt werden. Als Grundregel gilt laut FAQ der EU-Kommission: mindestens fünf Jahre, sofern die erwartete Nutzungsdauer nicht kürzer ist. Teams sollten schon bei der Produktplanung festlegen, wie lange Updates, Patches und Security-Fixes geliefert werden und wie das Kund:innen kommuniziert wird.

Nutzerinformationen und technische Dokumentation

Nutzer:innen müssen verständliche Informationen zu sicherer Nutzung, Updates, Einschränkungen und Meldewegen bekommen. Die technische Dokumentation soll nachvollziehbar machen, wie das Produkt aufgebaut ist, welche Risiken betrachtet wurden und wie Anforderungen erfüllt werden.

Verantwortlichkeiten

Benennt eine verantwortliche Person oder einen klaren Owner für CRA-Themen, auch wenn es kein eigenes Compliance-Team gibt. Aufgaben sind: Dokumentation pflegen, Dependency-Inventar überwachen, Security-Gates im Release verwalten, Meldungen koordinieren.

In Kürze: Startups sollten frühzeitig folgende Grundlagen schaffen: eine Risikobewertung, ein Dependency-Inventar oder SBOM, klare Update- und Patch-Prozesse, Vulnerability-Handling, technische Dokumentation, Nutzerinformationen, eine definierte Support Period und feste Verantwortlichkeiten. Diese Punkte lassen sich später nicht sauber in wenigen Wochen nachholen.

CE-Kennzeichnung Software: Wann das relevant wird und wann nicht

Die CE-Kennzeichnung Software ist die Erklärung, dass ein Produkt die einschlägigen EU-Anforderungen erfüllt. Wichtig: Nicht jede Software bekommt automatisch eine CE-Kennzeichnung. Relevant wird die Frage dort, wo tatsächlich ein CRA-pflichtiges Produkt mit digitalen Elementen auf den Markt gebracht wird.

Laut EUR-Lex kann bei Software die CE-Kennzeichnung über die EU-Konformitätserklärung oder die begleitende Website erfolgen. Für Gründer:innen bedeutet das praktisch: Erst Anwendungsbereich und Rolle klären, dann prüfen welcher Konformitätspfad einschlägig ist, und erst danach die CE-Frage konkret planen. Keine pauschale Aussage ist hier richtig: Nicht jede App und nicht jede CRA SaaS muss zwingend CE-gekennzeichnet werden.

Selbstbewertung oder Drittprüfung? So schätzt ihr den Prüfpfad ein

Die EU-Kommission unterscheidet drei Wege. Viele Standardprodukte, etwa mobile Apps oder Computerspiele, können per Selbstbewertung beurteilt werden. Für wichtige Produkte kann je nach Kategorie und Nutzung harmonisierter Normen eine benannte Konformitätsstelle als unabhängige notifizierte Prüfstelle nötig werden. Für kritische Produkte ist eine Drittprüfung verpflichtend.

Pragmatisch übersetzt: Eher Selbstbewertung, wenn das Produkt eine Standardkategorie abdeckt, die Risiken überschaubar sind und Dokumentation sowie Architektur klar sind. Eher Drittprüfung, wenn die Produktkategorie wichtig oder kritisch ist, komplexe Sicherheitsfunktionen vorliegen oder die Einordnung unsicher ist. Der Prüfpfad beeinflusst Budget, Launch-Zeitplan und Ressourcenplanung, also lohnt sich eine frühe Klärung.

Vier Praxisbeispiele, damit die Einordnung greifbar wird

Beispiel 1: B2B-SaaS. Browserbasierte Projektmanagement-Software ohne eigenes Gerät und ohne lokalen Client. Nicht automatisch CRA-pflichtig, aber genau prüfen, ob Produktbestandteile mit eigener digitaler Funktion auf dem Markt bereitgestellt werden. Erster Schritt: Angebot in Produktbestandteile zerlegen und Rolle klären.

Beispiel 2: KI-Tool mit Remote Processing. Desktop-Client oder Plugin sendet Daten an eigene Cloud-Inferenz. Remote-Verarbeitung kann Teil der Produktfunktion sein, CRA-Relevanz für Produktkomponenten wahrscheinlicher. Erster Schritt: Risikobewertung inklusive Datenfernverarbeitung dokumentieren. Passende Lektüre dazu: EU AI Act 2026: Die Compliance-Checkliste für KI-Startups und mit KI gründen.

Beispiel 3: IoT-Device. Sensorgerät mit App und Cloud-Dashboard. Ein klassisch näherliegender CRA-Fall, weil Hardware, Software und Vernetzung zusammenspielen. Erster Schritt: Security-by-Design, Update-Strategie, Support Period und Dependency-Inventar festziehen.

Beispiel 4: White-Label-Software. Software eines Drittanbieters wird unter eigener Marke verkauft. Die Herstellerfrage ist hier sehr relevant, der eigene Markenauftritt kann Verantwortung auslösen. Erster Schritt: vertraglich und operativ klären, wer technische Dokumentation, Updates, Schwachstellenprozess und Meldungen trägt.

Die pragmatische CRA-Checkliste für kleine Teams

  • Produktbestandteile kartieren: App, Backend, Client, Firmware, APIs, Cloud-Funktionen, Hardware
  • Rolle festlegen: Hersteller, Importeur, Distributor oder Mischkonstellation
  • Risikobewertung starten und Annahmen dokumentieren
  • Komponenten-/Dependency-Inventar oder SBOM anlegen
  • Update- und Patch-Prozess definieren
  • Prozess für Vulnerability-Handling festlegen
  • Schwachstellenmeldung ENISA vorbereiten, inklusive Kontaktweg und Eskalationsschema
  • Support Period festlegen und kundenseitig kommunizieren
  • Nutzerinformationen und Security-Hinweise strukturieren
  • Technische Dokumentation zentral ablegen und versionieren
  • Release-Prozess um Security-Gates ergänzen: feste Prüfpunkte vor jedem Release, z. B. Dependency-Scan sauber, kritische Findings bewertet, Authentifizierung getestet, Updatefähigkeit geprüft, Dokumentation aktualisiert

Cyber Resilience Act Software: Was Startups bis 2026 und 2027 konkret vorbereiten sollten

Die BSI TR-03183 ist eine hilfreiche Brücke zwischen Gesetz und Umsetzung: Teil 1 deckt allgemeine Anforderungen ab, Teil 2 SBOM, Teil 3 Vulnerability Reports and Notifications. Damit lässt sich für kleine Teams konkret ableiten, was als nächstes ansteht.

Ein 30-Tage-Plan für CRA Startups

Der Einstieg muss kein Konzernprojekt sein. Für CRA Startups gilt: Lieber jetzt mit kleinen, sinnvollen Schritten starten als 2027 hektisch alles auf einmal nachholen.

In den ersten 30 Tagen solltet ihr alle Produktkomponenten und Drittabhängigkeiten inventarisieren, eure Rolle im CRA grob bestimmen, eine Owner-Person benennen, eine erste Risikoliste erstellen, einen Security-Kontakt und Schwachstellenkanal einrichten, das Release-Template um einen einfachen Security-Check ergänzen und festhalten, welche Support Period für Kernprodukte realistisch ist.

Diese Schritte schaffen die Grundlage für spätere Dokumentation, Konformität und Meldeprozesse. Wer jetzt anfängt, hat 2026 und 2027 deutlich weniger Stress.

In Kürze: In den ersten 30 Tagen sollten Startups ihre Produktbestandteile kartieren, Abhängigkeiten erfassen, die eigene CRA-Rolle grob klären, eine verantwortliche Person benennen, eine erste Risikoliste erstellen, einen Schwachstellenkanal einrichten und den Release-Prozess um einfache Security-Checks ergänzen.

Ein 90-Tage-Plan bis zur belastbaren Grundlage

In den folgenden 90 Tagen geht es um Tiefe. Vervollständigt die Risikobewertung auf Produkt- und Architektur-Ebene, etabliert ein SBOM oder belastbares Dependency-Inventar, nehmt Security-Anforderungen in Roadmap und QA auf, testet Incident- und Meldeabläufe, definiert die Support- und Update-Regelung verbindlich, strukturiert die technische Dokumentation und validiert bei unsicherem Scope oder Prüfpfad frühzeitig fachlich.

Die Kernthese gilt besonders hier: Cybersecurity by Design gehört in Backlog, QA und Release-Prozess, nicht in ein Last-Minute-Dokument kurz vor 2027. Wer KI-gestützte Entwicklung nutzt, z. B. über Ansätze wie Vibe Coding, kann schneller releasen, aber saubere Security- und Dependency-Prozesse ersetzen diese Werkzeuge nicht.

Typische Fehler, die Gründer:innen vermeiden sollten

  • Fehler 1: “Wir kümmern uns kurz vor Launch darum.” Fehlende Dokumentation, fehlende Inventare und ungeklärte Support Period lassen sich nicht in zwei Wochen seriös nachholen.
  • Fehler 2: “Unsere Cloud-Lösung ist sicher außerhalb des CRA.” CRA SaaS kann im Einzelfall über Produktbestandteile und Datenfernverarbeitung relevant werden.
  • Fehler 3: “Open Source übernimmt Security für uns.” Open Source ist nützlich, aber kein Ersatz für eigenes Dependency-Management, Patchen und Risikoanalyse.
  • Fehler 4: “Wir haben Updates, also sind wir compliant.” Updates sind nur ein Baustein. Es geht auch um Risikobewertung, Dokumentation, Meldungen, Nutzerinfos und Verantwortlichkeiten.
  • Fehler 5: “Doku machen wir später.” Technische Dokumentation ist Teil des Nachweises, nicht bloß ein Nebenergebnis.

In Kürze: Häufige Fehler sind: CRA erst kurz vor Launch prüfen, SaaS pauschal als nicht betroffen einstufen, Open Source als vollständige Entlastung verstehen, Updates mit Compliance gleichsetzen oder technische Dokumentation auf später verschieben. Genau diese Punkte können später zu Launch-, Vertriebs- oder Compliance-Problemen führen.

Kurze Abgrenzung zu DSGVO und EU AI Act

Drei Regelwerke, drei Ziele: Der CRA regelt Produktsicherheit und Cybersicherheitsanforderungen für Produkte mit digitalen Elementen. Die DSGVO regelt den Umgang mit personenbezogenen Daten. Der EU AI Act regelt bestimmte Anforderungen an KI-Systeme.

Für KI-Startups können sich Anforderungen überschneiden, etwa bei Governance, Dokumentation und technischem Risikomanagement. Die Regelwerke verfolgen aber unterschiedliche Ziele und erfordern jeweils eigene Umsetzung. Weiterführende Artikel: EU AI Act 2026: Die Compliance-Checkliste für KI-Startups, Datenschutz für Startups, Mit KI gründen und Startup Tools.

Fazit

Für Cyber Resilience Act Software ist 2027 nicht der Startpunkt, sondern die Deadline. Die Arbeit beginnt jetzt, in Produktplanung, Security-Prozessen und Dokumentation.

Drei Takeaways für alle Gründer:innen: Erstens, nicht jede SaaS ist automatisch erfasst, aber Software, IoT und Remote-Funktionen können klar CRA-relevant sein. Zweitens, die Fristen 11.09.2026 für Meldepflichten und 11.12.2027 für Hauptpflichten sind für CRA Startups zentral. Drittens, wer Cybersecurity by Design, Schwachstellenmeldung ENISA, technische Dokumentation und Support Period früh aufsetzt, reduziert spätere Launch- und Compliance-Risiken erheblich.

Pro-Tipp: Startet jetzt damit, eure Produktbestandteile zu kartieren und eine verantwortliche Person zu benennen. Nutzt die 30/90-Tage-Checkliste als Fahrplan. Bei Grenzfällen oder Fragen zur CE-Kennzeichnung Software lohnt sich eine frühe fachliche Validierung durch spezialisierte Rechts- und Technikexpert:innen.

Newsletter abonnieren

Verwandte ArtikelMehr vom Autor