VII

Anhang VII

INHALT DER TECHNISCHEN DOKUMENTATION

Verordnung (EU) 2024/2847 — veröffentlicht 10. Dezember 2024 · Letzte Prüfung durch Kunnus: März 2026

Schnellantwort für Hersteller

Anhang VII definiert den Inhalt der Technischen Dokumentation: allgemeine Produktbeschreibung, Designaspekte, Risikobewertung, Testberichte, Schwachstellenbehandlungsprozess, SBOM, EU-Konformitätserklärung. Sie ist der Nachweis der CRA-Konformität.

Diese Schnellantwort + FAQ ergänzen den Original-Rechtstext mit praxisorientierter Auslegung. Rechtsverbindlich ist allein der Originaltext.

Die in Artikel 31 genannte technische Dokumentation muss mindestens die folgenden Informationen enthalten, soweit sie für das betreffende Produkt mit digitalen Elementen von Bedeutung sind:

1.

eine allgemeine Beschreibung des Produkts mit digitalen Elementen, einschließlich

a)

seiner Zweckbestimmung,

b)

Softwareversionen, die sich auf die Erfüllung der grundlegenden Cybersicherheitsanforderungen auswirken,

c)

wenn es sich bei dem Produkt mit digitalen Elementen um ein Hardwareprodukt handelt: Fotografien oder Abbildungen, aus denen äußere Merkmale, Kennzeichnungen und innerer Aufbau hervorgehen;

d)

Informationen und Anleitungen für die Nutzer gemäß Anhang II;

2.

eine Beschreibung der Konzeption, Entwicklung und Herstellung des Produkts mit digitalen Elementen und der Verfahren zur Behandlung von Schwachstellen, einschließlich

a)

erforderlicher Informationen über die Konzeption und Entwicklung des Produkts mit digitalen Elementen, gegebenenfalls mit Zeichnungen und Schemata und/oder einer Beschreibung der Systemarchitektur, aus der hervorgeht, wie Softwarekomponenten aufeinander aufbauen, miteinander zusammenwirken und sich in die Gesamtverarbeitung integrieren;

b)

erforderlicher Informationen und Spezifikationen bezüglich der vom Hersteller festgelegten Verfahren zur Behandlung von Schwachstellen, einschließlich der Software-Stückliste, des Konzepts für die koordinierte Offenlegung von Schwachstellen, des Nachweises der Bereitstellung einer Kontaktadresse für die Meldung der Schwachstellen und einer Beschreibung der gewählten technischen Lösungen für die sichere Verbreitung von Aktualisierungen;

c)

erforderlicher Informationen und Spezifikationen bezüglich der Herstellungs- und Überwachungsprozesse des Produkts mit digitalen Elementen und der Validierung dieser Prozesse;

3.

eine Bewertung der Cybersicherheitsrisiken, die bei der Konzeption, Entwicklung, Herstellung, Lieferung und Wartung des Produkts mit digitalen Elementen nach Artikel 13 berücksichtigt werden, einschließlich der Frage, inwieweit die grundlegenden Cybersicherheitsanforderungen gemäß Anhang I Teil I Anwendung finden;

4.

einschlägige Informationen, die bei der Festlegung des Unterstützungszeitraums gemäß Artikel 13 Absatz 8 des Produkts mit digitalen Elementen berücksichtigt wurden;

5.

eine Aufstellung der vollständig oder teilweise angewandten harmonisierten Normen, deren Fundstellen im Amtsblatt der Europäischen Union veröffentlicht wurden, der in Artikel 27 dieser Verordnung genannten gemeinsamen Spezifikationen oder der in Artikel 27 Absatz 8 dieser Verordnung genannten europäischen Schemata für die Cybersicherheitszertifizierung, angenommen gemäß der Verordnung (EU) 2019/881, und, falls keine solchen harmonisierten Normen, gemeinsamen Spezifikationen und europäischen Schemata für die Cybersicherheitszertifizierung angewandt werden, Beschreibungen der Lösungen, mit denen die grundlegenden Cybersicherheitsanforderungen in Anhang I Teile I und II erfüllt werden, mit einer Aufstellung sonstiger angewandter einschlägiger technischer Spezifikationen. Bei einer teilweisen Anwendung harmonisierter Normen, gemeinsamer Spezifikationen oder europäischer Schemata für die Cybersicherheitszertifizierung ist in der technischen Dokumentation anzugeben, welche Teile angewandt wurden;

6.

Berichte über die Tests und Prüfungen, die durchgeführt wurden, um die Konformität des Produkts mit digitalen Elementen und der Verfahren zur Behandlung von Schwachstellen mit den geltenden grundlegenden Cybersicherheitsanforderungen in Anhang I Teile I und II zu überprüfen;

7.

ein Exemplar der EU-Konformitätserklärung;

8.

gegebenenfalls auf begründetes Verlangen der Marktüberwachungsbehörde die Software-Stückliste, sofern dies erforderlich ist, damit diese Behörde die Einhaltung der grundlegenden Cybersicherheitsanforderungen in Anhang I überprüfen kann.

Auslegung der EU-Kommission

Guidance vom 27. Juli 2026

Die EU-Kommissions-Guidance vom 27. Juli 2026 enthält offizielle Auslegungshinweise zu dieser Vorschrift. Jeder Abschnitt: Kurzfassung, Kernaussagen und was das konkret für Sie bedeutet.

Abschnitt 2.6Komplexe Systeme und Interoperabilitäts-Constraints

Komplexe Systeme mit langen Entwicklungszyklen, Alt-Komponenten und Interoperabilitätszwängen sind nicht vom CRA ausgenommen — ihre Constraints fließen aber in den risikobasierten Ansatz ein. Wo einzelne wesentliche Anforderungen nicht oder nicht voll umsetzbar sind (vgl. Erwägungsgrund 55), müssen Hersteller die Constraints dokumentieren, die Risiken bewerten und kompensierende Maßnahmen treffen.

Kernaussagen

  • Ein unsicheres Legacy-Protokoll darf implementiert werden, wenn es für Interoperabilität nötig ist und die Risiken anderweitig mitigiert werden; unterstützt das Produkt beide Protokolle, muss das sichere der Default sein (Beispiel 10).
  • Constraints, Risiken und Mitigationen gehören transparent in die technische Dokumentation (Art. 31, Anhang VII) und die Nutzerinformationen (Anhang II).
  • Constraints sind während des Supportzeitraums regelmäßig neu zu bewerten; entfallen sie, muss das Produkt entsprechend nachgezogen werden.
  • Vor CRA-Geltung beschaffte Komponenten dürfen integriert werden, wenn die Risikobewertung keine spezifischen Risiken ergibt und das Gesamtprodukt die Anforderungen erfüllt (Beispiel 11).

Für die Praxis

Legen Sie für jede nicht (voll) erfüllbare Anforderung ein Constraint-Dossier an: Warum nicht umsetzbar (z. B. Interoperabilitätszwang), welches Risiko entsteht, welche Kompensationsmaßnahme greift — und terminieren Sie die Neubewertung. Genau diese Dokumentation wird die Marktüberwachung sehen wollen.

Abschnitt im Guidance-Überblick
Abschnitt 2.7Vor CRA-Geltung entwickelte Produkte — kein Redesign-Zwang

Produkte, die vor dem 11. Dezember 2027 entworfen, aber danach in Verkehr gebracht werden, müssen nicht zwingend neu designt werden. Der Hersteller führt eine aktuelle Risikobewertung durch; zeigt sie, dass vorhandene Maßnahmen die Risiken adressieren, kann er darauf die Konformität stützen. Historische Design- und Testdokumentation muss nicht rekonstruiert werden.

Kernaussagen

  • Konformitätsbewertungsverfahren, EU-Konformitätserklärung und CE-Kennzeichnung bleiben in jedem Fall Pflicht.
  • Keine Pflicht, Testnachweise aus der ursprünglichen Designphase nachzuliefern; Tests können über Produktfamilien gebündelt werden (Abschnitt 7.4 der Leitlinien).
  • Schwachstellenbehandlung (Anhang I Teil II), aktuelle Risikobewertung (Art. 13 Abs. 3) und Nutzerinformationen (Art. 13 Abs. 18) gelten uneingeschränkt.

Beispiel aus der Guidance

Ein vor CRA-Geltung entwickelter Mikrocontroller darf ohne Redesign weiter in Verkehr gebracht werden, wenn eine aktuelle Risikobewertung zeigt, dass die vorhandenen Sicherheitsmaßnahmen die identifizierten Risiken abdecken (Beispiel 12).

Für die Praxis

Planen Sie für Bestandsdesigns kein Redesign ein, bevor die Risikobewertung eines verlangt: Eine aktuelle Risikobewertung plus der Nachweis, dass vorhandene Maßnahmen die Risiken abdecken, genügt. Historische Design- und Testdoku müssen Sie nicht rekonstruieren — Konformitätserklärung und CE-Kennzeichnung bleiben aber Pflicht.

Abschnitt im Guidance-Überblick
Abschnitt 7.4Produktfamilien — eine Risikobewertung, eine Doku, eine Erklärung

Varianten mit gleicher Architektur, gleichem sicherheitsrelevantem Design, gleicher Zweckbestimmung und gleichem Risikoprofil dürfen eine gemeinsame Risikobewertung, technische Dokumentation, Konformitätsbewertung und EU-Konformitätserklärung teilen. Entscheidend ist allein, ob die Unterschiede zwischen den Varianten cybersicherheitsrelevant sind.

Kernaussagen

  • Unerheblich: Farbe, Formfaktor, Speichergröße und andere nicht sicherheitsrelevante Merkmale.
  • Relevant: abweichende Kommunikationsschnittstellen, Software-Stacks, Update-Mechanismen oder Remote-Konnektivität — solche Unterschiede müssen sich in Risikobewertung und Doku niederschlagen.
  • Die gemeinsame Konformitätserklärung muss die abgedeckten Varianten eindeutig identifizieren; neue Varianten mit neuen Risiken erfordern eine Aktualisierung.

Für die Praxis

Gruppieren Sie Ihre Produktvarianten nach sicherheitsrelevanten Unterschieden: Alles, was Architektur, Schnittstellen und Risikoprofil teilt, kann eine gemeinsame Risikobewertung, Doku und EU-Konformitätserklärung bekommen — Farbe, Formfaktor und Speichergröße trennen nicht. Das reduziert den Aufwand pro Variante drastisch; die Erklärung muss die abgedeckten Varianten nur eindeutig benennen.

Abschnitt im Guidance-Überblick
Abschnitt 8.2RDPS in Doku, Risikobewertung und Konformitätsbewertung

RDPS gehören in Risikobewertung, technische Dokumentation und Konformitätsbewertung des Produkts — beschränkt auf die Software-Module, die die Produktfunktion tragen, und deren Schnittstellen. Nachgelagerte Backend-Systeme ohne direkte Produkt-Interaktion sind kein RDPS, bleiben aber externe Abhängigkeiten, deren Risiken produktseitig zu mitigieren sind.

Kernaussagen

  • Ein RDPS, das mehrere Produkte bedient, ist in jeder Produkt-Doku zu deklarieren — die RDPS-Dokumentation darf über Konformitätsbewertungen hinweg wiederverwendet werden.
  • Wiederverwendbare Assurance-Nachweise für Dritt-Services: NIS-2-Nachweise (DVO (EU) 2024/2690), DORA-Nachweise, Zertifikate nach EU-Cybersicherheits-Schemata, ISO/IEC 27001/27017.
  • Änderungen an Dritt-Services sind keine wesentliche Änderung des Produkts — Hersteller sollten sich aber vertraglich (SLAs) Informationen und Sicherheitsgarantien zusichern lassen und die Risikobewertung nachziehen.

Für die Praxis

Legen Sie ein zentrales RDPS-Dossier an — betroffene Software-Module, Schnittstellen, genutzte Provider samt Nachweisen (ISO 27001/27017, NIS-2-, DORA-Evidenz, EUCC-Zertifikate) — und referenzieren Sie es aus jeder Produkt-Doku. Verankern Sie in Provider-SLAs, dass Sie über wesentliche Änderungen informiert werden: Die lösen zwar keine neue Konformitätsbewertung aus, wohl aber ein Update Ihrer Risikobewertung.

Abschnitt im Guidance-Überblick
Alle Guidance-Kapitel im Überblick

EU-Kommissions-Guidance (C(2026) 5252 final) — Die Guidance gibt die Auslegung der Europäischen Kommission wieder und ist rechtlich nicht bindend. Eine verbindliche Auslegung des EU CRA kann nur der Gerichtshof der Europäischen Union vornehmen.

Häufige Hersteller-Fragen

Was muss die Technische Dokumentation enthalten?

Produktbeschreibung mit Zweck und bestimmungsgemäßem Gebrauch, Designdokumentation, Risikobewertung, Testberichte, Schwachstellenbehandlungsprozess inkl. SBOM, Liste der angewandten harmonisierten Normen, EU-Konformitätserklärung, Berichte etwaiger notifizierter Stellen.

Muss die SBOM in der Technischen Dokumentation sein?

Ja. Anhang VII verweist auf Anhang I Teil II, der die SBOM-Pflicht definiert. Die SBOM ist damit Bestandteil der Technischen Dokumentation und muss bei Marktüberwachungs-Audits vorgelegt werden.

In welcher Form muss die Dokumentation aufbewahrt werden?

Strukturiert, vollständig, lesbar, archiviert. Format ist nicht vorgeschrieben — Papier oder elektronisch sind beide möglich, solange Authentizität und Integrität gewahrt sind. Versionierung empfohlen.

Wer hat Zugriff auf die Technische Dokumentation?

Primär die Marktüberwachungsbehörden und ggf. die notifizierte Stelle. Sie ist keine öffentliche Publikation — aber B2B-Kunden können Auszüge im Rahmen der Beschaffung verlangen.

Dieser Text wurde aus der Verordnung (EU) 2024/2847 des Europäischen Parlaments und des Rates vom 23. Oktober 2024 übernommen. Die Darstellung dient ausschließlich Informationszwecken und stellt keine Rechtsberatung dar. Maßgeblich ist allein der im Amtsblatt der Europäischen Union veröffentlichte Wortlaut. Originaltext auf EUR-Lex