# 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.