top of page

Decision Makers: EV Charging Cybersecurity, ISO 15118, PKI, Contracts

Writer: Swift Charging
Swift Charging
2 days ago
6 min read

Technician inspecting secure EV charging infrastructure

Treat every EV charger as a high-consequence cyber-physical asset, not an IT peripheral. That means PKI-backed authentication under ISO 15118, network segmentation between charge points and back-office systems, procurement clauses that mandate signed firmware, and a testing cadence that never lapses. The Joint Office of Energy and Transportation and CharIN already publish the reference language. Use it.

 

TL;DR:  
  • Most vulnerabilities stem from weak enforcement of authentication protocols, insecure backend APIs, and unpatched firmware on charge point hardware.

  • Enforcing TLS downgrade protection, signed firmware, and network segmentation significantly reduces attack risks on charging networks.

  • Contracts must specify patch response times, end-of-life procedures, and liability for security flaws to prevent gaps in cybersecurity defenses.

  • Regular testing, continuous telemetry, and site-level security discipline are essential to detect anomalies and prevent cyber-physical threats.

  • Industry practices often neglect cybersecurity in procurement, making it critical to include enforceable security requirements in RFPs and contracts.

 



Table of Contents

 

 

Why EV charging cybersecurity carries physical, not just digital, stakes

 

A charge point sits at the intersection of the grid, a vehicle’s battery management system, and a cloud-hosted management platform. Compromise one layer and the consequences ripple outward in ways a stolen customer database never does. Researchers reviewing the sector’s risk profile point out that these are cyber-physical systems: an attack that manipulates charging session data can also destabilise local grid load or create a genuine safety hazard for the person standing next to the cable.

 

The consequences fall into a few distinct categories:

 

  • Grid stability: coordinated manipulation of charging load across many sites can create demand spikes that stress local distribution networks.

  • Physical safety: falsified power delivery messages can push current beyond what a cable or connector is rated for.

  • Service outages: back-end failures can take entire charging networks offline simultaneously.

  • Data and privacy exposure: payment credentials, RFID identifiers, and vehicle telemetry all pass through the same infrastructure.

 

A demonstrated risk, not a theoretical one: researchers running a software-defined-radio implementation against CCS over HPGP intercepted 2,750 real charging sessions and used the intercepted link to briefly overcharge a test vehicle. This wasn’t a lab thought experiment. It was a working attack against a live protocol stack.

 

Attack surfaces: where EV charging network vulnerabilities actually sit

 

Attacks against charging infrastructure cluster around a handful of predictable surfaces. Mapping them matters more than memorising incident names, because the same categories recur across vendors and geographies.

 

  1. The physical charge cable and HPGP link. The wireless man-in-the-middle research referenced above forced a test vehicle to display an artificially high level of requested power, while a much lower power was actually delivered, by stripping TLS protection and spoofing protocol messages on the powerline communication layer.

  2. Backend APIs and management platforms. A literature review covering multiple academic and industry papers identifies OCPP implementations and backend APIs as the most frequently exploited weak points, largely because authentication between charge point and management system is often poorly enforced.

  3. Mobile apps and phantom clients. Flaws in driver-facing apps have let researchers disable an entire city’s public charging network through a single back-end vulnerability, a denial-of-service risk at municipal scale.

  4. Firmware and supply chain. Long field-service life, five to ten years for many DC units, combined with inconsistent vendor patching, means a flaw discovered today can sit unpatched on thousands of live units for years.

 

Which standards should govern secure charging solutions?

 

Four reference points cover most of what a technical procurement team or auditor needs to specify against. None of them replace the others; they work as a stack.

 

  • ISO 15118 governs Plug-and-Charge authentication between vehicle and charger, using digital certificates so a driver never has to swipe a card or tap an app. Our own explainer on Plug-and-Charge covers how the certificate exchange works in practice.

  • OCPP (Open Charge Point Protocol) governs communication between the charger and the back-office management platform. It’s also, per the same literature review cited above, one of the more common sources of exploitable weaknesses when implemented loosely. Our guide to OCPP breaks down where those weaknesses tend to appear.

  • CharIN publishes cybersecurity white papers arguing that security has to be built in at the design stage, because retrofitting mature protocols onto deployed hardware is expensive and frequently incomplete.

  • NIST / NCCoE profiles, alongside the Joint Office’s published procurement clauses, give you actual contract language for RFPs rather than abstract principles. Cite the Joint Office document directly in tender documents; it saves your legal team from drafting cybersecurity clauses from scratch.

 

Technical mitigations every architect should specify

 

PKI is the backbone of secure Plug-and-Charge. Certificates need proper lifecycle management: issuance, rotation, and revocation, ideally automated rather than dependent on a technician visiting site with a laptop.

 

TLS and elliptic-curve cryptography (ECC) protect the session layer, but only if downgrade protection is enforced. The wireless MitM research is the clearest evidence available that TLS stripping against CCS/HPGP isn’t hypothetical; it’s a working exploit that forced protocol downgrade to manipulate power delivery. Anti-downgrade extensions, the kind proposed in that same paper, close exactly this gap.

 

Beyond the cryptographic layer, a handful of controls do most of the practical work:

 

  • Signed firmware and secure boot, so a device refuses to run code that hasn’t been cryptographically verified.

  • Remote update testing before firmware ships to the fleet, not after.

  • Network segmentation that keeps charge points off the same VLAN as payment systems or corporate IT.

  • Rate-limiting and access control lists on backend APIs to blunt denial-of-service attempts.

  • Tamper detection on physical enclosures, feeding alerts back to a monitoring platform.

 

Pro Tip: Ask vendors for their certificate rotation process before signing anything. If rotating a charger’s certificate requires a technician to visit the site and plug in a laptop, that vendor’s PKI implementation isn’t ready for a fleet of any meaningful size.

 

For a deeper technical breakdown of these controls specific to charge point hardware, see securing commercial EV chargers against theft and cyberattack.

 

What should a security procurement checklist include?

 

Contracts, not just hardware specs, are where most cybersecurity gaps get created or closed. A tender document that’s silent on patching obligations will get exactly that: silence, once the units are installed.

 

  1. Patch SLAs. Specify a maximum response window for critical vulnerabilities, not a vague “as soon as possible” clause.

  2. End-of-life handling. Require key escrow and a documented handover process if the vendor exits the market or discontinues the model.

  3. Signed firmware and unique device keys. Installers frequently find hardware shipped with shared authentication keys across an entire product line, a single compromised unit then exposes every other unit using the same credentials.

  4. Liability for security defects. Make clear who bears the cost if a known vulnerability goes unpatched past the agreed SLA.

  5. Vulnerability disclosure process. Confirm the vendor has one, and that it’s been tested, not just written down.

 

A Symmnet network security checklist offers a useful general framework for the segmentation and access-control side of this if your organisation is building internal IT policy alongside charger-specific procurement.

 

How often should EV charging infrastructure be tested?


How often should EV charging infrastructure be tested? — overview diagram

Three test types cover the ground: firmware review (checking for hardcoded credentials or unsigned update paths), field testing of actual ISO 15118 authentication flows, and penetration testing against backend APIs and driver apps.

 

Monitoring should flag anomalies automatically. Unusual charge rates against a session’s authenticated profile, unexpected TLS downgrade attempts, and repeated “phantom client” connection patterns are the signals worth alerting on, all directly traceable to the attack types documented above.

 

  • Annual third-party penetration test as a baseline.

  • Continuous telemetry monitoring, not periodic sampling.

  • Quarterly certificate audits across the PKI estate.

  • At least one live recovery rehearsal per year, simulating a real outage.

 

Applying EV charging cybersecurity controls on real sites

 

Standards on paper mean little without site-level discipline. Every site survey a commercial EV charging provider conducts assesses the communications architecture and physical security of proposed charger locations before installation begins, not after.

 

Closeout packs should hand over certificate details, firmware version records, and patch responsibilities in writing. Someone specific needs to own PKI renewal and firmware updates once the installer leaves, whether that’s an internal facilities team or a maintenance contract with defined SLAs for response time and telemetry review.

 

Why the industry keeps treating charger security as an afterthought

 

The recurring failure isn’t a lack of standards. ISO 15118, OCPP and CharIN’s guidance already exist. The failure is procurement teams treating cybersecurity as a feature to compare, rather than a binding contract requirement with penalties attached. Every RFP for EV charging infrastructure should include security acceptance criteria as a pass or fail gate, not a nice-to-have line item.

 

— Swift Charging

 

Sources

 

For readers who want the primary sources behind the claims above: the Joint Office’s cybersecurity guidance, the DCeption wireless MitM research paper, CharIN’s cybersecurity white papers, the 2026 literature review on smart EV charging security, and WIRED’s reporting on charger vendor patching failures all repay a full read.

 

If your business is planning new charging infrastructure or reviewing an existing installation’s security posture, Swiftcharging’s team can run a site survey covering both the physical and network architecture, including for commercial EV charging projects in Chichester, where secure-by-design specification gets built into the project from day one rather than bolted on afterwards.

 

Recommended

 

 
 
bottom of page