Electric vehicle charging infrastructure's security concerns the protection, against cyber and physical threats, of the electric vehicle charging infrastructure (EVCI or EVI), the critical infrastructure of structures, machinery, and equipment necessary to support electric vehicles (EVs). As a cyber-physical system, the EVCI is composed of an operational technology (OT) and an information technology (IT) layer. The OT layer relies on the smart grid to deliver power and offer flexibility services such as vehicle-to-grid (V2G) and demand response. The IT layer handles charge management, authentication, payment, and roaming services, often communicating through protocols such as the Open Charge Point Protocol (OCPP) between charging stations and management systems, and the ISO 15118 standard for communication between the vehicle and the charging station.
Because EVCI is considered a critical infrastructure, it is regulated as such under several frameworks. In the European Union, EV charging infrastructure operators are explicitly designated as an energy sub-sector under the NIS2 Directive, with physical resilience obligations covered by the companion Critical Entities Resilience (CER) Directive, and product-level cybersecurity requirements introduced for connected chargers by the Cyber Resilience Act. In the United States, federally funded charging stations must comply with the cybersecurity strategies mandated by the National Electric Vehicle Infrastructure (NEVI) Formula Program minimum standards. Consequently, EVCI is exposed to a wide array of threats ranging from individual attackers and cybercriminals to nation-state adversaries. Identified attack vectors target the charging stations themselves, the communication protocols, the back-end management systems, and the interface with the power grid, with potential consequences including disruption of charging services, fraud, theft of user data, and instability of the electrical grid.
Stakeholders and system architecture
The EVCI is operated not by a single entity but by an ecosystem of interacting stakeholders, which the academic and standards literature describes through a division of roles. The charge point operator (CPO) installs, operates, and maintains the physical charging stations and runs the charge point management system (CPMS) through which they are monitored and controlled. The e-mobility service provider (eMSP) acts as the interface between the driver and the service, providing access through apps, RFID cards, or Plug and Charge, and handling authentication, billing, and support. A roaming hub sits between the two, acting as a clearing platform so that a driver registered with one eMSP can charge on a CPO's network without a separate contract, while the charge point owner finances the infrastructure and may delegate its operation entirely. On the energy side, the distribution system operator (DSO) owns the distribution network from which the CPO draws power and to which it remits payment for the electricity consumed. These actors often interoperate through open protocols across different communication channels:
ISO 15118 is the most common protocol between the EV and the charger. It defines the high-level digital communication between the vehicle and the charging station, enabling automated authentication and billing (the Plug and Charge feature), smart charging, and bidirectional power transfer such as vehicle-to-grid (V2G). Communication can be secured with TLS, which is mandatory for Plug and Charge and relies on a vehicle-to-grid public key infrastructure (V2G-PKI). OCPP is the main protocol for the communication between the chargers and the CPMS. Open Charge Point Interface (OCPI) is the principal solution for roaming exchanges between CPOs and eMSPs. Open Clearing House Protocol (OCHP) and Open Intercharge protocol (OICP) are the main alternatives. OpenADR, IEEE 2030.5, and IEC 61850 are the principal protocols for grid-facing communication, carrying demand-response signals and flexibility services between the grid operators (DSO, TSO, utility) and the CPO or charging stations, so that charging can be shifted or curtailed according to grid conditions.
Although the literature presents these roles as cleanly separated, the deployed infrastructure rarely matches that picture: a single company frequently combines several roles at once (for example, a CPO commonly acting as its own eMSP) and the CPO function itself is assumed by a wide range of actors, from logistics providers and fuel-station chains to energy companies and municipalities. While this flexibility helped sustain the pace of EV deployment, it now creates security concerns: the high co-dependence between system components makes lateral movement easy, and the absence of standardization hinders the use of common security measures.
IT security The IT layer comprises the back-end and cloud systems that manage charging rather than deliver power: the CPMS, the eMSP platforms, the roaming hubs, the payment and authentication systems, and the mobile applications and public APIs through which drivers and third parties interact with the service. Because this layer carries identity, billing, and personal data, its security objectives are dominated by confidentiality and integrity, and its assets are exposed to the same classes of threat as any networked information system.
EVCS-CPMS communication The communication between a charging station and its management system, carried by OCPP, is the most studied interface of the IT layer, and its security depends strongly on the protocol version and the transport binding in use. The widely deployed OCPP 1.6 (2015) is offered over two bindings (a legacy SOAP/XML binding and a JSON-over-WebSocket binding known as 1.6J, the latter now dominant), but its base specification contains no security provisions. These were added only afterwards through the Open Charge Alliance Improved security for OCPP 1.6 white paper, which defines three optional security profiles:
Profile 1: HTTP Basic authentication over an unencrypted WebSocket. Profile 2: a server-side certificate combined with Basic authentication over TLS. Profile 3: mutual TLS in which both endpoints authenticate with certificates.
OCPP 2.0.1 (2020) folds these profiles into the core specification and treats security as a first-class concern rather than an optional extension.
Because the OCPP 1.6 base specification leaves security optional, many 1.6 and 1.6J deployments run under Profile 1 or plain WebSocket transport, exchanging data (billing records, authentication tokens, and control commands alike) in clear text. This exposes them to eavesdropping, man-in-the-middle interception, message tampering, replay, and session hijacking, while the HTTP basic credentials themselves can be captured and reused. The application layer offers no message-authenticity guarantee, so an attacker on the channel could forge management commands or redirect the station to a malicious firmware image.
At the protocol level, OCPP 2.0.1 addresses the main shortcomings of 1.6:
+ Security-relevant differences between OCPP 1.6(J) and OCPP 2.0.1 Aspect OCPP 1.6(J) OCPP 2.0.1 Security in the specification Optional, added by a separate white paper Native part of the core specification Transport encryption None by default TLS 1.2+ mandatory for Profiles 2–3 Authentication HTTP Basic (Profile 1) Basic (Profile 2) or mutual-TLS client certificates (Profile 3) Firmware updates Unsigned Cryptographically signed, with signature verification Certificate and key management Not defined Install, update, and delete certificate messages with key management Security logging None and a dedicated security event log ISO 15118 / Plug and Charge certificates Not supported Natively handled
These improvements are not a complete solution. For backward compatibility, the insecure Profile 1 remains permitted, so misconfiguration or a protocol downgrade can still leave traffic unencrypted, and TLS alone does not remove the residual exposure from weak certificate validation or from untrusted intermediate nodes in the roaming chain. Transport security protects the channel but not the truthfulness of the data placed on it: OCPP 2.0.1 back-ends are shown to retain weaknesses such as single-factor authentication based only on the charging-station identifier, weak session management, and the absence of rate limiting, independently of the transport layer. A compromised or spoofed charging station, or a malicious back-end, can therefore mount a false data injection attack (FDIA), reporting fabricated meter values or status notifications that the management system accepts as genuine. Because the CPMS drives smart-charging setpoints from these reports, coordinated false data across many stations can be escalated into a load-altering attack (LAA) on the distribution grid, forming a cross-layer path from the IT interface to the physical power system. The principal countermeasures are therefore to enforce Profile 3 mutual TLS and disable Profile 1, to validate certificates against a managed public key infrastructure, and to complement transport security with application-layer defences: per-device strong authentication beyond the station identifier, request rate limiting, plausibility checks and anomaly detection on reported measurands, and dedicated power-system messaging-security standards such as IEC 62351.
Cloud management systems Beyond the protocol itself, charging-management systems are shown to carry systemic weaknesses, rooted in weak single-factor authentication based only on the charging-station identifier, inadequate session management, and the absence of rate limiting on back-end communications. These weaknesses enable man-in-the-middle attacks, denial of service, firmware theft, and data poisoning. Comparable flaws have appeared in deployed products, including WebSocket authentication bypasses that allow attackers to impersonate charging stations, issue commands, and hijack sessions. The recommended countermeasures center on strict mutual device authentication beyond the station identifier, secure session management, request rate limiting, comprehensive logging, and managed firmware and software updates.
Firmware and software supply chain Charging stations run vendor-supplied firmware and embedded software that is typically updated remotely through the back-end using the OCPP firmware-update messages, which makes firmware integrity as much a back-end and supply-chain concern as a device one. An attacker who compromises the back-end can push a malicious or backdoored image to the whole fleet. Where the channel itself is unsecured (as under OCPP 1.6, whose firmware updates are unsigned), an attacker positioned only on a single station's transport link can likewise tamper with that station's update alone. Conversely, firmware extracted from a station can be reverse-engineered to recover hard-coded keys, credentials, or protocol secrets and to craft further attacks, linking firmware theft directly to the data-poisoning and impersonation risks seen at the back-end layer.