CRA in Elektronikfertigung, EMS & Zulieferung

EMS, ODM, OEM-Zulieferer: Der CRA trifft Sie an einer ungewohnten Stelle

Wenn Sie Baugruppen bestücken, Kommunikationsmodule liefern oder komplette Geräte im Kundenauftrag fertigen, ist der Cyber Resilience Act (Verordnung (EU) 2024/2847) für Sie keine Frage nach der „richtigen Produktklasse" — sondern zuerst eine Rollenfrage. Der CRA verteilt Pflichten entlang der Rolle beim Inverkehrbringen: Wer ein Produkt mit digitalen Elementen unter eigenem Namen oder eigener Marke auf den EU-Markt bringt, gilt als Hersteller und trägt die Hauptverantwortung. Reine Lohnfertigung nach Kundenspezifikation (Build-to-Print) macht Sie in der Regel nicht zum Hersteller — aber diese Grenze verläuft nicht dort, wo das Bauchgefühl sie vermutet, sondern dort, wo Verträge, Labels und Firmware-Hoheit sie ziehen.

Der reale Schmerz der Branche: Sie sitzen am oberen Ende der Lieferkette (upstream) und liefern Fragmente — eine bestückte Platine, ein LoRa-Modul, ein White-Label-Gehäuse mit fertiger Firmware. Der Endkunde (der OEM oder Markenhersteller) muss daraus die vollständige technische Dokumentation, die Risikobewertung und die SBOM zusammensetzen. Kann er das nicht, weil Sie ihm die Bausteine nicht maschinenlesbar mitgeben, scheitert seine Konformität an Ihrer Zulieferung. Umgekehrt: Wenn ein Vertrag Sie ungewollt zum Hersteller macht (weil Ihre Marke auf dem Typenschild steht oder Sie die Firmware pflegen), erben Sie Herstellerpflichten, für die niemand budgetiert hat.

Das erzeugt einen doppelten Druck: nach unten (Ihre eigenen Software-Bestandteile und Zulieferer) und nach oben (die Nachweise, die Ihr Abnehmer von Ihnen braucht). SBOM-Weitergabe, Update-Verantwortung und Meldewege werden damit vom technischen Detail zum Vertrags- und Wettbewerbsmerkmal. Dieser Beitrag ordnet ein — er ersetzt keine Rechtsberatung und trifft keine verbindliche Einzelfallaussage.

Typische PDE-Produkte der Branche und ihre wahrscheinliche Anhang-III-Klasse

Produkte mit digitalen Elementen (PDE) in der Elektronikfertigung reichen von der schlichten bestückten Baugruppe bis zum Secure Element. Ein Grundsatz vorweg, der oft missverstanden wird: Die CRA-Klasse folgt dem Endprodukt und seiner Sicherheitsfunktion, nicht der Fertigungstiefe. Eine Standard-Baugruppe wird nicht dadurch „kritisch", dass sie aufwendig gefertigt ist. Umgekehrt kann eine einzelne Komponente — etwa ein manipulationssicherer Mikrocontroller — schon für sich in einer höheren Klasse liegen.

Für die Mehrheit der Standardprodukte genügt die Selbstbewertung nach Modul A. Bei Klasse-I-Produkten (Anhang III, „wichtig") ist die Selbstbewertung nur zulässig, wenn die einschlägigen harmonisierten Normen vollständig angewandt werden — sonst muss eine notifizierte Stelle eingebunden werden. Bei Klasse II ist die notifizierte Stelle immer erforderlich, bei Anhang-IV-Produkten ebenfalls, ggf. mit verpflichtendem EU-Zertifizierungsschema. Die technischen Beschreibungen der wichtigen und kritischen Kategorien präzisiert die Durchführungsverordnung (EU) 2025/2392. Als Zulieferer sollten Sie die Zielklasse Ihres OEM-Kunden kennen — denn liefern Sie in ein Klasse-II-Endprodukt zu, steigen die Nachweisanforderungen an Ihren Beitrag mit.

Branchennormen und Abgrenzung zu angrenzenden Regimen

Der einschlägige Sektor-Hebel ist die Normenfamilie IEC 62443: IEC 62443-4-1 beschreibt den sicheren Produktentwicklungslebenszyklus (Secure Development Lifecycle) und IEC 62443-4-2 die technischen Sicherheitsanforderungen an Komponenten. Mit dokumentierten Prozessen nach 62443-4-1 plus Secure-Coding- und Härtungsnachweisen belegen Sie als Zulieferer Ihren Beitrag zur CRA-Konformität des Endprodukts — genau das, was ein OEM in seiner technischen Doku braucht. Perspektivisch werden harmonisierte Normen unter dem CRA die konkrete Vermutungswirkung liefern; IEC 62443 ist heute schon die etablierte Grundlage.

Wichtig ist die saubere Abgrenzung zu benachbarten Rechtsakten, weil Ihre Produkte oft mehrere Regime berühren:

• RED-Delegierte-Verordnung 2022/30 (Funkanlagenrichtlinie): Für funkfähige Module (BLE, WLAN, Mobilfunk) gelten Cybersicherheitsanforderungen der RED. Es gibt Überschneidungen mit dem CRA; die Anforderungen sind nebeneinander zu betrachten, nicht gegeneinander auszuspielen.
• NIS2 adressiert Betreiber wesentlicher und wichtiger Einrichtungen — also die Organisation, nicht das Produkt. Ihre Fertigungs-IT kann NIS2-relevant sein; das ist ein anderer Rechtsakt als der produktbezogene CRA.
• AI Act greift, wenn ein Modul KI-Funktionen enthält, die dort geregelt sind — zusätzlich, nicht ersetzend.
• Kfz-Typgenehmigung, zivile Luftfahrt, Schiffsausrüstung, MDR/IVDR-Medizinprodukte sind sektoral gesondert geregelt; entsprechende Produkte sind vom CRA ausgenommen. Wer in solche Endprodukte zuliefert, folgt dem Sektorregime.

SBOM- und Lieferketten-Realität dieser Branche

Der typische Software-Stack in einer Baugruppe ist ein Schichtkuchen aus Fremdcode: Bootloader, Echtzeit-Betriebssystem oder embedded Linux, TCP/IP- und Krypto-Bibliotheken, Funk-Stacks, Herstellertreiber und SDKs der Chip-Lieferanten. Genau hier liegen die stillen Risiken: End-of-Life-Komponenten, für die kein Sicherheitsupdate mehr kommt, veraltete Open-Source-Bibliotheken (OSS) mit bekannten Schwachstellen, und vom Chip-Hersteller mitgelieferte Binär-Blobs ohne Herkunftsnachweis. Ein OEM kann diese Schichten nicht sehen — Sie als EMS/ODM sitzen an der Quelle und sind die Einzigen, die sie vollständig kennen.

Der CRA verlangt eine maschinenlesbare SBOM als Teil der technischen Dokumentation, mindestens auf Ebene der Top-Level-Abhängigkeiten. Maschinenlesbar heißt konkret CycloneDX ≥ 1.6 oder SPDX ≥ 3.0.1 — die Formatvorgabe der BSI TR-03183-2 (v2.1.0). Ein PDF mit einer Komponentenliste erfüllt das nicht. Eine belastbare SBOM je Baugruppe sollte enthalten: Komponentenname und -version, Lieferant/Herkunft, eindeutige Kennungen (z. B. PURL/CPE), Lizenz und die Abhängigkeitsbeziehungen. Eine allgemeine Veröffentlichungspflicht besteht nicht — die SBOM gehört in die technische Doku und wird upstream an den Abnehmer weitergereicht, nicht ins Schaufenster. Wer SBOM-Fragmente pro Baugruppe automatisiert erzeugt und sauber übergibt, macht daraus ein Verkaufsargument; wer es nicht kann, wird aus Ausschreibungen fallen.

Meldefähigkeit und PSIRT: die Art.-14-Kaskade korrekt gelesen

Die Meldepflichten nach Artikel 14 sind für Zulieferer heikel, weil eine Schwachstelle in Ihrer gelieferten Firmware zur Meldepflicht des Herstellers wird — und die Uhr läuft ab Kenntnis. Die Kaskade bei einer aktiv ausgenutzten Schwachstelle bzw. einem schweren Vorfall lautet:

• 24 Stunden — Frühwarnung (early warning) ab Kenntnisnahme;
• 72 Stunden — vollständige Meldung inklusive bereits ergriffener Korrektur- und Minderungsmaßnahmen;
• Abschlussbericht: bei einer aktiv ausgenutzten Schwachstelle innerhalb von 14 Tagen nach Verfügbarkeit einer Korrekturmaßnahme; bei einem schweren Sicherheitsvorfall innerhalb von einem Monat nach der 72-Stunden-Meldung.

Die verbreitete Kurzform „24h/72h/14 Tage" ist damit falsch — die 14 Tage und der eine Monat betreffen unterschiedliche Fälle. Gemeldet wird über die ENISA Single Reporting Platform (SRP) als Einmalmeldung an das CSIRT der Hauptniederlassung und ENISA; die Plattform ist zum 11.09.2026 bereitzustellen. Praktisch heißt das: Sie brauchen einen funktionierenden PSIRT-Prozess (Product Security Incident Response Team) und eine CVD-Policy (Coordinated Vulnerability Disclosure), die vertraglich mit dem OEM verzahnt ist — wer meldet, wer den Fix baut, wer über den Support-Zeitraum (Richtwert mindestens fünf Jahre) versorgt.

Welche Frist zuerst greift: 11.09.2026 vor 11.12.2027

Zwei Daten strukturieren die Vorbereitung. Zuerst greifen am 11.09.2026 die Melde- und Berichtspflichten nach Artikel 14 — die erste harte Herstellerpflicht. Ab diesem Tag müssen aktiv ausgenutzte Schwachstellen und schwere Vorfälle fristgerecht gemeldet werden, unabhängig davon, ob Ihr Produkt schon alle Produktanforderungen erfüllt. Die vollständige Anwendbarkeit aller Produktanforderungen (Security-by-Design, SBOM, technische Doku, CE-Konformität) folgt am 11.12.2027. Für Zulieferer bedeutet das: Der Melde- und PSIRT-Aufbau ist das dringlichere Projekt, die vollständige technische Konformität das größere. Beides parallel zu planen ist sinnvoll, weil die SBOM-Basis für beide gebraucht wird.

Durchgespieltes Beispiel: EMS fertigt ein IoT-Gateway

Ein mittelständischer EMS-Dienstleister fertigt für einen Markenhersteller ein LoRa-IoT-Gateway. Der Markenhersteller vertreibt es unter eigener Marke — er ist damit voraussichtlich Hersteller im Sinne des CRA, der EMS liefert zu. In der Firmware stecken ein embedded Linux, ein LoRa-Stack des Chip-Lieferanten und mehrere OSS-Bibliotheken, eine davon in einer Version mit bekannter Schwachstelle. Das Gateway selbst wäre voraussichtlich ein Standardprodukt (Modul A). Ungeklärt bleibt zunächst: Wer erzeugt und pflegt die SBOM? Wer baut Sicherheitsupdates über die Lebensdauer? Wie fließen CVD-Meldungen, wenn ein Sicherheitsforscher eine Lücke im LoRa-Stack meldet?

Ohne vertragliche Klärung erbt der Markenhersteller eine Kette, die er nicht kontrolliert. Die tragfähige Lösung: Der EMS erzeugt je Firmware-Release eine CycloneDX-SBOM automatisiert in der Build-Pipeline, übergibt sie maschinenlesbar, und ein Vertrag regelt Update-Verantwortung und die Meldekette (24 h / 72 h / Abschlussbericht) so, dass der Hersteller seine Art.-14-Pflicht ab 11.09.2026 tatsächlich erfüllen kann. Damit wird die Zulieferung nicht zum Haftungsrisiko, sondern zum belastbaren Baustein.

Was Blackfort Technology für Sie tut

Blackfort Technology (Blackfort Technology UG (haftungsbeschränkt)) begleitet EMS-, ODM- und OEM-Zulieferer entlang genau dieser Punkte — herstellerneutral und ohne amtliche Beauftragung:

• Betroffenheits- und Rollenanalyse: Klärung, in welchen Konstellationen Sie Hersteller, Importeur oder reiner Auftragsfertiger sind, und was daraus schematisch folgt (Scope pro Produktlinie).
• SBOM-Setup: Aufbau einer automatisierten SBOM-Erzeugung (CycloneDX ≥ 1.6 / SPDX ≥ 3.0.1) je Baugruppe/Firmware-Release, inkl. EOL- und OSS-Risiko-Sichtung und Upstream-Übergabeprozess.
• PSIRT und CVD: Aufbau eines Meldeprozesses samt CVD-Policy und Verzahnung der Meldekette mit Ihren OEM-Verträgen.
• Risikobewertung und Threat-Modeling: dokumentationsfähige Risikobewertung nach Art. 13/Anhang I als Methode für die technische Doku.
• Technische Dokumentation: Struktur und Inhalte für die konforme Doku, die Ihr Abnehmer weiterverwenden kann.

Ein pragmatischer Einstieg ist der Betroffenheits-Check. Für kleinere Fertiger lohnt der Blick auf unsere KMU-Perspektive, den fachlichen Rahmen liefert die Übersicht zum Cyber Resilience Act. Für ein konkretes Gespräch: Kontakt aufnehmen. Dies ist eine fachliche Einordnung und keine Rechtsberatung.