CRA in Ihrem eigenen Produkt: Wie wichtig bin ich wirklich?

Der erste Beitrag in dieser Serie behandelte die grundlegende Frage: Fällt ein PowerPoint-Add-In wie DrakeUp überhaupt unter das Cyber Resilience Act?

Meine vorläufige Antwort aus geschäftlicher Sicht war: ja, wahrscheinlich.

DrakeUp ist ein Softwareprodukt, also ein Produkt mit digitalen Elementen, das unter dem Namen HAPP Digital GmbH bereitgestellt wird und für den Einsatz in einer vernetzten IT-Umgebung vorgesehen ist.

Für diesen Beitrag reicht die Arbeitshypothese aus: Ich behandle DrakeUp als ein Produkt mit digitalen Elementen und gehe damit bewusst den konservativen Weg. Die interessantere Frage ist nicht mehr das "ob", sondern das "wie schwerwiegend":

In welche CRA-Kategorie fällt das Produkt?

Ist es ein normales Produkt mit digitalen Elementen? Ein wichtiges Produkt? Oder sogar ein kritisches Produkt?

Diese Klassifizierung bestimmt, welcher Konformitätsbewertungspfad in Betracht gezogen wird, ob eine benannte Stelle einbezogen werden muss und wie komplex der Nachweis der Konformität sein wird. Für ein großes Unternehmen ist dies ein zusätzlicher Projektstrang. Für ein kleines Produktteam kann es über Budget, Zeitplan und Markteintritt entscheiden.

Für DrakeUp ist diese Frage geschäftskritisch. Sie beeinflusst direkt die Produkt- und Rentabilitätsplanung. In dieser frühen Phase können externe Prüf- und Verifizierungskosten schnell die geplanten Jahresumsätze übersteigen.

Moderne Software besteht selten aus einer einzigen Funktion. Ein Add-In kann Benutzer authentifizieren, Daten speichern, Schnittstellen nutzen, Verschlüsselung einsetzen, Bibliotheken integrieren oder einen externen Dienst ansprechen. Das bedeutet jedoch nicht automatisch, dass jede dieser Funktionen die CRA-Kategorie des gesamten Produkts bestimmt.

Für die Klassifizierung kommt es darauf an, was das Produkt im Wesentlichen ist.

Ist es ein Browser? Ein Passwortmanager? Ein Betriebssystem? Eine Firewall? Ein Hypervisor? Ein Identitätsmanagementsystem? Oder ist es ein anderes Produkt, das lediglich einzelne sicherheitsrelevante Funktionen oder Komponenten nutzt?

Diese Unterscheidung ist für Hersteller wichtig. Wenn jede integrierte Komponente die Klassifizierung des Gesamtprodukts bestimmen würde, könnte kaum eine normale Software sauber klassifiziert werden. Fast jede moderne Anwendung enthält Authentifizierung, Verschlüsselung, Update-Mechanismen oder Drittanbieter-Bibliotheken.

Die richtige Einstiegsfrage lautet daher nicht:

"Welche sicherheitsrelevanten Funktionen sind irgendwo im Produkt vorhanden?"

Sondern:

"Welche Funktion definiert das Produkt im Wesentlichen?"

Erst dann kann sinnvoll geprüft werden, ob diese Kernfunktion in eine der Listen für wichtige oder kritische Produkte fällt.

Zur ersten Orientierung hilft eine einfache Struktur. Ich verwende den Begriff "Standardprodukt" als Arbeitsterminus. Er bezieht sich auf Produkte mit digitalen Elementen, die unter die CRA fallen, aber nicht explizit als wichtige oder kritische Produkte gelistet sind.

DrakeUp ist ein PowerPoint-Add-In. Seine Kernfunktion besteht darin, die Arbeit in PowerPoint zu unterstützen: Inhalte strukturierter zu erstellen, Präsentationen effizienter vorzubereiten und wiederkehrende Schritte im Präsentationsprozess zu erleichtern.

Es ist daher kein Sicherheitsprodukt, kein Identitätsmanagementsystem, kein Browser oder Netzwerkteil, auch wenn diese Funktionen Aspekte der Software darstellen.

Die anfängliche Beschreibung lautet: Produktivitätssoftware für PowerPoint.

Von dort aus beginnt die Ausrichtung an den CRA-Kategorien.

Basierend auf der aktuellen Produktkonfiguration sehe ich keine Kategorie aus Anhang III, die die Kernfunktion von DrakeUp beschreibt. DrakeUp ist kein Passwortmanager, kein Browser, kein Hypervisor, keine Firewall, kein SIEM, kein PAM-System und kein Betriebssystem. Auch Anhang IV passt nicht. DrakeUp ist kein sicheres Element, keine Smartcard, kein Smart Meter Gateway und kein Hardware-Sicherheitsmodul.

Meine Klassifizierung lautet daher: DrakeUp ist ein Standardprodukt.

Für HAPP Digital ist dies die wesentliche Erkenntnis. Auch als Standardprodukt muss DrakeUp den grundlegenden Katalog der CRA-Sicherheitsanforderungen erfüllen. Der Unterschied liegt nicht darin, ob Sicherheit erforderlich ist, sondern darin, wie die Konformität nachgewiesen wird und ob externe Stellen einbezogen werden.

Für ein kleines Softwareprodukt macht dies einen erheblichen Unterschied.

Einer der häufigsten Unsicherheiten entsteht bei Drittanbieterkomponenten.

Was passiert, wenn ein Produkt eine Verschlüsselungsbibliothek verwendet? Oder eine eingebettete Browsersteuerung? Oder eine Authentifizierungsfunktion? Wird das Gesamtprodukt automatisch zu einem wichtigen Produkt?

Die Antwort lautet: nicht automatisch. Die Kernfunktionalität des Gesamtprodukts bleibt entscheidend. Eine sicherheitsrelevante Komponente kann Risiken erhöhen und Dokumentationspflichten auslösen, aber sie ändert nicht automatisch die CRA-Kategorie des Produkts.

Das bedeutet jedoch nicht, dass Komponenten aus der Betrachtung verschwinden.

Wenn DrakeUp eine Bibliothek für Authentifizierung, Verschlüsselung oder API-Kommunikation verwendet, muss diese Komponente in die Sicherheitsbetrachtung einbezogen werden. Sie gehört in die Risikoanalyse, ins Schwachstellenmanagement und in die technische Dokumentation. Die Software-Stückliste (SBOM) wird dadurch ebenfalls relevanter.

Die Kategorie des Gesamtprodukts bleibt somit eine Frage der Kernfunktion. Die Sicherheitsanforderungen betreffen dennoch das Produkt als Ganzes, einschließlich der verwendeten Komponenten.

Die CRA-Klassifizierung ist nicht nur eine juristische Übung. Sie betrifft das Produktmanagement und die Unternehmensführung.

Eine Unterschätzung kann dazu führen, dass der falsche Konformitätsbewertungspfad gewählt wird. Dies kann später die technische Dokumentation, die EU-Konformitätserklärung, die Anwendung harmonisierter Normen, die CE-Kennzeichnung und den Marktzugang belasten oder zum Marktausschluss führen. Eine Überschätzung hingegen kann unnötige Kosten, Verzögerungen und Abstimmungsaufwand erzeugen.

Beides ist vermeidbar, wenn die Klassifizierung frühzeitig, durchdacht und transparent erfolgt. Sie sollte die aktuelle Entwicklung berücksichtigen, aber auch potenzielle Weiterentwicklungen des Produkts.

Ich würde es daher wie eine dokumentierte Produktentscheidung behandeln:

Der letzte Punkt ist besonders wichtig. Produkte entwickeln sich weiter. Wenn ein Produkt später Funktionen erhält, die mehr in Richtung Identitätsmanagement, Sicherheitsüberwachung, privilegierter Zugriff oder Netzwerkkontrolle gehen, muss die Klassifizierung neu bewertet werden.

Die CRA-Klassifizierung ist daher aktiv vom Produktmanagement zu steuern und bei wesentlichen Änderungen neu zu bewerten.

Es ist auch möglich, dass die EU-Kommission neue Produktkategorien zu Anhang III für wichtige oder Anhang IV für kritische Produkte hinzufügt. Dies könnte CRA-konforme Produkte strengeren Konformitätsbewertungsverfahren unterwerfen.

Die folgende Tabelle ist bewusst vereinfacht. Sie ersetzt keine Einzelfallbewertung, zeigt aber die Logik der Klassifizierung.

Eine detaillierte Auflistung der betroffenen Produkte zusammen mit technischen Beschreibungen wurde von der EU-Kommission im Dezember 2025 durch eine Durchführungsverordnung (EU 2025/2392) bereitgestellt.

Für DrakeUp ist die Klassifizierung als Standardprodukt zunächst ein guter Ausgangspunkt. Es bedeutet, dass das CRA nicht automatisch ein externes Prüfverfahren aufgrund der aktuellen Produktkonfiguration aus

Nach dem Scope-Check beginnt die Klassifizierung. Für viele Softwarehersteller ist das der Moment, in dem der CRA praktischer wird, weil er Konsequenzen hat. Jetzt entscheidet sich, ob der Weg über interne Kontrolle führt oder ob strengere Verfahren und externe Stellen einzuplanen sind.

Für DrakeUp fällt die vorläufige Antwort klar aus: Die Kernfunktion ist ein Produktivitäts-Add-in für PowerPoint. Nach aktuellem Stand passt diese Kernfunktion weder in Anhang III noch in Anhang IV. Damit bleibt DrakeUp voraussichtlich ein Standardprodukt, mit interner Kontrolle nach Modul A als naheliegendem Weg.

Die Einstufung als Standardprodukt macht den Nachweisweg beherrschbarer. Risikoanalyse, technische Dokumentation und Schwachstellenmanagement bleiben trotzdem erforderlich.

Ich möchte ohnehin Produktsicherheit nicht erst kurz vor dem Launch prüfen, sondern als Teil der Produktentwicklung zu behandeln.