⚡ TL;DR – EV Charger Cloud Security: Lessons from the ELECQ Attack
A ransomware attack on Chinese EV charger manufacturer ELECQ in March 2026 compromised customer names, addresses and contact details stored on AWS cloud infrastructure. The physical chargers were unaffected, and ELECQ interrupted the attack in progress. But the incident is a clear signal that cloud-connected charging platforms carry real security obligations, not just feature roadmaps. For CPOs and charger manufacturers operating in the UK, it is worth asking whether your own vendor, or your own platform, would pass scrutiny right now.
What Happened With ELECQ?
On 7 March 2026, ELECQ detected unusual activity on its AWS cloud platform and quickly confirmed that attackers had launched a ransomware campaign against parts of its infrastructure.
Some databases were both encrypted and exfiltrated before the company could pull the plug. Customer data – names, email addresses, phone numbers and home addresses – was almost certainly walked off-site before containment.
ELECQ managed to interrupt the attack in progress, restored systems from backups, shut down exposed remote access services including SSH and Telnet, and brought in forensic specialists.
The company notified the UK’s Information Commissioner’s Office and Germany’s equivalent regulator, suggesting customers in multiple European markets were involved.
ELECQ is a relatively minor player in the UK market, so the direct impact here is contained.
The broader lesson, however, is not about ELECQ specifically.
It is about a pattern of behaviour across the EV charging sector that this incident makes harder to ignore.
“Too many charger manufacturers have treated security as something to bolt on later. Customer names, addresses and account data are obvious targets. What matters now is whether procurement teams and regulators use this moment to ask harder questions of all vendors.”
⚡Dunstan Power, Managing Director, Versinetic
Why Does This Pattern Keep Repeating?
EV charging has grown extraordinarily fast. Government LEVI funding, 2030 ZEV mandates, and expanding CPO networks have all pushed manufacturers to prioritise speed to market over security architecture. Features, certifications, and cost competitiveness have dominated the roadmap. Security has often been treated as a compliance checkbox rather than a design principle.
The pattern is almost predictable now.
Hardware gets hardened first because regulations demand it. The UK’s PSTI Act and Smart Charge Points Regulations created clear, auditable requirements for device security, so manufacturers prioritised exactly that.
Cloud infrastructure sat behind the regulatory spotlight, running on legacy configurations that were “good enough” until they weren’t.
ELECQ’s chargers remained operational throughout the attack.
Their AWS backend did not.
That asymmetry. secure front door, unlocked back door, is what targeted ransomware exploits.
The preceding standard, ISO 15118-2 with TLS 1.2, became mandatory for newly installed publicly accessible chargers from 8 January 2026. That date has already passed.
The January 2027 mandate for ISO 15118-20, and with it mandatory TLS 1.3, is not a first step for the sector. It is a second one. For the first time, encrypted mutual authentication between device and vehicle will be a legal floor, not a design choice.
Manufacturers who treat that deadline as a firmware update are going to find themselves redesigning hardware instead.
⚡Regulatory Context
The UK’s Smart Charge Points Regulations 2021 require that charge points prevent unauthorised access, support secure firmware updates, and implement appropriate network security. The ICO’s involvement in the ELECQ breach notification signals that GDPR obligations apply wherever European customer data is held, regardless of where the manufacturer is based.
This is not a problem unique to Chinese manufacturers or smaller players.
The Smart Charge Points Regulations 2021 already impose specific security requirements on all manufacturers placing charge points on the UK market, covering protections against unauthorised access and obligations around secure communications.
OCPP 2.0.1 includes a significantly improved security model over OCPP 1.6, with TLS encryption, certificate management and message signing.
Yet adoption of these standards remains patchy, and enforcement scrutiny has been limited.
What Good Looks Like: Security as a Design Principle
The distinction between organisations that treat security as a design principle and those that treat it as an afterthought is increasingly visible. As procurement teams and regulators start asking harder questions, that distinction will have commercial consequences.
At a minimum, responsible cloud-connected EV charging architecture should separate the physical device network from customer data systems, enforce TLS across all OCPP communications, implement proper certificate lifecycle management, disable unnecessary remote access services by default, and have a documented, tested incident response plan in place before something goes wrong.
The fact that ELECQ’s physical chargers were unaffected is worth noting. It suggests that some degree of network segmentation was in place. That is a baseline, not a gold standard. The customer data still walked out the door.
Segmentation protects operational continuity. It does not substitute for a proper data security architecture.
What Procurement Teams and CPOs Should Be Asking Right Now
If you are a CPO deploying hardware from a third-party manufacturer, or a local authority procuring chargers under a LEVI project, this incident is a useful prompt to review your vendor security questions. The checklist below sets out the key areas.
These aren’t exhaustive penetration testing criteria. They’re the baseline questions any informed procurement conversation should cover.
If you are a manufacturer, the same checklist works as a self-assessment. If you find gaps, better to find them internally than through an ICO notification.
EV Charger Cloud Security Checklist
A Word on Network Segmentation
The ELECQ incident reinforces something that engineers at Versinetic have advocated for consistently: physical charging hardware and customer-facing cloud systems should be treated as distinct security domains.
Firmware, load management logic, and grid communications operate in a different threat environment to account databases and billing systems. Blending them on the same infrastructure, or allowing lateral movement between them, is a design choice that dramatically increases your blast radius when something goes wrong.
The UK’s rapid LEVI deployment means that thousands of new charging points are being connected to cloud back-ends right now – some with considerably more rigour than others – and the gap is not always visible at procurement stage.
Getting this architecture right at the point of installation is considerably cheaper than retrofitting security controls after a breach.
Are Your Systems and Your Vendors Ready to Meet These Requirements?
FAQs
Were the physical EV chargers affected by the ELECQ ransomware attack?
No. ELECQ confirmed that the physical charging devices remained fully operational throughout the incident.
This suggests that at least some network segmentation was in place between the cloud back-end and the hardware layer. That is encouraging, though it does not diminish the seriousness of the customer data exposure.
Do the UK's Smart Charge Points Regulations 2021 require manufacturers to implement cybersecurity measures?
Yes. The Smart Charge Points Regulations 2021 include specific security requirements for charge points placed on the UK market, covering unauthorised access prevention, secure communications, and protections around software updates. Compliance with these regulations is a legal requirement for manufacturers, not optional guidance. OCPP 2.0.1 provides a significantly stronger security framework than 1.6 and is increasingly expected by sophisticated CPO procurement teams.
What is ETSI EN 303 645 and is it relevant to EV charger manufacturers?
ETSI EN 303 645 is the European standard for cybersecurity in consumer IoT devices. It sets out 13 provisions covering areas such as prohibition of universal default passwords, secure software update mechanisms, secure communication, and minimisation of exposed attack surfaces. While originally targeted at consumer IoT broadly, it is directly applicable to connected EV charging hardware. Aligning your security self-assessment to EN 303 645 is a pragmatic starting point for manufacturers who have not yet undertaken a formal security review.
Does TLS version matter for EV charger security?
Yes, and it matters more than most procurement checklists currently reflect. The widely deployed ISO 15118-2 standard specifies TLS 1.2. Its successor, ISO 15118-20, mandates TLS 1.3, which drops legacy cipher suites and enforces forward secrecy by design. OCPP 2.1 picks up ISO 15118-20 support. When you are evaluating charger platforms for multi-year deployments, the question to ask vendors is not just "do you support TLS?" but "which version, and can you upgrade in the field without a hardware swap?"
If I am a CPO using a third-party manufacturer's hardware and cloud platform, am I liable if there is a breach?
This depends on your contractual arrangements and what data you collect and process as part of your own operations. As a data controller or joint controller under UK GDPR, you may have obligations regardless of whether the breach originated in a supplier's systems. This is a matter for your legal team to confirm, but the practical takeaway is clear: understand your data flows, include security requirements in vendor contracts, and ensure you have your own incident response procedures in place. We would always recommend taking specific legal advice on your individual situation.
What is Versinetic's approach to security in its own products?
Security is embedded in our architecture rather than added afterwards. Our MANTARAY communications controller, OCPP software stack, and SiteManager platform are built with TLS encryption , certificate-based authentication, and network segmentation as baseline requirements. We support OCPP 2.0.1 with its improved security model, and our ISO 15118 stack incorporates PKI-based Plug & Charge authentication. For customers integrating our hardware and software into their own platforms, we provide technical guidance on secure deployment architectures as part of our standard engagement.
Further reading
Julian Skidmore is Versinetic’s EV Industry Analyst.
He has a Computer Science degree from UEA and an MPhil in Computer Architecture from Manchester University, as well as over 20 years of experience in embedded systems development.
As a senior software engineer, Julian has worked on EV charging and V2G projects, and has also co-authored EV-related articles for the electronics industry press.
Julian is a proponent of the zero-carbon society and a Guardian News ‘climate hero’. He has owned a battery EV for over two years, has investments in wind farm cooperatives, and has a 4KW domestic solar PV installation.
