EV-Ladesäulen-Cybersicherheit: ISO 15118, Plug & Charge, OCPP und Backend absichern

Eine EV-Ladesitzung sieht für den Fahrer einfach aus: Kabel einstecken, authentifizieren, laden und bezahlen. Hinter diesem Erlebnis steht ein verteiltes System, das Fahrzeug, Ladesäule, Charging-Management-Backend, Roaming-Plattformen, Bezahldienste, Zertifikats-Infrastruktur, Mobile-Apps, Cloud-Provider und manchmal Versorger- oder Gebäudemanagement-Netze umfasst.

Eine Schwachstelle in einer dieser Domänen kann die anderen beeinflussen. Eine kompromittierte Ladesäule kann Kundendaten offenlegen oder zum Fuß in das Betreibernetz werden. Ein gestohlenes Backend-Credential kann Tausende Ladesäulen steuern. Ein gebrochener Plug & Charge Zertifikatsprozess kann die Authentifizierung im großen Stil stören. Eine unsichere Smart-Charging-Schnittstelle kann eine Flotte von Ladesäulen in ein koordiniertes Lastmanipulations-Werkzeug verwandeln.

Das NIST-Profil EV Extreme Fast Charging behandelt das Ökosystem als vier vernetzte Domänen: das EV, EVSE oder Ladesäule, Cloud- und Drittanbieter-Betrieb sowie Versorger- oder Gebäudenetze. Das ist der richtige Ausgangspunkt. EV-Ladesicherheit lässt sich nicht durch alleiniges Härten der Ladesäule lösen.

Dieser Leitfaden liefert ein praktisches Sicherheitsmodell für Automotive- und Lade-Stakeholder. Er konzentriert sich auf ladespezifische Architektur, Protokolle, Vertrauen, Betrieb und Beweismittel, statt allgemeine Penetrationstest-Hinweise für vernetzte Fahrzeuge zu wiederholen.

Die Vertrauenskette der Ladung abbilden

Beginnen Sie mit der Ende-zu-Ende-Transaktion, nicht mit einer Liste von Geräten.

Ein typischer öffentlicher Plug & Charge Flow kann umfassen:

1. Das Fahrzeug baut über ISO 15118 Kommunikation mit der EVSE auf.
2. EV und EVSE handeln Ladeparameter aus und authentifizieren sich über Zertifikate.
3. Die Ladesäule kommuniziert mit einem Charging Station Management System über OCPP.
4. Das CSMS tauscht Informationen mit einem Charge-Point-Operator, einem E-Mobility-Service-Provider, einer Roaming-Plattform, einem Zahlungsanbieter oder Zertifikatsdienst aus.
5. Smart-Charging-Logik kann mit einem Versorger, einem Site-Controller, einem Energiemanagementsystem oder einer DER-Plattform interagieren.
6. Firmware, Diagnose, Security-Logs und Betriebsbefehle laufen über separate Management-Kanäle.

Jeder Pfeil trägt Annahmen zu Identität, Autorisierung, Integrität, Verfügbarkeit, Datenschutz und Lebenszyklus. Die Sicherheitsarchitektur sollte dokumentieren:

• Welche Organisation jedes System betreibt.
• Welches Protokoll und welche Version verwendet wird.
• Wie sich Endpunkte authentifizieren.
• Wo Schlüssel und Zertifikate gespeichert sind.
• Welche Befehle zulässig sind.
• Welche Daten erhoben und aufbewahrt werden.
• Wie Software aktualisiert wird.
• Was passiert, wenn Konnektivität oder Vertrauen ausfällt.

Ein Diagramm ohne Eigentums- und Vertrauensinformationen reicht nicht. Viele Lade-Vorfälle beginnen in der Lücke zwischen Anbietern, nicht innerhalb eines Produkts.

Die vier Sicherheits-Domänen

1. Elektrofahrzeug

Das Fahrzeug enthält den Electric Vehicle Communication Controller, die Lade-Steuerlogik, Batteriemanagement-Schnittstellen, Vertragszertifikate, Provisioning-Credentials und Verbindungen zu Nutzerkonten. Sicherheitsbedenken umfassen Zertifikatsdiebstahl, unsichere Schlüssel-Speicherung, Protokoll-Parser-Schwachstellen, böswillige Ladenachrichten, unsichere Leistungsaushandlung und laterale Bewegung vom Infotainment oder der Telematik zu Lade-Systemen.

Das Fahrzeug sollte die Ladesäule als externes und potenziell feindliches System behandeln. Eingabevalidierung, Durchsetzung von Protokollzuständen, Timeouts, sicheres Fallback, Netzwerkisolation und kontrolliertes Zertifikatsmanagement sind essenziell.

2. Ladesäule oder EVSE

Die Säule kombiniert Leistungselektronik, eingebettete Software, Netzwerkanbindung, lokale Benutzeroberflächen, Zahlungsterminals, Wartungsports und physische Zugänge. Sie kann an einem unkontrollierten öffentlichen Ort über viele Jahre installiert sein.

Risiken umfassen offene Dienste, Default-Credentials, Missbrauch wechselbarer Speicher, Debug-Zugriff, Firmware-Manipulation, OCPP-Credential-Diebstahl, Log-Lecks, Denial of Service, Manipulation von Zählerdaten und physische Angriffe auf Kommunikations- oder Steuerhardware.

3. Cloud- und Drittanbieter-Betrieb

Das CSMS kann große Ladesäulenpopulationen verwalten, Firmware ausrollen, Konfigurationen ändern, Transaktionen autorisieren, Logs abrufen und Remote-Befehle senden. Seine Kompromittierung kann flottenweite Konsequenzen haben.

Die Cloud-Domäne umfasst auch Roaming, Identity, Bezahlung, Analytics, Kunden-Apps, Support-Werkzeuge und Anbieterportale. Gebrochene Objekt-Autorisierung, schwache Service-Credentials, unsichere API-Nutzung und exzessive administrative Privilegien sind große Sorgen.

4. Versorger- und Gebäudenetze

Smart Charging und Vehicle-Grid-Integration verbinden Ladung mit Standort-Energiemanagement und Netzbetrieb. Falsche oder böswillige Befehle können lokale Überlast, Versorgungsstörungen, finanzielle Verluste oder Instabilität verursachen, wenn sie über viele Assets koordiniert werden.

Sicherheit muss sowohl Energieziele als auch Ladeverfügbarkeit wahren. Das System braucht sicheres lokales Verhalten, wenn Cloud- oder Versorgeranweisungen nicht verfügbar oder nicht vertrauenswürdig sind.

ISO 15118 und Plug & Charge Sicherheit

ISO 15118 definiert die Kommunikation zwischen Fahrzeug und Ladegerät und ermöglicht Funktionen einschließlich Plug & Charge. Plug & Charge nutzt eine Public-Key-Infrastruktur, sodass das Fahrzeug sich authentifizieren und eine Ladefreigabe erhalten kann, ohne dass der Fahrer eine RFID-Karte zückt oder eine App öffnet.

Der Sicherheitswert ist erheblich, aber auch die operative Komplexität. Das Trust-Ökosystem kann umfassen:

• Provisioning-Zertifikate des Fahrzeug-OEM.
• Vertragszertifikate, die an einen E-Mobility-Service-Vertrag gebunden sind.
• EVSE-Zertifikate.
• Wurzel- und untergeordnete Zertifizierungsstellen.
• Zertifikats-Provisioning-Dienste.
• Online-Status- oder Sperrlistendienste.
• Charge-Point- und Mobility-Service-Operatoren.

Eine sichere Implementierung braucht mehr als TLS-Unterstützung. Teams sollten Folgendes regeln:

• Schlüsselerzeugung und -speicherung in Fahrzeug- und EVSE-Hardware.
• Zertifikatsausgabe und Identitätsprüfung.
• Installation und Erneuerung von Vertragszertifikaten.
• Trust-Store-Verteilung und Root-Wechsel.
• Sperrung und Statusprüfung.
• Verhalten bei Ablauf und Karenzfristen.
• Uhrgenauigkeit.
• Mehrverträge- und Fahrzeugübertragungs-Szenarien.
• Fehlgeschlagenes Provisioning und Recovery.
• Logging ohne Offenlegung privater Schlüssel oder unnötiger personenbezogener Daten.

Testen Sie die Negativfälle. Was passiert, wenn ein Zertifikat abgelaufen, gesperrt, aus einer unbekannten Kette ist, die falsche Policy hat oder für den falschen Vertrag präsentiert wird? Fällt das Fahrzeug oder die Ladesäule sicher zurück, oder umgeht es die Authentifizierung still?

OCPP-Sicherheit von Ladesäule bis Backend

OCPP ist das wichtigste Betriebsprotokoll zwischen Ladesäulen und Managementsystemen. OCPP 2.0.1 führte definierte Security Profiles, Client-Certificate-Key-Management, signierte Firmware-Unterstützung und Security-Event-Logging ein. Die aktuelle operative Leitlinie der Open Charge Alliance betont sicheres Credential-Management und sichere Hilfs-Dateitransferkanäle.

Schlüsselkontrollen umfassen:

Gegenseitiges Vertrauen

Nutzen Sie ein Security Profile, das zu Netzwerk und Bedrohungsmodell passt. Vermeiden Sie unauthentifizierten oder schwach geschützten Betrieb in nicht vertrauenswürdigen Netzen. Die Ladesäulen-Identität sollte an verwaltete Credentials gebunden sein, nicht nur an eine in einer Nachricht gesendete Seriennummer.

Zertifikats- und Credential-Lebenszyklus

Statten Sie jede Ladesäule mit eindeutigen Credentials aus. Rotieren Sie sie nach einem definierten Zeitplan und nach Kompromittierung. Verhindern Sie, dass das Credential einer Ladesäule ein anderes Gerät authentifiziert. Schützen Sie private Schlüssel über hardwaregestützte Speicherung, wenn gerechtfertigt.

Befehlsautorisierung

Das Backend sollte durchsetzen, welche Operatoren, Dienste und automatisierten Workflows Remote-Start-, Stop-, Unlock-, Konfigurations-, Reset-, Firmware- und Diagnosebefehle senden dürfen. Menschliche Administratoren sollten starke Authentifizierung und Least Privilege nutzen.

Sichere Firmware

Verifizieren Sie signierte Firmware vor der Installation, schützen Sie die Rollback-Policy, validieren Sie Kompatibilität und behalten Sie Beweise darüber, was auf jeder Ladesäule installiert wurde. Auch der Download-Kanal muss gesichert sein; ein signiertes Image schützt nicht Verfügbarkeit oder Vertraulichkeit eines unsicheren Übertragungspfads.

Security-Event-Logging

Normalisieren Sie Ladesäulen-Security-Events, bewahren Sie Zeit und Geräteidentität und routen Sie hochwertige Ereignisse ins Monitoring. Vermeiden Sie das Sammeln von Logs, die ohne Notwendigkeit Geheimnisse oder Kundendaten offenlegen.

Inventar und Versionskontrolle

Wissen Sie, welche Ladesäulen, Anbieter, Firmware-Versionen, Protokollprofile, Zertifikate und Konfigurationen ausgerollt sind. Ein Vulnerability-Advisory ist nur dann handhabbar, wenn der Betreiber betroffene Stationen schnell identifizieren kann.

Hilfskanäle nicht ignorieren

Der Haupt-OCPP-WebSocket kann geschützt sein, während andere Pfade exponiert bleiben. Ladesäulen nutzen oft separate Mechanismen für:

• Firmware-Download.
• Diagnose-Log-Upload.
• Remote Shell oder Hersteller-Support.
• Verwaltung des Zahlungsterminals.
• Verwaltung des Mobilfunkmodems.
• Lokale Web-Schnittstellen.
• Site-Controller-Integration.
• Zeitsynchronisation.
• Zertifikats-Enrollment.

Inventarisieren Sie jeden Kanal und wenden Sie dieselbe Identität, Verschlüsselung, Autorisierung, Logging- und Lebenszyklus-Disziplin an. Die Open Charge Alliance warnt ausdrücklich vor unsicheren Dateitransfermethoden für Firmware und Logs.

Hersteller-Support-Pfade verdienen besondere Aufmerksamkeit. Ein geteiltes Remote-Zugriffskonto oder ein nicht verwalteter Support-Tunnel kann die stärkeren Kontrollen umgehen, die in OCPP eingebaut sind.

Hochpriorisierte Angriffsszenarien

Übernahme einer Ladesäulenflotte

Ein Angreifer kompromittiert einen CSMS-Administrator, einen API-Client oder eine Software-Lieferkette und erteilt vielen Ladesäulen Befehle. Konsequenzen können großflächige Ausfälle, Konfigurations-Manipulation, Credential-Ersetzung oder bösartiges Firmware-Deployment sein.

Missbrauch von Plug & Charge Credentials

Ein Vertragszertifikat, ein Provisioning-Schlüssel oder ein Backend-Konto wird gestohlen und für betrügerische Ladung oder Identitätstäuschung genutzt. Schwacher Widerruf oder verzögerte Verbreitung erweitert das Angriffsfenster.

Manipulation von Zähler und Transaktion

Lade-Sitzungsdaten werden verändert, um Betrug zu begehen, Abrechnung zu bestreiten, Energie falsch zu melden oder unautorisierte Nutzung zu verbergen. Integrität muss die gesamte Kette von Messung bis Abrechnung abdecken.

Bösartige Eingabe von Ladesäule zu Fahrzeug

Eine kompromittierte EVSE sendet fehlerhafte oder unsichere Protokollnachrichten, um den Communication Controller des Fahrzeugs oder die Lade-Logik auszunutzen. Die Fahrzeug-Verteidigungen müssen davon ausgehen, dass öffentliche Ladesäulen nicht vertrauenswürdig sind.

Lastmanipulation

Ein Angreifer ändert Ladepläne über einen Standort oder eine Flotte und verursacht Lastspitzen, Betriebsunterbrechungen oder Störungen von Netzdienstleistungen. Starke Autorisierung und lokale Safety-Grenzen sind erforderlich.

Datenschutz-Exposition

Ladeaufzeichnungen verraten Standort, Bewegungsmuster, Fahrzeugidentität, Kontoinformationen und Zahlungsverhalten. Übermäßiges Logging oder schwache Empfänger-Autorisierung kann Betriebsdaten in Überwachungsdaten verwandeln.

Physische Kompromittierung

Ein Angreifer öffnet ein Gehäuse, greift auf Debug-Ports zu, ersetzt Speicher, hängt ein Schurken-Gerät an oder zapft Kommunikation an. Tamper-Evidenz, Secure Boot, Port-Kontrolle und Feldinspektion helfen, Persistenz zu begrenzen.

Architekturprinzipien für sicheres Laden

Leistungssteuerung von Geschäftsdiensten isolieren

Bezahlung, Werbung, lokale UI und Kunden-WLAN sollten keinen uneingeschränkten Zugang zur safety-relevanten Lade-Steuerung haben. Nutzen Sie Hardware- und Netzwerktrennung mit eng definierten Schnittstellen.

Lokales Verhalten sicher und resilient gestalten

Die Ladesäule sollte sichere elektrische Grenzen einhalten, wenn die Cloud-Steuerung verloren geht. Sie sollte vorhersagbar versagen, wenn Identität, Zeit, Zertifikatsstatus oder Smart-Charging-Anweisungen nicht verifiziert werden können.

Permanente Privilegien minimieren

Backend-Dienste und Operatoren sollten nur die Befehle und Stationsgruppen erhalten, die sie benötigen. Trennen Sie Firmware-Administration, Kundensupport, Bezahlbetrieb und Security-Monitoring.

Zero-Trust-Service-Identität nutzen

Authentifizieren Sie Service-zu-Service-Aufrufe in der Cloud, nicht nur User-Logins. Schützen Sie Geheimnisse, rotieren Sie sie und nutzen Sie wo möglich Workload-Identität.

Mandanten- und Betreiberdaten trennen

Roaming- und White-Label-Plattformen bedienen viele Organisationen. Setzen Sie Objekt-Level-Autorisierung durch, damit ein Betreiber nicht die Ladesäulen, Sitzungen, Kunden oder Zertifikate eines anderen Betreibers einsehen oder steuern kann.

Für Austausch und Supportende designen

Lade-Hardware kann länger ausgerollt bleiben als der Software-Support des Herstellers. Beschaffung sollte Security-Supportzeitraum, Patch-Lieferung, Credential-Übertragung, Komponenten-Ende-der-Lebensdauer und sicheres Decommissioning adressieren.

Anforderungen an sichere Beschaffung

Eine Ladesäulen-Sicherheits-Spezifikation sollte verifizierbare Fähigkeiten verlangen, nicht breite Aussagen.

Verlangen Sie von Anbietern:

• Unterstützte OCPP-Version, Edition, Security Profile und Zertifizierungsstatus.
• ISO 15118- und Plug & Charge-Fähigkeiten.
• Secure-Boot- und Signed-Firmware-Design.
• Eindeutige Geräteidentität und Schlüsselspeicherungs-Ansatz.
• SBOM und Vulnerability-Handling-Prozess.
• Supportzeitraum und Patch-Zeitpläne.
• Remote-Zugriffsarchitektur.
• Security-Event-Schema und Export-Optionen.
• Lokale Port- und physische Tamper-Kontrollen.
• Kryptografische Agilität und Zertifikats-Erneuerungsprozesse.
• Penetrationstest- und Protokoll-Fuzzing-Beweismittel.
• Verpflichtungen zur Incident-Meldung.
• Sicheren Factory-Reset und Decommissioning-Prozess.
• Datenbesitz-, Lokations-, Aufbewahrungs- und Löschungsbedingungen.

Bauen Sie Akzeptanztests ein. Eine Anforderung wie "unterstützt signierte Firmware" sollte mit ungültiger Signatur, falscher Version, gesperrtem Schlüssel, unterbrochener Installation und versuchtem Rollback getestet werden.

Teststrategie

EV-Ladung erfordert Tests auf Komponenten-, Protokoll-, Integrations- und Ökosystemebene.

Fahrzeug-EVSE-Protokolltests

Testen Sie ISO 15118 Nachrichten-Parsing, Zustandsübergänge, Timeouts, Zertifikatsketten, Renegotiation und fehlerhafte Eingaben. Schließen Sie Interoperabilität über mehrere Anbieter ein.

OCPP-Tests

Verifizieren Sie Authentifizierung, Zertifikats-Enrollment, Befehlsautorisierung, Replay-Resistenz, sichere Firmware, Event-Reporting, Konfigurations-Beschränkungen und Fehlerbehandlung. Testen Sie jede unterstützte Protokollversion und jedes Security Profile.

Backend-API-Tests

Testen Sie Mandantenisolation, Objekt-Autorisierung, Rate-Limiting, administrative Privilegien, Webhook-Validierung, Partner-APIs und Mobile-App-Flows.

Physische und Embedded-Tests

Bewerten Sie Debug-Ports, Boot-Integrität, Speicherschutz, lokale Schnittstellen, Modem-Konfiguration und Gehäusezugang. Bestätigen Sie, dass physische Kompromittierung nicht automatisch Cloud-Credentials oder Signierschlüssel offenlegt.

Resilienz-Tests

Simulieren Sie Cloud-Ausfall, Zertifikatsdienst-Ausfall, Zeitverlust, Mobilfunk-Ausfall, beschädigte Firmware, partielle Flotten-Konnektivität, Stromunterbrechung und bösartige Smart-Charging-Befehle. Validieren Sie sicheren degradierten Betrieb und Recovery.

Lieferketten-Tests

Prüfen Sie SBOMs, Drittkomponenten, Build-Provenienz, Signing-Prozesse und Update-Infrastruktur des Anbieters. Eine sichere Ladesäule darf nicht von einer unsicheren Update-Fabrik abhängen.

Monitoring und Incident Response

Betreiber benötigen Sichtbarkeit über Station, Cloud, Konto und Energieverhalten. Hochwertige Erkennungen umfassen:

• Wiederholte Authentifizierungs- oder Zertifikatsfehler.
• Credential-Nutzung von unerwarteten Stationen oder Regionen.
• Konfigurationsänderungen außerhalb von Wartungsfenstern.
• Bulk-Remote-Befehle.
• Firmware-Downloads oder -Installationen aus ungewöhnlichen Quellen.
• Security-Profile-Downgrade.
• Unerwartete Stations-Resets oder Zeitänderungen.
• Anomalien in Zählerdaten.
• Abnormale Transaktions- oder Autorisierungsmuster.
• Verlust der Protokollierung aus einer Stationsgruppe.
• Smart-Charging-Befehle außerhalb genehmigter Grenzen.

Ein Incident-Datensatz sollte Ladesäule, Standort, Firmware, Zertifikat, Betreiber, Backend-Dienst, betroffene Sitzungen und Behebung verknüpfen. Das ermöglicht Flotten-Scoping und unterstützt regulatorische, vertragliche und Kundenkommunikation.

Üben Sie Szenarien vorab. Eine Ladesäulenflotte kann nicht immer sicher oder kommerziell vom Netz genommen werden. Antwortoptionen können Credential-Widerruf, Befehlseinschränkung, Netzwerkisolation, ausschließlich lokalen Betrieb, gestaffelte Firmware, Vor-Ort-Besuch oder temporäre Servicebegrenzung umfassen.

Beweismittel und Governance

Ein Lade-Sicherheits-Beweismittelpaket sollte umfassen:

• Ende-zu-Ende-Architektur und Vertrauensgrenzen.
• Asset- und Dateninventare.
• Protokollversionen und Security Profiles.
• Zertifikatsrichtlinien und Betriebsdatensätze.
• Firmware-Baseline und Signing-Beweismittel.
• Ladesäulen-Konfigurations- und Credential-Inventar.
• Bedrohungsanalyse und Kontroll-Mapping.
• Testpläne, Ergebnisse und ungelöste Befunde.
• Anbieter- und Sub-Lieferanten-Beweismittel.
• Monitoring-Abdeckung und Incident-Datensätze.
• Change- und Release-Freigaben.
• Support- und Decommissioning-Pläne.

Halten Sie Beweismittel aktuell. Ein Testbericht für Firmware-Version 1.2 beweist nicht, dass Version 1.8 sicher ist. Zertifikats-, Konfigurations- und Backend-Änderungen können das Risiko verändern, ohne die Ladesäulen-Hardware zu verändern.

Eine gestaffelte Verbesserungs-Roadmap

Phase 1: Inventarisieren und eindämmen

Identifizieren Sie jede Ladesäule, Firmware-Version, jedes OCPP-Profil, Backend-Endpunkt, Zertifikat, jeden Remote-Zugriffspfad und Eigentümer. Eliminieren Sie geteilte Default-Credentials und unsichere Hilfsdatenübertragungen.

Phase 2: Vertrauen und Update-Kontrolle etablieren

Implementieren Sie eindeutige Identitäten, stärkere OCPP Security Profiles, Zertifikats-Lebenszyklus-Management, signierte Firmware, kontrollierte Administration und Release-Beweismittel.

Phase 3: Monitoring und Risiko verbinden

Normalisieren Sie Security-Events, verknüpfen Sie Schwachstellen mit ausgerollten Stationen, bauen Sie Flotten-Scoping-Abfragen und üben Sie Incident-Playbooks.

Phase 4: Interoperabilitäts-Assurance skalieren

Führen Sie wiederkehrende anbieterübergreifende ISO 15118- und OCPP-Tests durch, automatisieren Sie Beweismittelerfassung und beziehen Sie Versorger, Roaming-Partner und Zahlungsanbieter in gemeinsame Szenarien ein.

Wie ThreatZ die Ökosystem-Sicht unterstützen kann

Lade-Sicherheits-Beweismittel sind meist fragmentiert über Fahrzeug-TARA-Dateien, Ladesäulenhersteller-Portale, Cloud-Tickets, PKI-Systeme, Firmware-Repositories und Betreiber-Incident-Werkzeuge verteilt. ThreatZ kann eine vernetzte Risiko- und Beweismittel-Schicht bieten, die Fahrzeug, EVSE, Backend, Softwarekomponenten, Lieferanten, Bedrohungen, Kontrollen, Tests, Schwachstellen und Vorfälle verknüpft.

Der erste Pilot sollte eng sein: ein Fahrzeugprogramm, ein Ladesäulenmodell, ein CSMS-Backend und ein Plug & Charge Flow. Das Ergebnis ist eine Ende-zu-Ende-Vertrauens- und Beweismittel-Karte, die Lücken offenlegt, die keine einzelne Partei allein sehen kann.

Häufig gestellte Fragen

Ist OCPP 2.0.1 automatisch sicher?

Nein. Es bietet stärkere Sicherheitsfähigkeiten, aber Deployment-Entscheidungen, Credential-Management, Autorisierung, Firmware-Betrieb, Hilfskanäle und Backend-Sicherheit bestimmen das Ergebnis.

Ist Plug & Charge nur eine Zahlungsfunktion?

Nein. Es ist ein Authentifizierungs- und Autorisierungs-Ökosystem auf Basis von Zertifikaten und mehreren Organisationen. Sein PKI-Lebenszyklus ist ein sicherheitskritischer Betriebsdienst.

Wer verantwortet EV-Lade-Cybersicherheit?

Die Verantwortung wird geteilt zwischen OEMs, EVSE-Herstellern, Charge-Point-Operatoren, E-Mobility-Anbietern, Cloud- und Roaming-Plattformen, Versorgern, Standortbesitzern und Zertifikatsbetreibern. Verträge und Schnittstellenvereinbarungen sollten exakte Pflichten definieren.

Was ist das größte Flotten-Risiko?

Eine Kompromittierung des Charging-Management- oder Update-Planes kann viele Ladesäulen auf einmal betreffen. Starke administrative Sicherheit, Service-Identität, Befehlsautorisierung, Segmentierung und Monitoring sind essenziell.

Wo sollte ein Programm starten?

Beginnen Sie mit Inventar und Trust-Mapping. Viele Organisationen können nicht alle ausgerollten Firmware-Versionen, OCPP Security Profiles, Ladesäulen-Credentials, Remote-Zugriffspfade und Backend-Eigentümer auflisten. Diese Sichtbarkeit ist erforderlich, bevor fortgeschrittene Kontrollen wirksam sein können.

Maßgebliche Referenzen

• NIST IR 8473: Cybersecurity Framework Profile for EV Extreme Fast Charging Infrastructure
• Open Charge Alliance: OCPP
• Open Charge Alliance OCPP Security Operations Guide
• CharIN Plug & Charge
• CharIN Plug & Charge PKI
• U.S. Department of Energy: Securing EV Charging Infrastructure

Weiterführende Beiträge auf VxLabs

• ThreatZ-Integrationen
• X.509-Zertifikate
• Zertifikatsmanagement