CRA für Startups: schlanke Compliance mit einer Person

Sie bringen mit einem kleinen Team ein vernetztes Produkt auf den Markt, und der CRA erfasst es. Die Hauptpflichten gelten ab dem 11. Dezember 2027, die Meldepflicht für Schwachstellen bereits ab dem 11. September 2026. Das ist ein Thema für jetzt, nicht für später. Zwei Punkte werden für Startups schnell zur Falle: die mehrjährige Support-Pflicht, die in dem Moment beginnt, in dem Sie das Produkt auf dem EU-Markt bereitstellen, und die Tatsache, dass Sie das alles ohne dedizierte Sicherheitsstelle stemmen müssen.

Dieser Leitfaden richtet sich an Gründer und frühe Entwickler, die CRA-konform werden müssen, ohne zu viel Geld oder Aufwand zu investieren. Er zeigt, was Sie gefahrlos auslassen können, was nicht, und wie eine einzige Person die Verantwortung tragen kann.

Gilt der CRA überhaupt für Ihr Startup?

Vier schnelle Prüfungen genügen. Der CRA erfasst Produkte mit digitalen Elementen, die sich mit einem Netzwerk oder einem anderen Gerät verbinden und im Rahmen einer gewerblichen Tätigkeit auf dem EU-Markt bereitgestellt werden.

Fällt Ihr Produkt in den Geltungsbereich, entscheidet als Nächstes die Kategorie, in die es fällt, ob Sie sich selbst bewerten oder eine notifizierte Stelle brauchen. Klären Sie das mit dem Leitfaden zur Produktklassifizierung, bevor Sie auch nur einen Tag in etwas anderes investieren.

Ihr struktureller Vorteil: die Selbstbewertung

Der größte Kostenvorteil für ein Startup: Ein Produkt außerhalb der Kategorien Wichtig und Kritisch gilt als Default-Produkt. Dafür lässt der CRA eine Selbstbewertung zu. Sie erledigen die Konformitätsarbeit selbst, unterzeichnen die EU-Konformitätserklärung und bringen die CE-Kennzeichnung an. Keine externe Stelle, keine Gebühr pro Produkt. Die Mechanik der einzelnen Wege steht im Leitfaden zur Konformitätsbewertung. Der Punkt für Startups: Zahlen Sie nicht für eine Drittbewertung, die Sie nicht brauchen.

Die Erleichterungen, die der CRA für Startups vorsieht

Der CRA enthält Unterstützungsmaßnahmen, die gezielt für Kleinstunternehmen, kleine und mittlere Unternehmen sowie Startups formuliert sind. Ob die Erleichterungen greifen, hängt von Ihrer Größe ab, nach der üblichen EU-Definition: Ein Kleinstunternehmen hat weniger als 10 Beschäftigte und einen Jahresumsatz oder eine Bilanzsumme von höchstens 2 Mio. EUR, ein kleines Unternehmen weniger als 50 Beschäftigte und höchstens 10 Mio. EUR.

Vier Erleichterungen, die ein Startup tatsächlich nutzen kann:

• Vereinfachte Dokumentation: Kleinstunternehmen und kleine Unternehmen dürfen die technische Dokumentation in einem vereinfachten Format einreichen, das die Kommission festlegt, und notifizierte Stellen müssen dieses Format akzeptieren.
• Reduzierte Konformitätsgebühren: Braucht Ihr Produkt eine notifizierte Stelle, müssen die besonderen Bedürfnisse von KMU, einschließlich Startups, berücksichtigt und die Gebühren verhältnismäßig reduziert werden.
• Regulatorische Reallabore: Mitgliedstaaten können kontrollierte Umgebungen einrichten, in denen Sie ein innovatives Produkt gegen den CRA entwickeln und testen, bevor Sie es auf den Markt bringen, mit erleichtertem Zugang für Startups.
• Direkte Unterstützung: Wo angemessen, bieten Mitgliedstaaten Sensibilisierungs- und Schulungsangebote sowie eine eigene Beratungsstelle für kleinere Unternehmen, und die Kommission weist auf verfügbare Finanzierungshilfen hin.

Compliance mit einer einzigen Person

Sie brauchen kein Sicherheitsteam. Sie brauchen eine verantwortliche Person und eine kurze Liste an Dingen, die automatisch laufen. Diese Person pflegt die technische Dokumentation, triagiert eingehende Schwachstellenmeldungen und unterzeichnet die Konformitätserklärung. Eine Person kann diese Rolle übernehmen, aber seien Sie ehrlich: Die laufende Schwachstellenbearbeitung, die Update-Bereitstellung und die Dokumentation sind echte Engineering-Arbeit. Der Leitfaden zu CRA-Compliance-Kosten bildet Aufwand und Budget für ein kleines Team ab, damit Sie den Personalbedarf realistisch planen können.

Drei Dinge lohnt es, zuerst zu automatisieren. Jedes davon ist mit kostenlosen Tools ein gelöstes Problem, und zusammen decken sie Ihre sichtbarsten frühen Pflichten ab. Sie sind ein Ausgangspunkt, nicht das gesamte Bild.

• SBOM in der CI generieren: Der CRA verlangt eine Software-Stückliste (SBOM), die mindestens Ihre direkten Abhängigkeiten abdeckt, und Open-Source-Tools wie Syft und Trivy erzeugen bei jedem Build eine. Der vollständige Werkzeugkasten steht im SBOM-Generierungsleitfaden.
• Auf Schwachstellen überwachen: Scannen Sie Ihre Abhängigkeiten bei jedem Build und handeln Sie risikobasiert, bevor Funde Kunden erreichen. Dem CRA geht es darum, dass Sie triagieren und beheben, nicht darum, welchen Scanner Sie einsetzen.
• Sicherheitskontakt veröffentlichen: Eine security.txt-Datei und eine funktionierende Sicherheits-E-Mail-Adresse geben Forschenden einen Weg, Funde zu melden. Der security.txt-Leitfaden enthält eine fertige Vorlage.

Diese drei sind frühe Automatisierungserfolge, nicht die ganze Aufgabe. Sicheres Design, Risikobewertung, Update-Bereitstellung und die Produktkontrollen kommen dazu. Ihre technische Dokumentation wächst am besten mit dem Produkt mit, statt kurz vor dem Launch zusammengeschustert zu werden. Führen Sie Architektur- und Sicherheitsnotizen also laufend. Die geforderten Inhalte stehen im Leitfaden zur technischen Dokumentation.

Ihr Prozess für die Schwachstellenbehandlung muss stehen, bevor die Meldepflichten am 11. September 2026 beginnen. Ab diesem Datum löst eine aktiv ausgenutzte Schwachstelle oder ein schwerwiegender Sicherheitsvorfall über die ENISA-Meldeplattform eine enge Frist aus: eine Frühwarnung innerhalb von 24 Stunden, dann eine ausführlichere Meldung innerhalb von 72 Stunden. Der Abschlussbericht unterscheidet sich je nach Fall. Bei einer aktiv ausgenutzten Schwachstelle ist er innerhalb von 14 Tagen fällig, nachdem eine Korrektur- oder Minderungsmaßnahme verfügbar ist. Bei einem schwerwiegenden Sicherheitsvorfall ist er innerhalb eines Monats nach der 72-Stunden-Meldung fällig. Zusätzlich müssen Sie betroffene Nutzer informieren. Die Mechanik steht im Leitfaden zur Schwachstellenmeldung.

Schnell shippen, ohne bei jedem Release neu zu zertifizieren

Schnell iterieren heißt nicht, bei jedem Sprint die Konformitätsbewertung neu durchzuführen. Sie prüfen die Konformität nur nach einer wesentlichen Veränderung neu, also einer Änderung nach dem Launch, die die Einhaltung der grundlegenden Anforderungen berührt oder den bewerteten Verwendungszweck ändert. Ein Sicherheitsupdate, das nur das Cybersicherheitsrisiko senkt, ohne den Verwendungszweck zu ändern, ist keine wesentliche Veränderung, und eine kleine Änderung wie das Hinzufügen einer UI-Sprache in der Regel auch nicht. Ein Feature-Update, das die Angriffsfläche vergrößert oder ändert, was das Produkt tut, kann eine sein. Routinepatches und kleine Updates gehen also ohne Neubewertung raus, und Sie bewerten neu, wenn eine Änderung tatsächlich verändert, was das Produkt ist, oder sein Risikoprofil.

Wenn Sie auf Open Source aufbauen oder sie pflegen

Zwei Open-Source-Fakten sind für ein Startup relevant. Erstens: Freie und Open-Source-Software fällt nur dann in den Geltungsbereich, wenn sie im Rahmen einer gewerblichen Tätigkeit bereitgestellt wird. Software, die ihre Maintainer nicht monetarisieren, gilt in der Regel nicht als gewerbliche Tätigkeit. Monetarisierung reicht aber weiter als das reine Verkaufen von Code, wägen Sie also auch bezahlten Support und ähnliche Konstruktionen ab. Wenn Sie Quellcode zu einem Projekt beitragen, das nicht in Ihrer Verantwortung liegt, macht Sie das allein nicht CRA-pflichtig. Monetarisieren Sie Open Source oder liefern Sie sie in einem Produkt aus, das Sie verkaufen, fällt dieses Produkt ganz normal in den Geltungsbereich.

Zweitens schafft der CRA eine leichtere Rolle: den Open-Source-Software-Steward, für eine Organisation, die nicht Hersteller ist und die Entwicklung von Open-Source-Software für den kommerziellen Einsatz nachhaltig unterstützt. Die Pflichten eines Stewards drehen sich um eine dokumentierte Cybersicherheits-Richtlinie und die Zusammenarbeit mit den Behörden. Die Meldepflicht für Schwachstellen gilt in dem Umfang, in dem der Steward an der Produktentwicklung beteiligt ist, und die Meldung schwerwiegender Vorfälle sowie die Nutzerbenachrichtigung greifen, wenn ein Vorfall die Systeme betrifft, die der Steward für diese Entwicklung bereitstellt. Diese Pflichten sind leichter als das volle Pflichtenset eines Herstellers. Übernimmt Ihr Startup sowohl die Steward-Rolle als auch den Verkauf eines Produkts, machen Sie sich klar, welchen Hut Sie bei welcher Tätigkeit tragen, denn die Pflichten unterscheiden sich.

Die Fünf-Jahres-Support-Pflicht ist ein Geschäftsmodell-Problem

Das ist der Teil des CRA, aus dem sich ein Startup nicht heraus-toolen kann. Der Supportzeitraum muss mindestens fünf Jahre betragen. Ist eine kürzere Nutzungsdauer des Produkts zu erwarten, richtet sich der Zeitraum nach dieser kürzeren erwarteten Nutzung. In diesem Zeitraum behandeln Sie Schwachstellen risikobasiert, beheben sie unverzüglich und liefern die Updates an Kunden aus.

Für ein Unternehmen in der Frühphase ist das eine echte Verpflichtung, keine Checkbox:

• Die Pflicht folgt dem Produkt: Sie beginnt mit der ersten Bereitstellung auf dem EU-Markt, und ein späterer Pivot beendet sie nicht für bereits platzierte Einheiten.
• Sie muss eingepreist sein: Trägt Ihre Marge den Supportzeitraum nicht, stimmt der Preis nicht. Kalkulieren Sie die Supportkosten vor dem Launch in die Unit Economics ein, und rechnen Sie damit, dass sie abnehmen, sobald sich die Codebasis stabilisiert.
• Planen Sie für zehn Jahre, nicht fünf: Jedes Sicherheitsupdate, das Sie herausgeben, muss mindestens 10 Jahre nach der Veröffentlichung verfügbar bleiben, oder für den Rest des Supportzeitraums, je nachdem, was länger ist.
• Enddatum veröffentlichen: Sie müssen das Enddatum des Supportzeitraums, mindestens Monat und Jahr, zum Zeitpunkt des Kaufs anzeigen. Legen Sie es bewusst fest, denn Kunden und Käufer lesen es.

Sie können die Verpflichtung tragfähiger machen, aber achten Sie darauf, was sie tatsächlich erfüllt:

• Stabile Abhängigkeiten wählen: Jede schnelllebige Bibliothek, die Sie einbinden, ist Jahre an Wartung, die Sie sich damit einhandeln. Bevorzugen Sie langweilige, gut gepflegte Komponenten.
• Bewusst versionieren: Definieren Sie Produktgenerationen und planen Sie, wie der Support zwischen ihnen übergeht, damit Sie nicht eine unbegrenzte Zahl aktiver Versionen pflegen.
• Abmilderungen entbinden nicht von der Pflicht: Eine schriftliche Übertragung des Supports auf einen Erwerber, eine Escrow-Vereinbarung oder das Open-Sourcen der sicherheitskritischen Komponenten kann Fixes am Laufen halten, aber keine dieser Maßnahmen hebt für sich genommen Ihre Pflicht auf.

Stellen Sie den Betrieb ein und können die Pflicht nicht mehr erfüllen, müssen Sie die Marktüberwachungsbehörden und, soweit möglich, Ihre Nutzer informieren, bevor die Einstellung wirksam wird. Was mit der Restpflicht passiert, sobald das Unternehmen nicht mehr existiert, ist nicht eindeutig geklärt und hängt von der Jurisdiktion ab. Planen Sie den Abwicklungsweg jetzt, solange Sie noch können, und dokumentieren Sie ihn in der technischen Dokumentation.

Compliance in Vertrieb und Finanzierung verwandeln

Für ein Startup leistet CRA-Arbeit doppelte Dienste: Sie öffnet den Zugang zum EU-Markt, und sie liefert Ihnen Nachweise, die Sie einem Enterprise-Käufer oder einem Investor vorlegen können.

Stellen Sie das Due-Diligence-Paket einmal zusammen. EU-Beschaffungsteams können beim Vendor-Onboarding nach einem aktuellen SBOM, einer unterzeichneten Konformitätserklärung und einem dokumentierten Prozess zur Offenlegung von Schwachstellen mit Reaktionszeitraum fragen. Das sind starke Nachweise, kein Beweis vollständiger Compliance, denn die Konformität hängt letztlich davon ab, ob Sie jede grundlegende Anforderung erfüllen. Aber wenn diese Unterlagen an einem Ort gesammelt sind, ersparen Sie sich später die Hektik, sie zusammenzutragen, und es ist dasselbe Paket, das eine technische Due Diligence eines Investors sehen möchte.

Investoren interessiert, ob Sie legal ausliefern können. Verstöße gegen die grundlegenden Anforderungen oder die zentralen Herstellerpflichten ziehen Bußgelder von bis zu 15 Mio. EUR oder 2,5 % des weltweiten Jahresumsatzes nach sich, je nachdem, welcher Betrag höher ist. Praktischer formuliert: Ein Produkt, das ab dem 11. Dezember 2027 auf dem EU-Markt platziert wird, muss den CRA erfüllen, um dort verkauft werden zu dürfen. Compliance als Marktzugang und risikoreduzierten EU-Einstieg zu framen, kommt bei einem Board besser an, als sie als Kostenfaktor darzustellen.

Öffentliche Programme können einen Teil der Arbeit finanzieren. EU-Instrumente wie Horizon Europe, das Digital Europe Programme und der EIC Accelerator fördern Cybersicherheit und sichere Produktentwicklung, nationale Programme ergänzen das. Höhe und Förderfähigkeit variieren, prüfen Sie also bei Ihrem nationalen Digital Innovation Hub, was aktuell offen ist. Formulieren Sie den Antrag rund um den Aufbau vertrauenswürdiger, sicherer digitaler Produkte, nicht um das Abhaken einer regulatorischen Pflicht.

Kommen im Vertrieb Sicherheitszertifizierungen zur Sprache, sollten Sie wissen, wo der CRA im Verhältnis dazu steht. Die Überschneidung mit einem ISMS behandelt der Leitfaden CRA vs. ISO 27001, und Teams im Bereich Consumer-IoT sollten den Leitfaden zu EN 303 645 lesen.

Häufige Startup-Fehler

• „Sicherheit klären wir nach der Finanzierungsrunde": Auf der Runway verbrennt nachträgliches Sicherheits-Nachrüsten genau das Geld, das Sie gerade eingesammelt haben. Bauen Sie die Grundlagen ab dem ersten Sprint ein.
• „Wir haben das Produkt ohne die Support-Pflicht kalkuliert": Die mehrjährige Sicherheitswartung muss in Ihren Unit Economics stecken. Tut sie das nicht, stimmt der Preis nicht.
• „Unser Compliance-Verantwortlicher ist gegangen, und niemand hat übernommen": Hält eine Person die technische Dokumentation und den Meldeprozess, ist ihr Weggang eine Compliance-Lücke. Halten Sie schriftlich fest, wer zuständig ist.
• „Der Erwerber übernimmt die Pflicht einfach": Ein Deal kann die Support-Arbeit zuweisen, hebt aber die gesetzliche Pflicht nicht automatisch von Ihnen auf. Regeln Sie das ausdrücklich in den Vertragsbedingungen, und gehen Sie von nichts aus.
• „CRA bauen wir an, wenn wir in die EU expandieren": Können EU-Nutzer Ihr Produkt bereits erreichen, beliefern Sie den EU-Markt schon jetzt, und Compliance nachträglich anzuflanschen ist ein Umbau. Planen Sie von Anfang an für die Pflichten ab 2027.
• „Wir sind zu früh in der Phase, um betroffen zu sein": Als Startup bekommen Sie Erleichterungen, keine Ausnahme. Die Pflicht beginnt mit der ersten Bereitstellung, unabhängig von Ihrer Phase.