Protocol & Network Security
In-depth research on ISO 15118 PKI implementation, OCPP encrypted communications, and mitigation strategies against man-in-the-middle attacks on EV charging networks.
Protocol & Network Security
Building a Chain of Trust for EV Charging: ISO 15118 PKI, OCPP Security, and Mitigation of Man-in-the-Middle Attacks
Electric vehicle charging infrastructure is no longer an isolated electrical system. A modern charging session can involve a vehicle, charging station, local controller, charging-station management system, payment infrastructure, cloud services, energy-management systems, roaming platforms, and potentially the electric grid itself.
Each connection creates a trust boundary.
As charging networks become larger and more interconnected, cybersecurity therefore cannot be treated simply as “encrypting communications.” The relevant question is whether every participant can reliably establish who it is communicating with, whether the messages received are authentic and unmodified, and whether compromised credentials or devices can be contained without compromising the broader network.
Two standards are particularly important to this architecture: ISO 15118 on the vehicle-to-charger side and OCPP on the charger-to-management-system side.
Together they can form a strong security architecture, but only when their cryptographic mechanisms, certificate lifecycle, implementation practices, and operational controls are treated as parts of the same trust system.
The EV charging trust chain
A simplified charging architecture contains two fundamentally different communication domains:
EV ↔ EVSE ↔ CSMS
ISO 15118 primarily governs high-level communication between the electric vehicle and the Electric Vehicle Supply Equipment, while OCPP governs communications between the charging station and the Charging Station Management System.
ISO 15118 defines communication between the EV Communication Controller and Supply Equipment Communication Controller and supports functions including identification, authorization, charging control, payment-related mechanisms, and, in newer generations, bidirectional energy transfer. :chatgpt-content-reference{index=“0”}
OCPP serves another part of the system. It transports operational commands and information such as authorization, transaction data, configuration, remote control, diagnostics, security events, firmware-management functions, and smart-charging instructions between charging infrastructure and its backend.
The distinction matters because securing one communication domain does not automatically secure the other.
A vehicle may establish a cryptographically authenticated relationship with an EVSE while the charging station subsequently communicates with its backend through an inadequately authenticated OCPP connection. Conversely, a properly secured OCPP connection cannot compensate for an insecure or incorrectly implemented vehicle-to-EVSE interface.
Security has to remain continuous across the architecture.
ISO 15118 and Plug & Charge
One of the most important security capabilities associated with ISO 15118 is Plug & Charge.
The user experience is intentionally simple: the driver connects the vehicle and charging authorization can occur without manually presenting an RFID card, entering credentials, or using a mobile application.
Behind that simple interaction is a comparatively sophisticated Public Key Infrastructure.
Instead of relying exclusively on an identifier presented by the driver, the system can use digital certificates to authenticate relationships between actors participating in the charging process.
This fundamentally changes the security model.
A conventional identifier answers a question similar to:
“What identifier is being presented?”
Certificate-based authentication attempts to answer a much stronger question:
“Can this participant cryptographically prove that it possesses the private key associated with an identity trusted by this ecosystem?”
That difference is central to preventing impersonation.
PKI is more than a certificate
Public Key Infrastructure is sometimes described simply as “using certificates.” That description misses most of the system.
A functioning EV-charging PKI requires at least:
trusted root Certificate Authorities;
intermediate or subordinate Certificate Authorities;
end-entity certificates;
protected private keys;
certificate provisioning;
certificate-chain validation;
expiration handling;
revocation mechanisms;
certificate renewal and replacement;
secure time;
and procedures for responding to compromised credentials.
An X.509 certificate binds a public key to an identity or role and is signed by a trusted issuer.
During authentication, the receiving system validates a chain leading from the presented certificate toward a trusted root.
Conceptually:
Root CA → Intermediate CA → Operational Certificate → Device or Contract Identity
The private key corresponding to the certificate should never have to leave the entity that owns it.
That is the basis of asymmetric trust.
If the private key is poorly protected, however, the mathematical strength of the certificate infrastructure becomes largely irrelevant.
An attacker who extracts a legitimate charging-station private key may be able to impersonate that station until the credential is revoked or replaced.
For this reason, secure key storage is as important as certificate issuance itself.
Protecting private keys
Private keys should ideally be generated and stored inside hardware-backed security environments such as a secure element, Trusted Platform Module, Hardware Security Module, or equivalent protected cryptographic subsystem.
Software-only storage dramatically increases exposure.
An implementation that stores private keys as ordinary files in an accessible filesystem can convert a sophisticated PKI architecture into little more than a recoverable credential repository.
A robust device design should therefore consider:
Secure key generation. Keys should preferably be generated inside the protected cryptographic boundary.
Non-exportability. Operational private keys should not normally be extractable as plaintext.
Secure boot. The platform should verify that only trusted software can execute.
Signed firmware. Updates should be authenticated before installation.
Rollback protection. Attackers should not be able to reinstall an older firmware image containing known vulnerabilities.
The security of ISO 15118 authentication ultimately depends on the integrity of the hardware and software holding those credentials.
OCPP security: the second critical link
Once the EV and charger establish a charging session, the charger normally needs to communicate with a backend system.
This is where OCPP security becomes critical.
A common architecture uses OCPP over WebSockets, often transported across public or semi-public IP networks.
Without adequate protection, an attacker positioned between charger and CSMS could attempt to intercept, observe, alter, replay, or inject protocol traffic.
The Open Charge Alliance has progressively strengthened OCPP security requirements and guidance. Its current OCPP 1.6 Security Whitepaper applies security mechanisms developed for later OCPP generations to OCPP 1.6-J, including secure connection establishment, security-event handling, and secure firmware updates. :chatgpt-content-reference{index=“1”}
For OCPP 2.0.1, security forms part of the protocol and certification architecture. Current OCA certification distinguishes TLS-based operation with Basic Authentication from Advanced Security using client-side certificates. :chatgpt-content-reference{index=“2”}
The OCPP security profiles
The security profiles are useful for understanding increasing levels of trust.
At the lowest end is communication without meaningful transport-layer confidentiality. Such configurations should be considered unsuitable for security-sensitive production environments exposed to untrusted networks.
A stronger architecture uses TLS for encrypted communication while authenticating the charging station through application credentials.
The stronger certificate-based model uses TLS with client-side certificates.
This provides mutual authentication, commonly referred to as mTLS.
Instead of only the charger verifying the backend’s server certificate, the backend can cryptographically authenticate the charger as well.
The Open Charge Alliance identifies client-certificate TLS as its Advanced Security profile for both OCPP 1.6 and OCPP 2.0.1 certification. :chatgpt-content-reference{index=“3”}
This distinction is substantial.
A username and password can be copied.
A properly protected private key associated with a client certificate is considerably more difficult to clone.
What TLS actually protects
Properly configured TLS provides three essential properties:
Confidentiality: an observer should not be able to read the application traffic.
Integrity: modification of encrypted traffic should be detected.
Authentication: certificates enable the endpoint to verify the identity of the other endpoint.
Together, these properties make a conventional network-level man-in-the-middle attack substantially more difficult.
But the words “we use TLS” are not enough.
TLS security depends on correct implementation.
Certificate verification must not be bypassed. Hostnames or identities must be verified correctly. Trust stores must be controlled. Weak or obsolete cryptographic configurations must be excluded. Private keys must be protected. Certificate expiration must be monitored.
Otherwise encrypted communication can still terminate at the wrong endpoint.
The anatomy of a man-in-the-middle attack
A man-in-the-middle, or MITM, attack occurs when an adversary positions itself between two systems that believe they are communicating directly.
Conceptually:
Charging Station → Attacker → CSMS
If neither endpoint can authenticate the other properly, the attacker can potentially establish two independent connections:
Charging Station ↔ Attacker
and
Attacker ↔ CSMS
The adversary can then relay traffic while potentially inspecting or modifying it.
In an EV charging environment, the consequences could extend far beyond the disclosure of individual charging sessions.
Depending on the interfaces exposed and authorization controls present, an attacker could attempt to interfere with:
transaction authorization;
RemoteStartTransaction or equivalent commands;
RemoteStopTransaction operations;
charger configuration;
tariff information;
meter values;
availability states;
charging schedules;
diagnostics;
firmware distribution;
or energy-management commands.
At fleet scale, compromised control traffic becomes an infrastructure-security problem rather than merely a privacy problem.
Why encrypted transport alone is insufficient
Consider a charger configured to establish a TLS connection but instructed to accept any server certificate.
The traffic is encrypted.
Yet the charger has no reliable way of knowing which server received it.
An attacker capable of intercepting DNS or network routing could potentially present its own certificate, establish an encrypted connection with the charger, and subsequently relay traffic to the legitimate CSMS.
Both network links would be encrypted.
The architecture would still be compromised.
This illustrates one of the most important principles in applied cryptography:
Encryption without authenticated identity does not establish trust.
Certificate validation is not ancillary to TLS.
It is fundamental to it.
Mutual TLS and charger identity
For high-security environments, mTLS materially improves the trust model.
The CSMS presents its server certificate and proves possession of the corresponding private key.
The charging station independently presents a client certificate and proves possession of its own private key.
The resulting architecture resembles:
Charging Station Certificate ⇄ TLS Session ⇄ CSMS Certificate
Both endpoints authenticate each other before sensitive application traffic is accepted.
This also allows operators to revoke the identity of one charger independently of the rest of the fleet.
If charger 2,417 is compromised, its certificate can be invalidated without rotating a single shared password deployed across thousands of charging stations.
That is an important operational advantage of PKI.
Never deploy fleet-wide shared credentials
One of the most damaging architectural shortcuts is the reuse of the same password, key, certificate, or secret across an entire charger fleet.
Shared credentials destroy containment.
If one charger is physically compromised and the common credential extracted, every device using that credential may effectively become compromised.
Production charging networks should therefore prefer unique per-device identities.
The rule should be straightforward:
One charger, one cryptographic identity.
The same principle should apply wherever practical to subsystems and controllers.
Secure certificate lifecycle management
Deploying certificates is only the beginning.
A charging network may operate for ten or fifteen years, while individual credentials should typically have substantially shorter lifetimes.
Operators therefore need mechanisms for:
initial enrollment;
certificate installation;
certificate renewal;
expiration monitoring;
root and intermediate CA rotation;
emergency revocation;
device replacement;
ownership transfer;
and secure decommissioning.
Poor lifecycle management commonly creates two dangerous operational responses.
Either certificates are given excessively long lifetimes to avoid maintenance, or engineers disable validation when certificates unexpectedly expire.
Both approaches weaken the security architecture.
Certificate renewal should be treated as ordinary fleet management, not as an exceptional event.
Time is a security dependency
Certificate-based security also depends on trustworthy time.
A device cannot reliably determine whether a certificate is not yet valid or has expired if its clock cannot be trusted.
The Open Charge Alliance’s 2026 Security Operations Guide explicitly emphasizes trustworthy time as a prerequisite for multiple security mechanisms, including certificate validation and other cryptographic operations. :chatgpt-content-reference{index=“4”}
This means time synchronization itself becomes part of the threat model.
An attacker who can manipulate device time may interfere with certificate validation, log integrity, or other security functions.
Secure time therefore deserves the same architectural consideration as DNS, certificate stores, and firmware trust.
DNS and network-routing attacks
MITM mitigation should also consider how chargers locate their backend.
A correctly configured TLS stack provides substantial protection even if DNS is manipulated because the attacker should not possess a certificate trusted for the legitimate CSMS identity.
Nevertheless, DNS and routing remain relevant attack surfaces.
Operators can reduce risk through:
secure network segmentation;
controlled DNS resolvers;
restrictive outbound firewall rules;
VPN or private APN infrastructure where appropriate;
CSMS certificate validation;
allowlisting where operationally feasible;
and monitoring for unexpected endpoint changes.
A private network should not, however, replace application-layer security.
Private networks can themselves be compromised.
The objective should be defense in depth.
Firmware is part of the network-security boundary
An attacker does not necessarily need to defeat TLS if the charging station itself can be compromised.
Malicious firmware could read transactions before encryption, manipulate commands after decryption, extract credentials, create hidden administrative interfaces, or communicate directly with an attacker-controlled system.
For that reason, secure communications must be paired with a secure software supply chain.
The OCA security framework includes secure firmware-update mechanisms, and current OCPP guidance treats firmware integrity as part of charging-system security. :chatgpt-content-reference{index=“5”}
A robust firmware architecture should require cryptographically signed packages and verify signatures before installation.
Ideally the trust chain continues from the bootloader upward:
Hardware Root of Trust → Bootloader → Operating System → Charger Application → Network Credentials
Breaking any one of those layers can undermine those above it.
Network segmentation
Charging stations should not be treated as ordinary workstations attached directly to corporate infrastructure.
They are distributed edge devices, frequently located in physically accessible environments and sometimes maintained by third parties.
Their network privileges should therefore be minimal.
A charging-network architecture can separate:
EVSE network
CSMS application network
database services
payment infrastructure
administrative interfaces
EMS or grid-control infrastructure
corporate IT
Traffic between these zones should be explicitly controlled.
A charger normally has no legitimate reason to initiate arbitrary connections to corporate systems.
Network policy should reflect that fact.
The CSMS is a high-value target
Individual chargers are geographically distributed, but the CSMS centralizes control.
This makes the management system one of the highest-value components in the architecture.
Compromise of a single EVSE may affect one site.
Compromise of the CSMS can potentially affect an entire fleet.
Consequently, CSMS protection should include conventional enterprise controls alongside EV-specific protocol security:
strong administrative authentication;
MFA;
role-based access control;
least privilege;
administrative network segmentation;
API authorization;
immutable or protected audit logging;
security-event monitoring;
secret management;
database encryption;
backup protection;
vulnerability management;
and incident-response capability.
OCPP security cannot compensate for a compromised backend administrator account.
Logging and security events
Charging security also depends on detecting abnormal behavior.
Operators should monitor events such as:
repeated certificate-validation failures;
unexpected charger identities;
excessive authentication failures;
charger connections from unusual networks;
repeated reconnect loops;
certificate changes;
firmware-update failures;
altered configuration;
unexpected backend destinations;
time synchronization anomalies;
and unusual remote-command patterns.
OCPP’s modern security model includes security-event and logging capabilities specifically because prevention alone is insufficient. :chatgpt-content-reference{index=“6”}
The objective is not merely to prevent intrusion.
It is to detect when the trust model itself begins behaving unexpectedly.
ISO 15118 and OCPP should not become separate security islands
One architectural mistake is to implement ISO 15118 security and OCPP security as unrelated projects.
Consider a Plug & Charge transaction.
The vehicle may authenticate using the ISO 15118 certificate ecosystem.
The charging station receives information associated with that authorization.
The charging station then communicates with the backend through OCPP.
The backend may contact additional authorization, roaming, billing, or certificate systems.
Trust therefore crosses multiple protocol domains.
The effective path resembles:
Vehicle
↓
ISO 15118 authenticated channel
↓
EVSE
↓
OCPP authenticated channel
↓
CSMS
↓
Authorization / PKI / Billing / Roaming Infrastructure
Each transition must preserve the security properties expected by the preceding layer.
Otherwise the strongest cryptography in the system merely protects data until it reaches the weakest boundary.
Defense against MITM must therefore be layered
There is no single “anti-MITM” feature.
Effective mitigation is a combination of controls:
Use TLS for charger-backend communication.
Validate the complete server certificate chain.
Verify the expected CSMS identity.
Prefer mutual TLS for high-assurance deployments.
Provision unique charging-station certificates.
Protect private keys with hardware-backed storage where possible.
Implement certificate expiration, renewal, and revocation processes.
Use trustworthy time.
Sign and verify firmware.
Implement secure boot where hardware permits.
Restrict charger network privileges.
Segment backend, payment, EMS, and corporate environments.
Monitor authentication and certificate anomalies.
Maintain auditable security-event logs.
Test failure conditions, not only successful connections.
The final point is frequently neglected.
Security systems must be tested to ensure that they fail securely.
A charger should be tested not only with a valid certificate but also with an expired certificate, unknown CA, incorrect hostname, revoked credential, malformed chain, manipulated clock, and unreachable revocation infrastructure.
A system that works correctly only when everything is valid has not yet demonstrated its security behavior.
OCPP 1.6 is not automatically insecure
Large numbers of deployed chargers still use OCPP 1.6-J.
Replacing every such charger purely because it does not run OCPP 2.x is neither technically nor economically realistic.
Importantly, the Open Charge Alliance continues to publish security guidance specifically for OCPP 1.6. The fourth edition of its Security Whitepaper, published in February 2026, describes how security enhancements associated with OCPP 2.x can be implemented on top of OCPP 1.6-J. :chatgpt-content-reference{index=“7”}
The relevant distinction is therefore not simply:
OCPP 1.6 versus OCPP 2.x
but rather:
secure implementation versus insecure implementation.
A well-engineered OCPP 1.6 deployment using modern TLS, correct certificate validation, unique device credentials, secure firmware, and appropriate network controls may present a substantially stronger security posture than a poorly configured newer implementation.
Protocol version alone does not create security.
OCPP 2.x provides a stronger security foundation
That said, newer OCPP generations integrate security more systematically.
OCPP 2.0.1 certification now incorporates security into its Core certification requirements, and OCA also provides an Advanced Security profile supporting client-side TLS certificates. :chatgpt-content-reference{index=“8”}
OCPP 2.0.1 also now has certification coverage for ISO 15118 support, reflecting the increasing integration between vehicle-side and backend charging functionality. :chatgpt-content-reference{index=“9”}
For new charger designs, this creates an opportunity to engineer the security architecture from the beginning rather than adding encryption and certificates after the communication stack has already been designed.
Security is an architecture, not a feature
The strongest conclusion is also the simplest.
There is no individual EV-charging security feature that can make the system secure.
Not TLS.
Not ISO 15118.
Not OCPP.
Not Plug & Charge.
Not a private APN.
Not an HSM.
Each protects a different portion of the architecture.
A resilient charging network instead establishes a continuous chain of trust:
trusted hardware
→ trusted firmware
→ protected private keys
→ authenticated vehicle communication
→ authenticated charger communication
→ trusted backend services
→ controlled administrative access
→ continuous monitoring and incident response
If one layer fails, the remaining layers should limit the resulting damage.
That is the principle of defense in depth, and it is particularly important for EV charging because the infrastructure sits simultaneously in the domains of transportation, payments, telecommunications, cloud computing, and increasingly the electrical grid.
As charging networks evolve toward Plug & Charge, bidirectional charging, distributed energy resources, and grid-responsive control, cybersecurity will cease to be an accessory to charging infrastructure.
It will be part of the infrastructure itself.