Ladeinfrastruktur ohne Netzwerkzugriff: Wie Offline-First-Architektur die IT-Sicherheitsfreigabe ermöglicht

Kurzfassung. An sicherheitsrelevanten Standorten — Bundeseinrichtungen, Defense-Auftragnehmer, F&E-Labore, Halbleiterfabs, Betreiber Kritischer Infrastrukturen — ist der IT-Sicherheits­einwand gegen E-Lade­infra­struktur in der Regel weder Preis noch Zuverlässigkeit. Er lautet, dass konventionelle Ladestationen ungeprüfte IoT-Endpunkte sind, die entweder einen Platz im Unternehmensnetzwerk oder eine Mobilfunk-SIM mit aktivem Funk innerhalb des Perimeters verlangen. Beides ist ein Ausschlusskriterium. Die üblichen Gegenmaßnahmen (VLAN-Segmentierung, Mobilfunk-SIMs, Air-Gapped-Lader) scheitern jeweils auf mindestens einer Risiko­achse. Die Offline-First-Architektur von HeyCharge eliminiert beide Angriffsvektoren gleichzeitig: keine On-Prem-Netzwerk­anbindung, keine SIM, keinerlei Internet­konnektivität am Ladepunkt. Der Ladepunkt ist aus dem Internet nicht erreichbar — weil er mit nichts verbunden ist, was das Internet berührt. Genau dieser architektonische Schritt verwandelt „kein IoT in meinem Netzwerk” von einer Richtlinien­blockade in einen Nicht-Konflikt. Wir stehen mit US- und deutschen Behörden zu genau diesem Use Case im aktiven Austausch.

Dieser Artikel richtet sich an IT-, Sicherheits- und Beschaffungs­verantwortliche, die E-Ladeinfrastruktur an Standorten evaluieren, an denen die IT-Sicherheits­prüfung der entscheidende Schritt ist und keine Formalie. Er erläutert, warum konventionelle Lade­architekturen diese Prüfung nicht bestehen, warum die üblichen Gegenmaßnahmen den Kern des Problems nicht lösen, wie Offline-First das Bild verändert, und was eine ehrliche IT-Sicherheits­prüfung der Offline-First-Architektur tatsächlich findet.

---

Vergleich auf einen Blick

---

Warum sich die Frage überhaupt stellt

E-Ladeinfrastruktur an Bürostandorten, Flotten­depots und Besucher­parkplätzen wird zunehmend zur Pflicht — durch Beschaffungs­richtlinien, Nachhaltigkeits­vorgaben und Flotten­elektrifizierung. Für die meisten Betreiber ist die Lade­punkt­auswahl eine finanzielle und operative Entscheidung. Für eine Kunden­gruppe, die die Branche bislang weitgehend übersieht, ist sie eine Sicherheitsentscheidung.

Diese Organisationen haben eine IT-Standardposition: „Keine ungeprüften Geräte in unserem Netzwerk, niemals.” Sie sind Bundes­behörden und Defense-nahe Industrie. Sie sind Forschungslabore, deren geistiges Eigentum der gesamte Existenz­grund des Gebäudes ist. Sie sind Halbleiterfabs, in denen ein Ausfall in Wafern pro Minute gemessen wird. Sie sind Energie­versorger, Krankenhäuser, Häfen und Flughäfen — Standorte, an denen die regulatorische Folge eines Netzwerkkompromisses für sich genommen erheblich und die operative Folge ungleich schlimmer ist.

Für diese Kunden ist eine Ladestation kein bloßes Asset. Sie ist eine Forderung — ein Anspruch — dass ein ungeprüftes, nicht verwaltetes OT/IT-Gerät Zugang entweder zum Unternehmens-LAN oder zum HF-Spektrum innerhalb des Perimeters erhält. Dieser Anspruch kollidiert mit der grundlegendsten IT-Sicherheits­richtlinie, die diese Organisationen haben. Die Standard­antwort lautet Nein.

Das Ergebnis: E-Ladeinfrastruktur an diesen Standorten findet entweder gar nicht statt, sie entsteht langsam und teuer nach einem mehrjährigen Integrations­projekt, oder sie entsteht durch einen Workaround, mit dem die IT-Abteilung intern unzufrieden ist. Keines dieser Ergebnisse ist gut.

Drei Ausfallmodi konventioneller Ladeinfrastruktur an sicherheits­kritischen Standorten

Ausfallmodus 1: der Ladepunkt als weiterer ungeprüfter IoT-Endpunkt

Aus Sicht der IT-Abteilung ist eine netzwerk­gebundene Ladestation von jedem anderen IoT-Gerät nicht zu unterscheiden — ein vom Hersteller geliefertes Embedded-System mit hersteller­eigenem Firmware-Stack, das ausgehenden Internetzugang für Cloud-Management, OCPP-Backend-Kommunikation, Abrechnung und Over-the-Air-Updates erwartet. Der Hersteller plant, Sicherheits­patches dann auszuliefern, wenn es ihm passt. Der Hersteller erwartet, dass das Gerät zum Sitzungsstart aus dem Internet erreichbar ist, um den Fahrer zu authentifizieren, den Zahlungs­vorgang abzuwickeln, die Zählerwerte zu senden und die Quittung zurückzugeben.

Für einen Standort mit auch nur durchschnittlich reifer Sicherheits­haltung ist das eine Folge eskalierender Verstöße:

• Das Gerät ist im Unternehmens-LAN.
• Das Gerät hat ausgehenden Internetzugang.
• Das Gerät erhält unbeaufsichtigte Firmware-Updates aus einer Drittanbieter-Cloud.
• Der Hersteller des Geräts hat eine veröffentlichte Schwachstellen­historie, die weiterwachsen wird.
• Das Gerät und seine Geschwister sind ein Botnetz-Ziel im Kompromittierungsfall — Mirai- und Mozi-artige Schadsoftware zielt gezielt auf unbeaufsichtigte IoT-Endpunkte mit stabiler Netzwerk­präsenz.

Die Standard­antwort ist Netzwerk­segmentierung: Ladestationen in ein eigenes VLAN, nur die explizit benötigten Ausgangs­ziele erlauben, alles andere verweigern. Das funktioniert nur so lange, wie die Segmentierung niemals driftet. Es ist gut dokumentiert, dass mehrjährige IoT-Deployments Konfigurations­drift akkumulieren, und die Folge eines einzigen Fehl­patches — eine Router-Konfigurations­änderung, eine Firewall-Regel-Rotation, eine vergessene Service-Regel — ist, dass das Lader-VLAN nun mehr vom Netzwerk sieht als vorgesehen oder die Ladestationen mehr vom Internet sehen, als die Richtlinie zulässt. VLAN-Segmentierung reduziert den Schaden­radius. Sie eliminiert das Risiko nicht; sie verschiebt es auf den nächsten Konfigurations­wechsel.

Ausfallmodus 2: der Ladepunkt als unkontrollierter Mobilfunk-Sender im Perimeter

Die Standard­alternative zu „ins Netzwerk nehmen” lautet „eine SIM hineinstecken.” Hersteller verkaufen das als Feature: Die Ladestation kommt mit 4G/5G-Modem, der Betreiber zahlt die Daten­gebühren, die IT ist nicht beteiligt.

Für einen Standort, der das HF-Spektrum innerhalb des Perimeters kontrolliert, ist das schlechter, nicht besser. Eine SIM-bestückte Ladestation ist per Definition ein Gerät mit aktivem Mobilfunk­sender, das bidirektionalen Verkehr zu einem Drittanbieter-Netzwerk fähig ist, in das der Standort weder Sichtbarkeit noch Kontrolle hat. Der Standort hat nun ein Asset installiert, dessen Kommunikations­pfad eine Black Box ist. Aus TEMPEST-, Verschluss­raum- oder schlicht disziplinierter IT-Sicht ist das nicht akzeptabel. Viele sicherheits­kritische Standorte verbieten unverwaltete Mobilfunk-Endpunkte im Perimeter genau aus diesem Grund.

Hinzu kommt das Problem der Funk­abdeckung. Mobilfunk in Tiefgaragen — der häufigsten Einsatz­umgebung für Ladeinfrastruktur — ist in der Regel nicht vorhanden. Die Ladestation, die eine SIM hat, aber keinen Empfang, ist offline aus Versehen, nicht aus Design. Auf sie ist kein Verlass.

Ausfallmodus 3: der Firmware-Update-Pfad

Selbst das sicherheits­bewussteste Deployment muss die Firmware der Ladestation über deren Lebenszyklus aktualisieren. Bei den meisten Ladestationen geschieht das über die Luft: Die Hersteller-Cloud schiebt ein signiertes Firmware-Image, die Ladestation bootet neu, die neue Firmware ist installiert. Die IT-Abteilung hat damit ein kontinuierliches Root-of-Trust-Update an einen Dritten delegiert.

Genau dieser Lieferketten-Angriffsvektor war der explizite Gegenstand von Kongress­anhörungen, BSI-Hinweisen und dem IoT Cybersecurity Improvement Act. Dass eine einzige kompromittierte Hersteller-Cloud, oder ein einziger fehlerhaft ausgegebener Signier­schlüssel, angreifer­kontrollierte Firmware an Tausende von Geräten ausliefern kann, ist nicht theoretisch. Es ist passiert. Es wird weiter passieren. Für das Kunden­profil, das wir hier beschreiben, ist „der Hersteller schickt Ihnen Firmware-Updates, wann er möchte” ein Ausschluss­kriterium.

Warum die üblichen Gegenmaßnahmen das Problem nicht lösen

Drei Maßnahmen dominieren die Debatte, wenn ein IT-/Sicherheits­team gebeten wird, eine vernetzte Ladestation zu akzeptieren. Keine löst das Grundproblem.

VLAN-Segmentierung. Die am häufigsten vorgeschlagene Maßnahme. Die Ladestation kommt in ein eigenes VLAN, mit explizit erlaubten Zielen und Standard-Verweigerung für alles andere. Das ist solide Netzwerk­praxis und begrenzt den Schaden­radius. Es ändert nichts daran, dass das Gerät im Unternehmens­netzwerk ist, dass seine Firmware unbeaufsichtigt aktualisiert wird, dass es über seine sanktionierten Ausgangs­pfade aus dem Internet erreichbar ist, und dass jede künftige Konfigurations­drift die Grenze schwächt. VLAN-Segmentierung ist Schadens­begrenzung, keine Problem­lösung.

Mobilfunk-SIMs. Das LAN-Problem dadurch zu lösen, dass auf Mobilfunk umgestellt wird, ersetzt ein Risiko durch ein anderes — oft schlimmeres. Wie oben: Ein aktiver Mobilfunk-Endpunkt innerhalb eines sicherheits­kritischen Perimeters ist in vielen Bedrohungs­modellen für sich bereits ein Sicherheits­ereignis. Und in den Einsatz­umgebungen, in denen Lade­infrastruktur am dringendsten gebraucht wird — Keller, Tiefgaragen, dichte Innenstädte, Militär- und F&E-Campusse mit tiefer HF-Abschirmung — ist Mobilfunk schlicht nicht verlässlich genug, um als primärer Kommunikations­kanal zu dienen.

Air-Gapped-Ladestationen. Manche Hersteller bieten vollständig offline arbeitende Ladestationen an — kein LAN, keine SIM, keine Cloud. Das erfüllt die IT-Sicherheits­anforderung, opfert aber jede operative Eigenschaft, die ein realer Lade­betrieb braucht: keine Remote-Authentifizierung, keine zentrale Abrechnung, keine Flotten­transparenz, kein Firmware-Update-Pfad, keine identitäts­basierte Fahrer­berechtigung. Für eine einzelne Ladestation an einem entfernten Standort akzeptabel. Für ein echtes Lade-Deployment mit 50, 100 oder 1.000 Stellplätzen über mehrere Gebäude hinweg nicht.

Das Muster ist in allen drei Fällen dasselbe: Jede Maßnahme erzwingt einen Kompromiss zwischen Sicherheit und Betreibbarkeit. Der Betreiber akzeptiert entweder einen Sicherheits­kompromiss, um die Ladestation funktional zu halten, oder einen operativen Kompromiss, um sie sicher zu halten. In der konventionellen cloud­vernetzten Lade-Architektur gibt es keine Architektur, die beides liefert.

Die Offline-First-Architektur

Die SecureCharge-Plattform von HeyCharge geht von einer anderen Annahme aus: Die Ladestation soll niemals in einem Netzwerk hängen, für das die IT-Abteilung des Betreibers verantwortlich ist, und niemals einen Mobilfunk­sender tragen. Vier Eigenschaften greifen von dort an ineinander.

Die Ladestation hat keinerlei Internet­konnektivität, Punkt. Keine SIM. Kein Ethernet-Uplink. Keine WLAN-Verbindung ins Gebäudenetz. Die Ladestation ist bewusst nicht aus dem Internet erreichbar. Das ist die tragende architektonische Festlegung, auf der alles andere ruht.

Die Authentifizierung läuft lokal an der Ladestation. Beim Eintreffen eines Fahrers schließt das Smartphone (oder ein flotten­seitig ausgegebener Token) einen Autorisierungs-Handshake mit der Ladestation ab. Das Protokoll basiert auf industriestandardisierter asymmetrischer Kryptografie mit hardware-gestützter sicherer Schlüssel­speicherung an der Ladestation und verwendet patentierte Einmal-Tokens mit Sitzungs­bindung, die bei Wiedereinspielung oder Substitution fail-closed sind. BLE ist der Transport, der den Handshake trägt — nicht der Sicherheits­mechanismus. Die kryptografischen Garantien sind ergänzend zu dem, was Bluetooth Low Energy auf Link-Ebene bereits bietet, nicht von ihr abhängig. Es gibt keinen Remote-Angriffs­vektor, weil es keine Remote-Verbindung gibt.

Das Smartphone des Fahrers ist der Kurier. Sitzungs­metadaten, Abrechnungs­daten, Audit-Logs und Konfigurations­änderungen wandern asynchron zwischen Ladestation und HeyCharge-Plattform — getragen vom Smartphone des Fahrers über die HeyCharge-App. Jede Sitzung erzeugt einen signierten Datensatz an der Ladestation; dieser Datensatz wird vom nächsten Smartphone hochgeladen, das sich verbindet; die Plattform gleicht ab. Das ist dasselbe Store-and-Forward-Muster, das in taktischen Militär­funkgeräten, Satelliten-Relay-Logistik und Offline-First-Banking eingesetzt wird — etablierte Ingenieurs­praxis, kein Behelf.

Der Lieferketten-Angriffsvektor verliert seinen Auslieferungs­kanal. Ohne Internetzugriff an der Ladestation gibt es keinen automatisierten Pfad, über den eine kompromittierte Hersteller-Cloud angreifer­kontrollierte Firmware ausspielen könnte. Betreiber, die geplante, beaufsichtigte Updates wollen, lassen jedes Update von einem HeyCharge-autorisierten Techniker über den Service-Port einspielen; Betreiber, die OTA-ähnliche Updates wollen, lassen sie über den asynchronen BLE/Kurier-Kanal laufen. So oder so muss der Kunde nicht mehr darauf achten, welche Software auf der Ladestation läuft — das Gerät ist unabhängig von seiner Firmware-Version kein Angriffsvektor mehr.

Was die vier Eigenschaften zusammen­genommen liefern:

• Es gibt keinen IP-Verkehr zwischen Ladestation und einem vom Betreiber verwalteten Netzwerk.
• Es gibt überhaupt keinen IP-Verkehr zwischen Ladestation und einem Netzwerk.
• Es gibt keinen Mobilfunk­sender innerhalb des Perimeters.
• Es gibt keinen aus dem Internet erreichbaren Firmware-Auslieferungs­kanal, der beim Hersteller kompromittiert und ans Gerät weiter­propagiert werden könnte.
• Der Sitzungs-Authentifizierungs­kanal ist kurzreichweitig, einmalig, und kryptografisch signiert.

Die Ladestation ist im wörtlichsten Sinne aus dem Internet nicht erreichbar.

Was eine IT-Sicherheits­prüfung tatsächlich findet

Für das oben beschriebene Kunden­profil ist die IT-Prüfung eines Offline-First-Lade-Deployments vor allem darin ungewöhnlich, wie kurz sie ist.

Kommunikations­pfade. Die Ladestation hat genau zwei: BLE zu Fahrer-Smartphones, und eine Service-Port-Schnittstelle, die nur von einem autorisierten Techniker genutzt wird. Es gibt keinen dritten Kanal. Die Prüfung verifiziert dies gegen die Geräte­spezifikation und die ausgerollte Konfiguration.

Netzwerk­exposition. Null. Das Gerät verbindet sich nicht mit dem Unternehmens-LAN, dem Gäste-WLAN, der Gebäude­leittechnik oder einem Mobilfunk­netz. Es hat keine routbare Adresse in einem vom Betreiber verwalteten Netzwerk. Es gibt keine eingehende Angriffs­fläche, keinen ausgehenden Pfad.

Firmware-Update-Governance. Betreiber wählen das Update-Modell. Standorte, die Firmware pinnen wollen, lassen jedes Update von einem HeyCharge-autorisierten Techniker geplant und beobachtet über den Service-Port einspielen; Standorte, die das nicht brauchen, können Updates über den asynchronen BLE/Kurier-Kanal laufen lassen. So oder so gibt es an der Ladestation keinen aus dem Internet erreichbaren Update-Endpunkt. Das Lieferketten-Risiko, das den Großteil der IoT-Firmware-Bedenken treibt, hat hier schlicht kein Auslieferungs­vehikel.

Audit-Logs. Jede Sitzung erzeugt einen signierten, zeitstemplierten Datensatz an der Ladestation selbst. Datensätze werden asynchron über Fahrer-Smartphones hochgeladen und plattform­seitig abgeglichen. Aus Audit-Sicht ist der ladestations­seitige Datensatz die Grundwahrheit; der plattform­seitige Abgleich ist eine Komfort­schicht. Betreiber, die rein lokales Audit verlangen (keine Upstream-Replikation), können die Plattform so konfigurieren, dass abgeglichene Datensätze nach einer definierten Aufbewahrungs­frist verworfen werden.

Lieferkette. Die Hardware-Stückliste ist dokumentier­bar. Die kryptografischen Primitive sind industrie­standardisiert und reviewbar. Penetrations­tests sind machbar, weil die Angriffsfläche klein und gut definiert ist: das kryptografische Authentifizierungs­protokoll, der Service-Port und der signierte Firmware-Update-Fluss.

Die Form der Prüfung konvergiert auf eine kleine Zahl klar abgegrenzter Fragen, jede mit einer eindeutigen Antwort. Das ist für IoT ungewöhnlich.

Wie sich das in regulatorische Erwartungen einfügt

Die aktuelle Richtung der Cybersicherheits­regulierung in den USA und der EU konvergiert auf dieselbe IoT-Haltung: bekannte Lieferkette, abgegrenzte Angriffs­fläche, beaufsichtigter Firmware-Update-Pfad, minimal notwendige Netzwerk­exposition. Der IoT Cybersecurity Improvement Act of 2020 hat dies für die föderale Beschaffung in den USA kodifiziert. NIS2 und der EU Cyber Resilience Act dehnen diese Haltung auf die EU aus. Die Arbeit des BSI an TR-03183, und die ETSI-EN-303-645-Baseline, benennen dieselben Kontrollen. Keiner dieser Rahmen verlangt explizit Offline-First. Sie alle werden leichter erfüllbar, wenn das Gerät, um das es geht, schlicht keine Netzwerk­konnektivität hat, die die Regulierung adressiert. Wir machen hier kein Compliance-Argument — wir machen ein architektonisches Argument, das sich gut mit dem deckt, worauf die Regulatoren hinarbeiten.

Wann diese Architektur evaluieren?

Die Offline-First-Architektur ist operativ für die meisten großen Lade-Deployments geeignet. Sie ist einzigartig geeignet für Deployments, an denen konventionelle Architekturen die IT-Sicherheits­prüfung nicht bestehen:

• Bundesbehörden und Defense-nahe Industrie. Standorte mit Beschaffungs­richtlinien, die ungeprüfte IoT-Geräte, unverwaltete Mobilfunk­endpunkte oder hersteller­cloud­abhängige Infrastruktur im Perimeter ausschließen.
• Defense-F&E und VS-NfD-nahe Einrichtungen. Wo das Leitprinzip lautet: „keine Drittanbieter-Netzwerk­präsenz innerhalb der Grenze, keine Ausnahmen.”
• Betreiber Kritischer Infrastrukturen. Energie­versorger, Häfen, Flughäfen, Krankenhäuser — Standorte, an denen die regulatorische Folge eines Netzwerk­kompromisses operativ und reputativ hoch ist.
• Halbleiter­fabs und andere IP-intensive Industrien. Wo die Kosten eines Industrie­spionage­ereignisses die Kosten der Lade-Infrastruktur um Größenordnungen übersteigen.
• Diplomatische, nachrichtendienstliche und sensitiv-private Einsätze. Wo das Betriebsprinzip lautet „keine veröffentlichte Hersteller-Cloud sollte wissen, welche Ladestationen an dieser Adresse stehen.”

Der gemeinsame Nenner: „Kein ungeprüftes IoT in meinem Netzwerk” ist die Standard­position der IT-Abteilung, E-Ladeinfrastruktur ist eine kürzlich verpflichtende Priorität, und beide Teams stehen sich darüber, wie ausgerollt werden soll, im aktiven Konflikt gegenüber.

Wir stehen zu genau dieser Passung mit US- und deutschen Behörden im aktiven Austausch. Wir nennen noch keine Kunden. Der Sinn dieses Artikels ist nicht, Deployments zu reklamieren — sondern die architektonische Passung so zu beschreiben, dass die richtigen Teams sich darin wiedererkennen und sich melden.

FAQ

Verbindet sich die Ladestation jemals mit dem Internet? Nein. Die Ladestation hat keine SIM, keinen Ethernet-Uplink ins Internet und keine WLAN-Verbindung ins Gebäudenetz. Sie ist aus dem Internet nicht erreichbar. Der asynchrone Datenaustausch mit der HeyCharge-Plattform erfolgt über das Smartphone des Fahrers, das als Kurier zwischen Ladestation und Cloud fungiert.

Wie bekommt die Ladestation Software-Updates? Über den beaufsichtigten Pfad, den der Betreiber wählt. Standorte, die Firmware pinnen, lassen jedes Update von einem HeyCharge-autorisierten Techniker geplant und beobachtet über den Service-Port einspielen. Standorte, die das nicht brauchen, lassen Updates über den asynchronen BLE/Kurier-Kanal laufen. Architektonisch entscheidend ist der Punkt davor: An der Ladestation gibt es keinen aus dem Internet erreichbaren Update-Endpunkt — der Lieferketten-Angriffsvektor, der NIS2, den IoT Cybersecurity Improvement Act und BSI-Hinweise antreibt, hat hier keinen Auslieferungs­kanal.

Hängt das an der Sicherheit von Bluetooth? Nein. BLE ist die Transport­schicht, nicht der Sicherheits­mechanismus. Die Authentifizierung nutzt industrie­standardisierte asymmetrische Kryptografie — signierte Challenges sowie patentierte einmalig verwendbare, sitzungs­gebundene Tokens — mit hardware-gestützter sicherer Schlüssel­speicherung an der Ladestation. Das kryptografische Protokoll ist so entworfen, dass die Sicherheit, die BLE auf Link-Ebene liefert, ergänzend ist und nicht tragend. Dasselbe Protokoll würde identisch über jeden anderen kurzreichweitigen Transport laufen.

Was, wenn Bluetooth selbst an unserem Standort eingeschränkt ist? Für Standorte, die mitgebrachten Smartphones aus HF-Gründen den Zutritt verwehren, unterstützen wir flotten­seitig ausgegebene physische Authentifizierungs­token mit denselben kryptografischen Garantien, anstelle des Smartphones. Der Store-and-Forward-Pfad läuft dann über dedizierte Kurier­geräte, die mit den Besucher­richtlinien kompatibel sind.

Wie auditieren wir Nutzung und Abrechnung ohne durchgehende Netzwerk­verbindung? Jede Sitzung erzeugt einen signierten, zeitstemplierten Datensatz an der Ladestation selbst. Die Datensätze werden asynchron abgeglichen, sobald ein Fahrer-Smartphone oder ein Flotten-Token sie hochlädt. Für rein lokales Audit ist der ladestations­seitige Datensatz kanonisch, und der plattform­seitige Abgleich kann nach einer konfigurierbaren Aufbewahrungs­frist verworfen werden. Der Audit-Pfad ist vollständig, signiert und verifizierbar.

Können wir Penetrations­tests am Deployment fahren? Ja. Die Angriffsfläche ist klar abgegrenzt — kryptografisches Authentifizierungs­protokoll, Service-Port, signierter Firmware-Update-Fluss — und wir können die Dokumentation bereitstellen, die ein ernsthaftes Pen-Test-Engagement braucht. Wir haben das mit US- und deutschen Behörden­ansprech­partnern in frühen Gesprächen umrissen; einen veröffentlichten Pen-Test-Bericht haben wir noch nicht zu zeigen, und wir würden ein solches Engagement begrüßen.

Können Sie einen Kunden in diesem Segment nennen? Noch nicht. Wir stehen mit US- und deutschen Behörden zu genau dieser Passung im aktiven Austausch. Genau die Faktoren, die die Architektur für diese Kunden geeignet machen — minimale Hersteller­cloud-Kenntnisse, keine veröffentlichte Deployment-Topologie — bedeuten auch, dass öffentlich nennbare Referenz­kunden in diesem Segment unwahrscheinlich jemals existieren werden. Das wird unserer Einschätzung nach für jeden glaubwürdigen Anbieter in diesem Bereich gelten.

Wie sieht der Bereitstellungs­zeitplan aus? Für Standorte im oben beschriebenen Profil bitten wir zuerst um ein vertrauliches Briefing. Das eigentliche Deployment ist deutlich schneller als bei konventioneller Lade­infrastruktur, weil die IT-Netzwerk- und Mobilfunk­abdeckungs­schritte, die in den meisten Projekten den größten Anteil am Zeitplan haben, schlicht nicht erforderlich sind.

---

Fazit

Für die meisten Betreiber ist E-Ladeinfrastruktur eine Beschaffungs­entscheidung, getrieben von Kosten, Zuverlässigkeit und Installations­geschwindigkeit. Für eine reale, wachsende Kunden­gruppe — Bundes­einrichtungen, Defense-nahe Industrie, F&E, Kritische Infrastruktur — ist sie eine Sicherheits­entscheidung. Die konventionelle Lade-Architektur zwingt diesen Kunden entweder ein ungeprüftes IoT-Gerät im Unternehmens­netzwerk oder einen unkontrollierten Mobilfunk­sender im Perimeter auf. Beides ist nicht akzeptabel. Die Gegenmaßnahmen lösen das Grundproblem nicht.

Die Offline-First-Architektur von HeyCharge eliminiert beide Angriffsvektoren gleichzeitig. Kein On-Prem-Netzwerk. Keine SIM. Keine Hersteller-Cloud, die in die Anlage greift. Die Ladestation ist aus dem Internet nicht erreichbar. Genau dieser architektonische Schritt verwandelt „kein IoT in meinem Netzwerk” von einer Richtlinien­blockade in einen Nicht-Konflikt.

Wenn Ihr Team in dieser Lage ist, fordern Sie ein vertrauliches Sicherheits­briefing an. Wir gehen mit Ihnen die Architektur, die Annahmen des Bedrohungs­modells, den Audit-Log-Pfad und die Beschaffungs­optionen unter NDA durch. Keine öffentlichen Referenzen, keine Offenlegung der Deployment-Topologie, keine Zuschreibung.

Weiterführende Inhalte:

• SecureCharge: Wie die Offline-Architektur auf Protokoll­ebene funktioniert — für IT- und Sicherheits­teams, die mit dem technischen Detail beginnen wollen.
• E-Auto-Laden in Tiefgaragen ohne Internet — der Einsatz­umgebungs-Begleit­artikel für Standorte, an denen konventionelle Konnektivität auch aus nicht-sicherheits­bezogenen Gründen versagt.

— Chris Cardé, CEO & Mitgründer · Robert Lasowski, CTO & Mitgründer