Die Kurzfassung für CTOs mit wenig Zeit: Wenn Sie Software oder vernetzte Produkte auf den EU-Markt bringen, gilt der Cyber Resilience Act (Verordnung (EU) 2024/2847) mit an Sicherheit grenzender Wahrscheinlichkeit auch für Sie. Ab dem 11. September 2026 müssen Sie aktiv ausgenutzte Schwachstellen innerhalb von 24 Stunden, nachdem Sie davon Kenntnis erlangt haben, an die ENISA melden. Bis zum 11. Dezember 2027 brauchen Sie die vollständige Compliance: eine fortlaufend gepflegte SBOM, Secure-by-Design-Praktiken und zehn Jahre technische Dokumentation. Die Geldbußen reichen bis zu 15 Mio. € oder 2,5 % des weltweiten Jahresumsatzes, je nachdem, welcher Betrag höher ist.
Wenn Sie CEO, Gründerin, Gründer oder Board-Mitglied eines europäischen Softwareunternehmens sind, steht in Ihrem Kalender eine Frist, die Sie vermutlich noch nicht verinnerlicht haben.
- 11. September 2026: Die Meldepflichten nach dem EU Cyber Resilience Act (CRA) treten in Kraft.
- 11. Dezember 2027: Die vollständige Compliance folgt.
Die Geldbuße bei Verstößen: bis zu 15 Mio. € oder 2,5 % des weltweiten Umsatzes, je nachdem, welcher Betrag höher ist.
Auf diese Zahlen komme ich zurück. Zuerst die unangenehmere Frage.
„Sind Sie bereit?“
In den nächsten 18 Monaten wird jedes europäische Softwareunternehmen mit dieser Frage konfrontiert, von einem Board, einem Auditor, einem Käufer oder einer Behörde. Und in den meisten Gesprächen, die ich derzeit mit Engineering-Verantwortlichen führe, lautet die ehrliche Antwort ungefähr: „Wir glauben schon, aber wir wissen es nicht wirklich.“
Das liegt nicht an mangelndem Einsatz. Es liegt an einer fehlenden Definition.
Bis vor Kurzem war „sichere Software“ ein Gefühlsbegriff, durchgesetzt mit bestmöglichen Scans und gelegentlichen Penetrationstests. Der CRA ändert das. Er macht sichere Software zu einer regulierten, prüfbaren und nachweispflichtigen Kategorie, ähnlich wie die DSGVO aus „wir respektieren Ihre Privatsphäre“ eine dokumentierte Pflicht mit Konsequenzen gemacht hat.
Wer die Einführung der DSGVO miterlebt hat, erkennt das Muster: Getroffen hat es nicht die Unternehmen, die das Falsche getan haben. Getroffen hat es die, die nicht nachweisen konnten, dass sie das Richtige tun.
Was verlangt der CRA tatsächlich?
Ich erspare Ihnen die regulatorische Rundreise und konzentriere mich auf das, was im Betrieb zählt.
Eine Software Bill of Materials (SBOM) für jedes Produkt mit digitalen Elementen
In einem maschinenlesbaren Format, CycloneDX oder SPDX. Mindestens die Abhängigkeiten der obersten Ebene. Fortlaufend gepflegt, nicht einmal für den Auditor erzeugt und dann bis zum nächsten Prüfzyklus vergessen.
Wenn Ihre aktuelle SBOM-Strategie lautet „wir machen einen einmaligen Scan, wenn jemand fragt“, dann haben Sie keine SBOM-Strategie. Sie haben ein Word-Dokument, in dem schon das Bedauern von morgen steckt.
Ein Prozess zur Behandlung von Schwachstellen mit 24-Stunden-Meldefenster
Aktiv ausgenutzte Schwachstellen müssen innerhalb von 24 Stunden, nachdem Sie davon Kenntnis erlangt haben, an die ENISA gemeldet werden. Das gilt ab September 2026, auch für Legacy-Produkte, die Sie vor Jahren ausgeliefert haben.
Wenn Sie nicht wissen, welche Produkte in Ihrem Portfolio noch in den Anwendungsbereich fallen, ist das die erste Bestandsaufnahme, die Sie machen sollten. Die 24-Stunden-Frist beginnt mit der Kenntnisnahme, nicht mit der Triage, der Behebung oder der Freigabe durch das Board. Deshalb muss der Ablauf geübt werden, nicht nur dokumentiert.
Secure-by-Design in der Entwicklung
Technische Dokumentation, die zehn Jahre lang aufbewahrt wird. Überwachung von Schwachstellen über den gesamten Lebenszyklus. Die Fähigkeit, all das einer Marktüberwachungsbehörde auf Anfrage nachzuweisen.
Was das im Klartext bedeutet: Sie müssen wissen, was in Ihrer Software steckt, Sie müssen wissen, wann sie verwundbar wird, und Sie müssen schnell auf dieses Wissen reagieren können. Nichts davon ist exotisch. Alles davon ist Betriebsarbeit. Und alles davon ist teuer nachzurüsten und günstig, wenn man es von Anfang an einbaut.
Die Lücke, über die niemand spricht
Interessant ist Folgendes. Die meisten Engineering-Teams, mit denen ich arbeite, kennen den CRA auf einer abstrakten Ebene. Sie haben die Schlagzeilen gesehen. Sie haben ein Snyk-Abo, Dependabot ist aktiviert, oder ein Security Engineer hat einen Kurs dazu belegt.
Die Lücke liegt nicht im Bewusstsein. Die Lücke liegt in der Übersetzung.
Der CRA ist in regulatorischer Sprache geschrieben und landet bei Engineering-Teams, die in Tickets und Sprints denken. Zwischen diesen beiden Welten liegt eine Frage, für die niemand zuständig ist: Wie sieht Compliance in unserer konkreten Codebasis aus, mit unserer konkreten Architektur, unserem konkreten Team und der Art, wie wir tatsächlich ausliefern?
Diese Frage kann kein Tool beantworten. Sie braucht einen Senior Engineer, der genug Codebasen gesehen, in genug Boardrooms gesessen und genug von der eigentlichen Verordnung gelesen hat, um Ihnen eine belastbare Einschätzung zu geben.
Wie sieht CRA-Readiness konkret aus? Der Drei-Ergebnisse-Test
Nach meiner Erfahrung ist ein Softwareunternehmen wirklich bereit für den CRA, wenn es innerhalb von vierundzwanzig Stunden drei Dinge vorlegen kann:
- Eine aktuelle SBOM für jedes ausgelieferte Produkt, mit klar ausgewiesenem Schwachstellen- und Lizenzstatus.
- Eine schriftliche Richtlinie zur Behandlung von Schwachstellen mit benannten Verantwortlichen, Eskalationswegen und einer tatsächlich durchgespielten Übung des 24-Stunden-Meldeablaufs, nicht nur eine Confluence-Seite, die seit ihrer Erstellung niemand mehr gelesen hat.
- Ein Paket technischer Dokumentation, das ein Auditor oder Käufer in die Hand nehmen und verstehen kann: Architekturentscheidungen, Sicherheitskontrollen, die Zusage zum Supportzeitraum und die Änderungshistorie, die zählt.
Wenn Sie diese drei Dinge heute vorlegen können, gehören Sie bereits zu den besten zehn Prozent.
Wenn nicht, dauert der Weg dorthin je nach Ausgangslage sechs bis achtzehn Monate. Unternehmen, die erst im Sommer 2026 anfangen, werden zu spät dran sein.
Der CRA ist kein Sicherheitsproblem, sondern ein Führungsproblem
Ich schreibe das nicht, um jemandem Angst zu machen. Sondern weil ich in Unternehmen jeder Größe immer wieder dasselbe Muster sehe:
- Die Geschäftsführung geht davon aus, dass der CTO das im Griff hat.
- Der CTO geht davon aus, dass der Security Engineer das im Griff hat.
- Der Security Engineer ertrinkt bereits im CVE-Backlog und hat angenommen, dass ihm irgendwann jemand klare Prioritäten gibt.
Der CRA ist kein Sicherheitsproblem. Er ist ein Führungsproblem mit Auswirkungen auf die Sicherheit.
Es braucht jemanden, dessen Aufgabe es ist, das Gesamtbild zu betrachten, also Engineering-Fähigkeiten, die Realität der Codebasis, regulatorische Risiken und die Darstellung gegenüber dem Board, und daraus eine klare, geordnete Antwort zu machen. Das ist die Aufgabe eines Fractional CTO. Nicht die Aufgabe einer Snyk-Integration und auch nicht die Ihres überlasteten Head of Security.
Wie wir helfen: das CRA- & Engineering-Readiness-Audit von WeAreFabbrik
Bei WeAreFabbrik haben wir diese Arbeit in ein CRA- & Engineering-Readiness-Audit mit festem Umfang gepackt:
- Zwei Wochen, Festpreis, vorstandstaugliche Ergebnisse
- Eine Bestandsaufnahme gegenüber jeder operativen Anforderung des CRA
- Ein priorisierter Maßnahmenplan mit Aufwandsschätzungen und benannten Verantwortlichen
- Eine für das Board lesbare Zusammenfassung, geeignet für Ihre nächsten Unterlagen an Investoren oder den Prüfungsausschuss
Es ist für Gründer, CTOs und Investoren gedacht, die eine belastbare Antwort haben möchten, bevor jemand anderes sie einfordert, nicht erst danach.
Wie das in unser übergreifendes 3-Phasen-Modell passt, sehen Sie dort: Technical Blueprint, Build und Ship & Scale, je nachdem, ob nur eine Bewertung, eine Bewertung mit Umsetzung der Maßnahmen oder laufende CTO-Unterstützung gebraucht wird.
Holen Sie sich den CRA-Audit-Onepager
Wir haben einen Onepager zusammengestellt, der Umfang, Leistungen, Zeitplan und Preise des Audits zusammenfasst. Er ist als das Dokument gedacht, das Sie an Ihr Board, Ihren CTO oder Ihren Prüfungsausschuss weiterleiten.
CRA-Audit-Onepager anfordern →
Er landet innerhalb weniger Minuten in Ihrem Postfach. Ein Gespräch ist dafür nicht nötig.
Die Frist verschiebt sich nicht
September 2026 ist näher, als es Ihr nächster Board-Zyklus vermuten lässt. Zuerst greift die Meldepflicht des CRA; die vollständige Compliance folgt fünfzehn Monate später. Die Frage des Boards kommt so oder so. Die einzige offene Variable ist, wie gut Sie vorbereitet sind, wenn sie kommt.
Wenn Sie eine belastbare Einschätzung Ihres Status möchten und einen Plan mit festem Umfang, der Sie von dort, wo Sie stehen, dorthin bringt, wo Sie sein müssen, fordern Sie den Onepager an, buchen Sie ein 30-minütiges Strategiegespräch oder schreiben Sie uns.
Über den Autor: Konstantinos Tsolakidis ist Fractional CTO und Gründer von WeAreFabbrik, einem Senior-Engineering-Team mit Sitz in Athen und Tallinn. Er arbeitet mit Softwareunternehmen und PE-finanzierten Scale-ups in der DACH-Region und im gesamten europäischen Markt an Architektur, Engineering-Readiness und regulatorischen Risiken. Auf LinkedIn schreibt er The Builder's Edge.