EVSE Infrastructure Attack Surfaces

EV charging infrastructure has quietly become one of the more interesting attack surfaces in automotive security — it sits at the intersection of embedded systems, cloud backends, payment processing, and physical public access, often all owned by different vendors who never quite agreed on a shared threat model.

This post is a map of where the interesting seams are, not a how-to. Think of it as the outline I'd want before diving into any one piece in depth.

The actors in an EVSE deployment

A charging session typically touches:

• The vehicle — battery management system, onboard charger, communication controller

• The EVSE (charge point) — the physical charger, usually running embedded Linux or an RTOS

• The Charge Point Operator (CPO) backend — the cloud system managing the fleet of chargers

• The e-Mobility Service Provider (eMSP) — handles billing, roaming, apps

• The driver's app/RFID card — the authentication token

Each boundary between these is a potential attack surface, and each is usually built by a different vendor.

Surface 1: OCPP (charger ↔ backend)

OCPP is the dominant protocol between charge points and CPO backends. Versions matter a lot here:

• OCPP 1.6J (WebSocket/JSON) is still extremely common in the field, and its security depends almost entirely on how the implementer layered TLS and authentication on top — the spec itself doesn't mandate much.

• OCPP 2.0.1 improves on this with better security profiles, but adoption lags because rip-and-replace of deployed hardware is expensive.

Interesting angles: weak or absent mutual TLS, predictable charge point identifiers, backend APIs that trust whatever a charger claims about itself (meter values, transaction IDs) without independent verification.

Surface 2: ISO 15118 (vehicle ↔ charger)

This is the protocol for Plug & Charge — the vehicle authenticates to the charger (and vice versa) using certificates, without the driver tapping an app or card. It's elegant when it works, but it introduces a whole PKI trust chain:

• Root CAs, sub-CAs, provisioning certificates, contract certificates

• Certificate revocation handling (or the lack of it) in constrained embedded environments

• The physical layer underneath it (PLC over the charging cable) has its own history of implementation quirks

A compromised or misissued certificate anywhere in that chain has outsized consequences because Plug & Charge is designed to require no other authentication step.

Surface 3: The physical charger itself

Public chargers are, by definition, physically accessible to anyone. That means:

• Exposed debug ports (UART, JTAG) on units that weren't hardened for field deployment

• Firmware update mechanisms — how is a new firmware image authenticated before a charger accepts it?

• Local diagnostic interfaces meant for technicians, sometimes left reachable

This is the surface that most resembles classic embedded/IoT hardware hacking, and it's often the least mature from a security-engineering standpoint because chargers were historically treated as "dumb" appliances.

Surface 4: The backend and app layer

This is standard web/API security territory, but with automotive-specific consequences:

• BOLA/IDOR in fleet management APIs (start/stop someone else's charging session, pull their session history)

• Billing logic — can meter values or session duration be manipulated to under-report usage?

• Roaming — CPOs interconnect through the Open Charge Point Interface (OCPI) or similar; trust between operators who've never security-reviewed each other's systems is its own can of worms

Surface 5: Grid-facing and smart-charging features

Newer deployments add demand-response and V2G (vehicle-to-grid) features, where the charger can throttle or schedule charging based on grid signals. This is early-stage but worth watching — it's a new remote-control surface with real physical-world consequences (load manipulation at scale) if backend trust boundaries aren't solid.

Where I'd focus first

If I were prioritizing based on impact-per-effort, in rough order:

1. OCPP backend trust assumptions (surface 1) — most deployments, least mature TLS/auth hygiene

2. Physical charger debug/firmware surface (surface 3) — highest "someone will find this eventually" risk given public accessibility

3. ISO 15118 PKI (surface 2) — lower current prevalence (Plug & Charge adoption is still growing) but highest blast radius when it matters

Future posts will probably go deep on one of these at a time — likely starting with OCPP backend assumptions, since that's the one my pocket-charger build is already poking at.