EV Charging Cybersecurity: Securing ISO 15118, Plug & Charge, OCPP and the Backend

OCPP 2.1 was published in January 2025 and adds support for ISO 15118-20 (bidirectional charging / V2G). OCPP 2.0.1 remains the dominant deployed version and was approved as IEC 63584 in 2024. OCPP 1.6 is still in field use. Treat the version mix as part of your threat model — not an implementation detail.

An EV charging session looks simple to the driver: connect the cable, authenticate, charge, and pay. Behind that experience is a distributed system spanning the vehicle, charging station, charging-management backend, roaming platforms, payment services, certificate infrastructure, mobile applications, cloud providers, and sometimes utility or building-management networks.

A weakness in any one of those domains can affect the others. A compromised charging station can expose customer data or become a foothold into an operator network. A stolen backend credential can control thousands of chargers. A broken Plug & Charge certificate process can disrupt authentication at scale. An insecure smart-charging interface can turn a fleet of chargers into a coordinated load-manipulation tool.

NIST’s EV Extreme Fast Charging profile treats the ecosystem as four connected domains: the EV, EVSE or charger, cloud and third-party operations, and utility or building networks. That is the right starting point. EV charging cybersecurity cannot be solved by hardening the charger alone.

This guide provides a practical security model for automotive and charging stakeholders. It focuses on charging-specific architecture, protocols, trust, operations, and evidence rather than repeating general connected-vehicle penetration-testing advice.

Map the charging trust chain

Start with the end-to-end transaction rather than a list of devices.

A typical public Plug & Charge flow may involve:

1. The vehicle establishes communication with the EVSE using ISO 15118.

1. The EV and EVSE negotiate charging parameters and authenticate through certificates.

1. The charger communicates with a Charging Station Management System using OCPP.

1. The CSMS exchanges information with a charge-point operator, e-mobility service provider, roaming platform, payment provider, or certificate service.

1. Smart-charging logic may interact with a utility, site controller, energy-management system, or distributed-energy resource platform.

1. Firmware, diagnostics, security logs, and operational commands move through separate management channels.

Every arrow carries identity, authorization, integrity, availability, privacy, and lifecycle assumptions. The security architecture should document:

• Which organization operates each system.
• Which protocol and version is used.
• How endpoints authenticate.
• Where keys and certificates are stored.
• Which commands are permitted.
• Which data is collected and retained.
• How software is updated.
• What happens when connectivity or trust fails.

A diagram without ownership and trust information is not enough. Many charging incidents begin in the gap between vendors rather than inside one product.

The four security domains

1. Electric vehicle

The vehicle contains the Electric Vehicle Communication Controller, charging control logic, battery-management interfaces, contract certificates, provisioning credentials, and user-account connections. Security concerns include certificate theft, insecure key storage, protocol-parser vulnerabilities, malicious charging messages, unsafe power negotiation, and lateral movement from infotainment or telematics toward charging systems.

The vehicle should treat the charger as an external and potentially hostile system. Input validation, protocol-state enforcement, timeouts, safe fallback, network isolation, and controlled certificate management are essential.

2. Charging station or EVSE

The station combines power electronics, embedded software, network connectivity, local user interfaces, payment terminals, maintenance ports, and physical access. It may be installed in an uncontrolled public location for many years.

Risks include exposed services, default credentials, removable storage abuse, debug access, firmware manipulation, OCPP credential theft, log leakage, denial of service, meter-data tampering, and physical attacks on communication or control hardware.

3. Cloud and third-party operations

The CSMS can manage large charger populations, push firmware, change configuration, authorize transactions, retrieve logs, and issue remote commands. Its compromise can create fleet-scale consequences.

The cloud domain also includes roaming, identity, payment, analytics, customer apps, support tools, and vendor portals. Broken object authorization, weak service credentials, unsafe API consumption, and excessive administrative privilege are major concerns.

4. Utility and building networks

Smart charging and vehicle-grid integration connect charging to site energy management and grid operations. Incorrect or malicious commands can cause local overload, service disruption, financial loss, or instability when coordinated across many assets.

Security must preserve both energy objectives and charging availability. The system needs fail-safe local behavior when cloud or utility instructions are unavailable or untrusted.

ISO 15118 and Plug & Charge security

ISO 15118 defines communication between the vehicle and charging equipment and enables functions including Plug & Charge. Plug & Charge uses a public-key infrastructure so the vehicle can authenticate and receive charging authorization without the driver presenting an RFID card or opening an app.

The security value is significant, but so is the operational complexity. The trust ecosystem may include:

• Vehicle OEM provisioning certificates.
• Contract certificates tied to an e-mobility service contract.
• EVSE certificates.
• Root and subordinate certificate authorities.
• Certificate provisioning services.
• Online status or revocation services.
• Charge-point and mobility-service operators.

A secure implementation needs more than TLS support. Teams should govern:

• Key generation and storage in vehicle and EVSE hardware.
• Certificate issuance and identity proofing.
• Installation and renewal of contract certificates.
• Trust-store distribution and root transitions.
• Revocation and status checking.
• Expiry behavior and grace periods.
• Clock accuracy.
• Multi-contract and vehicle-transfer scenarios.
• Failed provisioning and recovery.
• Logging without exposing private keys or unnecessary personal data.

Test the negative cases. What happens when a certificate is expired, revoked, from an unknown chain, has the wrong policy, or is presented for the wrong contract? Does the vehicle or charger fall back safely, or does it silently bypass authentication?

OCPP security from charger to backend

OCPP is the main operational protocol between charging stations and management systems. OCPP 2.0.1 introduced defined security profiles, client-certificate key management, signed firmware support, and security-event logging. The Open Charge Alliance’s current operational guidance emphasizes secure credential management and secure auxiliary file-transfer channels.

Key controls include:

Mutual trust

Use a security profile appropriate to the network and threat model. Avoid unauthenticated or weakly protected operation on untrusted networks. Charger identity should be bound to managed credentials, not only a serial number sent in a message.

Certificate and credential lifecycle

Provision unique charger credentials. Rotate them on a defined schedule and after compromise. Prevent one charger’s credential from authenticating another device. Protect private keys using hardware-backed storage where justified.

Command authorization

The backend should enforce which operators, services, and automated workflows may send remote-start, stop, unlock, configuration, reset, firmware, and diagnostic commands. Human administrators should use strong authentication and least privilege.

Secure firmware

Verify signed firmware before installation, protect rollback policy, validate compatibility, and retain evidence of what was installed on each charger. The download channel must also be secured; a signed image does not protect availability or confidentiality of an insecure transfer path.

Security-event logging

Normalize charger security events, preserve time and device identity, and route high-value events to monitoring. Avoid collecting logs that expose secrets or customer data without need.

Inventory and version control

Know which chargers, vendors, firmware versions, protocol profiles, certificates, and configurations are deployed. A vulnerability advisory is actionable only if the operator can identify affected stations quickly.

Do not ignore auxiliary channels

The main OCPP WebSocket may be protected while other paths remain exposed. Charging stations often use separate mechanisms for:

• Firmware download.
• Diagnostic-log upload.
• Remote shell or vendor support.
• Payment-terminal management.
• Cellular modem management.
• Local web interfaces.
• Site-controller integration.
• Time synchronization.
• Certificate enrollment.

Inventory each channel and apply the same identity, encryption, authorization, logging, and lifecycle discipline. The Open Charge Alliance specifically warns against insecure file-transfer methods for firmware and logs.

Vendor support paths deserve special scrutiny. A shared remote-access account or unmanaged support tunnel can bypass the stronger controls designed into OCPP.

High-priority attack scenarios

Charger fleet takeover

An attacker compromises a CSMS administrator, API client, or software supply chain and issues commands to many chargers. Consequences may include widespread outage, configuration manipulation, credential replacement, or malicious firmware deployment.

Plug & Charge credential abuse

A contract certificate, provisioning key, or backend account is stolen and used for fraudulent charging or impersonation. Weak revocation or delayed propagation extends the attack window.

Meter and transaction manipulation

Charging-session data is altered to commit fraud, dispute billing, misreport energy, or hide unauthorized use. Integrity needs to cover the full chain from measurement to settlement.

Malicious charger-to-vehicle input

A compromised EVSE sends malformed or unsafe protocol messages to exploit the vehicle communication controller or charging logic. Vehicle defenses must assume public chargers are untrusted.

Load manipulation

An attacker changes charging schedules across a site or fleet, causing peaks, interrupting operations, or interfering with grid services. Strong authorization and local safety limits are required.

Privacy exposure

Charging records reveal location, travel patterns, vehicle identity, account information, and payment behavior. Excessive logging or weak recipient authorization can turn operational data into surveillance data.

Physical compromise

An attacker opens a cabinet, accesses debug ports, replaces storage, attaches a rogue device, or taps communications. Tamper evidence, secure boot, port control, and field inspection help limit persistence.

Architecture principles for secure charging

Isolate power control from business services

Payment, advertising, local UI, and customer Wi-Fi should not share unrestricted access with safety-relevant charging control. Use hardware and network separation with narrowly defined interfaces.

Make local behavior safe and resilient

The charger should maintain safe electrical limits if cloud control is lost. It should fail predictably when identity, time, certificate status, or smart-charging instructions cannot be verified.

Minimize standing privilege

Backend services and operators should receive only the commands and station groups they need. Separate firmware administration, customer support, payment operations, and security monitoring.

Use zero-trust service identity

Authenticate service-to-service calls in the cloud, not only user logins. Protect secrets, rotate them, and use workload identity where possible.

Separate tenant and operator data

Roaming and white-label platforms serve many organizations. Enforce object-level authorization so one operator cannot view or control another operator’s chargers, sessions, customers, or certificates.

Design for replacement and end of support

Charging hardware may remain deployed longer than the vendor’s software support. Procurement should address security support period, patch delivery, credential transfer, component end of life, and secure decommissioning.

Secure procurement requirements

A charger security specification should require verifiable capabilities, not broad claims.

Ask vendors for:

• Supported OCPP version, edition, security profile, and certification status.
• ISO 15118 and Plug & Charge capabilities.
• Secure-boot and signed-firmware design.
• Unique-device identity and key-storage approach.
• Software bill of materials and vulnerability-handling process.
• Support period and patch timelines.
• Remote-access architecture.
• Security-event schema and export options.
• Local port and physical-tamper controls.
• Cryptographic-agility and certificate-renewal processes.
• Penetration and protocol-fuzzing evidence.
• Incident-notification commitments.
• Secure factory-reset and decommissioning process.
• Data ownership, residency, retention, and deletion terms.

Include acceptance tests. A requirement such as "supports signed firmware" should be tested with an invalid signature, wrong version, revoked key, interrupted installation, and attempted rollback.

Testing strategy

EV charging requires testing at component, protocol, integration, and ecosystem levels.

Vehicle-EVSE protocol testing

Test ISO 15118 message parsing, state transitions, timeouts, certificate chains, renegotiation, and malformed input. Include interoperability across several vendors.

OCPP testing

Verify authentication, certificate enrollment, command authorization, replay resistance, secure firmware, event reporting, configuration restrictions, and error handling. Test every supported protocol version and security profile.

Backend API testing

Test tenant isolation, object authorization, rate limiting, administrative privilege, webhook validation, partner APIs, and mobile-app flows.

Physical and embedded testing

Assess debug ports, boot integrity, storage protection, local interfaces, modem configuration, and cabinet access. Confirm that physical compromise does not automatically expose cloud credentials or signing keys.

Resilience testing

Simulate cloud outage, certificate-service outage, time loss, cellular failure, corrupted firmware, partial fleet connectivity, power interruption, and malicious smart-charging commands. Validate safe degraded operation and recovery.

Supply-chain testing

Review SBOMs, third-party components, build provenance, signing processes, and vendor update infrastructure. A secure charger cannot depend on an insecure update factory.

Monitoring and incident response

Operators need visibility across station, cloud, account, and energy behavior. High-value detections include:

• Repeated authentication or certificate failures.
• Credential use from unexpected stations or regions.
• Configuration changes outside maintenance windows.
• Bulk remote commands.
• Firmware downloads or installations from unusual sources.
• Security-profile downgrade.
• Unexpected station resets or time changes.
• Meter-data anomalies.
• Abnormal transaction or authorization patterns.
• Loss of logging from a station group.
• Smart-charging commands outside approved limits.

An incident record should connect the charger, site, firmware, certificate, operator, backend service, affected sessions, and remediation. This enables fleet scoping and supports regulatory, contractual, and customer communication.

Practice scenarios in advance. A charger fleet cannot always be taken offline safely or commercially. Response options may include credential revocation, command restriction, network isolation, local-only operation, staged firmware, site visit, or temporary service limitation.

Evidence and governance

A charging-security evidence package should include:

• End-to-end architecture and trust boundaries.
• Asset and data inventories.
• Protocol versions and security profiles.
• Certificate policies and operational records.
• Firmware baseline and signing evidence.
• Charger configuration and credential inventory.
• Threat analysis and control mapping.
• Test plans, results, and unresolved findings.
• Vendor and sub-supplier evidence.
• Monitoring coverage and incident records.
• Change and release approvals.
• Support and decommissioning plans.

Keep evidence current. A test report for firmware version 1.2 does not prove version 1.8 is secure. Certificate, configuration, and backend changes can alter the risk without changing the charger hardware.

A phased improvement roadmap

Phase 1: Inventory and contain

Identify every charger, firmware version, OCPP profile, backend endpoint, certificate, remote-access path, and owner. Eliminate shared default credentials and insecure auxiliary transfers.

Phase 2: Establish trust and update control

Implement unique identities, stronger OCPP security profiles, certificate lifecycle management, signed firmware, controlled administration, and release evidence.

Phase 3: Connect monitoring and risk

Normalize security events, link vulnerabilities to deployed stations, build fleet-scoping queries, and exercise incident playbooks.

Phase 4: Scale interoperability assurance

Run recurring cross-vendor ISO 15118 and OCPP testing, automate evidence collection, and include utilities, roaming partners, and payment providers in joint scenarios.

How ThreatZ can support the ecosystem view

Charging security evidence is usually fragmented across vehicle TARA files, charger vendor portals, cloud tickets, PKI systems, firmware repositories, and operator incident tools. ThreatZ can provide a connected risk and evidence layer that links the vehicle, EVSE, backend, software components, suppliers, threats, controls, tests, vulnerabilities, and incidents.

The first pilot should be narrow: one vehicle program, one charger model, one CSMS backend, and one Plug & Charge flow. The outcome is an end-to-end trust and evidence map that reveals gaps no single party can see alone.

Frequently asked questions

Is OCPP 2.0.1 automatically secure?

No. It provides stronger security capabilities, but deployment choices, credential management, authorization, firmware operations, auxiliary channels, and backend security determine the result.

Is Plug & Charge just a payment feature?

No. It is an authentication and authorization ecosystem based on certificates and multiple organizations. Its PKI lifecycle is a security-critical operational service.

Who owns EV charging cybersecurity?

Responsibility is shared among OEMs, EVSE manufacturers, charge-point operators, e-mobility providers, cloud and roaming platforms, utilities, site owners, and certificate operators. Contracts and interface agreements should define exact duties.

What is the highest fleet-scale risk?

Compromise of the charging-management or update plane can affect many chargers at once. Strong administrative security, service identity, command authorization, segmentation, and monitoring are essential.

Where should a program start?

Start with inventory and trust mapping. Many organizations cannot list all deployed firmware versions, OCPP security profiles, charger credentials, remote-access paths, and backend owners. That visibility is required before advanced controls can be effective.

Related reading on VxLabs

• ThreatZ integrations
• X.509 certificates in automotive
• certificate management

Authoritative references

• NIST IR 8473: Cybersecurity Framework Profile for EV Extreme Fast Charging Infrastructure
• Open Charge Alliance: OCPP
• Open Charge Alliance OCPP Security Operations Guide
• CharIN Plug & Charge
• CharIN Plug & Charge PKI
• U.S. Department of Energy: Securing EV Charging Infrastructure