ISO 15118 Zertifikatslebenszyklusmanagement im Jahr 2026: Von der TLS-Dringlichkeit zur CRA-Konformität

TL;DR (Zusammenfassung der Exekutivmaßnahmen)

• Die Umstellung auf TLS ist eine strikte Grenze (keine Empfehlung): Aus 24. Februar 2026DigiCert wird Akzeptieren Sie nicht mehr öffentliche TLS-Zertifikatsanfragen mit Gültigkeit mehr als 199 Tageund ab diesem Datum ausgestellte Zertifikate haben eine Maximale Gültigkeitsdauer: 199 TageDies ist für viele Betreiber der praktische Übergang – die Erneuerungsgeschwindigkeit erhöht sich sofort.
• Der Fahrplan von 200→100→47 Tagen ist bereits festgelegt: Die CA/Browser Forum Baseline Requirements sehen eine schrittweise Reduzierung vor: 200 Tage ab dem 15. März 2026, 100 Tage ab dem 15. März 2027, Und 47 Tage ab dem 15. März 2029.
• Die CRA führt eine Frist für die Einhaltung der Vorschriften ein: Die CRA-Meldevorschriften erfordern Frühwarnung innerhalb von 24 Stunden, vollständige Benachrichtigung innerhalb von 72 Stundenund legte endgültige Meldefristen für aktiv ausgenutzte Sicherheitslücken und schwerwiegende Vorfälle fest.
• Das größte versteckte Risiko ist nicht das Ablaufdatum: Der systemische Ausfallmodus ist Vertrauen Sie auf den Anker, der treibt—Roots-/Intermediate-/Cross-Signing-Änderungen sind zwischen EVSE, lokalen Controllern und Backend-Validierungspfaden nicht synchron.
• Erste Investition zum Schutz der Betriebszeit: Systemgesteuerte Automatisierung (ACME + Bestandsaufnahme + stufenweise Einführung) plus Kantenkontinuität (lokale Validierung/Zwischenspeicherung, Nachweisprotokolle und Zeitsynchronisierungssteuerung).

Einleitung: 2026 wird Plug & Charge zu einem betriebsbereiten System

Im Jahr 2026 hört Plug & Charge (P&C) auf, eine „einstellen und vergessen“-Funktion zu sein, und wird zu einer kontinuierliches Betriebssystem.
Die ISO 15118-Vertrauensebene (PKI + TLS + Widerruf + Aktualisierungen) wird nun durch Zeitvorgaben geregelt, die manuelle Arbeitsabläufe nicht zulassen.

Um die Systemgrenzen zu verstehen – wofür ISO 15118 zuständig ist und wofür OCPP – beginnen Sie mit unserem Begleitartikel:
ISO 15118 vs. OCPP: Realität der Umsetzung im Jahr 2026.

Der unmittelbare Druck ist TLS-LebenszykluskomprimierungOperativ gesehen kann man nicht „bis März warten“.
DigiCert wird Akzeptieren Sie nicht mehr öffentliche TLS-Anfragen überschreiten 199 Tage beginnend 24. Februar 2026,
und ab diesem Tag ausgestellte Zertifikate werden eine Maximale Gültigkeitsdauer: 199 Tage.
DigiCert hebt außerdem ein wichtiges operatives Detail hervor: Die maximal zulässige Gültigkeitsdauer wird durch die Ausstellungsdatumnicht zum Zeitpunkt der Bestellung.

Gleichzeitig führt der EU-Cyberresilienz-Aktionsakt (CRA) eine zweite Frist ein: Meldepflichten erfordern
24-Stunden-Frühwarnung Und 72-Stunden-Benachrichtigung für aktiv ausgenutzte Sicherheitslücken und schwerwiegende Vorfälle, die Produkte mit digitalen Elementen beeinträchtigen.

Dieser Leitfaden konzentriert sich auf die Architektur und die Risikokontrollen für den Betrieb von ISO 15118-Zertifikaten unter diesen Einschränkungen.

Meilensteine und erforderliche Maßnahmen 2024–2026 (Text-Gantt-Diagramm)

Betriebshinweis: Der 24. Februar 2026 ist oft der eigentliche Wendepunkt, da sich dann das Emissionsverhalten der großen Zertifizierungsstellen ändert.

Grundsatzhinweis: Die schrittweise Reduzierung der Lebensdauer ist in den Basisanforderungen (200/100/47 Tage) definiert.

Die Landschaft des Lebenszyklus: Bereitstellung → Betrieb → Verlängerung → Widerruf

Lebenszyklusdiagramm (was Sie bedienen können müssen)

1. OEM-Bereitstellung: Schlüssel generiert/eingeschleust; Vertrauensanker hergestellt (HSM/sicheres Element).
2. Vertragsanmeldung: An Benutzerverträge gebundene Vertragszertifikate (ökosystemabhängig).
3. Inbetriebnahme der Ladestation: Trust-Store-Baselines, Richtlinien und Zeitsynchronisierungs-Baselines wurden festgelegt.
4. Operative Validierung: TLS-Handshakes, Kettenaufbau, Widerrufsprüfung, Richtliniendurchsetzung.
5. Verlängerung / Neuausstellung: Automatisierung + stufenweise Einführung + Rücknahme.
6. Widerruf / Reaktion auf Vorfälle: Kompromittierung/Fehlausstellung/Ausnutzung → widerrufen/rotieren/wiederherstellen.
7. Wiederherstellung und Versöhnung: Wiederherstellung des Betriebs unter Wahrung der Prüfbarkeit und der Integrität der Abrechnung.

Der unterschätzte Schwachpunkt: Vertrauensanker-Drift

Die meisten „mysteriösen Ausfälle von Schutz- und Klimatechnik“ in Umgebungen mit mehreren Originalherstellern sind nicht auf ein einzelnes abgelaufenes Zertifikat zurückzuführen – sie sind
Pfadvalidierungsfehler verursacht durch eine Verschiebung des Vertrauensankers:

• Es entstehen neue Wurzeln/Zwischenformen (Realität mit mehreren Wurzeln).
• Gegenseitige Unterzeichnung Veränderungen verändern mögliche Kettenreaktionen.
• Backend-Truststores werden schneller aktualisiert als EVSE/lokale Controller.
• Widerrufsartefakte veralten am Rand.

Behandeln Sie Aktualisierungen von Vertrauensankern als sicherheitskritischen Änderungsprozess:

• Versionierte Vertrauensspeicher
• Canary-Rollouts
• Rücknahmepläne
• Telemetriedaten zu Validierungsfehlern nach Aussteller/Seriennummer/Pfad
• Ein expliziter Verantwortlicher für „wer aktualisiert was wann“

Fehlende gegenseitige Beschilderung und Wegebau (Realität 2026): In Multi-Root-ISO-15118-Ökosystemen,
Plug & Charge schlägt oft nicht fehl, weil ein Zertifikat ungültig ist, sondern weil die Ladestation kein gültiges Zertifikat erstellen kann.
Zertifikatspfad nach Änderungen der Kreuzsignatur (neue Zwischenzertifikate, Brücken-CAs, neu ausgestellte Ketten).
Mit dem Beitritt weiterer OEMs und PKI-Domänen steigt die Pfadkomplexität. Wenn Edge-Truststores (EVSE/lokale Controller)
Da die Backend-Aktualisierungen hinterherhinken, können TLS-Handshakes selbst dann fehlschlagen, wenn Backend-Zertifikate isoliert betrachtet „gültig“ erscheinen.

Abbildung 1 (Empfohlene Darstellung): Pfadvalidierung in Multi-Root ISO 15118

(V2G Root / OEM Root / Contract Root, Zwischenknoten und Cross-Sign-Bridges anzeigen.)
Markieren Sie die Stelle, an der ein neu signiertes Zwischenprodukt den Pfadaufbau auf EVSE unterbricht, wenn die Vertrauensspeicher nicht synchron aktualisiert werden.

Kernaussage: Die meisten Strom- und Kommunikationsausfälle, die auf „PKI“ zurückgeführt werden, sind tatsächlich Pfadvalidierungsfehler bedingt durch Cross-Signing-Drift und nicht synchronisierte Trust Stores.

ACME & Automatisierung: Menschgesteuert vs. Systemgesteuert bei einer Lebensdauer von 199/200 Tagen

Warum die manuelle Erneuerung zu einem deterministischen Ausfallgenerator wird

Kurze Laufzeiten erfordern kontinuierliche Verlängerungen. DigiCerts Umstellung auf 199 Tage ab dem 24. Februar 2026
Dies ermöglicht es vielen Flotten, dies sofort umzusetzen. Und der branchenweite Zeitplan ist bereits festgelegt:
200 Tage (ab dem 15. März 2026), dann 100 Tage, Dann 47 Tage.

Für jede Flotte skalieren Erneuerungsereignisse wie folgt:

Erneuerungsereignisse pro Jahr ≈ N × (365 / L)

Wo N ist die Anzahl der TLS-Endpunkte und L ist die Gültigkeitsdauer des Zertifikats (in Tagen).
Als L Mit sinkenden Verfügbarkeitszielen wird die vom Menschen gesteuerte Erneuerung mathematisch unvereinbar.

Szenario (Dimensionierung auf Vorstandsebene)

Für einen CPO-Betrieb 5.000 EndpunkteEine Lebensdauer von 199 Tagen bedeutet:

Erneuerungsereignisse/Jahr ≈ 5000 × (365 / 199) ≈ 9.171

In diesem Maßstab, selbst ein 1% menschliche Fehlerrate entspricht ungefähr
92 durch Zertifikate verursachte Ausfälle pro Jahr—vor Berücksichtigung der Auswirkungen während der Spitzenzeiten,
SLA-Strafen oder kaskadierende Ausfälle in einem Hub.

ACME in Ladenetzen: Was sollte automatisiert werden?

ACME (Automated Certificate Management Environment) wandelt Erneuerungen in richtliniengesteuerte Vorgänge um für:

• EVSE ↔ Backend-TLS
• Lokaler Controller / Edge-Proxy TLS
• Standort-Gateways und Hub-Controller

Systemgesteuerter Workflow (Architekturmuster)

1. Inventar jeder Endpunkt (Aussteller, Seriennummer, Kette, Ablaufdatum, letzte Rotation).
2. Erneuerungsrichtlinie (Erneuerung bei einem festgelegten Schwellenwert, nicht „nahe am Ablauf“).
3. Hardwaregestützte Tasten Wo immer möglich, sollte der Export privater Schlüssel vermieden werden.
4. Stufenweise Einführung mit Gesundheitsprüfungen (Handshake + Autorisierung + Sitzungsstart).
5. Automatische Rücksetzung aufgrund erhöhter Ausfallraten.
6. Beweisprotokolle für jede Ausgabe/jeden Einsatz (Rückverfolgbarkeit gemäß Compliance-Standard).

Menschgeführt vs. Systemgeführt

• Von Menschen gesteuert: Tickets, Tabellenkalkulationen, verspätete Verlängerungen, unklare Eigentumsverhältnisse, riskante Notfalländerungen.
• Systemgesteuert: Deterministische Richtlinien, automatisierte Ausgabe, kontrollierter Rollout, kontinuierliche Telemetrie, überprüfbare Nachweise.

Widerrufsprüfungen: der „P&C-Killer“ (CRL vs. OCSP, schwache Netzwerke und vertretbare Richtlinien)

Warum OCSP/CRL in Garagen und Depots versagen

• Schwache/zeitweise LTE/5G-Verbindung
• Eingeschränkter Fluchtweg (Firewalls/Gefangenenportale)
• Latenzsensitive Validierungsschritte
• Externe Abhängigkeiten (OCSP-Responder, CRL-Verteilungspunkte)

Ergebnis: Das EVSE kann eine Sitzung starten, diese aber nicht abschließen. Widerrufsvalidierung zuverlässig.

CRL vs. OCSP: Praktische Abwägungen

• CRL: Größere Downloads, aber zwischenspeicherbar und planmäßig aktualisierbar (gut für die Edge-Kontinuität).
• OCSP: Leichtgewichtig pro Anfrage, erfordert aber oft Live-Erreichbarkeit am schwächsten Punkt.

Im Jahr 2026 wird die korrekte Körperhaltung mehrschichtig sein:

• Geplantes CRL-Caching zur Erhöhung der Ausfallsicherheit
• OCSP, wo die Konnektivität zuverlässig ist
• Explizite Richtlinie für verschlechterte Zustände

Warum „Soft-Fail“ immer schwieriger zu verteidigen ist

Historisch gesehen wurde durch „Soft-Fail“ (Zulassen der Sitzung, wenn die Widerrufsprüfungen fehlschlagen) die Verfügbarkeit erhalten.
Im Jahr 2026 wird es schwieriger, ein Scheitern ohne Konsequenzen zu rechtfertigen, denn:

• Die Lebenszeiten werden kürzer (geringere Toleranz gegenüber überholten Annahmen).
• Die Meldefrist der CRA erzwingt strengere Disziplin bei Vorfällen und eine lückenlose Beweissicherung.

Ein vertretbares Design erfordert explizite, dokumentierte Richtlinien:

• Totalausfall für öffentliche/Hochrisiko-Umgebungen
• Anmut mit Beweisen für geschlossene Flotten (begrenztes Zeitfenster + kompensierende Steuerungen)
• Beweisprotokollierung für jede verschlechterte Entscheidung

Architektonische Maßnahmen zur Risikominderung (Muster, keine Produktversprechen)

Muster 1: Kanten-Vorvalidierung + Caching

• Cache-CRLs mit definierten Aktualitätsfenstern
• Zwischenspeicherung und validierte Ketten
• Vorabruf während Perioden mit „guter Konnektivität“

Muster 2: OCSP-Heftung (sofern möglich)

OCSP-Stapling verlagert die Zustellung des Widerrufsnachweises weg vom schwächsten Rand – wodurch die Abhängigkeit von der CA-Infrastruktur während des Sitzungsaufbaus reduziert wird.

Implementierungshinweis (eingebettete Realität): In EVSE-Umgebungen die Unterstützung für Heftklammer-Erweiterungen bestätigen.
in Ihrem eingebetteten TLS-Stack und Build-Konfiguration (z. B. mbedTLS, wolfSSL) und validieren Sie das Verhalten auf älterer Hardware,
weil der Funktionsumfang und die Speicher-/RTOS-Beschränkungen variieren.

Muster 3: Multi-Root-Trust-Governance

• Einheitlicher Truststore-Updatekanal für mehrere OEM-Anker
• Canary-Updates und Rollback bei plötzlichem Anstieg von Pfadaufbaufehlern

Muster 4: Zeitsynchronisations-Governance (nicht verhandelbar)

• NTP-Richtlinie (oder PTP, falls zutreffend)
• Driftüberwachung und Alarmschwellenwerte
• Definiertes Verhalten bei nicht vertrauenswürdigen Uhren

Offline-Kontinuität: Plug & Charge bleibt auch bei Verbindungsabbrüchen zwischen Netzwerkrand und Cloud nutzbar

Was Offline-Kontinuität ist (und was nicht)

Offline-Kontinuität bedeutet nicht, die PKI zu umgehen. Es handelt sich um eine kontrollierte Verschlechterung, die Folgendes gewährleistet:

• Integrität von Schlüsseln und Vertrauensspeichern
• Prüfbarkeit der Abrechnung und der Reaktion auf Vorfälle
• Explizite Beschränkungen hinsichtlich dessen, was lokal validiert werden kann (und wie lange).

Lokale Controller / Edge-Proxys als Verfügbarkeitsprimitive

• Lokale Vertrauenscaches (Anker/Zwischenzertifikate/CRLs) verwalten
• Durchsetzung von Richtlinien für eingeschränkte lokale Genehmigungen
• Zählerstände/Protokolle zur späteren Abstimmung puffern
• Verringern Sie den WAN-Ausbreitungsradius, indem Sie als lokaler Endpunkt für EVSE fungieren.

Abbildung 2 (Empfohlene Darstellung): Edge-Proxy als Vertrauenscache in Standorten mit schwachen Netzwerken

(EVSEs werden mit einem lokalen Edge-Proxy/Controller verbunden. Der Proxy verwaltet zwischengespeicherte Vertrauensanker/Zwischenzertifikate.)
Geplante CRL-Aktualisierung, Zeitsynchronisierungsüberwachung und Beweisprotokolle; es puffert Ereignisse im Cloud-CSMS/PKI, wenn die Uplink-Verbindung instabil ist.)

Kernaussage: Edge-Proxys reduzieren die Abhängigkeit von externen OCSP/CRL-Endpunkten im laufenden Betrieb und ermöglichen eine kontrollierte Offline-Kontinuität, ohne die PKI zu umgehen.

CRA & VMP: von Meldefristen ab September 2026 hin zu einem prüfbaren Betriebsmodell

CRA-Meldevorschriften: Ausrichtung auf die 24-Stunden-/72-Stunden-Uhr

Die Meldevorschriften der CRA verpflichten Hersteller, aktiv ausgenutzte Sicherheitslücken und schwerwiegende Vorfälle mit Auswirkungen zu melden.
zur Sicherheit von Produkten mit digitalen Elementen:

• Frühwarnung innerhalb von 24 Stunden sich dessen bewusst werden
• Vollständige Benachrichtigung innerhalb von 72 Stunden
• Abschlussbericht innerhalb definierter Zeitfenster (abhängig von der Vorfallsklasse)

Eine großflächige Störung des Plug & Charge-Systems, verursacht durch massenhaften Widerruf von Verträgen oder eine Kompromittierung der Vertrauensanker. könnten sich qualifizieren
als schwerwiegender Vorfall, abhängig von den Auswirkungen und den Beweisen für die Ausbeutung.

Prozess des Schwachstellenmanagements (VMP): minimale funktionsfähige Fähigkeiten

1. Die Wahrheit der Flotte: Anlagen- und Versionsinventar (EVSE-Firmware, Controller-Images, Trust-Store-Versionen).
2. SBOM-Integration (dynamisch): SBOM ist auf einsetzbare Artefakte abgebildet; kontinuierliche Korrelation mit Informationen zu Schwachstellen.
3. VEX-gesteuertes Expositionsmanagement: Pflegen Sie VEX-Aussagen, um zwischen „vorhanden, aber nicht ausnutzbar“ und „in unserer Bereitstellung ausnutzbar“ zu unterscheiden und so eine glaubwürdige Abgrenzung innerhalb des T+24h-Fensters zu ermöglichen.
4. Warum VEX im 24-Stunden-Takt so wichtig ist: SBOM zeigt Ihnen, was vorhanden ist; VEX hilft Ihnen, zu bestimmen, was ist ausnutzbarDadurch werden Fehlalarme reduziert und verhindert, dass die Einsatzteams nicht auf nicht verwertbare Störungen reagieren.
5. Aufnahme und Triage: Lieferantenhinweise, CVEs, interne Erkenntnisse; Priorisierung von Ausnutzbarkeit und Gefährdung.
6. T+24h Scoping-Workflow: Korrelation von SBOM, VEX und Inventar zur Identifizierung betroffener Bevölkerungsgruppen; erste Eindämmungsmaßnahmen; Beweissicherung.
7. T+72h Benachrichtigungsworkflow: Bestätigter Umfang, Gegenmaßnahmen, Einführungs-/Rücknahmeplan, Kommunikationsprotokoll.
8. Arbeitsablauf für den Abschlussbericht: Validierungsnachweise + Ursachenanalyse + Präventionsverbesserungen nach Verfügbarkeit von Korrekturmaßnahmen.
9. Patch-Kadenz-Engineering: Stufenweise Einführung, Rücknahmepläne, unterzeichnete Dokumente, Verifizierungsmechanismen.
10. Durchsetzung der Vertrauenskette: Sicherer Systemstart + sichere Firmware-Updates; Signaturschlüssel sind in HSM/sicheren Elementen geschützt.
11. Evidenzbasierte Protokollierung: Zertifikatsereignisse, Änderungen im Vertrauensspeicher, Widerrufsfehler, Integrität der Zeitsynchronisierung.

Hochriskantes Vertrauensszenario: Wird der Widerruf durch einen kompromittierten Stamm- oder Ausstellungsschlüssel ausgelöst,
Behandeln Sie es als einen schwerwiegenden Vertrauensvorfall, der sofortige Eindämmungsmaßnahmen und flottenweite Maßnahmen im Vertrauensspeicher erfordert.
und die Bereitschaft zur Berichterstattung gemäß CRA-Richtlinien, abhängig von den Erkenntnissen über Auswirkungen und Ausbeutung.

CRA-Checkliste für die Reaktion auf Vorfälle (operative Vorlage)

T+0 (Erkennung / Bewusstsein)

• Einfrieren von Beweismitteln: Protokolle, Zertifikatsereignisse, Truststore-Versionen, Zeitsynchronisierungsstatus
• Betroffene Oberflächen identifizieren: EVSE-Firmware, lokale Steuergeräte, Backend-TLS-Endpunkte
• PKI-Anbieter/Backend-Sicherheitsbeauftragten einbeziehen

T+24h (Frühwarnbereitschaft)

• Kernziel: Verwenden SBOM + VEX + Flotteninventar um die betroffene Bevölkerung zu ermitteln und eine evidenzbasierte Frühwarnung vorzulegen
• Entscheidung über die Eindämmungsmaßnahmen: Widerruf/Rotation, Trust-Store-Rollback, Standortisolierung
• Entwurf eines Frühwarnpakets: Umfang, laufende Gegenmaßnahmen, Übergangsstrategie

T+72h (Vollständige Benachrichtigungsbereitschaft)

• Bestätigen Sie die betroffenen Bevölkerungsgruppen nach Region/Standort; stellen Sie einen Sanierungsplan und eine Umsetzungsmethode bereit.
• Erstellung von Kunden-/Bedienerkommunikations- und Eskalationsprotokollen

Fenster für den Abschlussbericht

• Den Abschlussbericht gemäß den CRA-Anforderungen einreichen (die Frist hängt von der Vorfallsklasse ab).
• Validierungsnachweise nach der Fehlerbehebung + Erkenntnisse

Kosten- und Risikobewertung (Vorlagen, die Sie in Ihre Flotte integrieren können)

Arbeitskostenmodell für die manuelle Erneuerung

Lassen:

• N = Anzahl der TLS-Endpunkte (EVSE + Controller + Gateways + verwaltete Backend-Knoten)
• L = Gültigkeitsdauer des Zertifikats (Tage)
• T = menschlicher Zeitaufwand pro Erneuerung (Stunden)
• C = Lohnkosten inklusive aller Kosten (USD/Stunde)

Arbeitskosten ≈ N × (365 / L) × t × c

Ausfallrisikomodell (Ablauf oder fehlgeschlagene Bereitstellung)

Lassen:

• P_miss = Wahrscheinlichkeit einer verpassten/fehlgeschlagenen Erneuerung pro Zyklus
• H_down = erwartete Ausfallzeitstunden pro Vorfall
• C_Stunde = stündliche Auswirkungen auf das Geschäft (Umsatzeinbußen, Strafen, SLA-Gutschriften)

Kosten_Ausfall ≈ P_miss × H_down × C_hour

Entscheidungshilfe: Wenn Online-Widerrufsprüfungen fehlschlagen (OCSP/CRL-Timeout)

1. Öffentliches Gelände oder geschlossener Fuhrpark/Depot?
   • Öffentlich → bevorzugen Totalausfall (oder streng kontrollierte Gnade nur mit Beweisen + kompensierenden Kontrollen)
   • Flotte/Depot → Anmut mit Beweisen Für begrenzte Fenster mag dies akzeptabel sein.
2. Ist die Netzwerkzuverlässigkeit vorhersehbar?
   • Ja → Online-OCSP/CRL-Überwachung
   • Nein → Edge-Vorvalidierung + Caching (CRL-Aktualisierungsfenster, zwischengespeicherte Ketten)
3. Lässt sich die Online-Abhängigkeit während der Sitzung reduzieren?
   • Wo möglich → übernehmen OCSP-Heftmuster (Push-Beweis näher an den Rand)
4. Verfügen Sie über eine Protokollierung von Nachweisen und eine Zeitsynchronisierungs-Governance?
   • Falls nicht → beheben Sie diese zuerst; Richtlinien für den eingeschränkten Betrieb sind ohne sie schwer zu verteidigen.

Praktische Verantwortungsmatrix (Grenzen zur Verhinderung von Ausfällen)

Glossar

• PKI: Public-Key-Infrastruktur (Ausstellung, Validierung, Vertrauensanker, Widerruf)
• GIPFEL: Automatisierte Zertifikatsverwaltungsumgebung (automatisierte Ausstellung/Verlängerung)
• OCSP / CRL: Online-Zertifikatstatusprotokoll / Liste der Zertifikatssperrungen
• OCSP-Heftung: Der Server legt einen Widerrufsnachweis vor, um die Abhängigkeit von einem aktiven OCSP-Server zu reduzieren.
• Vertrauensanker: Root-/Zwischenzertifikate, denen Ihre Validatoren vertrauen
• SBOM: Software-Stückliste (Komponenteninventar zur Schwachstellenanalyse)
• ÄRGERN: Vulnerability Exploitability eXchange (Ausnutzungsstatusberichte)
• TLS 1.3: Modernes TLS-Profil; Handshake und Zertifikatsvalidierung bleiben latenzempfindlich
• VMP: Prozess des Schwachstellenmanagements (Aufnahme, Priorisierung, Patching, Berichterstattung, Nachweise)

Zukunftsorientiertes Risiko: Krypto-Agilität und PQC-Bereitschaft

Während 2026 von kurzen TLS-Lebensdauern und CRA-Meldepflichten geprägt sein wird, sollten Ladeinfrastrukturen mit der Bewertung beginnen.
Krypto-AgilitätBei langlebigen Anlagen (Fahrzeugen und Ladegeräten) sollten Architekturen eine Hardwareabhängigkeit vermeiden, indem sie Folgendes sicherstellen:
HSM/Sicherheitselemente und eingebettete Stacks können zukünftige Algorithmus- und Zertifikatsprofilaktualisierungen unterstützen, ohne dass eine Hardwareerneuerung erforderlich ist.

Häufig gestellte Fragen

Funktioniert Plug & Charge auch offline?

Teilweise – beabsichtigt. Offline-P&C ist eine kontrollierte Verschlechterung mittels lokalem Trust-Caching (Anker/Zwischenspeicher/CRLs, wo möglich).
Explizite Kulanzrichtlinien und gepufferte Audit-Logs zur Datenabgleichung sind erforderlich. Die PKI sollte nicht umgangen werden; die Abhängigkeit von der laufenden Cloud sollte reduziert werden.
unter Wahrung der Integrität und Nachvollziehbarkeit.

Wie oft müssen Zertifikate mit einer Gültigkeitsdauer von unter 199/200 Tagen erneuert werden?

Planen Sie mehrere Erneuerungszyklen pro Jahr und Endpunkt ein. Für viele Betreiber beginnt die operative Umstellung.
24. Februar 2026 weil DigiCert öffentliche TLS-Zertifikate mit einem Maximum ausstellt 199 Tage Gültigkeit ab diesem Datum.
Auf der Ebene des breiteren Ökosystems definieren die Basisanforderungen eine schrittweise Reduzierung auf 200/100/47 Tage.

Was löst die Meldepflichten gegenüber der CRA aus?

Die CRA-Meldevorschriften erfordern 24-Stunden-Frühwarnung Und 72-Stunden-Benachrichtigung bei aktiv ausgenutzten Sicherheitslücken und schwerwiegenden Vorfällen,
zuzüglich der letzten Meldefristen. Eine großflächige Störung des Vertrauensverhältnisses im Schaden- und Unfallversicherungsbereich (z. B. böswilliger Widerruf oder Kompromittierung der Validierung) kann je nach Fall relevant sein.
auf der Grundlage von Wirkungs- und Nutzungsnachweisen; ein CRA-konformer VMP sollte unterstützen SBOM + VEX + Flotteninventar Scoping innerhalb der ersten 24 Stunden.