CRA-Herstellerpflichten: Was Hersteller jetzt konkret umsetzen müssen

Hersteller tragen im Cyber Resilience Act die umfassendste Verantwortung. Sie müssen Produkte mit digitalen Elementen risikogerecht sicher konzipieren, entwickeln und herstellen, eine Cybersicherheitsrisikobewertung dokumentieren, Schwachstellen während des Supportzeitraums behandeln, technische Unterlagen erstellen, das passende Konformitätsbewertungsverfahren durchführen und die vorgeschriebenen Informationen bereitstellen.

Den Gesamtzusammenhang aus Anwendungsbereich, Fristen, Rollen und Nachweisen bündelt der zentrale CRA-Leitfaden. Diese Seite konzentriert sich auf die Pflichten des Herstellers und verknüpft sie mit Konformitätsbewertung und CE sowie den Meldepflichten bei Schwachstellen und Sicherheitsvorfällen.

Umsetzungspaket: Das CRA Compliance Masterpaket bündelt Risikobewertung, SBOM, Reporting, Supportzeitraum, Lieferantenprüfung, technische Dokumentation und Projektplan in einer gemeinsamen Arbeitsstruktur.

Einordnung im CRA-Wissen: Dieser Fachartikel gehört zum Themenbereich Rollen & Pflichten. Dort finden Sie die angrenzenden Anforderungen und eine praktische Reihenfolge für die Umsetzung.

Für die organisatorische Umsetzung helfen eine klare PSIRT-Funktion und eine CVD-Policy für externe Sicherheitsmeldungen. Wird ein Vertreter eingesetzt, müssen die Aufgaben und Grenzen des schriftlichen Mandats eines CRA-Bevollmächtigten eindeutig geregelt sein.

Welche Pflichten haben Hersteller nach dem CRA?

Die Herstellerpflichten stehen vor allem in Artikel 13 und werden durch die Anhänge I, II und VII ergänzt. Der Hersteller muss bei der Markteinführung gewährleisten, dass das Produkt die grundlegenden Cybersicherheitsanforderungen erfüllt. Gleichzeitig müssen die Prozesse für den Umgang mit Schwachstellen den Anforderungen entsprechen.

Die Pflichten lassen sich in acht Arbeitsbereiche aufteilen: Produktklassifizierung, Cybersicherheitsrisikobewertung, sichere Produktentwicklung, Komponenten- und Lieferkettenmanagement, Schwachstellenbehandlung, Support und Sicherheitsupdates, technische Dokumentation sowie Konformitätsbewertung und Marktinformationen.

Wie beginnt die CRA-Risikobewertung?

Die Risikobewertung ist der Ausgangspunkt. Hersteller müssen die Cybersicherheitsrisiken eines Produkts bewerten und das Ergebnis in Planung, Konzeption, Entwicklung, Herstellung, Lieferung und Wartung berücksichtigen. Die Bewertung soll sich auf die bestimmungsgemäße und vernünftigerweise vorhersehbare Verwendung beziehen und die Betriebsumgebung sowie schützenswerte Werte berücksichtigen.

Eine brauchbare Risikobewertung ist deshalb produktbezogen. Eine allgemeine Unternehmens-Risikomatrix reicht nicht aus, wenn daraus nicht hervorgeht, welche Angriffswege, Schutzgüter, Nutzerrollen und Sicherheitsmaßnahmen für das konkrete Produkt relevant sind.

Welche Informationen gehören in die Risikobewertung?

Mindestens sinnvoll sind Produktzweck, Nutzergruppen, Schnittstellen, Datenflüsse, Remote-Dienste, Authentifizierungswege, Updatekanäle, Abhängigkeiten, Betriebsumgebung, mögliche Fehlanwendung und die Auswirkungen eines Sicherheitsvorfalls. Daraus werden technische und organisatorische Sicherheitsanforderungen abgeleitet.

Die Bewertung muss nachvollziehbar erklären, welche Anforderungen aus Anhang I anwendbar sind, wie sie umgesetzt wurden und warum einzelne Punkte gegebenenfalls nicht einschlägig sind. Diese Begründung gehört in die technische Dokumentation.

Was verlangt Secure by Design?

Secure by Design bedeutet, dass Sicherheitsanforderungen in die Produktarchitektur und Entwicklung eingebaut werden. Das Produkt soll ein angemessenes Cybersicherheitsniveau auf Basis der Risiken bieten. Sicherheitsfunktionen dürfen nicht bloß nachträglich „aufgesetzt“ werden, wenn grundlegende Architekturentscheidungen bereits unsichere Zustände erzeugen.

Welche technischen Themen sind typisch?

Je nach Produkt gehören dazu sichere Authentifizierung, Rollen- und Rechtekonzepte, Schutz vertraulicher Daten, Integritätsschutz, sichere Kommunikation, Begrenzung von Schnittstellen, Protokollierung sicherheitsrelevanter Ereignisse, Schutz vor Manipulation, robuste Fehlerbehandlung und ein sicherer Updateweg.

Der CRA schreibt nicht für jedes Produkt denselben Algorithmus oder dieselbe technische Lösung vor. Die Maßnahmen müssen zum Risiko passen und begründet werden können.

Was bedeutet Secure by Default?

Produkte sollen in einer sicheren Standardkonfiguration bereitgestellt werden. Der Nutzer darf nicht erst mehrere kritische Sicherheitsoptionen aktivieren müssen, um einen angemessenen Grundschutz zu erreichen. Standardpasswörter wie „admin/admin“, unnötig offene Netzwerkdienste oder deaktivierte Sicherheitsupdates sind deshalb besonders kritisch.

Hersteller sollten für jedes Produkt dokumentieren, welche sicherheitsrelevanten Standardeinstellungen gewählt wurden und warum. Wenn ein Geschäftskunde abweichende Einstellungen ausdrücklich vereinbart, sollte auch das nachvollziehbar dokumentiert werden.

Welche Rolle spielt die SBOM?

Der CRA verlangt, Schwachstellen und Komponenten zu ermitteln und zu dokumentieren. Dazu gehört eine Software-Stückliste, häufig SBOM genannt, in einem gängigen maschinenlesbaren Format, die zumindest die obersten Abhängigkeiten enthält.

Eine SBOM ist mehr als eine einmal erzeugte Liste. Sie muss zu Produktversionen passen und für Vulnerability Handling nutzbar sein. Wenn eine neue Schwachstelle in einer Bibliothek veröffentlicht wird, sollte ein Hersteller schnell beantworten können: Welche Produkte enthalten die Komponente? In welcher Version? Ist die Schwachstelle im konkreten Einsatz ausnutzbar? Welche Produktversion benötigt ein Update?

Wie wird die SBOM in den Prozess eingebaut?

Am besten wird die SBOM automatisiert im Build- oder Releaseprozess erzeugt. Sie erhält eine eindeutige Zuordnung zu Produkt, Version und Build. Änderungen an Abhängigkeiten werden nachvollziehbar. Zusätzlich braucht es einen Prozess, der neue Sicherheitsinformationen gegen die verwendeten Komponenten prüft.

Welche Sorgfalt gilt bei Drittkomponenten?

Hersteller müssen bei der Integration von Komponenten Dritter die gebotene Sorgfalt anwenden, damit diese die Cybersicherheit des Gesamtprodukts nicht beeinträchtigen. Das gilt auch für freie und quelloffene Software, die selbst möglicherweise nicht kommerziell bereitgestellt wird.

Für Einkauf und Entwicklung bedeutet das: Sicherheitsstatus, Wartungsaktivität, bekannte Schwachstellen, Supportperspektive, Lizenz, Updatefähigkeit und verfügbare Sicherheitsinformationen sollten bei kritischen Komponenten bewertet werden. Ein beliebtes Paket ist nicht automatisch ein geeigneter Langzeitbaustein für ein Produkt mit mehrjährigem Support.

Wie muss Vulnerability Handling organisiert sein?

Hersteller müssen Schwachstellen unverzüglich behandeln und beheben, soweit dies im Hinblick auf das Risiko erforderlich ist. Sicherheitsaktualisierungen sollen bereitgestellt werden. Soweit technisch machbar, sollen neue Sicherheitsupdates getrennt von Funktionsupdates angeboten werden.

Ein vollständiger Prozess umfasst Eingang, Triage, technische Analyse, Risikobewertung, Entscheidung, Entwicklung der Korrektur, Test, Veröffentlichung, Nutzerinformation und gegebenenfalls CRA-Meldung. Für externe Sicherheitsforscher und Kunden braucht es eine klar erkennbare Kontaktmöglichkeit.

Was ist eine koordinierte Offenlegung von Schwachstellen?

Hersteller sollten eine Policy für die koordinierte Offenlegung bereitstellen. Darin wird beschrieben, wie Sicherheitsforscher Schwachstellen melden können, welche Informationen hilfreich sind, wie der Hersteller reagiert und wie Veröffentlichung und Patch aufeinander abgestimmt werden.

Die zentrale Kontaktstelle darf Nutzer nicht ausschließlich auf automatisierte Tools beschränken. Der CRA verlangt eine Möglichkeit zur direkten und schnellen Kommunikation.

Welche Tests verlangt der CRA?

Anhang I Teil II verlangt, die Sicherheit des Produkts regelmäßig und wirksam zu testen und zu überprüfen. Welche Testmethoden angemessen sind, richtet sich nach Produkt und Risiko. Für ein vernetztes Gerät kann das andere Prüfungen bedeuten als für eine lokale Desktopanwendung.

Typische Bausteine sind Codeanalyse, Dependency Scanning, Architekturreviews, Sicherheitsanforderungstests, Penetrationstests für relevante Angriffsflächen, Fuzzing bei geeigneten Schnittstellen, Update- und Rollbacktests sowie Tests sicherer Standardkonfigurationen. Entscheidend ist nicht die Zahl der Tools, sondern ob die relevanten Risiken abgedeckt und Ergebnisse nachvollziehbar behandelt werden.

Wie wird der Supportzeitraum festgelegt?

Hersteller müssen einen Supportzeitraum bestimmen, während dessen Schwachstellen des Produkts wirksam behandelt werden. Bei der Festlegung sind unter anderem erwartete Nutzungsdauer, Art des Produkts, Nutzererwartungen und Verfügbarkeit vergleichbarer Produkte zu berücksichtigen.

Das Enddatum des Supportzeitraums muss beim Kauf klar und verständlich angegeben werden, mindestens mit Monat und Jahr. Daraus entsteht eine direkte Verbindung zwischen Produktstrategie und Security-Ressourcen. Ein langer erwarteter Lebenszyklus ohne Wartungsbudget passt nicht zu dieser Pflicht.

Was sollte intern zum Supportzeitraum dokumentiert werden?

Dokumentiert werden sollten die Annahmen zur Nutzungsdauer, die technische Updatefähigkeit, die geplanten Sicherheitsressourcen, Abhängigkeiten von Drittkomponenten und die Kommunikation an Nutzer. Wenn sich die Produktstrategie ändert, sollte geprüft werden, ob die ursprüngliche Festlegung noch tragfähig ist.

Wie lange müssen Unterlagen aufbewahrt werden?

Die technische Dokumentation und die EU-Konformitätserklärung müssen grundsätzlich mindestens zehn Jahre nach Inverkehrbringen oder für die Dauer des Supportzeitraums aufbewahrt werden, je nachdem, welcher Zeitraum länger ist. Auch Nutzerinformationen müssen entsprechend lange zugänglich bleiben.

Für digitale Produkte mit häufigen Versionen ist deshalb Versionsdisziplin wichtig. Es muss später erkennbar sein, welche Dokumentation zu welcher Produktversion und welchem Markteinführungszeitpunkt gehörte.

Welche Informationen müssen Nutzer erhalten?

Anhang II enthält die Informationen und Anleitungen, die dem Produkt beigefügt werden müssen. Dazu zählen Herstellerangaben, Kontaktmöglichkeiten, die zentrale Stelle für Schwachstellenmeldungen, Produktidentifikation, Zweckbestimmung, Sicherheitsumgebung, sicherheitsrelevante Eigenschaften und Hinweise zur sicheren Installation, Nutzung und Wartung.

Die Informationen müssen klar, verständlich und in einer für Nutzer und Marktüberwachungsbehörden leicht verständlichen Sprache bereitgestellt werden. Sie dürfen nicht nur technisch korrekt sein, sondern müssen eine sichere Nutzung tatsächlich ermöglichen.

Was gehört in die technische Dokumentation?

Die technische Dokumentation nach Artikel 31 und Anhang VII soll zeigen, wie Produkt und Prozesse die CRA-Anforderungen erfüllen. Sie enthält typischerweise eine allgemeine Produktbeschreibung, Design- und Entwicklungsinformationen, die Cybersicherheitsrisikobewertung, angewandte Standards oder Spezifikationen, Prüfungen, Ergebnisse und Unterlagen zur Schwachstellenbehandlung.

Eine gute Produktakte wird während der Entwicklung aufgebaut. Architekturentscheidungen, Risikobehandlungen, Testberichte und Releaseinformationen werden fortlaufend verknüpft. Das reduziert Aufwand und verbessert die Beweiskette.

Wann kommt die Konformitätsbewertung?

Vor dem Inverkehrbringen muss der Hersteller das geeignete Konformitätsbewertungsverfahren durchführen oder durchführen lassen. Welcher Weg zulässig ist, hängt von der Produktkategorie und von verwendeten harmonisierten Normen beziehungsweise anderen Konformitätsgrundlagen ab.

Nach erfolgreicher Bewertung erstellt der Hersteller die EU-Konformitätserklärung und bringt die CE-Kennzeichnung an. Für wichtige und kritische Produkte gelten teilweise strengere Regeln. Die Details stehen im Ratgeber CRA-Konformitätsbewertung und CE-Kennzeichnung.

Welche Pflichten gelten nach der Markteinführung?

CRA-Compliance endet nicht mit dem Verkauf. Hersteller müssen während des Supportzeitraums Schwachstellen behandeln, Sicherheitsupdates bereitstellen, Produktänderungen bewerten, Konformität in der Serienproduktion sicherstellen und auf neue Sicherheitsinformationen reagieren.

Ab 11. September 2026 kommen die Meldepflichten für aktiv ausgenutzte Schwachstellen und schwere Sicherheitsvorfälle hinzu. Der Prozess dafür ist unter CRA-Meldepflichten beschrieben.

Wie kann ein Hersteller die CRA-Umsetzung in Arbeitspakete teilen?

Welche typischen Fehler verursachen später Mehrarbeit?

Risikobewertung erst am Ende erstellen

Dann dokumentiert die Bewertung nur noch bestehende Entscheidungen, statt sie zu steuern. Sicherheitslücken in der Architektur werden teuer.

SBOM ohne Prozess erzeugen

Eine statische Liste erfüllt ihren praktischen Zweck nicht, wenn neue Schwachstellen nicht gegen Produktversionen geprüft werden.

Security Updates nicht unabhängig planen

Wenn ein Sicherheitsfix nur zusammen mit einem großen Funktionsrelease ausgeliefert werden kann, steigen Reaktionszeit und Risiko. Der CRA bevorzugt soweit technisch machbar eine Trennung.

Lieferanten nicht einbinden

Ohne vertraglich und technisch geregelte Sicherheitsinformationen können Hersteller Schwachstellen in Komponenten kaum innerhalb kurzer Fristen bewerten.

Supportzeitraum nur aus Marketing ableiten

Der Zeitraum muss technisch und organisatorisch tragfähig sein. Produktversprechen und Wartungsfähigkeit müssen zusammenpassen.

Welche Nachweise sollten Hersteller laufend sammeln?

Viele CRA-Projekte werden unnötig teuer, weil Nachweise erst kurz vor der Konformitätsbewertung zusammengesucht werden. Besser ist ein Evidence-by-Design-Ansatz: Jede sicherheitsrelevante Entscheidung, Prüfung und Freigabe erzeugt direkt einen verwertbaren Nachweis.

Dazu gehören beispielsweise freigegebene Architekturstände, dokumentierte Risikobewertungen, Security-Anforderungen, Ergebnisse automatisierter Tests, Penetrationstest-Berichte, SBOMs je Release, Schwachstellen-Tickets, Patchentscheidungen, Lieferanteninformationen, Supportentscheidungen und Freigaben für Produktversionen.

Wer sollte für welche Nachweise verantwortlich sein?

Die Verantwortung sollte dort liegen, wo die Information entsteht. Entwicklung dokumentiert technische Änderungen, Security bewertet Risiken und Schwachstellen, Produktmanagement hält Zweckbestimmung und Supportannahmen fest, Einkauf pflegt sicherheitsrelevante Lieferantenanforderungen und Compliance führt die Nachweise für die Konformitätsbewertung zusammen.

Warum ist Versionsbezug so wichtig?

Ein Nachweis ohne Produkt- oder Versionsbezug verliert schnell seinen Wert. Hersteller sollten jederzeit erkennen können, welche Risikobewertung, SBOM, Testergebnisse und Freigaben zu einer bestimmten ausgelieferten Version gehören. Gerade bei Software mit häufigen Releases verhindert diese Zuordnung, dass alte und neue Nachweise vermischt werden.

Wie lässt sich das ohne zusätzliche Bürokratie lösen?

Bestehende Entwicklungswerkzeuge können genutzt werden. Tickets, Pull Requests, CI/CD-Protokolle, Artefakt-Repositories und Freigabeworkflows enthalten bereits viele Informationen. Entscheidend ist, verbindlich festzulegen, welche Daten aufbewahrt und wie sie einer Produktversion zugeordnet werden.

Was sollten Hersteller 2026 zuerst erledigen?

Erstens muss die Meldefähigkeit für den 11. September 2026 hergestellt sein. Zweitens sollte das Produktportfolio vollständig klassifiziert werden. Drittens müssen Risikobewertung, SBOM und Vulnerability Handling für aktive Produkte funktionieren. Viertens sollte der Konformitätspfad für Produkte feststehen, die 2027 auf den Markt kommen sollen.

Wer noch nicht weiß, welche Produkte erfasst werden, beginnt mit dem CRA-Anwendungsbereich. Für die zeitliche Priorisierung dient die Seite CRA-Fristen 2026–2027.

Wie priorisiert man ein größeres Produktportfolio?

Unternehmen mit vielen Produkten sollten nicht alle Produktlinien gleichzeitig in derselben Tiefe bearbeiten. Sinnvoll ist eine Priorisierung nach Marktrelevanz, Risiko, erwarteter Nutzungsdauer, technischer Komplexität und geplanter Vermarktung ab 2027.

Produkte mit langer Lebensdauer, vielen Drittkomponenten, hoher Netzwerkexposition oder bevorstehenden Releases sollten früher geprüft werden. Gleichzeitig können Produkte, die vor der Vollanwendung auslaufen und nicht mehr wesentlich geändert werden, einen anderen Arbeitsaufwand verursachen als strategische Kernprodukte.

Diese Priorisierung sollte dokumentiert werden. Sie hilft, Security-, Entwicklungs- und Compliance-Ressourcen dort einzusetzen, wo Zeitdruck und Risiko am höchsten sind.

Wo stehen die Herstellerpflichten im Original?

Der verbindliche Wortlaut steht insbesondere in Artikel 13 sowie den Anhängen I, II und VII der Verordnung (EU) 2024/2847 bei EUR-Lex. Für konkrete Produkte sollten Hersteller zusätzlich aktuelle Leitlinien, harmonisierte Normen und gegebenenfalls Anforderungen einer benannten Stelle berücksichtigen.