Welche neuen Dokumente, Nachweise und Prozesse müssen wir aufbauen, damit unsere Produkte mit digitalen Elementen künftig konform in Verkehr gebracht und während ihres Lebenszyklus sicher unterstützt werden können?
Dieser Artikel konzentriert sich bewusst nicht auf allgemeine IT-Security-Beratung. Im Mittelpunkt stehen die CRA-Dokumentation, die technische Dokumentation nach CRA-Anhang VII, die CRA-Risikobewertung, die CRA-EU-Konformitätserklärung, die CRA-CE-Kennzeichnung sowie die Schnittstellen zur bestehenden CE-Dokumentation und – bei Maschinen – zur MVO. Genau dort entsteht für viele Hersteller der größte Handlungsbedarf.
Wer bereits technische Dokumentation, Risikobeurteilungen, Betriebsanleitungen und EU-Konformitätserklärungen für Maschinen, elektrische Produkte oder andere CE-pflichtige Produkte erstellt, muss für den CRA nicht bei null anfangen.
Die CRA-Dokumentation ist in vielen Fällen eine Erweiterung bestehender Product-Compliance-Prozesse. Sie ergänzt die klassische CE-Dokumentation um Cybersicherheitsrisiken, Schwachstellenmanagement, Support-Zeiträume, Sicherheitsupdates und produktbezogene Security-Nachweise.
Kurzüberblick für Hersteller
Thema | Bedeutung für Hersteller |
|---|---|
Cyber Resilience Act | Produktbezogene Cybersicherheitsanforderungen für Produkte mit digitalen Elementen |
NIS2 | Unternehmensbezogene Cybersicherheitsanforderungen für bestimmte Einrichtungen und Dienste |
Maschinenverordnung | Sicherheitsbezogener Schutz von Maschinen gegen Korrumpierung und Manipulation |
CRA‑Dokumentation | Nachweise zur Cybersicherheit des Produkts über den Lebenszyklus |
CRA technische Dokumentation | Technische Unterlagen nach CRA‑Anhang VII |
CE‑Dokumentation | Ausgangspunkt für eine integrierte Produktdokumentation |
Wichtigste CRA‑Dokumente | Risikobewertung, technische Dokumentation, EU‑Konformitätserklärung, Nutzerinformationen und Schwachstellenprozesse |
Relevante Frist | CRA‑Meldepflicht ab 11. September 2026 |
Relevante Frist | MVO grundsätzlich anwendbar ab 20. Januar 2027 |
Relevante Frist | Vollständige CRA‑Anwendung ab 11. Dezember 2027 |
HighDoc‑Fokus | Strukturierte technische Dokumentation, CE‑Dokumentation, Konformitätserklärungen und produktbezogene Nachweise |
CRA und NIS2 früh unterscheiden
CRA und NIS2 werden häufig zusammen genannt. Für Hersteller ist es aber entscheidend, beide Regelwerke sauber zu trennen.
Der Cyber Resilience Act (EU) 2024/2847 ist eine EU-Verordnung. Er richtet sich produktbezogen an Wirtschaftsakteure wie Hersteller, Bevollmächtigte, Importeure und Händler. Sein Kern ist die Cybersicherheit von Produkten mit digitalen Elementen. Dazu zählen unter anderem Software, vernetzte Hardware, Embedded-Systeme, IoT-Produkte und bestimmte industrielle Komponenten.
Die NIS2-Richtlinie (EU) 2022/2555 ist dagegen eine EU-Richtlinie. Sie betrifft bestimmte Unternehmen und Organisationen, insbesondere in regulierten oder kritischen Sektoren. Sie fragt nicht primär, ob ein einzelnes Produkt CE-konform dokumentiert ist. Sie fragt, ob das Unternehmen angemessene technische, operative und organisatorische Maßnahmen zum Umgang mit Cyberrisiken eingerichtet hat.
Die Kurzform lautet:
CRA = Product Security
NIS2 = Organizational Security
Für Hersteller kann beides gleichzeitig relevant sein. Ein Unternehmen kann ein betroffenes Produkt mit digitalen Elementen herstellen und zugleich – falls es in den national umgesetzten NIS2-Anwendungsbereich fällt – organisatorische Risikomanagement- und Nachweispflichten haben.
Zusätzlich können NIS2-Anforderungen über Kunden, Betreiber oder Lieferketten indirekt an Hersteller weitergegeben werden.
Produktebene
-
CRA
- Technische Dokumentation
-
Maschinenverordnung
- Safety-Risikobeurteilung
Unternehmensebene
-
NIS2
- Risikomanagement
- Incident Response
- Lieferkette
Cybersecurity an der Maschine dokumentieren
Ihre Maschine ist vernetzt und soll ab 2027 der Maschinenverordnung entsprechen? HighDoc verbindet Risikobeurteilung, Bedrohungsanalyse und Betriebsanleitung zu einem konsistenten Nachweis – inklusive der sicherheitsrelevanten Schnittstellen nach Anhang III.
Maschinenverordnung: Cybersecurity wird zur Sicherheitsanforderung
Für Maschinenhersteller ist neben CRA und NIS2 eine dritte Regelung wichtig: die Verordnung (EU) 2023/1230 über Maschinen, kurz Maschinenverordnung oder MVO. Sie ist grundsätzlich ab dem 20. Januar 2027 anwendbar und macht Cybersecurity dort relevant, wo Manipulationen die sichere Funktion einer Maschine beeinträchtigen können.
Im Mittelpunkt stehen insbesondere zwei Anforderungen aus Anhang III: Hardware, Software und Daten, die für die Einhaltung der Sicherheits- und Gesundheitsschutzanforderungen relevant sind, müssen gegen unbeabsichtigte und vorsätzliche Korrumpierung geschützt werden. Steuerungssysteme müssen – soweit es den Umständen und Risiken angemessen ist – zudem vernünftigerweise vorhersehbaren böswilligen Einwirkungen Dritter standhalten.
Für die Praxis bedeutet das: Wird etwa eine Sicherheitssteuerung, ein sicherheitsrelevanter Parameter, eine Firmware oder ein Fernwartungszugang manipuliert, darf daraus keine gefährliche Situation entstehen.
Maschinenhersteller müssen deshalb nicht nur die funktionale Sicherheit betrachten, sondern auch prüfen, über welche digitalen und physischen Schnittstellen sicherheitsrelevante Funktionen beeinflusst werden können.
Der Entwurf E DIN EN 50742:2026-03 auf Grundlage von prEN 50742:2025 beschreibt hierfür einen maschinenbauspezifischen Ansatz. Im Fokus stehen sicherheitsrelevante Hardware, Software, Daten und Schnittstellen sowie eine Bedrohungsanalyse als Ergänzung zur klassischen Risikobeurteilung. Der Entwurf nennt zudem die Nachvollziehbarkeit von Eingriffen und Änderungen sowie einen alternativ nutzbaren IEC-62443-basierten Ansatz.
Wichtiger Statushinweis: E DIN EN 50742:2026-03 ist ein deutscher Norm-Entwurf. Der Entwurf ist nicht mit einer final veröffentlichten und im Amtsblatt der EU gelisteten harmonisierten EN-Norm gleichzusetzen.
Für verbindliche Entwicklungs-, Prüf- oder Konformitätsentscheidungen sind der maßgebliche Originaltext und der aktuelle Harmonisierungsstatus zu prüfen.
MVO und CRA: ähnlich, aber nicht dasselbe
Der CRA verfolgt einen breiteren, produktbezogenen Cybersecurity-Ansatz. Er betrachtet Produkte mit digitalen Elementen und ihren Lebenszyklus, beispielsweise sichere Entwicklung, Schwachstellenmanagement, Sicherheitsupdates, Support und technische Dokumentation.
Die MVO fragt dagegen vorrangig, ob eine Korrumpierung zu einer Gefährdung durch die Maschine führen kann.
Perspektive | Maschinenverordnung und prEN 50742 | Cyber Resilience Act |
|---|---|---|
Primäres Schutzgut | Sichere Maschinenfunktion und Vermeidung gefährlicher Situationen | Cybersicherheit von Produkten mit digitalen Elementen |
Fokus | Sicherheitsrelevante Hardware, Software, Daten und Schnittstellen | Produktweite Cybersecurity über den Lebenszyklus |
Zentrale Nachweise | Safety‑Risikobeurteilung, Bedrohungsanalyse, Schutz gegen Korrumpierung und nachvollziehbare Änderungen | Risikobewertung, technische Dokumentation, Vulnerability Management, Updates und Support |
Praxisfrage | Kann eine Manipulation zu einer gefährlichen Situation führen? | Ist das Produkt angemessen cybersicher entwickelt, dokumentiert und unterstützt? |
Kurz gesagt: Die MVO schützt die sichere Maschinenfunktion vor Manipulation. Der CRA verfolgt einen umfassenderen, produktbezogenen Cybersecurity‑Ansatz.
Welche Anforderungen für ein konkretes Produkt gelten, ist anhand des Produkts, seiner digitalen Elemente, seiner Rolle im System und der einschlägigen sektoralen Rechtsakte zu bestimmen.
Die Regelwerke sollten nicht pauschal gleichgesetzt werden: Eine CRA-Konformitätsbewertung ersetzt nicht automatisch einen MVO-Nachweis und umgekehrt.
Für Hersteller ist dennoch eine gemeinsame Dokumentationsbasis sinnvoll: Risikobeurteilung, Bedrohungsanalyse, Schnittstellenübersicht, Sicherheitsmaßnahmen, Softwarestände, Änderungen und Nutzerinformationen sollten konsistent zusammengeführt werden.
So lassen sich Synergien nutzen, ohne die rechtliche Einordnung von MVO und CRA zu vermischen.
Warum der CRA für die technische Dokumentation so wichtig ist
Der CRA verändert nicht nur Entwicklungsprozesse. Er verändert auch die Nachweisführung. In klassischen CE-Prozessen kennen Hersteller bereits typische Dokumente wie:
- Risikobeurteilung
- technische Unterlagen
- Betriebsanleitung
- Montageanleitung
- Prüfberichte
- Konformitätsbewertung
- EU-Konformitätserklärung
Der Cyber Resilience Act erweitert diese Logik um Cybersicherheit. Hersteller müssen künftig nicht nur zeigen, dass ein Produkt mechanisch, elektrisch oder funktional sicher ist. Sie müssen auch nachvollziehbar dokumentieren, dass Cybersecurity-Risiken berücksichtigt wurden.
Das betrifft insbesondere:
- Cybersecurity-Risikobewertung
- Auswahl und Umsetzung grundlegender Cybersicherheitsanforderungen
- technische Dokumentation nach CRA-Anhang VII
- CRA-EU-Konformitätserklärung
- Nutzerinformationen
- Software-Komponenten und Abhängigkeiten
- Schwachstellenbehandlung
- Update- und Support-Prozesse
- Meldeprozesse für bestimmte Schwachstellen und Sicherheitsvorfälle
Damit wird Cybersicherheit zu einem dokumentierten Bestandteil der Produktkonformität.
Welche Produkte mit digitalen Elementen betroffen sein können
Der CRA erfasst grundsätzlich Produkte mit digitalen Elementen, die auf dem EU-Markt bereitgestellt werden und eine direkte oder indirekte logische oder physische Datenverbindung mit einem Gerät oder Netzwerk haben können.
Für Hersteller bedeutet das: Es reicht nicht aus, nur klassische IT-Produkte zu betrachten.
Auch Produkte aus Maschinenbau, Elektrotechnik, Automatisierung, medizintechniknahen Bereichen, Gebäudetechnik oder Konsumgüterindustrie können erfasst sein, sofern digitale Elemente und Konnektivität vorhanden sind.
Produktgruppe | Beschreibung | Beispiel |
|---|---|---|
Software | Eigenständig bereitgestellte Softwareprodukte | App, Desktop‑Software, Firmware |
Vernetzte Geräte | Produkte mit Netzwerk‑ oder Datenverbindung | Gateway, Router, IoT‑Gerät |
Maschinen und
Industrieprodukte | Produkte mit digitaler Steuerung, Schnittstellen oder Remote‑Funktionen | Produktionsmaschine,Fernwartungskomponente |
Embedded‑Systeme | Produkte mit integrierter Software | Steuerung, Sensor, Aktor |
Softwarekomponenten | Komponenten, die eigenständig bereitgestellt werden | Bibliothek, Modul, Update‑Paket |
Cloud‑verbundene Produkte | Produkte mit für die Funktion erforderlicher Remote‑Datenverarbeitung | Gerät mit Cloud‑Backend |
Nicht jedes digitale Produkt fällt automatisch vollständig unter den CRA. Es gibt Abgrenzungen zu sektoralen Rechtsakten, beispielsweise bei bestimmten Medizinprodukten, Fahrzeugprodukten, Luftfahrtprodukten oder Marine Equipment.
Bei Maschinen ist insbesondere das Zusammenspiel mit der Maschinenverordnung zu prüfen. Eine saubere Produktklassifizierung ist deshalb der erste Schritt.
Die wichtigsten Fristen für Hersteller
Die CRA‑Fristen und der MVO‑Stichtag sind für die Projektplanung entscheidend.
Datum | Bedeutung | Was Hersteller dokumentieren sollten |
|---|---|---|
20. November 2024 | Veröffentlichung der
Verordnung (EU) 2024/2847 im
Amtsblatt der EU | Rechtsgrundlage und interne Compliance‑Bewertung |
11. September 2026 | Beginn der CRA‑Meldepflicht für aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle | Meldeprozess, Zuständigkeiten, Produktdaten und Eskalationswege |
20. Januar 2027 | Maschinenverordnung grundsätzlich anwendbar | Safety‑bezogene Cybersecurity in Risikobeurteilung, Konstruktion und Nachweisen berücksichtigen |
11. Dezember 2027 | Vollständige Anwendung des CRA einschließlich Konformitätsbewertung, CE‑Kennzeichnung und technischer Dokumentation | Prüffähige CRA‑Dokumentation und EU‑Konformitätserklärung |
Die Fristen dürfen nicht als Startpunkte verstanden werden. Für Hersteller mit mehrjährigen Entwicklungszyklen müssen zentrale Vorarbeiten deutlich vorher abgeschlossen sein.
Besonders wichtig ist die CRA-Meldepflicht seit dem 11. September 2026. Hersteller müssen organisatorisch in der Lage sein, relevante Schwachstellen und Sicherheitsvorfälle schnell zu erkennen, intern zu bewerten, zuständige Personen einzubinden und fristgerecht zu melden.
Das funktioniert nur, wenn Produktdaten, Softwarestände, Verantwortlichkeiten und Eskalationswege vorher dokumentiert sind.
Meldefristen sicher einhalten
Wissen Sie im Ernstfall innerhalb von Stunden, welche Produkte und Softwarestände betroffen sind? HighDoc bringt Produktdaten, Versionsstände und Verantwortlichkeiten in eine Struktur, mit der Sie Schwachstellen bewerten und fristgerecht melden können.
Welche Dokumentationspflichten aus dem CRA entstehen
Maßnahme | Beschreibung | Beispiel für die Dokumentation |
|---|---|---|
CRA‑Risikobewertung | Bewertung von Cybersecurity‑Risiken über Design, Entwicklung, Herstellung, Lieferung und Wartung | Threat Model, Risikomatrix, abgeleitete Security Requirements |
CRA‑technische
Dokumentation | Zusammenstellung der technischen Nachweise nach CRA‑Anhang VII | Produktbeschreibung,Architektur,Softwarebestandteile,Prüfberichte |
CRA‑EU‑Konformitätserklärung | Formale Erklärung, dass das Produkt die anwendbaren Anforderungen erfüllt | Integrierte EU‑Konformitätserklärung mit CRA‑Bezug |
Nutzerinformationen | Sicherheitsrelevante Informationen für Installation, Nutzung, Updates und Support | Betriebsanleitung mit Security‑Hinweisen |
Schwachstellenmanagement | Prozess zur Identifikation, Bewertung, Behebung und Kommunikation von Schwachstellen | CVD‑Policy, Kontaktadresse, Advisory‑Prozess |
Sicherheitsupdates | Planung und Nachweis sicherer Update‑Bereitstellung | Update‑Konzept,Signaturverfahren,Release‑Dokumentation |
Support‑Zeitraum | Festlegung und Kommunikation des Zeitraums für Sicherheitsupdates | Support‑Matrix,Produktdatenblatt,Kundeninformation |
Cybersecurity‑Risikobewertung
Die CRA-Risikobewertung ist die Grundlage der CRA-Dokumentation. Sie sollte zeigen, welche Cybersicherheitsrisiken für das Produkt identifiziert, bewertet und behandelt wurden. Eine praxistaugliche Risikobewertung beschreibt beispielsweise:
- Produktgrenzen und bestimmungsgemäße Verwendung
- digitale Schnittstellen
- Kommunikationswege
- Remote-Zugänge
- schützenswerte Assets
- mögliche Bedrohungen
- relevante Angriffsflächen
- Risikobewertung und Risikobehandlung
- abgeleitete Security Requirements
- getroffene technische und organisatorische Maßnahmen
- verbleibende Restrisiken
- Annahmen für den Betrieb beim Kunden
Für HighDoc-Kunden ist besonders wichtig: Diese Risikobewertung lässt sich methodisch an vorhandene Risikobeurteilungen und CE-Dokumentationsstrukturen anbinden. Sie sollte nicht isoliert neben der technischen Dokumentation stehen, sondern in ein konsistentes Nachweissystem eingebettet werden.
Technische Dokumentation nach CRA‑Anhang VII
CRA-Anhang VII beschreibt, welche technischen Unterlagen Hersteller bereithalten müssen. Dazu gehören unter anderem Informationen zum Produkt, zu Design und Entwicklung, zur Herstellung, zur Funktionsweise, zu Cybersicherheitsmaßnahmen und zu Verfahren für den Umgang mit Schwachstellen.
Baustein | Zweck | Typischer Nachweis |
|---|---|---|
Produktbeschreibung | Einordnung des Produkts und seiner digitalen Elemente | Zweckbestimmung, Varianten, Softwareversionen |
Systemarchitektur | Nachvollziehbarkeit von Aufbau und Schnittstellen | Architekturdiagramm,Datenflussbeschreibung |
Softwarebestandteile | Transparenz über Komponenten und Abhängigkeiten | SBOM oder Komponentenliste |
Security‑Maßnahmen | Nachweis der umgesetzten Schutzmaßnahmen | Security Requirements,
Testnachweise |
Schwachstellenverfahren | Nachweis des Vulnerability Managements | CVD‑Policy, Kontaktadresse, Prozessbeschreibung |
Update‑Konzept | Nachweis sicherer Aktualisierungen | Update‑Prozess,Signaturkonzept,Rollback‑Konzept |
Support‑Zeitraum | Nachweis der geplanten
Sicherheitsunterstützung | Support‑Matrix,Produktinformation |
Nutzerinformationen | Sichere Nutzung durch Kunden und Betreiber | Betriebsanleitung,Installationshinweise |
Der CRA macht damit sichtbar, was in vielen Produktentwicklungen bisher nur informell vorhanden war. Entscheidungen zur Cybersicherheit müssen nachvollziehbar, prüfbar und aktuell dokumentiert werden.
EU‑Konformitätserklärung und CRA‑CE‑Kennzeichnung
Die CRA-EU-Konformitätserklärung ist ein zentrales Element der Produktkonformität. Hersteller erklären damit, dass das Produkt die anwendbaren Anforderungen erfüllt.
Für Produkte, die bereits anderen CE-Rechtsakten unterliegen, wird die CRA-Konformitätserklärung nicht isoliert betrachtet werden dürfen. In vielen Fällen wird sie Teil einer integrierten Konformitätsstrategie sein. Relevant ist dann, welche Rechtsakte auf das Produkt anwendbar sind und wie die jeweiligen Anforderungen in einer konsistenten Dokumentation nachgewiesen werden.
Die CRA-CE-Kennzeichnung macht Cybersicherheit damit zu einem sichtbaren Bestandteil des europäischen Produktrechts. Für Hersteller bedeutet das: Die technische Dokumentation muss vor der Konformitätserklärung belastbar, konsistent und prüffähig sein.
Nutzerinformationen und Betriebsanleitung
Der CRA betrifft nicht nur interne Unterlagen. Auch die Informationen für Anwender werden wichtiger. Hersteller sollten prüfen, ob ihre Produktinformationen verständlich beschreiben:
- sichere Installation
- sichere Standardeinstellungen
- empfohlene Konfigurationen
- Einspielen von Updates
- Dauer der Sicherheitsupdates
- Meldeweg für Schwachstellen
- Voraussetzungen beim Betreiber
- Risiken bei unsachgemäßer Konfiguration
Für Hersteller mit bestehenden Betriebsanleitungen ist das ein wichtiger Integrationspunkt. Cybersicherheitsinformationen sollten nicht beliebig verstreut sein, sondern sauber in Anleitung, Sicherheitsinformationen und technische Dokumentation eingebunden werden.
Schwachstellenmanagement als dokumentierte Herstellerpflicht
Ein Kernpunkt des CRA ist der Umgang mit Schwachstellen. Hersteller müssen nicht nur sichere Produkte entwickeln, sondern auch nach dem Inverkehrbringen mit neu bekannt werdenden Schwachstellen umgehen können.
Maßnahme | Beschreibung | Beispiel |
|---|---|---|
Identifikation | Schwachstellen aus internen und externen Quellen erfassen | CVE‑Monitoring, Kundenmeldung, Security Researcher |
Bewertung | Betroffenheit und Risiko für eigene Produkte prüfen | Impact Assessment je Produktversion |
Priorisierung | Maßnahmen nach Risiko und Ausnutzbarkeit steuern | Kritikalitätsstufe,Patch‑Priorität |
Behebung | Korrektur entwickeln und testen | Security Patch, Firmwareupdate |
Kommunikation | Kunden und relevante Stellen informieren | Security Advisory, Release Notes |
Dokumentation | Entscheidungen und Nachweise festhalten | Ticket, Änderungsnachweis, Prüfbericht |
Ein Hersteller muss in kurzer Zeit beantworten können:
- Welche Produkte sind betroffen?
- Welche Softwareversionen sind betroffen?
- Welche Komponenten oder Bibliotheken sind betroffen?
- Gibt es eine ausnutzbare Schwachstelle?
- Gibt es bereits aktive Ausnutzung?
- Welche Kunden oder Märkte sind betroffen?
- Welche Maßnahmen sind erforderlich?
- Muss eine Meldung erfolgen?
- Welche Informationen müssen dokumentiert werden?
Ohne strukturierte Produkt- und Softwaredokumentation ist diese Bewertung kaum fristgerecht möglich.
Koordinierte Offenlegung von Schwachstellen
Der CRA verlangt von Herstellern eine Politik zur koordinierten Offenlegung von Schwachstellen. Diese wird häufig als Coordinated Vulnerability Disclosure oder CVD bezeichnet. Eine solche Policy sollte aus Herstellersicht mindestens regeln:
- Meldekanal für Schwachstellen
- zuständige Kontaktadresse
- erforderliche Informationen durch Meldende
- Eingangsbestätigung
- interne Bewertung und Priorisierung
- Umgang mit vertraulichen Informationen
- Information von Kunden
- Kommunikation von Sicherheitsupdates
- Dokumentation des Prozesses
Für die technische Dokumentation ist nicht nur die Existenz einer solchen Policy relevant. Entscheidend ist, dass der Prozess zur Produktorganisation passt und in der Praxis genutzt werden kann.
Sicherheitsupdates und Support‑Zeitraum dokumentieren
Ein Produkt mit digitalen Elementen ist mit dem Verkauf nicht abgeschlossen. Der CRA verlangt, dass Hersteller Schwachstellen während des definierten Support-Zeitraums behandeln und Sicherheitsupdates bereitstellen.
Frage | Warum sie wichtig ist | Möglicher Nachweis |
|---|---|---|
Wie lange wird das Produkt unterstützt? | Kunden und Marktüberwachung benötigen Transparenz | Support‑Matrix |
Wie wird der Zeitraum festgelegt? | Die Entscheidung muss nachvollziehbar sein | Produktstrategie,Risikoabwägung |
Wie werden Updates verteilt? | Updates müssen sicher bereitgestellt werden | Update‑Konzept |
Wie wird die Integrität geschützt? | Manipulierte Updates müssen verhindert werden | Signaturverfahren,Prüfsummen |
Wie werden Updates getestet? | Patches dürfen keine neuen Risiken erzeugen | Testprotokolle, Freigaben |
Wie wird das Supportende kommuniziert? | Kunden müssen planen können | End‑of‑Support‑Hinweis |
Gerade bei Maschinen, Industrieprodukten und langlebigen Embedded-Systemen ist dieser Punkt kritisch. Wenn sichere Update-Mechanismen nicht in der Architektur vorgesehen sind, lassen sie sich kurz vor der Markteinführung nur schwer nachträglich ergänzen.
SBOM und Software‑Lieferkette
Viele Produkte enthalten heute Open-Source-Komponenten, Drittanbieterbibliotheken, Betriebssystemmodule, Frameworks, Treiber oder Cloud-Komponenten. Deshalb wird die Software-Lieferkette zu einem zentralen Bestandteil der CRA-Dokumentation.
Eine Software Bill of Materials (SBOM) hilft Herstellern, Softwarebestandteile strukturiert zu erfassen.
SBOM‑Information | Nutzen für Hersteller |
|---|---|
Komponentenname | Identifikation betroffener Bausteine |
Version | Prüfung konkreter Schwachstellen |
Hersteller oder Maintainer | Zuordnung von Verantwortlichkeiten |
Lizenzinformationen | Transparenz für Compliance und Weitergabe |
Abhängigkeiten | Bewertung indirekter Risiken |
Identifikatoren | Abgleich mit Schwachstellendatenbanken |
Produktversionen | Verbindung zwischen Komponente und
ausgeliefertem Produkt |
Die SBOM ist kein Selbstzweck. Sie hilft vor allem bei der Frage, ob ein Produkt von einer neu veröffentlichten Schwachstelle betroffen ist. Für die Meldefristen und das Schwachstellenmanagement kann sie deshalb entscheidend sein.
CE‑Dokumentation als Ausgangspunkt nutzen
Für viele Hersteller ist der wichtigste Perspektivwechsel: CRA-Dokumentation muss nicht als völlig neues Paralleluniversum aufgebaut werden. Wer bereits CE-konforme technische Dokumentation erstellt, verfügt häufig über viele Strukturen, die erweitert werden können:
Bestehende CE‑Dokumentation | CRA‑ oder MVO‑Erweiterung |
|---|---|
Produktbeschreibung | Digitale Elemente, Schnittstellen, Remote‑Funktionen und Softwarestände |
Risikobeurteilung | CRA‑Risikobewertung; bei Maschinen zusätzlich sicherheitsbezogene Bedrohungsanalyse |
Normenliste | Cybersecurity‑Normen und technische Spezifikationen |
Prüfberichte | Security‑Tests und Update‑Tests |
Betriebsanleitung | Security‑Hinweise und sichere Konfiguration |
Konformitätserklärung | Rechtsakte‑ und Konformitätsmatrix mit CRA‑ und gegebenenfalls MVO‑Bezug |
Änderungsmanagement | Softwareversionen, Patches und Security Releases |
Archivierung | Nachweise über Support‑Zeitraum, Produktlebenszyklus und Änderungen |
Das Ziel ist eine integrierte technische Dokumentation. Sie reduziert Doppelarbeit, vermeidet widersprüchliche Aussagen und erleichtert die spätere Konformitätsbewertung.
1CRA- und MVO-Gap-Analyse
2aCybersecurity-Risikobewertung
2bSafety-bezogene Bedrohungsanalyse
3 · Technische Dokumentation
Nutzerinformationen
EU-Konformitätserklärung
Vulnerability Management
- Updates und Support
Was NIS2 für Hersteller zusätzlich bedeutet
NIS2 ist für Hersteller vor allem auf Unternehmensebene relevant. Betroffene Unternehmen müssen angemessene technische, operative und organisatorische Maßnahmen zum Management von Cyber‑ risiken umsetzen.
NIS2‑Maßnahme | Bedeutung für Hersteller | Dokumentationsbezug |
|---|---|---|
Risikoanalyse | Cyberrisiken des Unternehmens bewerten | Risikoregister,Maßnahmenplan |
Incident Management | Sicherheitsvorfälle erkennen und behandeln | Incident‑Prozess,Eskalationsschema |
Business Continuity | Ausfälle und Krisen beherrschbar machen | Notfallplan,Wiederanlaufkonzept |
Lieferkettensicherheit | Dienstleister und Zulieferer bewerten | Lieferantenbewertung,Sicherheitsanforderungen |
Sichere Beschaffung | Security‑Anforderungen in Einkauf integrieren | Vertragsanforderungen, technische Spezifikationen |
Zugriffskontrolle | Systeme und Daten schützen | Rollenmodell,Berechtigungskonzept |
Schulungen | Mitarbeitende sensibilisieren | Schulungsnachweise |
Nachweispflichten | Umsetzung gegenüber Kunden oder Behörden belegen | Audit‑Unterlagen,
Managementberichte |
Für Hersteller ist besonders die NIS2-Lieferkette wichtig. Auch wenn ein Hersteller selbst nicht unmittelbar unter NIS2 fällt, können Kunden aus NIS2-regulierten Sektoren Anforderungen an Lieferanten weitergeben.
Dann werden Produktdokumentation, Sicherheitsnachweise, Update-Zusagen, Schwachstellenprozesse und technische Informationen zunehmend Bestandteil der Beschaffung. NIS2 kann dadurch indirekt den Druck erhöhen, CRA-nahe Dokumentation frühzeitig bereitzustellen.
CRA, MVO und NIS2 im Vergleich
Thema | CRA | Maschinenverordnung | NIS2 |
|---|---|---|---|
Rechtscharakter | EU‑Verordnung | EU‑Verordnung | EU‑Richtlinie mit nationaler Umsetzung |
Fokus | Produkt | Maschine und Maschinensicherheit | Unternehmen, Einrichtung oder Dienst |
Kernfrage | Ist das Produkt cybersicher und dokumentiert? | Kann Manipulation die sichere Maschinenfunktion beeinträchtigen? | Ist die Organisation cyberresilient aufgestellt? |
Dokumentation | Technische Dokumentation, Risikobewertung, Konformitätserklärung und Nutzerinformationen | Risikobeurteilung, Bedrohungsanalyse, Schutzmaßnahmen und Nachweise | Sicherheitsmaßnahmen, Risikomanagement, Incident Response und Nachweise |
Lieferkette | Softwarekomponenten, SBOM und Produktabhängigkeiten | Sicherheitsrelevante Komponenten und Schnittstellen | Lieferantenrisiken, Beschaffung und Dienstleistersteuerung |
CE‑Bezug | Ja | Ja | Nein |
Praktische Dokumentations‑Checkliste für Hersteller
Hersteller sollten frühzeitig prüfen, ob folgende Dokumentationsbausteine vorhanden oder geplant sind.
Bereich | Prüffrage | Beispielhafter Nachweis |
|---|---|---|
Produkt und
Anwendungsbereich | Welche Produkte enthalten
digitale Elemente? | Produktliste,
Variantenübersicht |
Schnittstellen | Welche Datenverbindungen
und Servicezugänge bestehen? | Schnittstellenliste,
Datenflussdiagramm |
Risikobewertung | Welche Cybersecurity‑ und bei
Maschinen Safety‑relevanten
Manipulationsrisiken
bestehen? | CRA‑Risikobewertung,
Bedrohungsanalyse |
Technische Dokumentation | Sind die einschlägigen
Anforderungen abgedeckt? | Dokumentationsmatrix |
Softwarebestandteile | Welche Komponenten sind
enthalten? | SBOM, Komponentenliste |
Schwachstellenmanagement | Wie werden Schwachstellen
bewertet und behandelt? | CVD‑Policy,
Prozessbeschreibung |
Meldepflicht | Wer entscheidet über
CRA‑Meldungen? | Rollenmodell, Eskalationsplan |
Sicherheitsupdates | Wie werden Updates erstellt
und verteilt? | Update‑Konzept,
Release‑Prozess |
Support | Wie lange werden
Sicherheitsupdates
bereitgestellt? | Support‑Matrix |
Nutzerinformationen | Sind sichere Nutzung und
Updates beschrieben? | Betriebsanleitung,
Security‑Hinweise |
Konformität | Sind die anwendbaren
Rechtsakte sauber zugeordnet? | Rechtsakte‑ und
Konformitätsmatrix |
Archivierung | Sind Nachweise auffindbar und
versioniert? | Dokumentenlenkung,
Ablagestruktur |
Typische Lücken in bestehenden Herstellerprozessen
Typische Lücke | Risiko | Sinnvolle Maßnahme |
|---|---|---|
Risikobeurteilung
berücksichtigt Cybersecurity
noch nicht systematisch | Cyberrisiken bleiben außerhalb
der CE‑Dokumentation | CRA‑Risikobewertung und bei
Maschinen Bedrohungsanalyse
ergänzen |
Softwareversionen sind nicht
sauber mit Produktvarianten
verknüpf | Betroffenheit bei
Schwachstellen ist schwer
prüfbar | Versionsmatrix aufbauen |
Open‑Source‑Komponenten
werden nicht zentral erfasst | Schwachstellen können
übersehen werden | SBOM‑Prozess einführen |
Sicherheitsupdates sind
technisch möglich, aber nicht
dokumentiert | Nachweis der Updatefähigkeit
fehlt | Update‑Konzept
dokumentieren |
Support‑Zeiträume sind
vertrieblich bekannt, aber nicht
regulatorisch begründet | Kundeninformation und
Nachweisführung sind
lückenhaf | Support‑Entscheidung
dokumentieren |
Schwachstellenmeldungen
haben keinen klaren
Eingangskanal | CRA‑Meldepflicht kann verfehlt
werden | CVD‑Policy und Kontaktadresse
definieren |
Verantwortlichkeiten sind
unklar | Entscheidungen dauern zu
lange | Rollen und Eskalation festlegen |
Betriebsanleitungen enthalten
keine Security‑Hinweise | Anwender erhalten keine
ausreichenden Informationen | Nutzerinformationen erweitern |
Konformitätserklärungen sind
nicht auf CRA vorbereitet | CE‑Prozess bleibt unvollständig | Rechtsakte‑ und
Konformitätsmatrix
aktualisieren |
Diese Lücken lassen sich am besten frühzeitig durch eine strukturierte Gap‑Analyse schließen.
Umsetzungspfad bis zur vollständigen CRA‑Anwendung
Ein pragmatischer Fahrplan für Hersteller kann so aussehen:
1Produktportfolio erfassen
2Rechtsakte prüfen
3Dokumentationsstruktur festlegen
4aCRA-Risikobewertung erstellen
4bMVO-Bedrohungsanalyse ergänzen
5Security Requirements ableiten
6Technische Dokumentation ergänzen
7Schwachstellenprozess aufbauen
8Update und Support dokumentieren
9Konformitätsbewertung vorbereiten
10EU-Konformitätserklärung finalisieren
Produktportfolio erfassen
Zuerst sollte geklärt werden, welche Produkte digitale Elemente enthalten und welche davon unter den CRA fallen können. Wichtig sind dabei auch Varianten, Firmwarestände, Cloud‑Anteile und Remote‑Services.
Rechtsakte und Schnittstellen prüfen
Danach folgt die regulatorische Einordnung. Neben dem CRA können je nach Produkt weitere Rechtsakte relevant sein, beispielsweise Maschinenverordnung, Funkanlagenrichtlinie, Niederspannungsrichtlinie, EMV‑Recht, Medizinprodukterecht oder branchenspezifische Vorgaben.
Dokumentationsstruktur festlegen
Hersteller sollten definieren, wie CRA‑Nachweise in bestehende technische Dokumentation integriert werden. Bei Maschinen sollte außerdem festgelegt werden, wie sicherheitsbezogene Bedrohungsanalyse und Nachweise zu Korrumpierungsszenarien mit der Risikobeurteilung verbunden werden. Ziel ist ein System, das auch bei Produktänderungen und Softwareupdates aktuell bleibt.
Risikobewertung und Security Requirements etablieren
Cybersecurity‑Risiken müssen in Anforderungen übersetzt werden. Diese Anforderungen sollten in Entwicklung, Test, Freigabe und Dokumentation nachverfolgbar sein
Schwachstellen‑ und Meldeprozess aufbauen
Seit dem 11. September 2026 sind CRA‑Meldepflichten für relevante Fälle anwendbar. Hersteller benötigen daher klare Prozesse, Zuständigkeiten und Entscheidungswege.
Update‑ und Support‑Konzept dokumentieren
Für jedes betroffene Produkt sollte nachvollziehbar sein, wie lange Sicherheitsupdates bereitgestellt werden, wie Updates verteilt werden und wie Kunden informiert werden.
Konformitätsbewertung vorbereiten
Bis zur vollständigen CRA‑Anwendung ab dem 11. Dezember 2027 sollten technische Dokumentation, Risikobewertung, Nutzerinformationen und EU‑Konformitätserklärung auf einem prüffähigen Stand sein. Maschinenhersteller müssen die grundsätzlich ab dem 20. Januar 2027 anwendbare MVO in ihrer Planung gesondert berücksichtigen.
Wie HighDoc Hersteller unterstützen kann
HighDoc unterstützt Hersteller dort, wo CRA, MVO und NIS2 besonders eng mit bestehender Produktdokumentation verbunden sind: bei Struktur, Nachweisführung, Konsistenz und Verständlichkeit technischer Unterlagen.
Unterstützungsbereich | Beschreibung | Ergebnis |
|---|---|---|
CE‑Dokumentation prüfen | Bestehende technische
Dokumentation auf CRA‑ und
MVO‑relevante Erweiterungen
analysieren | Gap‑Liste und Prioritäten |
CRA‑Dokumentation
strukturieren | Anforderungen aus
CRA‑Anhang VII in eine
Dokumentationslogik
übersetzen | Dokumentationsmatrix |
Risikobewertung einbinden | Cybersecurity‑Risikobewertung
mit vorhandenen CE‑Prozessen
verbinden | Konsistente Nachweisführung |
Nutzerinformationen erweitern | Security‑Hinweise in
Betriebsanleitungen und
Produktinformationen
integrieren | Verständliche
Anwenderdokumentation |
Konformitätserklärung
vorbereiten | Inhalte für
CRA‑EU‑Konformitätserklärung
strukturieren | Belastbarer Entwurf |
Versionierung abbilden | Produktvarianten,
Softwareversionen und
Support‑Zeiträume
dokumentieren | Versions‑ und Support‑Matrix |
Schnittstellen abstimmen | CRA mit MVO‑, Funkanlagen‑
oder anderen
CE‑Anforderungen verbinden | Integrierte technische
Dokumentation |
Interne Vorlagen erstellen | Checklisten und
Dokumentationsleitfäden für
Teams entwickeln | Wiederverwendbare
Arbeitsgrundlagen |
HighDoc ersetzt dabei keine spezialisierte technische Cybersecurity‑Prüfung, kein Penetration Testing und keine individuelle Rechtsberatung. Der Mehrwert liegt in der Verbindung von Product Compliance, CE‑Dokumentation und verständlicher technischer Dokumentation.
Verwandter Beitrag: Digitaler Produktpass – Vorbereitung für Unternehmen
Häufig gestellte Fragen (FAQ)
Gilt der CRA nur für klassische IT-Produkte?▾
Müssen Hersteller eine komplett neue Dokumentation erstellen?▾
Was ist der Unterschied zwischen CRA und NIS2?▾
Der CRA ist produktbezogen, NIS2 ist unternehmensbezogen.
Der CRA fragt nach der Cybersicherheit eines Produkts mit digitalen Elementen. NIS2 fragt nach der Cyberresilienz bestimmter Unternehmen, Einrichtungen und Dienste.
Was ist der Unterschied zwischen CRA und der Maschinenverordnung bei vernetzten Maschinen?▾
CRA: betrachtet die Cybersicherheit von Produkten mit digitalen Elementen über ihren gesamten Lebenszyklus, etwa sichere Entwicklung, Schwachstellenmanagement, Sicherheitsupdates, Support und technische Dokumentation.
Maschinenverordnung: betrachtet Cybersecurity aus Sicht der Maschinensicherheit. Sie verlangt insbesondere, dass sicherheitsrelevante Hardware, Software und Daten gegen Korrumpierung geschützt werden und dass Manipulationen an Steuerungssystemen nicht zu gefährlichen Situationen führen.
Der Entwurf E DIN EN 50742:2026-03 beschreibt einen maschinenbauspezifischen Ansatz für diese sicherheitsbezogene Betrachtung. Er ist jedoch noch keine final veröffentlichte und harmonisierte EN-Norm.
Welche Frist ist für Hersteller besonders dringend?▾
Seit 11. September 2026: CRA-Meldepflichten für aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle
Ab 20. Januar 2027: Maschinenverordnung grundsätzlich anwendbar
Ab 11. Dezember 2027: vollständige Anwendung des CRA
Was gehört in die technische CRA-Dokumentation?▾
Warum ist eine SBOM wichtig?▾
Was sollten Hersteller zuerst tun?▾
Fazit
Der Cyber Resilience Act macht Cybersicherheit zu einem festen Bestandteil der europäischen Produktkonformität. Für Hersteller von Software, vernetzten Geräten und Produkten mit digitalen Elementen entstehen dadurch Anforderungen an CRA-Risikobewertung, technische Dokumentation, Schwachstellenmanagement, Sicherheitsupdates, Support-Zeiträume, CRA-EU-Konformitätserklärungen und CRA-CE-Kennzeichnung.
Für Maschinenhersteller ergänzt die Maschinenverordnung diese Perspektive um die Frage der Safety: Eine Manipulation digitaler Elemente darf die sichere Funktion der Maschine nicht beeinträchtigen oder zu einer gefährlichen Situation führen.
NIS2 ergänzt diese Entwicklung auf Unternehmensebene. Betroffene Unternehmen müssen Cyberrisiken organisatorisch beherrschen und Nachweise führen. Gleichzeitig können NIS2-Anforderungen über Kunden und Lieferketten auch solche Hersteller erreichen, die nicht unmittelbar im Zentrum der Richtlinie stehen.
Die wichtigste Botschaft lautet: CRA-Dokumentation ist für viele Hersteller kein völlig neuer Vorgang, sondern eine gezielte Erweiterung bestehender CE-Dokumentationsprozesse. Für Maschinenhersteller kommt die sicherheitsbezogene Betrachtung von Korrumpierungsszenarien hinzu.
Wer jetzt seine Produktdokumentation, Risikobewertung, Versionierung, Update-Prozesse und Schwachstellenkommunikation strukturiert, schafft eine belastbare Grundlage für sichere, nachvollziehbare und marktfähige Produkte.
HighDoc unterstützt Hersteller dabei, diese Anforderungen in eine klare, prüffähige und verständliche technische Dokumentation zu übersetzen.
CRA-Dokumentation prüfen lassen
Unsicher, ob Ihre technische Dokumentation die Anforderungen des Cyber Resilience Act erfüllt? HighDoc prüft Ihre bestehenden Unterlagen gegen CRA-Anhang VII und zeigt, welche Nachweise, Prozesse und Angaben ergänzt werden müssen – aufbauend auf Ihrer vorhandenen CE-Dokumentation.
Quellen und weiterführende Informationen
- EUR-Lex: Verordnung (EU) 2024/2847, Cyber Resilience Act: https://eur-lex.europa.eu/eli/reg/2024/2847/oj/deu
- EUR-Lex: Verordnung (EU) 2023/1230 über Maschinen: https://eur-lex.europa.eu/eli/reg/2023/1230/oj
- EUR-Lex: Richtlinie (EU) 2022/2555, NIS2: https://eur-lex.europa.eu/eli/dir/2022/2555/oj/deu
- Europäische Kommission: Cyber Resilience Act: https://digital-strategy.ec.europa.eu/en/policies/cyber-resilience-act
- ENISA: Single Reporting Platform und Product Security: https://www.enisa.europa.eu/topics/product-security-and-certification
- DIN Media: E DIN EN 50742:2026-03: https://www.dinmedia.de/en/draft-standard/din-en-50742/399142141
- VDE VERLAG: E DIN EN 50742 VDE 0113-742:2026-03: https://www.vde-verlag.de/p/normen/e-din-en-50742-vde-0113-742-2026-03/1101006-DE-PR
