Bin ich selbst vom Cyber Resilience Act betroffen?

In meiner täglichen Arbeit begleite ich Unternehmen durch den regulatorischen Dschungel des Cyber Resilience Act, kurz CRA. Es geht um Anwendungsbereiche, Herstellerpflichten, Risikobewertungen, technische Dokumentation, Normenentwürfe und sehr konkrete Sicherheitsanforderungen.

Bis vor Kurzem war das für mich vor allem Beratungsalltag.

Dann wurde die Frage plötzlich persönlich.

Ich habe die HAPP Digital GmbH gegründet, um ein professionelles PowerPoint-Plugin zu entwickeln. Der Arbeitstitel lautet DrakeUp. Nach einem ersten Mockup zur technischen Validierung steht nun die Neukonzeption des eigentlichen Produkts an. Und damit stellte sich genau die Frage, die auch viele meiner Kunden beschäftigt:

Gilt der CRA eigentlich auch für mein eigenes Vorhaben?

Ist ein PowerPoint-Plugin ein CRA-Produkt?

DrakeUp ist kein klassisches Stück Software, das man als Datei herunterlädt und lokal installiert. Technisch handelt es sich um ein Office-Web-Add-in. PowerPoint lädt dabei unter anderem eine Manifest-Datei im XML-Format. Diese beschreibt, wie sich das Add-in in PowerPoint integriert und auf welche Webressourcen es verweist. Das Manifest ist nicht die eigentliche Anwendung, sondern der Einstiegspunkt, über den PowerPoint die Anwendung DrakeUp lädt.

Auf den ersten Blick könnte man versucht sein zu sagen: „Das ist doch nur eine Konfigurationsdatei. Ist das überhaupt Software?“

Für die CRA-Bewertung greift diese Frage aber zu kurz. Entscheidend ist nicht, ob eine einzelne XML-Datei isoliert betrachtet bereits „Software“ ist. Ich möchte das Gesamtbild betrachten: DrakeUp besteht aus einem Add-in-Konzept, einem Manifest, geladenen Webressourcen und einem DrakeUp-Service, der die Produktlogik bereitstellt. Dazu kommen noch Authentifizierungsdienste und ein Lizenzserver. Damit steht nicht mehr nur eine technische Datei im Raum, sondern ein funktionales digitales Produkt.

Trotzdem bleibt die Einordnung nicht trivial.

Der CRA definiert Software als Teil eines elektronischen Informationssystems, der aus Computer-Code besteht. Außerdem erfasst der CRA „Produkte mit digitalen Elementen“ nicht nur das Software- oder Hardwareprodukt selbst, sondern auch die dazugehörige Remote-Datenverarbeitung beziehungsweise Datenfernverarbeitung, soweit diese für die Produktfunktion erforderlich ist.

Meine vorläufige Arbeitshypothese lautet daher:

DrakeUp sollte als Produkt mit digitalen Elementen behandelt werden.

Nicht, weil jede XML-Datei automatisch ein CRA-Produkt wäre, sondern weil das Gesamtangebot als PowerPoint-Add-in eine Softwarefunktion bereitstellt, die über den DrakeUp-Service geladen und auf dem Markt angeboten werden soll..

Die nächste Frage ist mindestens genauso wichtig: Welche Rolle spielt der DrakeUp-Service, wenn ohne ihn keine Produktfunktion bereitsteht?

Der CRA kennt den Begriff der "Remote Data Processing Solution", also Remote-Datenverarbeitung. Gemeint ist Datenverarbeitung auf Distanz, wenn die Software vom Hersteller oder unter dessen Verantwortung entwickelt wurde und das Produkt ohne diese Verarbeitung eine seiner Funktionen nicht erfüllen könnte.

Das ist für DrakeUp relevant. Wenn der DrakeUp-Service offline ist, funktioniert das Add-in nicht sinnvoll. Der Dienst ist damit nicht bloß Hosting oder technische Infrastruktur, sondern stellt die Produktlogik bereit.

Das ist ein wichtiger Unterschied.

Ein isolierter SaaS-Dienst fällt nicht automatisch unter den CRA, nur weil er in der Cloud läuft. Cloud-Lösungen fallen nur dann als Remote-Datenverarbeitungslösung in den Anwendungsbereich, wenn sie die CRA-Definition erfüllen und für eine Produktfunktion erforderlich sind. Websites oder Cloud-Dienste, die die Funktion eines Produkts mit digitalen Elementen nicht unterstützen oder außerhalb der Verantwortung des Herstellers entwickelt wurden, sind nicht allein deshalb vom CRA erfasst.

Bei DrakeUp sieht es anders aus: Wenn HAPP Digital das Add-in und den dazugehörigen Dienst aus einer Hand anbietet, muss ich das Gesamtsystem betrachten.

Natürlich könnte ich nun viel Energie darauf verwenden, das Geschäftsmodell so zu formulieren, dass DrakeUp möglichst außerhalb des CRA landet.

Aber genau das wäre aus meiner Sicht der falsche Ansatz.

Ich berate Unternehmen nicht mit dem Ziel, Regulierung durch Wortakrobatik zu vermeiden. Ich berate Unternehmen mit dem Ziel, digitale Produkte sicherer, robuster und marktfähiger zu machen. Genau diesen Anspruch muss ich auch an mein eigenes Produkt stellen.

Der CRA ist dabei nicht nur eine Compliance-Pflicht. Er ist auch ein Qualitätsmaßstab für mich und meine Software.

Ich möchte wissen, welche Risiken mein Produkt hat. Ich möchte wissen, welche Komponenten ich einsetze. Ich möchte wissen, wie ich mit Schwachstellen umgehe. Ich möchte wissen, wie Updates verteilt werden. Und ich möchte später gegenüber Kunden belastbar erklären können, warum DrakeUp professionell entwickelt und betrieben wird.

Das gilt umso mehr, weil sich Geschäftsmodelle verändern können. Heute ist DrakeUp als Web-Add-in mit zentralem Dienst gedacht. Morgen könnte ein Unternehmenskunde verlangen, den Dienst selbst zu betreiben oder eine dedizierte Umgebung zu erhalten. Spätestens dann wird aus einer abstrakten Scope-Diskussion eine sehr konkrete Herstellerfrage.

Aus einem überwiegend SaaS-geprägten Angebot kann dann ein klar auslieferbares Softwareprodukt werden.

Wenn ich dann erst mit CRA-Strukturen beginne, bin ich zu spät.

Deshalb habe ich mich entschieden, DrakeUp nicht am CRA vorbeizuentwickeln, sondern den CRA als Leitplanke für die Produktkonzeption zu nutzen.

Das bedeutet nicht, dass ich heute schon behaupte, DrakeUp sei "CRA-konform". Dafür wäre es zu früh. Aber ich werde das Produkt systematisch CRA-ready machen.

Der erste Schritt ist eine geordnete Cybersecurity-Risikobewertung. Der CRA verlangt, dass Hersteller die Cybersicherheitsrisiken ihres Produkts bewerten und das Ergebnis in Planung, Design, Entwicklung, Lieferung und Wartung berücksichtigen.

Genau hier setze ich an.

Für DrakeUp werde ich unter anderem klären:

Ein Teil der CRA-Umsetzung wird sich an harmonisierten Normen orientieren. Im Mai 2026 ist die Normungslandschaft aber noch in Bewegung. Die EN 40000-Reihe enthält unter anderem geplante horizontale Normen zu Prinzipien der Cyber Resilience, generischen Sicherheitsanforderungen und Schwachstellenbehandlung. Zentrale horizontale Normungsprojekte umfassen EN 40000-1-2, EN 40000-1-3 und EN 40000-1-4.

Ich werde daher nicht so tun, als gäbe es bereits für jede Frage eine finale Normantwort.

Stattdessen nutze ich die bereits erkennbaren Leitplanken:

• die Anforderungen des CRA selbst

• die entstehenden europäischen Normen

• etablierte Security-Praktiken für Webanwendungen

• OWASP-orientierte Prüfungen

• nachvollziehbare Risikoentscheidungen

• eine Dokumentation, die später in eine technische CRA-Akte überführt werden kann

Der CRA verlangt keine akademische Perfektion. Er verlangt ein angemessenes Cybersicherheitsniveau auf Basis der Risiken. Für Produkte mit digitalen Elementen gehören dazu unter anderem sichere Voreinstellungen und das Bereitstellen ohne bekannte ausnutzbare Schwachstellen, soweit dies auf Basis der Risikobewertung anwendbar ist.

Die meisten materiellen Herstellerpflichten des CRA gelten ab dem 11. Dezember 2027. Die Meldepflichten für aktiv ausgenutzte Schwachstellen und schwere Sicherheitsvorfälle greifen bereits ab dem 11. September 2026.

Das klingt nach viel Zeit. Für ein echtes Produkt ist es das aber nicht. Und für viele Unternehmen mit gewachsenen Bestandsprodukten ist es erst recht wenig Zeit.

Wer erst kurz vor Ablauf der Übergangsfrist mit Risikoanalyse, Komponentenübersicht, Vulnerability Handling, Update-Prozess, Supportlogik und technischer Dokumentation beginnt, wird am Ende unter Druck geraten.

Ich möchte diesen Druck vermeiden. Und ich möchte zeigen, dass CRA-Umsetzung auch für kleine Hersteller machbar ist, wenn man sie frühzeitig und pragmatisch in die Produktentwicklung integriert.

Dabei ist mir bewusst, dass eine Neuentwicklung grundsätzlich einfacher ist als die nachträgliche Absicherung über Jahre oder Jahrzehnte gewachsener Produktarchitekturen. Ich kann Entscheidungen frühzeitig und vergleichsweise kostengünstig an Sicherheitsanforderungen ausrichten. Ich habe keine große Bestandssoftware, für die ich bereits in diesem Jahr Meldepflichten organisatorisch berücksichtigen muss. Zudem ist die Entwicklung und der Betrieb einer einzelnen Software deutlich überschaubarer als die CRA-Umsetzung in Unternehmen mit hunderten oder tausenden Produkten.

Gerade deshalb eignet sich DrakeUp als Fallbeispiel. Es zeigt nicht die schwierigste denkbare Ausgangslage. Aber es zeigt, wie man CRA-Anforderungen von Anfang an ernst nimmt und in konkrete Produktentscheidungen übersetzt.

In dieser Serie werde ich die CRA-Umsetzung für DrakeUp Schritt für Schritt dokumentieren.

Nicht als theoretisches Lehrbuch, sondern als reale Produktreise.

Ich werde zeigen, wie ich den Anwendungsbereich bewerte, wie ich den bestimmungsgemäßen Gebrauch formuliere, wie ich Risiken identifiziere, welche Sicherheitsanforderungen daraus entstehen, wie ich Drittkomponenten betrachte, wie ein Vulnerability-Handling-Prozess für ein kleines Unternehmen aussehen kann und wie daraus am Ende eine belastbare technische Dokumentation entsteht.

Ich hoffe, dass meine Gedanken und Beispiele den einen oder anderen Unternehmer, Softwareentwickler, Sicherheitsarchitekten oder Compliance-Ingenieur inspirieren.

Ich bin gespannt auf eure Reaktionen.