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, beginnt der Cyber Resilience Act (Verordnung (EU) 2024/2847) für Sie mit einer Rollenfrage; die „richtige Produktklasse" kommt danach. 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 grundsätzlich nicht zum Hersteller. Wo die Grenze verläuft, bestimmen Verträge, Labels und Firmware-Hoheit - das Bauchgefühl liegt dabei leicht daneben.

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: Die Klasse folgt der Kernfunktion des Produkts, das Sie in Verkehr bringen, nicht der Fertigungstiefe (Art. 7 Abs. 1). Eine Standard-Baugruppe wird nicht dadurch „kritisch", dass sie aufwendig gefertigt ist. Umgekehrt kann eine einzelne, separat gelieferte Komponente - etwa ein manipulationssicherer Mikrocontroller - für sich in einer höheren Klasse liegen.

Für Standardprodukte genügt die Selbstbewertung nach Modul A. Bei Klasse-I-Produkten (Anhang III, „wichtig") ist die Selbstbewertung nur zulässig, wenn harmonisierte Normen, gemeinsame Spezifikationen oder ein europäisches Cybersicherheitszertifizierungsschema (mindestens Vertrauenswürdigkeitsstufe „mittel“) vollständig angewandt werden - sonst muss eine notifizierte Stelle eingebunden werden (Modul B+C oder H). Klasse II verlangt Modul B+C, Modul H oder ein europäisches Schema mindestens „mittel“. Anhang IV verlangt ein europäisches Schema, falls ein delegierter Rechtsakt es vorschreibt, sonst gilt dasselbe wie für Klasse II. Die technischen Beschreibungen der wichtigen und kritischen Kategorien präzisiert die Durchführungsverordnung (EU) 2025/2392. Wichtig für Zulieferer: Ein in ein Gerät eingebautes Klasse-I- oder Klasse-II-Bauteil stuft das Gerät nicht hoch (Art. 7 Abs. 1 Satz 2); umgekehrt bestimmt die Klasse des Endprodukts nicht die Klasse Ihres separat gelieferten Bauteils.

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. Harmonisierte Normen zum CRA sind beauftragt (M/606), am 9. Oktober 2026 aber noch nicht im Amtsblatt veröffentlicht; IEC 62443 ist heute schon die etablierte Grundlage.

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

• RED-Delegierte-Verordnung 2022/30 (Funkanlagenrichtlinie): Für bestimmte Funkanlagen, vor allem solche, die über das Internet kommunizieren können, gelten seit dem 1. August 2025 Cybersicherheitsanforderungen der RED; das kann funkfähige Module (BLE, WLAN, Mobilfunk) betreffen. Es gibt Überschneidungen mit dem CRA; bis zur Aufhebung der VO 2022/30 zum 11.12.2027 sind beide Anforderungen nebeneinander zu betrachten, danach deckt der CRA sie ab.
• NIS2 adressiert wesentliche und wichtige Einrichtungen - also die Organisation, nicht das Produkt. Hersteller elektronischer Erzeugnisse können ab mittlerer Größe selbst unter NIS2 fallen (Anhang II Nr. 5), dann auch mit ihrer Fertigungs-IT; das ist ein anderer Rechtsakt als der produktbezogene CRA.
• AI Act gilt zusätzlich, sobald ein KI-System verbaut ist; der Umfang der Pflichten hängt von der Risikostufe ab.
• Sektorausnahmen: Ausgenommen sind Produkte, auf die MDR, IVDR oder die Typgenehmigungsverordnung (EU) 2019/2144 Anwendung finden, nach der Verordnung (EU) 2018/1139 zertifizierte Luftfahrtprodukte und Schiffsausrüstung (Art. 2 Abs. 2 bis 4). Für Zulieferer kommt es auf das gelieferte Bauteil an: Fällt es selbst unter einen dieser Rechtsakte, etwa als Bauteil für Kraftfahrzeuge, ist es ausgenommen. Ein allgemein verwendbares Modul, das Sie einem Medizinproduktehersteller liefern, bleibt dagegen ein Produkt mit digitalen Elementen im Sinne des CRA.

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 Software-Stückliste in einem gängigen maschinenlesbaren Format, aus der zumindest die obersten Abhängigkeiten hervorgehen (Anhang I Teil II Nr. 1), als Teil der technischen Dokumentation. Ein bestimmtes Format schreibt die Verordnung nicht vor; die Kommission kann Format und Elemente per Durchführungsrechtsakt festlegen (Art. 13 Abs. 24). Die Technische Richtlinie BSI TR-03183-2 (v2.1.0) empfiehlt CycloneDX ab Version 1.6 oder SPDX ab Version 3.0.1; sie ist eine nationale Empfehlung, keine Pflicht aus dem CRA. Ein PDF mit einer Komponentenliste ist nicht maschinenlesbar. Eine brauchbare 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. Eine Rechtspflicht des Zulieferers zur Weitergabe begründet der CRA nicht; ein strukturierter SBOM-Austausch erleichtert Abnehmern aber den Nachweis und wird damit zum Verkaufsargument.

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 schwerwiegenden Vorfall lautet:

• 24 Stunden - Frühwarnung: unverzüglich, spätestens 24 Stunden nach Kenntnis;
• 72 Stunden - Meldung: unverzüglich, spätestens 72 Stunden nach Kenntnis, mit den verfügbaren allgemeinen Informationen und den ergriffenen Korrektur- oder Risikominderungsmaßnahmen;
• Abschlussbericht: bei einer aktiv ausgenutzten Schwachstelle innerhalb von 14 Tagen nach Verfügbarkeit einer Korrektur- oder Risikominderungsmaßnahme; bei einem schwerwiegenden Sicherheitsvorfall innerhalb von einem Monat nach der 72-Stunden-Meldung.

Die Kurzform „24h/72h/14 Tage" ist damit falsch - die 14 Tage und der eine Monat betreffen unterschiedliche Fälle. Gemeldet wird über die einheitliche Meldeplattform (Art. 16), über den Endpunkt des als Koordinator benannten CSIRT im Mitgliedstaat der Hauptniederlassung, gleichzeitig für ENISA zugänglich - eine Einmalmeldung. 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 Unterstützungszeitraum versorgt (in der Regel mindestens fünf Jahre, kürzer nur bei kürzerer voraussichtlicher Nutzungsdauer, Art. 13 Abs. 8).

Welche Frist zuerst greift: 11.09.2026 vor 11.12.2027

Zwei Daten strukturieren die Vorbereitung. Seit dem 11.09.2026 greifen die Melde- und Berichtspflichten nach Artikel 14, die erste harte Herstellerpflicht. Seit diesem Tag müssen aktiv ausgenutzte Schwachstellen und schwerwiegende 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, weil die Pflicht bereits gilt, 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), sofern Routing nicht seine Kernfunktion ist. 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 praktikable 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 (Frühwarnung, Meldung, Abschlussbericht) so, dass der Hersteller seine seit 11.09.2026 geltende Art.-14-Pflicht tatsächlich erfüllen kann. So wird die Zulieferung zum nachweisbaren Baustein in der Dokumentation des Herstellers.

Was Blackfort Technology für Sie tut

Blackfort Technology begleitet EMS-, ODM- und OEM-Zulieferer entlang genau dieser Punkte - herstellerneutral und ohne amtliche Beauftragung:

• Betroffenheits- und Rollenanalyse: technische Einschätzung, in welchen Konstellationen Sie Hersteller, Einführer oder reiner Auftragsfertiger sind, und was daraus schematisch folgt (Scope pro Produktlinie), zur Prüfung durch Ihre Rechtsabteilung.
• SBOM-Setup: Aufbau einer automatisierten SBOM-Erzeugung, etwa in CycloneDX oder SPDX, 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: Aufbau der Unterlagen nach Anhang VII, so dass Ihr Abnehmer sie 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.