CRA-Pflichten für Hersteller — Übersicht 2026

Überblick: Was der CRA von Herstellern verlangt

Der Cyber Resilience Act (EU-Verordnung 2024/2847) legt in Artikel 13 die Kernpflichten für Hersteller von Produkten mit digitalen Elementen fest.¹ Drei Kategorien strukturieren diese Pflichten:

1. Vor dem Inverkehrbringen — einmalige Pflichten, die vor dem ersten Verkauf erfüllt sein müssen
2. Während der Supportzeit — laufende Pflichten für mindestens 5 Jahre
3. Bei wesentlichen Änderungen — wiederkehrende Pflichten bei erheblichen Produktänderungen

Alle drei Kategorien gelten ab dem 11. Dezember 2027 vollumfänglich. Die Meldepflicht (Kategorie 2) greift bereits ab 11. September 2026.

Dezember 2027 klingt weit weg. Ist es nicht. Technische Dokumentation, Risikoanalyse und SBOM-Prozesse brauchen realistisch 6–12 Monate Vorlaufzeit. Hinzu kommt: Großkunden und Vergabestellen fordern CRA-Konformität bereits heute vertraglich — lange bevor Behörden kontrollieren.

---

Kategorie 1: Pflichten vor dem Inverkehrbringen

Cybersicherheits-Risikoanalyse (Artikel 13 Absatz 2, Anhang I) — Rechtspflicht

Vor dem ersten Inverkehrbringen müssen Hersteller eine Risikoanalyse durchführen, die alle Cybersicherheitsrisiken des Produkts identifiziert und bewertet. Kein einmaliges Dokument — über den gesamten Lebenszyklus müssen Hersteller sie aktualisieren.

Was die Risikoanalyse umfassen muss:

• Identifikation aller Angriffspfade und Bedrohungsszenarien
• Bewertung der Eintrittswahrscheinlichkeit und potenzieller Schäden
• Ableitung konkreter Schutzmaßnahmen
• Dokumentation der Restrisiken

Ein Hersteller von embedded-Software für Heizungssteuerungen ist hier genauso betroffen wie ein IoT-Startup mit industriellen MQTT-Gateways. Wer Firmware liefert, die remote erreichbar ist, hat Angriffspfade — und muss sie dokumentieren.

Umsetzung der 10 Sicherheitsanforderungen (Anhang I) — Rechtspflicht

Anhang I der Verordnung listet die technischen und prozessualen Mindestanforderungen:¹

#	Anforderung	Kurzform
1	Risikobasierte Schutzmaßnahmen nach Stand der Technik	Secure Design
2	Sichere Standardkonfigurationen ab Werk	Secure by Default
3	Authentifizierung, Zugriffskontrolle, Identitätsmanagement	Access Control
4	Vertraulichkeit gespeicherter und übertragener Daten	Encryption
5	Integrität von Daten, Software und Konfigurationen	Integrity
6	Minimierung der Angriffsoberfläche	Attack Surface
7	Schutz vor Denial-of-Service-Angriffen	Availability
8	Datenminimierung	Data Minimization
9	Schwachstellenmanagement, Sicherheitsupdates	Vulnerability Mgmt
10	Transparenz über Software-Komponenten (SBOM)	Transparency

Anforderung 2 — „Secure by Default” — verdient besondere Aufmerksamkeit. Konkret bedeutet das: keine Standard-Passwörter, keine offenen Dienste, die für die Grundfunktion nicht benötigt werden, kein optionaler Sicherheitsschutz, der erst aktiviert werden muss. Was viele unterschätzen: Ein großer Teil bestehender Produkte — gerade im Maschinenbau und bei Industrie-4.0-Komponenten — erfüllt das heute nicht.

Software Bill of Materials (SBOM) — Rechtspflicht

Die SBOM ist eine vollständige, maschinenlesbare Liste aller Softwarekomponenten in einem Produkt — einschließlich Drittanbieter-Bibliotheken, Open-Source-Komponenten und deren Versionen.¹ Sie ist die Grundlage für das Schwachstellenmanagement: Nur wer weiß, welche Komponenten im Produkt stecken, erkennt bekannte Schwachstellen (CVEs) schnell und kann sie schließen.

Standardformate:

• CycloneDX (von OWASP, weit verbreitet in der EU)
• SPDX (von der Linux Foundation, ISO-Standard 5962:2021)

Marktaufsichtsbehörden können die SBOM jederzeit anfordern. Eine Pflicht zur öffentlichen Veröffentlichung besteht nicht, ist aber für Open-Source-Komponenten wünschenswert.

Tools zur SBOM-Erstellung (Empfehlung, keine Pflicht):

• Syft (Open Source, OWASP)
• Trivy (Open Source, Aqua Security)
• Dependency-Track (Open Source, OWASP, für Verwaltung)

Konformitätsbewertung (Artikel 32–36, Anhang VIII) — Rechtspflicht

Je nach Risikoklasse schreibt der CRA ein unterschiedliches Konformitätsbewertungsverfahren vor:¹

Klasse	Verfahren
Default	Modul A — Interne Fertigungskontrolle (Selbstbewertung)
Important Class I (mit harmonisierten Standards)	Modul A — Selbstbewertung möglich
Important Class I (ohne harmonisierte Standards)	Modul B+C, B+H oder H — Notified Body erforderlich
Important Class II	Modul B+C, B+H oder H — Notified Body zwingend
Critical	Modul B+C oder H — Notified Body + ggf. EUCC

Die Module bezeichnen unterschiedliche Prüfungsverfahren aus dem EU-Konformitätsbewertungsrecht (Beschluss 768/2008/EG):

• Modul A: Vollständige interne Selbstbewertung ohne externe Prüfstelle
• Modul B: EU-Baumusterprüfung durch Notified Body (Prüfung des Musters)
• Modul C: Konformität mit dem geprüften Baumuster (Herstellererklärung)
• Modul H: Umfassendes Qualitätssicherungssystem, geprüft und überwacht durch Notified Body

Das ist der Punkt, den viele übersehen: Die Unterscheidung „mit harmonisierten Normen” vs. „ohne harmonisierte Normen” bei Important Class I hängt davon ab, ob einschlägige harmonisierte Standards im Amtsblatt der EU veröffentlicht worden sind. Nach aktuellem Stand ist diese Normierung noch nicht vollständig abgeschlossen. Für Hersteller von Class-I-Produkten — etwa Netzwerk-Switches für Industrieumgebungen oder Fernwartungsmodule — bedeutet das echte Planungsunsicherheit. Wer auf Nummer sicher gehen will, plant jetzt bereits mit Notified-Body-Kapazitäten. Diese sind begrenzt und werden knapper.

Technische Dokumentation (Anhang VII) — Rechtspflicht

Hersteller müssen eine umfangreiche technische Dokumentation erstellen und 10 Jahre nach Inverkehrbringen aufbewahren. Anhang VII listet den Mindestinhalt:¹

• Allgemeine Beschreibung des Produkts
• Beschreibung der Entwicklung und des Produktionsprozesses
• Ergebnisse der Risikoanalyse
• Beschreibung der umgesetzten Sicherheitsanforderungen (Anhang I)
• EU-Konformitätserklärung
• Liste der angewendeten Normen und Spezifikationen
• SBOM
• Beschreibung der Schwachstellenbehandlungsprozesse

CE-Kennzeichnung und EU-Konformitätserklärung (Artikel 28–30) — Rechtspflicht

Nach abgeschlossener Konformitätsbewertung müssen Hersteller:

• Die CE-Kennzeichnung am Produkt anbringen (oder in der Begleitdokumentation bei Software)
• Die EU-Konformitätserklärung ausfertigen (mit Produktbeschreibung, Normen, Konformitätsbewertungsmodul, ggf. Notified-Body-Nummer)
• Die Konformitätserklärung 10 Jahre aufbewahren

Vulnerability-Disclosure-Policy und Single Point of Contact — Rechtspflicht

Bereits vor dem Inverkehrbringen müssen Hersteller:

• Eine öffentlich zugängliche Adresse (E-Mail oder Formular) für Sicherheitsmeldungen bereitstellen
• Eine dokumentierte Policy zur Behandlung gemeldeter Schwachstellen (Coordinated Vulnerability Disclosure, CVD) veröffentlichen

In der Praxis erleben wir: Viele Unternehmen unterschätzen, was eine CRA-konforme CVD-Policy bedeutet. Sie muss nicht nur existieren, sondern auch funktionieren. Wer bei einer behördlichen Anfrage noch keinen robusten Meldeprozess betreibt, hat ein ernstes Konformitätsproblem — unabhängig davon, wie gut das Produkt selbst gebaut ist.

---

Kategorie 2: Pflichten während der Supportzeit

Mindest-Supportzeitraum: 5 Jahre — Rechtspflicht

Sicherheitsupdates müssen Hersteller für mindestens 5 Jahre nach Inverkehrbringen bereitstellen — oder kürzer, wenn der erwartete Nutzungszeitraum des Produkts kürzer ist. Die Updates müssen kostenfrei sein und separat von Funktionsupdates bereitgestellt werden können.¹

Ein Maschinenbauunternehmen, das eine Steuereinheit für CNC-Fräsen verkauft, muss also bis 2032 Sicherheits-Patches liefern — für jedes Gerät, das ab Dezember 2027 ausgeliefert wird. Das ist keine theoretische Anforderung. Das ist Produktplanung.

Schwachstellen-Monitoring — Rechtspflicht

Hersteller müssen kontinuierlich:

• Bekannte Schwachstellen in verwendeten Komponenten überwachen (CVE-Datenbanken, Herstellermeldungen)
• Neu entdeckte Schwachstellen im eigenen Produkt bewerten
• Patches innerhalb eines angemessenen Zeitraums bereitstellen

Meldepflicht ab 11. September 2026 (Artikel 14) — Rechtspflicht

Ab dem 11. September 2026 gilt eine strikte Meldepflicht:¹

Innerhalb von 24 Stunden nach Kenntnis:

• Meldung aktiv ausgenutzter Schwachstellen an ENISA (über die neue europäische Single-Entry-Point-Plattform)
• Meldung schwerwiegender Sicherheitsvorfälle, die die Produktsicherheit beeinträchtigen

Innerhalb von 72 Stunden:

• Detaillierterer Zwischenbericht mit aktuellen Erkenntnissen zur Ursache und Auswirkung

Innerhalb von 14 Tagen:

• Abschließender Bericht mit vollständiger Analyse, ergriffenen Maßnahmen und Empfehlungen

Zusätzlich müssen Hersteller bei schwerwiegenden Vorfällen die nationalen CSIRT-Behörden (in Deutschland: BSI als CERT-Bund) informieren.

24 Stunden sind wenig. Sehr wenig. Wer diesen Prozess ohne Vorbereitung zum ersten Mal unter echtem Vorfallsdruck aufbauen muss, wird die Frist regelmäßig reißen. Was viele CRA-Berater nicht sagen: Die Meldepflicht ist der Teil des CRA, für den Hersteller am ehesten operative Kapazitäten aufbauen müssen — nicht nur Dokumentation. Ein IoT-Startup mit drei Entwicklern, das gerade seinen ersten industriellen MQTT-Gateway auf den Markt bringt, braucht hier einen klaren internen Eskalationspfad. Schriftlich. Geübt.

Nutzerkommunikation — Rechtspflicht

Sobald sicherheitsrelevante Updates bereitstehen, müssen Hersteller Nutzer informieren — auf einem angemessenen Kanal und in verständlicher Form.

---

Kategorie 3: Pflichten bei wesentlichen Änderungen

Nimmt ein Hersteller eine wesentliche Änderung an einem bereits in Verkehr gebrachten Produkt vor, gelten folgende Pflichten:

• Neue Risikoanalyse für die geänderten Teile
• Aktualisierung der technischen Dokumentation
• Prüfung, ob das gewählte Konformitätsbewertungsverfahren noch gilt
• Ggf. erneute Konformitätsbewertung (auch durch Notified Body)
• Aktualisierung der EU-Konformitätserklärung

Was ist eine „wesentliche Änderung”? Der CRA definiert dies als eine Änderung, die die Erfüllung der grundlegenden Cybersicherheitsanforderungen beeinflusst oder die Zweckbestimmung des Produkts ändert. Reine Sicherheits-Patches sind in der Regel keine wesentlichen Änderungen. Ob eine konkrete Änderung als wesentlich gilt, lässt sich nach aktuellem Stand nicht immer trennscharf beurteilen — Leitlinien der Marktaufsichtsbehörden fehlen hier noch.

Konkret bedeutet das: Ein Hersteller von embedded-Software für Gebäudeautomation, der ein neues Kommunikationsprotokoll in seine Steuereinheit integriert, muss prüfen, ob das eine wesentliche Änderung ist. Fügt das neue Protokoll eine externe Schnittstelle hinzu, ist die Antwort fast immer ja.

---

Besonderheiten für verschiedene Unternehmensgrößen

Bei einigen Pflichten unterscheidet der CRA nach Unternehmensgröße:

• Kleinstunternehmen (weniger als 10 Mitarbeitende, Jahresumsatz/Bilanzsumme unter 2 Mio. Euro) können von der Marktaufsichtsbehörde zeitlich begrenzte Ausnahmen oder vereinfachte Verfahren für die technische Dokumentation erhalten (Artikel 13 Absatz 14).¹
• Open-Source-Stewards (Organisationen, die Open-Source-Software pflegen und kommerziell bereitstellen) haben vereinfachtere Pflichten, sind aber nicht vollständig ausgenommen.

Wichtig: Das sind Kann-Regelungen, keine garantierten Ausnahmen. Kleinstunternehmen sollten nicht darauf vertrauen, dass die Marktaufsicht automatisch Nachsicht übt.

---

Dokumentations-Checkliste für Hersteller

Bis zum 11. Dezember 2027 müssen folgende Dokumente vorliegen:

Dokument	Pflichtbasis	Aufbewahrung
Cybersicherheits-Risikoanalyse	Artikel 13, Anhang I	10 Jahre
Technische Dokumentation	Anhang VII	10 Jahre
SBOM (CycloneDX oder SPDX)	Anhang I, Punkt 10	Laufend aktuell
EU-Konformitätserklärung	Artikel 28	10 Jahre
Vulnerability-Disclosure-Policy	Artikel 13 Absatz 6	Öffentlich zugänglich
Sicherheits-Update-Strategie	Artikel 13 Absatz 8	Dokumentiert
Meldeprozess (24h-Fähigkeit)	Artikel 14	Ab Sept 2026 aktiv

---

Verhältnis zu anderen Standards

Wer bereits nach ISO 27001 oder IEC 62443 zertifiziert ist, hat einen Vorsprung — aber keine vollständige CRA-Konformität. Das klingt nach einer Kleinigkeit. Ist es nicht.

• ISO 27001: Deckt organisatorische Governance, nicht produktspezifische technische Anforderungen. Kein direktes Mapping zu Anhang I. ISO 27001 hilft — aber wer glaubt, damit CRA-konform zu sein, wird bei der ersten Behördenanfrage böse überrascht.
• IEC 62443: Sehr starkes inhaltliches Mapping für Industrieprodukte (~70–80 %). Kann als Grundlage für CRA-Konformitätsdokumentation dienen.
• ETSI EN 303 645: Relevanter harmonisierter Standard für Consumer-IoT-Produkte. Die Anwendung dürfte nach aktuellem Stand die Selbstbewertung für Important Class I ermöglichen — sobald die entsprechenden harmonisierten Normen im Amtsblatt veröffentlicht sind.

Mehr zur Klassifizierung Ihres Produkts finden Sie unter CRA Risikoklassen erklärt.

Starten Sie jetzt den kostenlosen CRA-Check und erfahren Sie, welche dieser Pflichten konkret für Ihr Produkt gelten — abhängig von Ihrer Risikoklasse.

---

Quellen

1. EU-Verordnung 2024/2847 (Cyber Resilience Act), Artikel 13, Artikel 14, Artikel 28–36, Anhang I, Anhang VII, Anhang VIII: https://eur-lex.europa.eu/legal-content/DE/TXT/?uri=OJ:L_202402847
2. BSI — Cyber Resilience Act, technische Anforderungen: https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Informationen-und-Empfehlungen/Cyber_Resilience_Act/
3. ENISA — CRA Implementierungsleitfaden: https://www.enisa.europa.eu/topics/cyber-resilience-act
4. OWASP — CycloneDX Standard: https://cyclonedx.org/
5. Linux Foundation — SPDX (ISO/IEC 5962:2021): https://spdx.dev/
6. EU-Kommission — Beschluss 768/2008/EG (Konformitätsbewertungsmodule): https://eur-lex.europa.eu/legal-content/DE/TXT/?uri=CELEX:32008D0768