CRA in Ladeinfrastruktur & E-Mobility

Ein Ladepunkt ist heute kein Stück Leistungselektronik mehr, sondern ein vernetzter Kleincomputer mit Zahlungs-, Abrechnungs-, Lastmanagement- und Fernwartungsfunktionen — ständig online, oft feldverteilt zu Tausenden, 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-Landschaft für Hersteller doppelt unübersichtlich macht.

Hinzu kommt Zeitdruck. Die erste harte Herstellerpflicht — die Melde- und Berichtspflicht nach Art. 14 — greift bereits ab 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 zuerst stehen, das Produkt-Engineering hat etwas mehr Vorlauf.

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

Der weit überwiegende Teil der Ladehardware dürfte schematisch in die Standardkategorie fallen — mit Selbstbewertung nach Modul A. Anders sieht es bei Komponenten aus, deren Kernfunktion Sicherheit oder Netzwerksteuerung ist: Ein zentrales Steuer-/Energiemanagement-Gateway, das Zugriffe verwaltet oder als Router/Firewall zwischen Segmenten wirkt, kann in Anhang III (Klasse I) rutschen. Die maßgebliche technische Abgrenzung der wichtigen und kritischen Kategorien liefert die Durchführungsverordnung (EU) 2025/2392.

Faustregel: Für die meisten Hersteller ist der Konformitätspfad die Selbstbewertung — vorausgesetzt, die technische Dokumentation, die Risikobewertung und die harmonisierten Normen sind sauber angewandt. Eine notifizierte Stelle wird erst dann zwingend, wenn eine Komponente in Klasse I fällt und keine harmonisierten Normen voll angewandt werden — oder in Klasse II, wo die notifizierte Stelle immer erforderlich ist.

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 erfahrungsgemäß der anspruchsvollste Teil — und ein Feld, in dem Blackfort Technology zu Hause ist.

Wichtig ist die saubere Abgrenzung zu benachbarten Regimen: Der CRA adressiert die Produkt-Cybersicherheit beim Hersteller. NIS2 hingegen verpflichtet Betreiber wesentlicher und wichtiger Einrichtungen (im Energiesektor durchaus einschlägig für den CPO/Betreiber) — das ist ein getrennter Rechtsakt und darf nicht mit dem CRA gleichgesetzt werden. Enthält ein Ladepunkt Funkmodule (z. B. für Fernwartung), kann zusätzlich die RED-Delegierte-Verordnung 2022/30 greifen; hier ist die Überschneidung zum CRA im Blick zu behalten. Klar getrennt bleiben Themen der Kfz-Typgenehmigung (die das Fahrzeug betrifft, nicht die Ladehardware) und der AI Act, sofern KI-Funktionen (z. B. Lastprognose) ins Spiel kommen.

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.

Eine maschinenlesbare SBOM ist deshalb kein Formular, sondern das Frühwarnsystem. Nach BSI TR-03183-2 (v2.1.0) muss sie in CycloneDX ≥ 1.6 oder SPDX ≥ 3.0.1 vorliegen, mindestens die Top-Level-Abhängigkeiten abbilden und Teil der technischen Dokumentation sein (eine allgemeine Veröffentlichungspflicht besteht nicht). Konkret leistet sie: 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 Support-Zeitraum (Leitlinie mindestens 5 Jahre) muss technisch nachweisbar sein, inklusive Secure OTA.

Meldefähigkeit und PSIRT für Ladeinfrastruktur

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

• 24 Stunden: Frühwarnung (early warning) an das zuständige CSIRT und ENISA.
• 72 Stunden: vollständige Meldung inklusive erster Korrektur-/Minderungsmaßnahmen.
• 14 Tage: Abschlussbericht bei einer aktiv ausgenutzten Schwachstelle — gerechnet ab Verfügbarkeit einer Korrekturmaßnahme.
• 1 Monat: Abschlussbericht bei einem schweren Sicherheitsvorfall — nach der 72-Stunden-Meldung.

Gemeldet wird über die ENISA Single Reporting Platform (SRP) als Einmalmeldung an das CSIRT der Hauptniederlassung und ENISA. Für einen Ladeinfrastruktur-Hersteller heißt „Meldefähigkeit" konkret: ein benanntes PSIRT/Kontaktteam, eine veröffentlichte Coordinated-Vulnerability-Disclosure-Policy (CVD) über den Support-Zeitraum, 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 kommt der 11.09.2026: ab 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 dann 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 — sofern die harmonisierten Normen und die technische Dokumentation sauber angewandt werden. Das EMS-Gateway mit Firewall-Charakter prüft er gesondert auf eine mögliche Klasse-I-Einordnung.

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 ≥ 5 Jahre 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 ab dem 11.09.2026 die 24-h-/72-h-/14-Tage-Kaskade bedienen kann. 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 UG (haftungsbeschränkt) begleitet Hersteller und Importeure von Ladeinfrastruktur pragmatisch und branchenspezifisch:

• Betroffenheits- und Scope-Analyse: PDE-Einordnung Ihres Portfolios, plausible Anhang-III-Kategorie je Komponente, Konformitätspfad (Modul A vs. notifizierte Stelle) — schematisch, keine Rechtsberatung.
• SBOM-Setup: maschinenlesbare Stücklisten in CycloneDX ≥ 1.6 / SPDX ≥ 3.0.1, 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 SRP-Anbindungslogik 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: strukturiert, prüffest, 10 Jahre aufbewahrbar, inklusive Konformitätserklärung und CE-Grundlage.

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.