Versinetic · EV Charging Security
EV Charger Cloud Security
Checklist 2026
Smart Charge Regs 2021
OCPP 2.0.1
ETSI EN 303 645
UK GDPR
Why this checklist exists: The March 2026 ransomware attack on EV charger manufacturer ELECQ exposed a recurring pattern in the sector — cloud security treated as an afterthought. This checklist is designed to help you identify gaps before an attacker does. It is not a penetration testing framework; it is a structured starting point for an informed conversation about your security posture. There are 24 items in total.
Priority type:
Regulatory / Legal
Architecture
Operations
Process & Governance
1
Data Architecture & Segregation
Is customer data properly isolated from operational systems?
Is customer PII (names, addresses, email, phone) stored in a separate database from OCPP operational data?
The ELECQ incident illustrates the risk of co-locating customer account data with back-office systems. Segregated data stores limit your blast radius significantly.
Is there documented network segmentation between the physical charger hardware layer and the cloud back-end?
ELECQ's chargers were unaffected because some segmentation existed. This should be an explicit design requirement, not an incidental outcome.
Are cloud storage buckets, databases and object stores configured with least-privilege access controls?
AWS S3 bucket misconfigurations and over-permissioned IAM roles remain among the most common vectors for cloud data exfiltration.
Is data minimisation applied — do you collect only what is strictly needed to operate the service?
Under UK GDPR, you should be able to articulate a lawful basis and business need for every category of personal data you hold. Data you do not collect cannot be stolen.
2
Remote Access & Authentication
Are your access pathways locked down in production?
Are remote access services (SSH, Telnet, RDP) disabled by default on production infrastructure?
ELECQ shut down SSH and Telnet post-incident — they should not have been exposed in the first place. Use jump hosts, VPNs or zero-trust access proxies where admin access is required.
Is multi-factor authentication (MFA) enforced for all cloud management console and admin portal access?
ETSI EN 303 645 prohibits universal default passwords and requires authentication appropriate to the risk level. MFA on all cloud admin access is a non-negotiable baseline.
Are API endpoints for OCPP communication protected with token-based or certificate-based authentication?
OCPP 2.0.1 includes improved security profiles over OCPP 1.6. If you are still running 1.6 without additional authentication controls layered on top, this warrants prompt attention.
Is privileged access managed via a PAM (Privileged Access Management) tool, with sessions logged and time-limited?
Standing privileged access is a significant risk. Just-in-time access controls substantially reduce your exposure window and generate an audit trail for forensic investigation.
3
Communications Security
Are data flows encrypted and authenticated end-to-end?
Are TLS 1.0 and 1.1 fully disabled, and is your roadmap migrating from TLS 1.2 to TLS 1.3 for all OCPP communications?
TLS 1.0 and 1.1 are deprecated and must not be present in any production environment. TLS 1.2 is required under Smart Charge Points Regulations 2021 and OCPP 2.0.1 security profiles, but is itself now being phased out in favour of TLS 1.3. ISO 15118-20, mandatory under EU AFIR for all newly installed public and private Mode 3 chargers from 1 January 2027, requires TLS 1.3 with mutual authentication. If your stack cannot support TLS 1.3, that is a hardware and software roadmap issue to address now, not at the deadline.
Is there a documented certificate lifecycle management process, including renewal schedules and revocation procedures?
Expired certificates are a routine cause of both service disruption and security degradation. Certificate management should be automated where possible to remove human error from the chain.
If ISO 15118 Plug & Charge is implemented or planned, is PKI provisioning and certificate revocation designed for scale?
ISO 15118 introduces a full PKI chain involving vehicle, charger and back-end certificates. The security model is strong, but implementation complexity is significant. Engaging specialists early avoids costly rework.
Are inter-service communications within your cloud platform (microservices, internal APIs) also encrypted and authenticated?
Attackers who gain initial access to one service can pivot laterally if internal traffic is unencrypted. East-west traffic encryption is as important as north-south.
4
Firmware & Software Update Security
Can attackers tamper with your update pipeline?
Are OTA firmware updates cryptographically signed and verified on-device before installation?
ETSI EN 303 645 and the Smart Charge Points Regulations both address the security of software update mechanisms. Unsigned updates are an unacceptable risk in deployed infrastructure.
Is secure boot enabled on charger hardware, preventing unauthorised firmware from executing at startup?
Secure boot ensures only cryptographically verified software runs during the boot sequence, protecting against persistent firmware-level compromise even if the device is physically accessed.
Is there a firmware rollback capability, and has it been tested under realistic failure conditions?
A failed update leaving chargers inoperable across a large deployment is a significant operational and reputational risk. Rollback is standard practice; testing it regularly is less common but equally important.
Is there a documented vulnerability disclosure and patch management process, with defined SLAs for critical patches?
Many breaches exploit known vulnerabilities that were unpatched for months. A defined SLA (e.g. critical patches within 14 days) provides a measurable standard and demonstrates due diligence to procurement teams.
5
Incident Response & Regulatory Readiness
Do you know what to do when — not if — something goes wrong?
Is there a documented incident response plan that includes a 72-hour ICO notification procedure?
UK GDPR requires notification to the ICO within 72 hours of becoming aware of a personal data breach (where feasible). Many organisations discover they have no documented process only when one is urgently needed.
Has the incident response plan been tested in the past 12 months, including a tabletop exercise with relevant stakeholders?
A plan that has never been tested is a significant source of false confidence. Tabletop exercises regularly expose gaps in notification chains, tooling access, and decision-making authority under pressure.
Are system and event logs retained for a sufficient period, stored in a tamper-resistant location separate from production systems?
Logs stored on compromised infrastructure are frequently deleted or encrypted by ransomware attackers. Off-system, immutable log storage is the appropriate architecture for forensic integrity.
Are backup and restore procedures in place and regularly tested, with defined recovery time and recovery point objectives?
Restore from backup was central to ELECQ's recovery. Untested backups frequently fail at the point they are most needed. RTOs and RPOs should be agreed, documented and validated at least annually.
6
Vendor & Procurement Security
Questions for CPOs and local authorities evaluating third-party vendors
Does your vendor contract include security obligations, breach notification timescales, and right-to-audit clauses?
Many CPO contracts focus on uptime and hardware warranties. Security obligations are frequently absent or vague. If your vendor suffers a breach involving your customers' data, contractual clarity matters considerably.
Can your vendor demonstrate compliance with the UK Smart Charge Points Regulations 2021 (or EU equivalent) security requirements?
This is a legal requirement for placing charge points on the UK market. Ask for documentation, not verbal assurances. UKCA certification alone does not cover all security obligations under UK (or EU) Regulations. For vendors exporting to EU markets, CE marking and compliance with the equivalent EU framework apply alongside UK requirements. Expect both, and ask for both in writing.
Has your vendor undergone independent penetration testing of its cloud infrastructure in the past 12 months, with results available under NDA?
Responsible vendors can typically provide a penetration test summary or remediation log. A vendor unwilling to discuss security testing results at all warrants additional scrutiny in the procurement process.
Does your vendor have a published or documented software bill of materials (SBOM) and a process for tracking third-party component vulnerabilities?
Supply chain attacks increasingly target dependencies rather than the primary product. An SBOM allows you and your vendor to assess exposure when a new CVE is published for a widely-used library or component.
✓
How to Interpret Your Score
There are 24 items in this checklist. The bands below are based on the number of items you can answer "yes" to — not items ticked for review. Be honest: a tick here means your organisation has this control confirmed and in place, not merely planned or in progress.
0
items confirmed · out of 24
Not yet started
Tick each item above as you confirm it is in place.
0 – 8
High Exposure
Significant gaps exist. Prioritise network segmentation, remote access controls, and incident response planning as immediate actions. Consider engaging a security specialist.
9 – 16
Developing Posture
Foundations are in place but meaningful gaps remain. Focus first on items tagged Regulatory — these carry legal obligations under UK GDPR and the Smart Charge Regs 2021.
17 – 24
Strong Baseline
Good posture overall. Consider formal penetration testing and ETSI EN 303 645 alignment as next steps toward a security-by-design standard across your full product portfolio.