CRA in Ladeinfrastruktur & E-Mobility

Ein Ladepunkt ist heute ein vernetzter Kleincomputer mit Zahlungs-, Abrechnungs-, Lastmanagement- und Fernwartungsfunktionen - ständig online, in großer Zahl im Feld verteilt, und mit einer direkten Datenverbindung ins Backend. Genau diese Eigenschaften machen ihn zu einem Produkt mit digitalen Elementen (PDE) im Sinne des Cyber Resilience Act (Verordnung (EU) 2024/2847). Wer AC-Wallboxen, DC-Schnelllader, Ladepunkt-Controller oder die dazugehörige Software herstellt, importiert oder unter eigenem Namen in Verkehr bringt, sollte die CRA-Betroffenheit früh prüfen - dies ist eine schematische Einordnung und ersetzt keine Rechtsberatung.

Der reale Schmerz dieser Branche ist spezifisch: Ladeinfrastruktur sitzt an der Nahtstelle von Energie- und Mobilitätsnetz, spricht mit Backends (OCPP), mit Fahrzeugen (ISO 15118, Plug&Charge) und mit Payment-Dienstleistern - jede dieser Schnittstellen ist Angriffsfläche. Ladesäulen stehen jahrelang im öffentlichen Raum, teils an Standorten mit wackliger Mobilfunk-Konnektivität, und müssen trotzdem über ihre gesamte Lebensdauer sicher aktualisierbar bleiben. Gleichzeitig ist der Sektor energienah und damit im Dunstkreis von NIS2 - was die Compliance-Anforderungen für Hersteller doppelt unübersichtlich macht.

Hinzu kommt Zeitdruck. Die erste harte Herstellerpflicht, die Melde- und Berichtspflicht nach Art. 14, greift bereits seit dem 11.09.2026. Die vollständigen Produktanforderungen (Security-by-Design, technische Dokumentation, CE-Kennzeichnung) folgen zum 11.12.2027. Für einen Wallbox- oder Ladesäulenhersteller heißt das: Der Meldeprozess muss bereits stehen, das Produkt-Engineering muss bis zum 11.12.2027 abgeschlossen sein.

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

Ladehardware ohne Anhang-III-Kernfunktion dürfte schematisch in die Standardkategorie fallen - mit Selbstbewertung nach Modul A. Anders sieht es bei Komponenten aus, deren Kernfunktion eine gelistete Kategorie ist (Art. 7 Abs. 1): Ein zentrales Steuer-/Energiemanagement-Gateway, dessen Kernfunktion Routing ist, fällt in Anhang III Klasse I (Nr. 12); ist die Firewall seine Kernfunktion, Klasse II. Eine eingebaute Filterfunktion allein genügt nicht. Die technischen Beschreibungen der wichtigen und kritischen Kategorien liefert die Durchführungsverordnung (EU) 2025/2392.

Faustregel: Für Produkte der Standardkategorie ist der Konformitätspfad die Selbstbewertung (Modul A) - vorausgesetzt, technische Dokumentation und Risikobewertung sind sauber erstellt. Eine notifizierte Stelle wird nötig, wenn eine Komponente in Klasse I fällt und weder harmonisierte Normen noch gemeinsame Spezifikationen noch ein europäisches Cybersicherheitszertifizierungsschema (mindestens Stufe „mittel“) vollständig angewandt werden (dann Modul B+C oder H). Klasse II verlangt Modul B+C, Modul H oder ein europäisches Schema mindestens „mittel“.

Branchennormen und Abgrenzung zu angrenzenden Regimen

Technisch ruht Ladeinfrastruktur auf einem klar umrissenen Normen-Stack: IEC 62443 für die Sicherheit der Steuerungs-/OT-Ebene, ISO 15118 für die Fahrzeug-Ladepunkt-Kommunikation inklusive Zertifikats- und PKI-Handling für Plug&Charge, sowie OCPP 2.0.1 mit seinen Security-Profilen (TLS-Client-/Serverzertifikate, Secure Firmware Update) für die Backend-Anbindung. Diese Normen liefern das Material, mit dem sich die CRA-Grundanforderungen aus Anhang I konkret erfüllen und dokumentieren lassen. Das PKI-Thema um ISO 15118 ist dabei anspruchsvoll; Blackfort Technology bringt PKI-Erfahrung aus anderen Branchen mit.

Wichtig ist die saubere Abgrenzung zu benachbarten Regimen: Der CRA adressiert die Produkt-Cybersicherheit beim Hersteller. NIS2 hingegen verpflichtet wesentliche und wichtige Einrichtungen (im Energiesektor durchaus einschlägig für den CPO/Betreiber) - das ist ein getrennter Rechtsakt und darf nicht mit dem CRA gleichgesetzt werden. Hersteller elektronischer Erzeugnisse oder elektrischer Ausrüstungen können ab mittlerer Größe selbst unter NIS2 fallen (Anhang II Nr. 5); das betrifft dann die Organisation, nicht die Produktkonformität. Enthält ein Ladepunkt Funkmodule, über die er mit dem Internet kommuniziert (z. B. für Fernwartung), kann zusätzlich die RED-Delegierte-Verordnung 2022/30 greifen, bis sie zum 11.12.2027 aufgehoben wird; bis dahin ist die Überschneidung zum CRA im Blick zu behalten. Klar getrennt bleiben die Typgenehmigungsverordnung (EU) 2019/2144 (die das Fahrzeug und für Fahrzeuge konstruierte Bauteile betrifft, nicht die stationäre Ladehardware) und der AI Act, der zusätzlich gilt, sobald ein KI-System (z. B. für Lastprognosen) verbaut ist.

SBOM- und Lieferketten-Realität dieser Branche

Ladefirmware ist ein Komposit: Embedded-Linux als Basis, ein TLS-Stack für gesicherte Kommunikation, ein OCPP-Client, das ISO-15118-Kommunikationsmodul und - bei Direktzahlung - eine Payment-Middleware. Genau dieser Stack ist der klassische CRA-Stolperstein. Veraltete oder abgekündigte Komponenten (etwa eine End-of-Life-TLS-Bibliothek) tauchen erst dann auf, wenn eine Schwachstelle bekannt wird - und dann muss ein Fix zu Tausenden feldverteilter Säulen ausgerollt werden, teils über instabile Konnektivität.

Die SBOM ist deshalb Ihr Frühwarnsystem. 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 (eine allgemeine Veröffentlichungspflicht besteht nicht). 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. Gut gepflegt leistet die SBOM: eindeutige Komponenten- und Versionsidentifikation, Lieferanten-/Herkunftsangabe und die Verknüpfbarkeit mit Schwachstellendatenbanken - sodass bei einer neuen CVE in Sekunden statt Wochen feststeht, ob und welche Ladesäulenmodelle betroffen sind. Ergänzend gilt: Update-Fähigkeit über den Unterstützungszeitraum (in der Regel mindestens fünf Jahre, kürzer nur bei kürzerer voraussichtlicher Nutzungsdauer, Art. 13 Abs. 8) muss technisch nachweisbar sein, inklusive Secure OTA.

Meldefähigkeit und PSIRT für Ladeinfrastruktur

Wird eine aktiv ausgenutzte Schwachstelle oder ein schwerwiegender Sicherheitsvorfall bekannt, läuft ab Kenntnisnahme die Art.-14-Kaskade. Sie wird leicht verkürzt falsch dargestellt - die korrekten Fristen sind:

• 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.
• 14 Tage: Abschlussbericht bei einer aktiv ausgenutzten Schwachstelle - gerechnet ab Verfügbarkeit einer Korrektur- oder Risikominderungsmaßnahme.
• 1 Monat: Abschlussbericht bei einem schwerwiegenden Sicherheitsvorfall - nach der 72-Stunden-Meldung.

Gemeldet wird über die einheitliche Meldeplattform (Art. 16), über den Endpunkt des als Koordinator benannten CSIRT im Mitgliedstaat Ihrer Hauptniederlassung, gleichzeitig für ENISA zugänglich - eine Einmalmeldung. Für einen Ladeinfrastruktur-Hersteller heißt „Meldefähigkeit" konkret: ein benanntes PSIRT/Kontaktteam, eine veröffentlichte Coordinated-Vulnerability-Disclosure-Policy (CVD) über den Unterstützungszeitraum, ein eingeübter Ablauf, der die Fristen einhält, und die Fähigkeit, per SBOM in Minuten zu bestimmen, welche Firmware-Stände betroffen sind.

Welche Frist zuerst zählt

Für Hersteller in dieser Branche gibt es eine klare Reihenfolge. Zuerst kam der 11.09.2026: Seit diesem Datum greifen die Melde- und Berichtspflichten (Art. 14). Wer eine ausnutzbare Schwachstelle im OCPP-/TLS-Stack oder im Plug&Charge-PKI-Handling entdeckt, muss fristgerecht melden können, unabhängig davon, ob die Produktanforderungen schon voll gelten. Der zweite Meilenstein ist der 11.12.2027: dann müssen Ladepunkte die vollständigen Produktanforderungen erfüllen (Security-by-Design/Default, dokumentierte Risikobewertung, SBOM, EU-Konformitätserklärung, CE). Praktisch bedeutet das: PSIRT/Meldeprozess mit Priorität aufsetzen, parallel das Produkt-Engineering und die technische Doku auf 2027 ausrichten.

Ein durchgespieltes Beispiel

Ein mittelständischer Hersteller bietet AC-Wallboxen und einen DC-Schnelllader an, dazu einen Ladepunkt-Controller mit OCPP-2.0.1-Client und ISO-15118-Plug&Charge. Schematisch fallen die Geräte in die Standardkategorie, sodass die Selbstbewertung (Modul A) der plausible Pfad ist; die technische Dokumentation muss trotzdem vollständig sein. Das EMS-Gateway prüft er gesondert: Ist Routing seine Kernfunktion, fällt es in Klasse I, ist es die Firewall, in Klasse II.

Sein Fahrplan: Er erstellt CycloneDX-1.6-SBOMs für jede Firmware-Linie und erkennt dabei eine bald abgekündigte TLS-Bibliothek, die er ersetzt. Er richtet ein Secure-OTA-Verfahren ein, das Sicherheitsfixes über den gesamten Unterstützungszeitraum auch an Säulen mit schwacher Konnektivität ausrollt. Er härtet das ISO-15118-Zertifikats-/PKI-Handling. Er benennt ein PSIRT und veröffentlicht eine CVD-Policy, sodass er die seit dem 11.09.2026 geltende Kaskade bedienen kann (Frühwarnung unverzüglich, spätestens nach 24 Stunden, Meldung spätestens nach 72 Stunden, Abschlussbericht). Und er verknüpft seine SBOM mit einem Schwachstellen-Monitoring, damit bei der nächsten CVE sofort klar ist, welche Modelle betroffen sind.

Was Blackfort Technology für Sie tut

Blackfort Technology begleitet Hersteller und Importeure von Ladeinfrastruktur pragmatisch und branchenspezifisch:

• Betroffenheits- und Scope-Analyse: technische Einschätzung der PDE-Einordnung Ihres Portfolios, der plausiblen Anhang-III-Kategorie je Komponente und des Konformitätspfads (Modul A vs. notifizierte Stelle) - schematisch, keine Rechtsberatung.
• SBOM-Setup: maschinenlesbare Stücklisten, etwa in CycloneDX oder SPDX, EOL-/OSS-Risiken im Ladefirmware-Stack sichtbar gemacht, in die technische Doku integriert.
• PSIRT/CVD: Aufbau eines meldefähigen Prozesses entlang der Art.-14-Kaskade, inklusive Anbindung an die einheitliche Meldeplattform und Coordinated Vulnerability Disclosure.
• Risikobewertung & Threat-Modeling: für OCPP-Backend-Kopplung, ISO-15118-PKI und OTA-Update-Wege - dokumentiert nach Art. 13/Anhang I.
• Technische Dokumentation: Aufbau der Unterlagen nach Anhang VII bis zur EU-Konformitätserklärung, aufbewahrt mindestens zehn Jahre oder für den längeren Unterstützungszeitraum (Art. 13 Abs. 13).

Starten Sie mit dem Betroffenheits-Check, werfen Sie einen Blick auf unseren CRA-Überblick und den KMU-Leitfaden - oder sprechen Sie uns direkt an: Kontakt aufnehmen.