Cyber Resilience Act | Produktpflichten und Nachweise

Die Arbeit am Cyber Resilience Act (CRA) ist nicht erledigt, wenn eine Anforderung in einer Tabelle steht. Ein Produktteam muss wissen, für welches Produkt die Anforderung gilt, wer die Arbeit verantwortet, wann sie fällig ist, warum eine Entscheidung getroffen wurde und wo die Nachweise liegen.

Die CRA-Meldepflichten gelten seit 11. September 2026. Der Hauptteil der Verordnung gilt ab 11. Dezember 2027. Ein Teil des Betriebsmodells muss deshalb bereits jetzt funktionieren. Der Rest sollte früh genug aufgebaut werden, damit die technische Dokumentation nicht am Ende rekonstruiert werden muss.

Wichtige CRA-Termine

Datum	Was sich ändert
11. September 2026	Die Meldepflichten nach Artikel 14 gelten
11. Dezember 2027	Die wesentlichen CRA-Pflichten gelten

Bei meldepflichtigen Ereignissen beginnt die Frist, wenn der Hersteller Kenntnis erlangt. Die Kommission beschreibt eine Frühwarnung innerhalb von 24 Stunden und eine vollständige Meldung innerhalb von 72 Stunden. Die Frist für den Abschlussbericht unterscheidet sich zwischen einer aktiv ausgenutzten Schwachstelle und einem schwerwiegenden Vorfall.

Praktischen CRA-Meldeablauf für 24 und 72 Stunden ansehen

Beim CRA geht es um ein Produkt, nicht um einen abstrakten Compliance-Wert für das gesamte Unternehmen

Die erste hilfreiche Frage lautet: Welches konkrete Produkt mit digitalen Elementen bewerten wir?

Die Verordnung erfasst Software- und Hardwareprodukte sowie unter bestimmten Bedingungen deren Datenfernverarbeitungslösungen. Auch die Rolle der Organisation ist wichtig: Hersteller, Bevollmächtigter, Einführer, Händler oder ein Akteur, der eine wesentliche Änderung vornimmt.

Beginnen Sie mit einer Aufzeichnung für ein Produkt:

Produktname und eindeutige Kennung;
Fassung oder Release-Familie;
Hersteller und Marke, unter der das Produkt bereitgestellt wird;
Art der Bereitstellung auf dem EU-Markt;
Zweckbestimmung und Hauptfunktionen;
Komponenten und Abhängigkeiten;
für Produktfunktionen erforderliche entfernte Dienste;
Unterstützungszeitraum;
Verantwortliche für Produktsicherheit, Schwachstellen und Releases.

Prüfen, wie der CRA-Anwendungsbereich für ein Produkt bewertet wird

Sieben Bereiche, die verbunden sein müssen

1. Anwendungsbereich

Bestimmen Sie, ob das Produkt und die Rolle der Organisation unter den CRA fallen. Eine Bezeichnung wie „SaaS“, „IoT“ oder „Software“ ist keine Bewertung des Anwendungsbereichs.

2. Produktrisiko

CRA-Anforderungen sind mit einer Bewertung der Cybersicherheitsrisiken des Produkts verbunden. Diese Bewertung sollte an eine Produktfassung gebunden bleiben und bei Änderungen der Architektur, der Zweckbestimmung oder des Risikos überprüft werden.

3. Security by Design und sichere Voreinstellungen

Eine Anforderung muss in Entwicklungsarbeit übergehen: eine Designentscheidung, eine Maßnahme, eine verantwortliche Person, ein Test, eine Prüfung und Nachweise.

Zu Security by Design im CRA

4. Schwachstellen und SBOM

Der CRA verlangt von Herstellern, Schwachstellen und Produktkomponenten zu ermitteln und zu dokumentieren. Dazu gehört die Erstellung einer Software-Stückliste (Software Bill of Materials, SBOM) in einem gängigen, maschinenlesbaren Format, das mindestens die Abhängigkeiten auf oberster Ebene abdeckt.

Warum eine SBOM den Prozess eröffnet und nicht abschließt

5. Meldungen

Die einheitliche CRA-Meldeplattform (Single Reporting Platform, SRP) ist seit dem 11. September 2026 in Betrieb. In der Praxis braucht ein Hersteller mehr als einen Portalzugang: einen klaren T0, Eskalationskriterien, eine verantwortliche Person, eine Vertretung und die Informationen, die für die Einreichung einer Meldung erforderlich sind.

6. Technische Dokumentation

Technische Dokumentation sollte kein Archiv unverbundener Dateien sein. Produkt, Fassung, Architektur, Risikobewertung, Schwachstellenbehandlung, Tests, Entscheidungen und die Grundlage des Unterstützungszeitraums müssen nachvollziehbar sein.

Praktische Struktur einer technischen CRA-Dokumentation ansehen

7. Unterstützungszeitraum

Der Hersteller bestimmt einen Unterstützungszeitraum anhand der erwarteten Nutzung und der im CRA festgelegten Kriterien. Grundsätzlich beträgt er mindestens fünf Jahre, sofern das Produkt voraussichtlich nicht für einen kürzeren Zeitraum genutzt wird.

Unterstützungszeitraum dokumentieren

Wo kleinere Organisationen Schwierigkeiten haben

Die CRA-Umfrage von ENISA unter KMU aus dem Jahr 2026 zeigt die Lücke zwischen Kenntnis und Umsetzung. In einer freiwilligen Stichprobe mit 194 Antworten kannten 66 % den CRA. Zugleich berichteten 54 % von begrenzten oder fehlenden Kenntnissen der Konformitätsbewertung und 42 % von begrenzten oder fehlenden Kenntnissen der erforderlichen Dokumentation. 73 % der Befragten wählten Unterstützung bei der technischen Dokumentation aus.

Die Umfrage sollte nicht als repräsentative Schätzung für den gesamten EU-Markt behandelt werden: Es handelt sich um eine kleine, freiwillige Stichprobe. Als Hinweis bleibt sie dennoch nützlich: Das Problem besteht nicht allein darin, „zu wissen, dass es den CRA gibt“. Teams brauchen wiederholbare Betriebsprozesse.

Prüfen Sie die Lücken im eigenen Produktprogramm anhand konkreter Vorgänge: einer Freigabe, einer Schwachstellenmeldung und einer Entscheidung zum Unterstützungszeitraum. Wer hat entschieden, welche Version war betroffen und welche Nachweise lagen vor? Eine Datei beantwortet die Frage nur, wenn ihr Umfang zur Entscheidung passt. Halten Sie fehlende oder ungeeignete Nachweise mit Verantwortlichen und nächstem Prüfschritt fest. Diese vorgeschlagene Diagnose bewertet den Arbeitsablauf Ihrer Organisation; sie ist keine aus einer Marktumfrage abgeleitete Aussage zur allgemeinen Vorbereitung.

Bewerten Sie die Ergebnisse anhand Ihrer Produktdaten und der geprüften Anforderungen. Eine dokumentierte Lücke erhält eine konkrete Maßnahme; allgemeine Annahmen über andere Unternehmen ersetzen diese Prüfung nicht.

Ein Produktprogramm aufbauen, das die Entwicklung nutzen kann

Der folgende Ablauf ist unsere praktische Empfehlung. Er ergänzt die Umsetzung, schafft aber keine zusätzlichen gesetzlichen Pflichten. Geben Sie dem Programm zuerst eine Produktgrenze, eine verantwortliche Leitung und konkrete Ergebnisse. Ein Hersteller mit drei Produkten braucht Entscheidungen für jedes Produkt. Gemeinsame Verfahren dürfen gemeinsam bleiben. Drei kopierte Richtlinien zur Vorfallsbearbeitung werden sonst unterschiedlich aktualisiert, obwohl alle dieselbe organisatorische Regel beschreiben sollen.

Wählen Sie das erste Produkt anhand eines nachvollziehbaren Kriteriums: laufende Nutzung, Sicherheitsrisiko, wirtschaftliche Bedeutung oder bevorstehendes Release. Das einfachste Produkt verbessert möglicherweise nur die Anzeige im Bericht. Das schwierigste Produkt ohne eingeplante Entwicklungszeit kann dagegen die gesamte Arbeit blockieren. Halten Sie den Auswahlgrund fest. Verwenden Sie anschließend dessen vollständige Nachweiskette als Arbeitsbeispiel für weitere Produkte, statt nur den Ordner zu kopieren.

Das Programm hat eine technische und eine organisatorische Ebene. Die technische Ebene beschreibt Architektur, Fassungen, Komponenten, Zweckbestimmung und Annahmen zur Unterstützung. Die organisatorische Ebene beschreibt, wer einen Vorfall bewertet, ein Release genehmigt, einen Lieferanten erreicht und Aufzeichnungen pflegt. Beide Ebenen sind nötig. Ein detailliertes Architekturdiagramm sagt noch nicht, wer am Freitagabend eine eingegangene Schwachstellenmeldung bearbeitet oder die erforderliche Entscheidung treffen darf.

Aktuelle Aufgaben von der Vorbereitung auf 2027 trennen

Am 2. Oktober 2026 liegt der Beginn der Meldepflichten bereits in der Vergangenheit. Ein Plan, der sämtliche CRA-Arbeiten auf Ende 2027 verschiebt, verfehlt deshalb eine aktuelle Pflicht. Prüfen Sie zuerst den Anwendungsbereich bestehender Produkte und den Meldeablauf. Bereiten Sie parallel die Entwicklung und Dokumentation für die weiteren Anforderungen vor. Diese Reihenfolge ist eine Umsetzungsempfehlung. Die gesetzlichen Termine und Übergangsregeln bleiben unverändert maßgeblich.

Bilden Sie dafür zwei miteinander verbundene Arbeitspakete. Das aktuelle Paket behandelt überwachte Eingangskanäle, Kenntniserlangung, Einstufungsverantwortung, Zugang zur Meldeplattform und Vertretung. Das Vorbereitungspaket behandelt wesentliche Anforderungen, Risikobewertung, Schwachstellenbehandlung, technische Dokumentation und Unterstützungszeitraum. Zeigen Sie die Abhängigkeiten zwischen den Paketen. Ein Meldeverfahren kann betroffene Produktfassungen nicht zuverlässig nennen, wenn niemand das Verzeichnis dieser Fassungen pflegt oder die ausgelieferten Komponenten zuordnet.

Prüfen Sie den Plan bei geänderten Annahmen und nicht ausschließlich im monatlichen Treffen. Das Unterstützungsende eines Lieferanten, eine Übernahme, eine neue Anwendung oder eine wesentliche Produktänderung kann mehrere Entscheidungen gleichzeitig betreffen. Eine kurze Änderungsbewertung benennt die betroffenen Aufzeichnungen und zuständigen Menschen. Eine steigende Prozentzahl im Fortschrittsbericht zeigt der Leitung weder diese Abhängigkeit noch den tatsächlichen Aufwand, der dadurch neu entsteht.

Nachweise während der Arbeit erstellen

Bewahren Sie für wichtige Entscheidungen das Ausgangsmaterial und eine kurze Begründung auf. Wenn eine Anforderung als nicht anwendbar bewertet wird, müssen die dafür maßgeblichen Produkteigenschaften sichtbar sein. Bei einem bestandenen Test gehören Release und Testbedingungen zur Aufzeichnung. Bei verschobener Behebung gehören Risiko, entscheidende Person und nächster Prüftermin dazu. Diese empfohlenen Arbeitsweisen machen die Entscheidungen des Herstellers später erklärbar, ohne jede Besprechung vollständig protokollieren zu müssen.

Ein Nachweis sollte für jemanden außerhalb des ursprünglichen Projekts verständlich sein. Eine Bildschirmaufnahme mit dem Titel „Sicherheit erledigt“ beschreibt weder Konfiguration noch Umfang oder Fassung. Ein Bericht, der die Ablehnung eines nicht autorisierten Updatepakets durch Release 2.6 unter genannten Bedingungen zeigt, ist genauer. Seine Aussage bleibt begrenzt. Er belegt dieses Verhalten und nicht automatisch die Erfüllung aller anderen Sicherheitsanforderungen des Produkts oder sämtlicher Prozesse des Herstellers.

Vergeben Sie stabile Kennungen für Nachweise. Für ein kleines Team können Dateiname, Release-Kennung, Ablageort und Datum ausreichen, sofern die Unterlagen kontrolliert und erreichbar bleiben. Größere Organisationen benötigen möglicherweise einen formalen Index und Freigabeablauf. Das Ziel ist keine bestimmte Software und keine hohe Dokumentenzahl. Das Team muss den richtigen Nachweis finden können, ohne die Person anzurufen, die ihn vor Monaten zufällig erstellt hat.

Hypothetisches Beispiel eines industriellen Gateways

Ein kleiner, hypothetischer Hersteller verkauft ein Netzwerk-Gateway mit eingebetteter Software und einem optionalen Überwachungsdienst aus eigener Entwicklung. Die Produktaufzeichnung beginnt beim Gateway. Das Team beschreibt, welche Funktionen den entfernten Dienst benötigen, welche Software mit der Hardware ausgeliefert wird und welche Gesellschaft das Produkt auf den EU-Markt bringt. Diese Tatsachen tragen die Bewertung des Anwendungsbereichs. Das Beispiel bedeutet ausdrücklich nicht, dass jeder Cloud-Dienst vom CRA erfasst wird.

Die Risikobewertung des Gateways nennt unbefugte Konfigurationsänderungen und eine Unterbrechung des Updatevorgangs als relevante Szenarien. Die Entwicklung verbindet diese Risiken mit Authentifizierung, Updateprüfung und Wiederherstellungsverhalten. Der Einkauf dokumentiert Wartungszusagen für Komponenten. Das Produktmanagement untersucht die erwartete Nutzung in Industrieanlagen. Der Kundendienst richtet den Eingang für Schwachstellenmeldungen ein. Die Tätigkeiten greifen ineinander. Daher brauchen die Aufzeichnungen gemeinsame Produkt- und Release-Kennungen und nicht fünf unverbundene Listen.

Später wird eine Schwachstelle einer Komponente bekannt, die ein unterstütztes Release betrifft. Das Team prüft, ob die verwundbare Funktion vorhanden und erreichbar ist, bewertet die Produktauswirkung und untersucht die Kriterien des Artikels 14. Ein Korrekturticket allein erklärt die regulatorische Entscheidung nicht. Umgekehrt ersetzt eine Meldung keine technische Behebung. Der Fall verbindet Entscheidung, Änderung, Prüfung und Kommunikation. Daraus wird weder ein behaupteter Kundenerfolg noch eine pauschale Aussage über Produktkonformität abgeleitet.

Zuständigkeit ohne eine zweite Organisation festlegen

In einem kleinen Betrieb kann ein Gründer die Produktverantwortung übernehmen, eine erfahrene Entwicklerin die technische Ersteinschätzung und ein Qualitätsverantwortlicher die Aufzeichnungen. Eine Person darf mehrere Aufgaben haben. Verfügbarkeit, Entscheidungsbefugnis und Vertretung müssen trotzdem ausdrücklich vereinbart werden. Wer eine Bewertung vorbereitet, muss wissen, wann eine Genehmigung nötig ist. Ebenso muss klar sein, wer diese Genehmigung erteilen kann, wenn die normalerweise zuständige Person nicht erreichbar ist.

Binden Sie Lieferanten früh in den Ablauf ein. Fragen Sie nach Informationen, die für das konkrete Produkt benötigt werden: Komponentenkennung, unterstützte Fassungen, Schwachstellenkontakt, Updateverfügbarkeit und einschlägige vertragliche Zusagen. Ein allgemeiner Fragebogen mit Hunderten Fragen kann Zeit verbrauchen, ohne eine dieser Tatsachen festzustellen. Fehlende Informationen werden eskaliert, wenn sie eine Entscheidung verhindern. Halten Sie die Lücke sichtbar. Eine fehlende Antwort darf nicht stillschweigend als positive Zusage des Lieferanten gelten.

Die Leitung benötigt eine Schätzung für Einführung und laufenden Betrieb. Trennen Sie Entwicklungsänderungen, Releasetests, Dokumentationspflege und Unterstützungsaufgaben. Diese Arbeiten haben unterschiedliche Zuständigkeiten und Kosten. Ein einmaliges Budget zum Schreiben von Richtlinien finanziert keine mehrjährige Schwachstellenbehandlung. Verwenden Sie produktbezogene Annahmen und halten Sie deren Unsicherheit fest. Passen Sie die Schätzung an, sobald Architektur, Komponentenwartung oder erwartete Nutzungsdauer genauer bekannt sind oder sich nach einer Produktänderung verschieben.

Fortschritt anhand vollständiger Fälle prüfen

Wir empfehlen, für die regelmäßige Prüfung ein tatsächliches Release und einen Schwachstellenfall auszuwählen. Beim Release folgen Sie dem Weg von der anwendbaren Anforderung über Risiko, Umsetzung und Test bis zur freigegebenen Aufzeichnung. Beim Schwachstellenfall prüfen Sie Eingang, Produktauswirkung, Entscheidung und Korrektur. Fehlt eine Verbindung, entsteht eine konkrete Verbesserungsaufgabe. Das ist für die Umsetzung hilfreicher als ein allgemeiner Reifegrad, dessen Zusammensetzung niemand im Entwicklungsteam erklären kann.

Interne Kennzahlen können Produkte mit genehmigter Bewertung des Anwendungsbereichs, unterstützte Releases mit identifizierbaren Komponentenaufzeichnungen, überfällige Sicherheitsmaßnahmen und geübte Vertretungen im Meldeablauf zeigen. Nennen Sie stets die Bezugsmenge. Zehn erstellte SBOM-Dateien sagen wenig, wenn zwanzig Produkte betreut werden und nur eines brauchbare Release-Aufzeichnungen hat. Solche Kennzahlen beschreiben die Durchführung des Programms. Sie sind kein eigenständiger Konformitätsnachweis und sollten nicht als solcher in Verkaufsunterlagen verwendet werden.

Die erste Leitungsprüfung muss ausführbare Entscheidungen hinterlassen: Welche Produktgrenze ist zu klären? Welche technische Änderung wird finanziert? Wer beschafft einen fehlenden Nachweis? Wann wird der Meldeablauf geübt? Eine kurze und genaue Aufgabenliste ist wertvoller als eine elegante Aussage, die Organisation sei „CRA-bereit“. Der Zustand muss bei einer konkreten Produktfrage und bei einem tatsächlichen Ereignis bestehen. Vergeben Sie daher für jede offene Entscheidung eine verantwortliche Person und einen überprüfbaren nächsten Termin.

Wo Pulsar GRC passt

Pulsar GRC verbindet Arbeit, die häufig über Dokumente, Tabellen, Tickets und E-Mails verteilt ist:

Anforderung → Risiko → Kontrolle oder Maßnahme → verantwortliche Person → Fälligkeit → Dokument oder Nachweis → Prüfung → Entscheidungshistorie.

Pulsar verbindet Audits, Kontrollen, Risiken, Dokumente, Nachweise, Berichte, CAPA, Lieferanten und Aufgaben. Das hilft beim Durchführen und Nachweisen eines Prozesses, ohne vorzugeben, dass die Software die rechtliche Einstufung für den Kunden übernimmt.

Pulsar zertifiziert keine CRA-Konformität, ersetzt keine rechtliche Bewertung und entscheidet nicht selbstständig, ob ein Ereignis gemeldet werden muss. Entscheidungen zum Anwendungsbereich, die regulatorische Einstufung und die Entscheidung zur Einreichung bleiben bei verantwortlichen Menschen.

Beginnen Sie mit einem Produkt

Beginnen Sie nicht mit einem Programm namens „CRA im gesamten Unternehmen umsetzen“. Wählen Sie ein tatsächliches Produkt. Definieren Sie seinen Anwendungsbereich, Verantwortliche, aktuelle Risiken, Schwachstellenablauf, Dokumentation und Unterstützungszeitraum. Dort werden bearbeitbare Lücken sichtbar.

Pulsar GRC an einem operativen Ablauf ansehen

Quellen

Quellen geprüft: 2. Oktober 2026.