Cyber Resilience Act Software
2.6.2026
Cyber Resilience Act Software bringt für Startups ab sofort neue Spielregeln, auch wenn die zentralen Pflichten erst 2026 und 2027 greifen. Die EU-Verordnung verpflichtet dich als Gründer:in, Cybersicherheit fest in Entwicklung, Betrieb und Updates von Software oder vernetzten Produkten zu verankern.
Hier erfährst du, wie du dein Startup mit Augenmaß, Praxisnähe und ohne Panik fit für den CRA machst – und warum vorausschauendes Handeln gerade für kleine Teams jetzt entscheidend ist, um keine teuren Fehler beim Markteintritt zu begehen.
Was der Cyber Resilience Act für dich als Gründer:in wirklich bedeutet
Der CRA ist keine freiwillige Empfehlung, sondern wird verbindliches EU-Recht für jedes Produkt mit digitalen Elementen – unabhängig davon, ob du Software, Hardware, App, Firmware, Agent, SaaS-Angebote oder IoT-Geräte entwickelst. Spätestens mit dem Markteintritt gilt: Security und Compliance werden mit dem Cyber Resilience Act Software zum Grundbaustein. Viele Gründer:innen unterschätzen, wie sehr fehlende Produktdokumentation, schwache Meldeprozesse oder unklare Herstellerrollen zum Stolperstein für Kundenakquise, Vertrieb oder späteres Wachstum werden können.
Der Begriff „Produkt mit digitalen Elementen“ – was darunter konkret fällt
Hinter der sperrigen Bezeichnung verbirgt sich mehr als du denkst. Es geht um alle Lösungen, bei denen eine digitale Komponente, Software oder Firmware maßgeblich zur Produktfunktion beiträgt. Das umfasst nicht nur den klassischen IoT-Tracker oder die App mit Cloud-Backend, sondern auch reine Enterprise-Software, KI-Tools mit Cloud-Anbindung und sogar White-Label-Lösungen, die du unter deiner Marke vertreibst. Auch Produkte, deren Funktion auf Datenfernverarbeitung basiert, sind betroffen. Cloud bedeutet nicht automatisch „draussen“, sobald das Remote Processing Teil der Funktionalität ist.
Ein häufiges Missverständnis: Wer Open Source einsetzt oder nur B2B-Software betreibt, wähnt sich oft außerhalb der Pflicht. Das ist nicht grundsätzlich richtig. Sobald du Komponenten kommerziell vertreibst, dich als Hersteller positionierst oder Software an Hardware bindest, läufst du schnell ins CRA-Regime.
Gilt der Cyber Resilience Act für reine SaaS-Angebote?
Nicht jedes SaaS-Startup landet automatisch im Fokus des CRA. Entscheidender ist, welche Bestandteile deines Angebots digital bereitgestellt und vermarktet werden. Nutzt dein Produkt beispielsweise zusätzlich einen Client, ein Embedded-Device, eine lokale Software-Komponente oder bedient sich einer Firmware, dann rutscht es fast immer in den Scope. Dagegen bleibt ein rein browserbasiertes, nicht ausgeliefertes Tool möglicherweise außen vor. Du solltest kritisch prüfen, wo überall aus deiner Wertschöpfung ein „Produkt mit digitalen Elementen“ entstehen könnte. Diese Unterscheidung ist die wichtigste Weiche für die weitere Vorbereitung.
Rolle klären – Hersteller, Importeur, Distributor: Wer ist wofür verantwortlich?
Der CRA unterscheidet strikt zwischen Hersteller, Importeur und Distributor. Entscheidest du über Branding, Funktionsumfang und bringst das Produkt unter eigenem Namen in den Markt, bist du rechtlich Hersteller – auch wenn du die Entwicklung auslagerst oder Open-Source-Elemente einbaust. Holst du Hardware aus Drittstaaten herein, kann deine Startup-Rolle zudem noch die eines Importeurs oder Distributors werden, jeweils mit eigenen Compliance-Aufgaben.
Achtung: Wer etwa eine Software unter eigenem Branding als White-Label-Lösung weitervermarktet, kann nicht einfach Verantwortung auf andere schieben. Für Startups heißt das: Kläre interne Verantwortlichkeiten, Lieferantenverträge und Dokumentationspflichten von Anfang an. Sonst drohen Lücken, die dich zum Launch aufhalten oder im Fall einer Sicherheitslücke für lange Zeit blockieren können.
Diese Deadlines musst du im Blick haben
Der Cyber Resilience Act ist unterteilt in mehrere Stufen. Aktuell läuft schon die Vor-Phase zur Planung – sie erfasst alle, die mit Software-Markteintritt ab Ende 2027 rechnen. Bereits Mitte 2026 starten die Vorbereitungen der Konformitätsbewertungsstellen. Ab September 2026 kommen erstmals technische Berichtspflichten und Schwachstellenmeldungen auf dich zu. Ab Dezember 2027 wird der gesamte Pflichtenkatalog verbindlich umgesetzt. Für Produkte, die vor diesem Stichtag in Verkehr gebracht wurden, gelten Übergangsregeln – aber viele Meldepflichten ziehen schon vorher.
Das sind deine wichtigsten Pflichten als Startup bis 2027
Der Kern der Umsetzung besteht aus Elementen, die du nicht auf die lange Bank schieben solltest. Denn alles, was jetzt nach und nach aufgebaut wird, reduziert das Risiko teurer Compliance-Baustellen später.
Risikobewertung vorbereiten
Als Hersteller bist du verpflichtet, eine nachvollziehbare Risikobewertung für dein Produkt inklusive aller Datenfernverarbeitungen zu dokumentieren. Identifiziere, welche Angriffsflächen deine Architektur bietet, welche Nutzergruppen und Szenarien zu Schäden oder Datenverlust führen könnten und welche technischen sowie organisatorischen Schutzmaßnahmen dagegen wirken. Notiere alle Annahmen strukturiert und aktualisiere sie regelmäßig.
Cybersecurity by Design und Default
Stelle von Anfang an sicher, dass Security nicht erst zum Schluss geprüft wird, sondern bereits in der Architektur, den Release- und Update-Prozessen sowie in der Standardkonfiguration gelebt wird. Dazu gehören Role-basierte Zugangskontrollen, secrets Management, konsequentes Logging sensibler Aktionen, plausible kryptographische Standards und eine strategisch geplante Update-Fähigkeit deiner Produkte.
Komponenten und Abhängigkeiten im Griff behalten
Du musst zu jeder Zeit Auskunft geben können, welche Open-Source-Bestandteile, Libraries, Container, eigens entwickelte oder eingebettete Module in deinem Produkt sind. Der sogenannte Software Bill of Materials (SBOM) ist kein Selbstzweck: Im Ernstfall entscheidest du mit einem sauberen Dependency-Inventar, wie schnell Schwachstellen behoben und Schwachstellenberichte erstellt werden können. Das spart im Incident echte Zeit und Reputation.
Vulnerability Management und Meldewege üben
Die Pflicht zur Schwachstellenmeldung an ENISA und nationale Computer Emergency Response Teams verlangt abgestimmte interne Prozesse – und zwar spätestens ab September 2026. Versäumnisse werden nicht als Startup-typische Eskapaden akzeptiert. Lege Verantwortlichkeiten fest, bestimme eine zentrale Kontaktadresse für Security-Incidents und definiere Fristen für die Bearbeitung und Kommunikation nach außen. Orientiere dich am eigenen Risiko und der Komplexität deines Produkts, aber triff Vorbereitungen für einen 24h-72h-Meldeprozess.
Support- und Update-Pflicht langfristig planen
Ein neuralgischer Punkt ist die Supportperiod: Für wie lange bietest du Sicherheitsupdates und Fehlerbehebungen an? Mindestens fünf Jahre nach Markteintritt sind der Default, sofern die Lebensdauer nicht plausibel kürzer ist. Das muss nicht nur technisch machbar sein, sondern wird auch kommuniziert und im Pricing bedacht. Überlege früh, welche Updatekanäle und End-of-Life-Prozesse in dein Geschäftsmodell passen.
Nutzerinformation, Dokumentation und Ownership früh strukturieren
Technische Dokumentation ist ab sofort kein „späteres To-do“ mehr. Sie wird zum Nachweis, wie du technische und organisatorische Maßnahmen realisiert hast, wie nutzerseitige Sicherheit gewährt ist und wie Updates, Einschränkungen und Schwachstellen-Meldekanäle funktionieren. Benenne einen Owner für CRA-Themen, unabhängig von der Teamgröße. Das hilft, bei Wachstum oder Pitch-Invests jederzeit lückenlos Compliance belegen zu können.
Wann eine CE-Kennzeichnung für deine Software notwendig wird
Die CE-Kennzeichnung ist künftig auch für CRA-pflichtige Produkte mit digitalen Elementen relevant. Sie ist kein pauschaler Aufkleber, sondern eine förmliche Erklärung, dass dein Produkt die Sicherheitsanforderungen erfüllt. Ob du selbst bewertest oder eine benannte Stelle hinzuziehst, hängt von Risiko, Produktkategorie und kritischer Funktion ab. Wichtig: Die CE-Frage klärst du erst, nachdem du den CRA-Scope für dein Produkt und deine Rolle sauber abgesteckt hast. Software, die ohne physische Auslieferung betrieben wird, benötigt teils eine Online-CE-Deklaration – prüfe das frühzeitig und adressiere Unsicherheiten gezielt.
Selbstbewertung oder externe Prüfung – wie du dein Vorgehen realistisch einschätzt
Die allermeisten Standardsoftwareprodukte können in einem internen Selbstbewertungsprozess – also durch Dokumentation und gezielte Prüfung gegen CRA-Anforderungen – in Verkehr gebracht werden. Wird dein Produkt jedoch als kritisch eingestuft (etwa bei Sicherheitssoftware, Systemlösungen im kritischen Infrastrukturbereich oder speziellen KI-Anwendungen), prüfe rechtzeitig, ob externe begutachtende Stellen eingebunden werden müssen. Kalkuliere diese Option in deinen Zeitplan und dein Budget ein, damit ein geplanter Release nicht an einer unerwischt gebliebenen Formalität scheitert.
Praxisbeispiele: So wird die CRA-Relevanz für Startups greifbar
Stell dir ein B2B-SaaS-Startup vor, das ausschließlich Browserlösungen ohne ausgelieferten Client betreibt – hier muss dein Scope kritisch geprüft werden, bist du wirklich ausserhalb des CRA? Entwickelst du ein KI-Tool, das lokal Daten erhebt und zur Remote-Verarbeitung an einen Cloud-Service übergibt, ist die CRA-Relevanz direkt präsent. Ein IoT-Startup mit Sensorik, App und Cloud-Dashboard fällt klar hinein. Betreibst du White-Label-Software unter deinem Namen, ist die Herstellerfrage nüchtern zu klären: Wer trägt die Updates, technische Dokumentation und die Verantwortung für Meldungen? Je nach Modell variiert hier das Maß an selbst zu tragender Compliance-Pflicht.
Dein Fahrplan: Die ersten 30 Tage, um den Grundstein für die CRA-Compliance zu legen
Du willst nicht abwarten, bis es zu spät ist. Deshalb solltest du in den ersten 30 Tagen sämtliche Produktbestandteile und Drittabhängigkeiten erfassen, eine erste Risikoabschätzung festhalten, die eigene Herstellerrolle klären und einen klar Verantwortlichen für Security und CRA bestimmen. Lege einen Security-Kontakt an, ergänze dein Release-Template konsequent um einfach prüfbare Security-Checks und bestimme schon jetzt die realistisch zu stemmende Supportperiod. Diese Schritte bilden das Fundament, damit die weiteren Compliance-Elemente nicht auf unsicherem Boden stehen.
Die 90-Tage-Agenda: Von der Basis zum belastbaren CRA-Niveau
Mit den Basics in der Hand kannst du im nächsten Schritt gezielt nachschärfen. Die Risikobewertung wird zum strategischen Steuerwerkzeug – komplettiere und versioniere sie, entwickle mit deinem Team oder durch Vendor-Support ein überzeugendes SBOM, vereinfache Incident-Meldewege (z.B. mit zentral konfigurierten Security-Mails) und prüfe alle technischen Release-Gates. Definiere Update- und Supportregeln verbindlich, dokumentiere alles zentral und prüfe gegebenenfalls frühzeitig, ob du dich in einer CE-Pflicht-Kategorie bewegst.
Typische Fehler bei der CRA-Umsetzung von Startups
Viel zu oft werden Security und Compliance schlicht aufgeschoben: „Wir kümmern uns kurz vor Launch“, „Cloud ist sowieso sicher, betrifft uns nicht“, „Open Source regelt das schon“ oder „Dokumentation reicht auch später“. Diese Denkfehler führen in der Praxis immer wieder zu unnötigen Verzögerungen, Abmahnungen, Vertriebsstopps oder Imageschäden. Die Realität: Dokumentation und SBOM kann niemand in zwei Wochen nachholen, Schwachstellenmanagement braucht Praxis – und Updates sind nur die halbe Lösung. Vermeide das, indem du Security und Compliance von Anfang an als integralen Bestandteil deiner Product Ops verstehst.
Abgrenzung zu DSGVO und EU AI Act – was du parallel wissen musst
Der Unterschied ist wichtig: DSGVO behandelt den Datenschutz, der CRA die Produkt- und Softwaresicherheit, und der AI Act betrifft spezielle Anforderungen an den Umgang mit KI. Die Überschneidung bei Methoden, Dokumentation und Risikoanalyse liegt bei Hybridprodukten nahe, aber jedes Regelwerk verfolgt eigene Ziele und verlangt eigene Dokumente sowie Prozesse. Prüfe daher systematisch: Wann muss ich DSGVO-Prozesse aufbauen? Wann AI-Governance etablieren? Und wie bringe ich alles unter einen Hut?
Fazit: Jetzt starten, um 2027 fest und flexibel aufgestellt zu sein
Für dich als Gründer:in bringt der Cyber Resilience Act Software eine Verschiebung der Prioritäten. Cybersecurity, Compliance und verständliche Dokumentation gehören ab sofort in das Gesamtbild deiner Produktentwicklung. Nicht jedes SaaS ist automatisch betroffen – aber ohne saubere Analyse droht später Stress. Wer heute schon in ersten 30 und 90 Tagen die wichtigsten Protokolle für Risiko, Update, Dokumentation und Incident Handling etabliert, minimiert sein Risiko signifikant. Die zentrale Lektion: Verstehe Compliance als agile Produktdisziplin, nicht als lästigen Verwaltungsakt.
16.7.2021