Cyber Resilience Act Software
Cyber Resilience Act Software betrifft nicht mehr nur große Hersteller oder Hardware-Produzenten, sondern explizit auch kleine Startups, SaaS-Anbieter und Entwickler von Software, Tools, Clients, Apps oder vernetzten Lösungen.
Die Umstellung auf die neuen Vorschriften startet schon jetzt: Nicht nur Security, sondern auch Produktdokumentation, klare Verantwortlichkeiten und organisierte Meldewege werden für den Marktzugang in der EU ab 2026 und 2027 zwingend. Die Zeit für hektische Compliance-Lösungen kurz vor dem Launch ist vorbei.
29.5.2026
Was hinter dem Cyber Resilience Act wirklich steckt
Du wirst als Gründer:in schnell mit dem Begriff konfrontiert: Cyber Resilience Act (CRA) ist eine EU-Verordnung, die Cybersicherheitsanforderungen erstmals verpflichtend und produktübergreifend für sog. „Produkte mit digitalen Elementen“ festlegt. Das umfasst Hardware, Software, Firmware, Embedded Solutions, Apps, cloudvernetzte Angebote, aber auch reine B2B-Software-Komponenten. Wenn du ein Produkt unter eigener Marke auf dem EU-Markt bereitstellst – egal ob als App, Client, SaaS mit Hardwarekomponente oder White-Label-Lösung – können CRA-Pflichten greifen.
Die Anforderungen surpassen die rein technische Sicherheit: Security by Design, Produktidentifikation (SBOM/Dependency-Inventar), Updatefähigkeit über die Support-Periode, dokumentierte Release-Prozesse, verständliche Nutzerinfos sowie festgelegte Melde- und Supportwege sind gefragt. De facto entstehen neue Mindeststandards und Markteintrittsbarrieren, die du als Startup frühzeitig adressieren solltest.
Wann bist du betroffen? Kriterien für Software-Startups und SaaS
Vielfach herrscht die Annahme vor, der CRA gelte „nur für Hardware“ oder „nur bei IoT“. Das ist falsch. Auch rein digitale Produkte wie SaaS, Apps oder Embedded Solutions können betroffen sein, insbesondere wenn folgende Dinge zutreffen:
Du entwickelst oder vertreibst eine Software, App, Client- oder Backend-Lösung unter deiner Marke. Dein Produkt steuert vernetzte Geräte an, verarbeitet Kernfunktionen über entfernte Server oder Edge-Komponenten und wird am Markt kommerzialisiert.
Open-Source-Komponenten entlasten dich nur dann, wenn du keine kommerzielle Bereitstellung vornimmst und kein Produkt im eigentlichen Sinn auf EU-Märkten vertreibst. Die Herstellerrolle entsteht meist bereits, wenn du die Software gebrandet oder als Essential für ein Angebotsportfolio platzierst.
Was ist mit reinen Cloud-Tools oder SaaS-Angeboten? Auch hier ist die Gleichung nicht trivial. Sobald dein Angebot über eine eigenständige App, Client, Firmware, Edge- oder Hardwareanbindung verfügt, bist du im Mittelpunkt der CRA-Regelungen. Aber auch SaaS, die einen essentiellen Remote-Verarbeitungsteil bieten, können je nach Produktstruktur erfasst werden. Prüfe stets, welche Komponenten als „Produkt mit digitalen Elementen“ im Sinne der EU-Verordnung gelten.
Welche Rollen musst du verstehen und wie wirken sie sich auf dein Startup aus?
Der CRA differenziert zwischen Hersteller, Importeur und Distributor. Für dich als Startup ist meist die Herstellerrolle relevant, selbst wenn du Entwicklungsteile outgesourct oder White-Label-Lösungen übernommen hast.
Bringst du ein Produkt unter deiner Marke in Verkehr (selbst, wenn du auf Basis externer Technik arbeitest), bist du mit den Herstellerpflichten konfrontiert: Du bist für Risikobewertung, technische Dokumentation, Updates, Schwachstellenmeldungen und Nutzerschutzmaßnahmen verantwortlich.
Beziehst du als Importeur Lösungen außerhalb der EU und vertreibst sie dann unter deiner Marke, kommen weitere Pflichten hinzu. In beiden Fällen entstehen operative Herausforderungen, die du keinesfalls erst kurz vor 2027 improvisieren solltest.
Diese Fristen sind für alle Gründer:innen relevant
Du musst dich auf vier entscheidende Zeitpunkte einstellen:
Ab 10. Dezember 2024 ist der CRA rechtlich wirksam. Plane daher alle Produktentwicklungen und Governance-Prozesse bereits jetzt unter Compliance-Gesichtspunkten.
Am 11. Juni 2026 gelten neue Regeln zu externen Prüfstellen und Zertifizierungen. Planst du kritische Produkte, solltest du rechtzeitig Kapazitäten sichern.
Ab 11. September 2026 tritt die Meldepflicht für Schwachstellen in Kraft. Damit sind Frühwarnungen und strukturierte Reaktionsprozesse kein optionales Thema mehr.
Zwischen 11. Dezember 2027 und darüber hinaus muss dein Produkt alle relevanten Hauptpflichten (Sicherheitsanforderungen, Support, technische Doku, Meldewege) erfüllen.
Was geht jetzt schon? Dein Startup-Setup in Sachen Compliance, Security und Doku
Ab jetzt ist die richtige Zeit, das Fundament zu legen. Typische Schwerpunkte lauten:
Du erstellst eine dokumentierte Risikobewertung, die deine Produktfunktion, Angriffsflächen, Nutzerprofile, Drittmodule und potentielle Schwachstellen sichtbar macht.
Cybersecurity by Design muss fester Bestandteil deiner Produktarchitektur, Entwicklung, Standardkonfiguration und Update-Strategie sein: Zugriffskonzepte, sichere Defaults, Patch- und Release-Feinsteuerung, transparenter Umgang mit Third-Party Dependencies.
Ein vollständiges Dependency-Inventar liefert dir Übersicht darüber, welche Bibliotheken, Open-Source-Komponenten, Images, SDKs oder Firmware-Bausteine du verwendest – die Basis für schnelle Schwachstellenkommunikation und risikobasiertes Patchen.
Beim Vulnerability-Management brauchst du einen definierten Kontaktpunkt und Eskalationsweg (z.B. zentrale Mailbox, Severity-Schema, Deadlines für Bearbeitung).
Der gesamte Release-Prozess erhält einen Security-Gate, d.h. jede Freigabe ist von dokumentierten Checks, Patch-Status und aktuellem Doku-Stand abhängig.
Die technische Dokumentation wächst mit: Sie erklärt, wie Produkt, Release- und Security-Prozesse organisiert sind, welche Schwachstellen existieren könnten und wie Updates gewährleistet werden.
Schließlich wird die Support-Periode für Sicherheitsupdates schon beim Design definiert und den Nutzer:innen transparent kommuniziert.
Support Period, Meldeprozess und technische Dokumentation: Warum du diese Anforderungen nicht verschieben darfst
Die Supportperiode dauert in der Regel mindestens fünf Jahre – es sei denn, die erwartete Produktnutzungsdauer ist nachweislich kürzer. Während dieses Zeitraums musst du Security Updates und Patches bereitstellen und erreichbare Meldekanäle für Kundenfragen und Schwachstellen öffentlicher machen.
Für Schwachstellenmeldungen, die ab September 2026 verpflichtend werden, brauchst du Schnittstellen zu den europäischen Plattformen (ENISA, CSIRT). Das setzt standardisierte Abläufe voraus: Frühwarnungen innerhalb von 24 Stunden, tiefergehende Info in maximal 72 Stunden, Abschlussbericht innerhalb weniger Wochen.
Die technische Dokumentation ist kein Nebenprodukt mehr, sondern Nachweis deiner Compliance. Sie sollte pro Produktbestandteil der Entwicklung, Konformitätsbewertungen, Release- und Support-Prozesse sauber rekonstruieren können.
CE-Kennzeichnung für Software: Wann ist sie Pflicht?
Du fragst dich, ob jede Software nun ein CE-Zeichen braucht? Nicht zwingend. Die CE-Kennzeichnung ist dort gefragt, wo tatsächlich ein „Produkt mit digitalen Elementen“ im Sinne des CRA an den Markt gebracht wird. Oft genügt bei reiner Software oder Apps die Konformitätserklärung auf der Produktwebsite.
Bedenke: Es gibt weder Automatismen noch Ausnahmen für Startups. Erst wenn du Anwendungsbereich, Rolle und Pflichtenkatalog sauber bewertet hast, ergibt sich, ob und wie die CE-Kennung zum Einsatz kommt.
Selbstbewertung oder Drittprüfung? Der Prüfpfad ist keine Formalie
Die EU macht hier einen klaren Unterschied: Standardprodukte (wie viele Apps, Nicht-Kritische Software) können sich als Firma selbst bewerten, sofern die Risiken überschaubar sind.
Zeichnet sich dein Produkt durch hohe sicherheitskritische Funktion, komplexe Vernetzung, KI-Elemente oder besondere Branchenrelevanz aus, brauchst du rechtzeitig Kontakt zu Notified Bodies und planst für die externe Begutachtung zusätzliche Zeiträume und Kosten ein.
Was heißt das operativ für dich? Der Prüfpfad sollte immer am Anfang der Go-to-Market Planung definiert sein, denn eine späte Kategorisierung kann Markteintritt und Vertriebsstart empfindlich verzögern.
Praxisnah: Anwendungsbeispiele für typische Startup-Produkte
Wenn du beispielsweise eine browserbasierte SaaS-Lösung ohne lokale Komponenten entwickelst, bist du nicht automatisch betroffen – aber prüfe, was du als Produktbestandteil tatsächlich auf dem Markt bereitstellst.
Ein KI-Plugin mit Remote-Data-Processing und Desktop-Clients rückt dich sofort in den CRA-Fokus – hier sind Risikobewertung und technische Doku inklusive Remote-Verarbeitung entscheidend für die Compliance.
Betreibst du ein IoT-Device samt App-Anbindung und Cloud-Backend, fallen fast alle relevanten CRA-Pflichten an: von SBOM über Vulnerability-Handling und regelmäßige Updates bis zu klarer Herstellerverantwortung.
Im White-Label-Geschäft ist rasch zu klären, ob du als Marke auftrittst und Updates, Dokumentation und Schwachstellenhandling in deiner Hand liegen.
30-/90-Tage-Plan: So startest du im Startup mit dem CRA-Fundament
Die wichtigsten Maßnahmen orientieren sich an zwei Etappen.
In den ersten 30 Tagen solltest du alle Produktbestandteile, Komponenten und Third-Party-Dependencies erfassen, deine voraussichtliche CRA-Rolle grob bestimmen, eine/n Owner:in benennen, einen Security/Compliance-Kanal aufsetzen und ein Release-Template mit einfachen Security-Checks verankern. Das Ziel: Du legst den Grundstein für weitere Maßnahmen und bist handlungsfähig, solltest du bereits jetzt Anforderungen erfüllen müssen.
In den nachfolgenden 90 Tagen erfolgt die Vertiefung: Ergänze die Risikobewertung, etabliere eine belastbare Inventarisierung (SBOM), sichere die Update-Fähigkeit, füge Security-Anforderungen zur Roadmap/QS und bereite dich auch auf Testläufe des Meldeprozesses vor. Die Support-Perioden werden im Produktboard dokumentiert und die technische Doku ist bereits so aufgestellt, dass sie im Fall eines Audits konsistent abgerufen werden kann.
Welche Fehler du als Gründer:in unbedingt vermeiden solltest
Der meistverbreitete Fehler ist der Glaube, dass sich Security und Compliance als Last-Minute-Aufgabe vor dem Launch nachholen lassen. Das ist nicht der Fall: Weder die technische Dokumentation noch die Support-Period oder das Dependency-Inventar lassen sich realistisch in Tagen oder Wochen lückenlos nachholen.
Ein weiterer Irrtum: Dass Cloud-Produkte generell außen vor sind. Das stimmt nicht, sobald Bestandteile oder Datenverarbeitung im Sinne des CRA relevant werden. Auch Open Source ist kein Ventil, um Pflicht und Verantwortung vollständig zu umgehen.
Updates und Patches alleine reichen nicht – sie sind Teil eines größeren Compliance-Puzzles. Wer Doku, Risikobewertung oder Meldestrukturen aufschiebt, riskiert einen bitteren Launch- oder Vertriebsstopp durch fehlende Nachweise.
Abgrenzung zu DSGVO und AI Act: Wo du unterscheiden musst
Während sich der CRA auf Produktsicherheit und Cybersecurity konzentriert, adressiert die DSGVO ausschließlich Anforderungen an den Umgang mit personenbezogenen Daten. Der EU AI Act reguliert hingegen dezidiert KI-Systeme und deren Governance, mit teilweise überschneidenden, aber eigenständigen Compliance-Anforderungen.
Für Startups, die in mehreren Bereichen aktiv sind – etwa im KI-SaaS-Umfeld – kann es zu Überschneidungen kommen, zum Beispiel bei Doku oder Risikomanagement. Dennoch solltest du die Pflichten nie miteinander vermischen, sondern pro Regime gezielt umsetzen.
Fazit: 2027 ist nicht der Start, sondern die Ziellinie
Wenn du mit Cyber Resilience Act Software planst, ist ein früher Einstieg entscheidend. Ab 2027 müssen alle Strukturen stehen: Risikobewertung, technische Dokumentation, Schwachstellenprozesse und Support-Perioden.
Gerade als Startup hast du jetzt die Chance, Prozesse von Anfang an effizient und skalierbar zu gestalten, statt später hohe Nachbesserungskosten und Launch-Risiken einzugehen.
Drei Leitplanken solltest du mitnehmen: Nicht jede SaaS ist betroffen, jedoch solltest du Produktbestandteile und Herstellerrolle frühzeitig beurteilen. Die Stichtage 11.09.2026 für Meldungen und 11.12.2027 für Hauptpflichten sind deine Deadline. Und: Wer Security by Design, Meldeprozesse und Doku von vornherein mitdenkt, verschafft sich Marktvorteile und schützt das Vertrauen der Kunden bei deinem Markteintritt.
