Pflichtlektüre fürs Produkt: Welche Informationen müssen laut CRA mitgeliefert werden?

Unsere bisherigen Beiträge zum CRA haben gezeigt, welche Anforderungen Hersteller an die Cybersicherheit ihrer Produkte von der sicheren Entwicklung bis zum Umgang mit Schwachstellen nach der Markteinführung erfüllen müssen. Doch ein Aspekt zieht sich durch alle Phasen und wird oft unterschätzt: die Dokumentation.

Denn egal ob Marktzugang, Sicherheitsupdate oder End-of-Life – ohne verständliche und vollständige Informationen für den Nutzer geht nichts mehr. Anhang II des Cyber Resilience Acts macht unmissverständlich klar, welche Inhalte mit jedem Produkt mitgeliefert werden müssen. Und wer glaubt, es reiche, irgendwo eine Bedienungsanleitung im PDF-Format abzulegen, sollte dringend weiterlesen.

Warum eine verpflichtende Dokumentation notwendig ist

Mit der zunehmenden Vernetzung von Produkten wachsen auch die Risiken für Hersteller als auch für Nutzer. Der CRA will dem entgegenwirken, indem er Transparenz schafft. Nutzer sollen in die Lage versetzt werden, Produkte mit digitalen Elementen sicher zu betreiben, zu aktualisieren und außer Betrieb zu nehmen. Gleichzeitig soll eine einheitliche Informationsbasis dafür sorgen, dass Schwachstellen zügig gemeldet und adressiert werden können. Für Hersteller bedeutet das, dass es ohne saubere Dokumentation keine Compliance gibt. Und ohne Compliance gibt es keinen Marktzugang.

Was genau dokumentiert werden muss

Der CRA zählt in Anhang II insgesamt neun Punkte auf, die zwingend mitgeliefert werden müssen. Was auf den ersten Blick nach formaler Bürokratie aussieht, entpuppt sich bei näherem Hinsehen als durchdachtes Set an Informationen, das Cybersicherheit im Produktlebenszyklus konkret unterstützt.

Zunächst müssen Hersteller ihre Kontaktdaten bereitstellen, inklusive Name, eingetragener Handelsname oder eingetragene Handelsmarke des Herstellers, Postanschrift, E-Mail-Adresse und gegebenenfalls Website. Klingt banal, wird aber erstaunlich oft vernachlässigt oder inkonsistent gepflegt. Wichtig ist hier vor allem eine dauerhafte Erreichbarkeit für Endnutzer oder auch Sicherheitsforscher und Behörden über den gesamten Unterstützungszeitraum.

Ein zentrales Element ist die sogenannte Schwachstellen-Kontaktstelle. Sie muss benannt werden, und es muss klar sein, wie Sicherheitslücken gemeldet werden können. Zudem muss das Konzept für koordinierte Offenlegung einsehbar sein. Wer hier keinen Plan hat, fällt durch. Die Pflicht gilt übrigens unabhängig davon, ob Schwachstellen „wahrscheinlich“ sind oder nicht. Es geht um das Vorhalten einer verlässlichen Meldekultur. Im letzten Beitrag sind wir in Punkt 5 bereits auf Möglichkeiten eingegangen. Wichtig ist hierbei, dass die dort vorgeschlagenen Punkte die Dokumentation nicht ersetzen.

Ebenfalls erforderlich ist die eindeutige Produktidentifikation. Das umfasst den Produktnamen, die Typenbezeichnung und weitere relevante Angaben. Seriennummer, Firmwarestand oder Modellvariante sind typische Kandidaten. Ziel ist es, im Fall einer Sicherheitslücke im Feld klar sagen zu können, welches Produkt betroffen ist.

Die Zweckbestimmung des Produkts muss ebenfalls beschrieben werden, und zwar inklusive der Sicherheitsumgebung. Hersteller müssen erklären, was das Produkt tun soll, in welchem Kontext es eingesetzt werden darf und welche Schutzmechanismen vorgesehen sind. Wichtig dabei: Auch die Hauptfunktionen und Sicherheitseigenschaften gehören dazu. Wer hier zu vage bleibt, riskiert Missverständnisse und im Zweifel eine fehlerhafte Nutzung.

Apropos fehlerhafte Nutzung: Auch alle bekannten oder vorhersehbaren Missbrauchsszenarien, die zu erheblichen Risiken führen können, müssen angegeben werden. Gemeint sind also nicht hypothetische Worst-Case-Szenarien, sondern realistische Fehlanwendungen, die sich aus der Nutzungspraxis ergeben können. Diese Frage lässt sich nur beantworten und dokumentieren, wenn die zugrundeliegende Risikoanalyse und -bewertung sauber durchgeführt wurde. An dieser Stelle sei nochmals auf die Methoden PASTA und STRIDE verwiesen, die wir in einem vorherigen Beitrag bereits vorgestellt haben.

Sofern vorhanden, muss die Internetadresse zur EU-Konformitätserklärung angegeben werden. Das ist eher ein formaler Punkt, aber ohne Verweis auf die Erklärung ist die Doku unvollständig.

Deutlich praxisrelevanter wird es beim Thema Sicherheitsunterstützung. Hersteller müssen angeben, welche technischen Hilfestellungen sie bereitstellen und wie lange Nutzer mit der Behebung von Schwachstellen sowie mit Sicherheitsaktualisierungen rechnen können. Der sogenannte Unterstützungszeitraum ist verbindlich und darf nicht offenbleiben. Wer keine klare Aussage dazu trifft oder den Zeitraum zu kurz wählt, erfüllt die Anforderungen des CRA nicht, selbst wenn das Produkt technisch weiterhin einwandfrei funktioniert.

Ein besonders umfangreicher Punkt betrifft die Anleitungen zur sicheren Nutzung. Hier verlangt der CRA eine klare Beschreibung von Maßnahmen zur Inbetriebnahme, zu sicherheitsrelevanten Änderungen, zur Installation von Updates, zur sicheren Außerbetriebnahme sowie zum Löschen von Nutzerdaten. Sogar das Deaktivieren der automatischen Sicherheitsupdates muss erklärt werden. Wer also bisher keine vollständige Lifecycle-Dokumentation hatte, muss gründlich nachrüsten.

Zu guter Letzt wird auch die Software-Stückliste relevant, wenn der Hersteller sie bereitstellt. In diesem Fall muss beschrieben werden, wo sie abrufbar ist. Auch wenn dies derzeit noch freiwillig ist, zeichnet sich ab, dass die SBOM zum künftigen Standard wird.

Die Umsetzung in der Praxis

Viele Unternehmen stehen nun vor der Herausforderung, diese Anforderungen strukturiert und effizient umzusetzen. Die gute Nachricht ist, dass es nicht darum geht, völlig neue Formate zu erfinden. Vielmehr können bestehende technische Dokumentationen erweitert und dem Endnutzer bereitgestellt werden. Wichtig ist ein zentraler Redaktionsprozess, der technische, rechtliche und sicherheitsrelevante Inhalte verzahnt. Auch eine dynamische Online-Doku kann hier helfen, vor allem wenn Updates regelmäßig eingepflegt werden müssen. Damit wird auch klar, dass die Erfüllung dieser Anforderungen nur in Zusammenarbeit aller notwendigen Abteilungen erfolgen kann. Produktentwicklung, Marketing, Legal sowie Service und Support müssen an einen Tisch, um sauber liefern zu können.

Wer jetzt denkt, das sei alles lästig, hat den eigentlichen Vorteil noch nicht erkannt. Eine gute Dokumentation schützt nicht nur den Nutzer, sondern auch den Hersteller. So zum Beispiel im Fall von Haftungsfragen oder bei Supporteinsätzen im Feld. Zudem lässt sich mit klaren Informationen auch Vertrauen schaffen. Und das kann im B2B-Umfeld entscheidend sein.

Fazit

Der CRA macht Schluss mit halbgaren Dokumentationen. Was mitgeliefert werden muss, ist klar geregelt und inhaltlich sinnvoll. Hersteller sollten nicht den Fehler machen, diesen Teil der Verordnung auf die leichte Schulter zu nehmen. Denn wer seine Nutzer im Dunkeln lässt, muss sich nicht wundern, wenn die Sicherheit am Ende auf der Strecke bleibt. Dokumentation wird zur Compliance-Pflicht – und zur Visitenkarte jedes digitalen Produkts.

Nehmen Sie sich daher jetzt die Zeit für eine ehrliche Bestandsaufnahme. Prüfen Sie, welche Anforderungen Sie bereits erfüllen und wo noch Handlungsbedarf besteht. Gerne unterstützen wir Sie mit unserem CRA-Workshop. Praxisnah, kompakt und mit klarem Fahrplan für die Umsetzung.