ISO 15118 Plug and Charge: Security and PKI Basics

Why ISO 15118 matters beyond the marketing

"Just plug in and it charges automatically." That sentence describes Plug and Charge, and it sounds simple. Under the surface it is one of the most sophisticated security protocols in the automotive world — a full public key infrastructure (PKI) built into a charging cable, operating in real time between a vehicle, a charging station, and multiple certificate authorities across the internet.

Understanding how the trust chain works is not optional for engineers designing EV charging systems, OEM backend teams, or CPOs deploying public infrastructure. Certificate failures, revocation gaps, and cross-network authentication breakdowns are the leading causes of PnC session failures in early deployments — and they all trace back to gaps in understanding the architecture.

What Plug and Charge replaces

Before PnC, EV charging authorization required an external step: an RFID card tap, an app payment flow, or a QR code scan. The vehicle and the payment infrastructure were separate systems. ISO 15118 moves authorization inside the vehicle itself. The car carries a cryptographic certificate that identifies it and authorizes payment automatically when it connects to a compatible station.

The protocol operates over the combined charging communication link — specifically the PLC (power line communication) channel carried over the CP (control pilot) line in the CCS connector. No additional hardware is needed beyond what a CCS-compliant system already requires.

Simplified side-by-side diagram:

Left — RFID card-based authorization flow (user → card → reader → backend → EVSE).

Right — PnC flow (car → EVSE directly, certificate in car, backend verification automatic).

The PKI trust chain: four layers that must all work

The security architecture relies on a certificate hierarchy with four distinct layers. Each layer signs the one below it, creating a verifiable chain of trust from a root authority down to the individual charging session.

Layer 1 — Root Certificate Authority (Root CA)

Operated by a V2G Root CA — in Europe this is primarily Hubject, in North America CharIN is defining the governance model. The root certificate never leaves the Root CA's hardware security module (HSM). It signs only intermediate CAs. Validity period: typically 40 years.

Layer 2 — Sub-CA (Intermediate Certificate Authorities)

Two types exist: the OEM Provisioning Certificate Authority, which issues vehicle identity certificates, and the Mobility Operator Sub-CA, which issues contract certificates. Both carry validity periods of 5–10 years.

Layer 3 — OEM Provisioning Certificate (Vehicle Certificate)

Installed in the vehicle during manufacturing, one per VIN. This certificate is used for TLS mutual authentication with the charging station to establish the encrypted session — it does not authorize payment directly. Valid for the vehicle's commercial lifetime, typically 15–20 years.

Layer 4 — Contract Certificate

Issued by the e-Mobility Service Provider (eMSP). This is what actually authorizes the charging session and billing. Tied to the charging contract held by the vehicle owner. Valid for 1–2 years, renewable automatically in ISO 15118-20.

Vertical certificate chain diagram

Table 1 — Certificate hierarchy summary

The TLS handshake during a PnC session

When you plug a PnC-capable vehicle into a compatible EVSE, the following sequence happens automatically and invisibly, completing within 3–8 seconds before any power flows.

1. SLAC — Signal Level Attenuation Characterization: the car and EVSE detect each other over the Type 2 cable's PLC channel and establish physical-layer communication. 2. IPv6 addressing — Link-local IPv6 addresses are negotiated over the PLC channel. 3. TLS 1.2 mutual authentication — The car presents its OEM Provisioning Certificate. The EVSE presents its CPO certificate. Both parties verify the other's certificate chain back to the Root CA. 4. ChargeParameterDiscovery — The vehicle requests charging parameters: maximum current, voltage window, energy target. 5. Contract certificate exchange — The vehicle's encrypted Contract Certificate is transmitted to the EVSE. 6. Authorization — The EVSE backend verifies the contract certificate against the eMSP's records and the PKI revocation status. Authorization confirmed, power flow begins.

ISO 15118 -2 Message Sequence diagram

Where implementations fail in real deployments

The security model is architecturally sound. Deployment engineering is where things break down. The following failure modes account for the majority of reported PnC session failures in early European and North American deployments.

Certificate provisioning delays

OEM Provisioning Certificates must be provisioned during vehicle assembly and registered with the PKI backend before the customer takes delivery. Supply chain disruptions, software update timing issues, or VIN database propagation lag can result in vehicles with absent or invalid certificates at delivery. This is more common than manufacturers publicly acknowledge.

OCSP and CRL availability

Online Certificate Status Protocol (OCSP) or Certificate Revocation Lists (CRL) must be reachable by EVSE backends in real time. In areas with poor backend connectivity — or during EVSE software failures — revocation checks are skipped or served from cache. This creates a window in which compromised certificates may still authorize sessions. EVSE operators must define explicit policy on fail-secure vs fail-open behavior and document it.

Cross-network interoperability

A contract certificate issued by an eMSP in Germany must be verifiable by a CPO-operated EVSE in France or the United States. This requires a common root of trust. ISO 15118 mandates one, but Root CA certificate distribution across all EVSE and backend operators has been incomplete in practice through 2024. Cross-operator PnC session failures remain the most frequent complaint in multi-CPO testing scenarios.

HSM requirements at the EVSE

The EVSE must perform private key operations in a hardware security module. Budget hardware frequently implements this in software, which is technically non-compliant with the standard's security intent and creates a vulnerability where the station's TLS private key can be extracted by an attacker with physical access.

Table 2 — Common PnC failure modes and root causes

What changes with ISO 15118-20

ISO 15118-20, published in 2022 and currently in early commercial deployment, extends the original standard with capabilities that go well beyond basic PnC.

Bidirectional power support (V2G/V2H): The authorization and metering framework now covers energy flowing from the vehicle back to the grid or to a home energy system. This is the foundation for Vehicle-to-Grid programs.

Wireless charging support (WPT): Communication over inductive wireless charging pads uses the same PKI model, ensuring PnC authentication is pad-technology agnostic.

Dynamic load management: Real-time grid signal communication (grid price, demand response signals) can be transmitted through the 15118-20 session, enabling adaptive charging curves without separate backend APIs.

Automated certificate renewal: The manual contract certificate renewal process that caused PnC failures at contract expiry in 15118-2 is replaced with an automated Certificate Installation Service within the charging session itself.

Table 3 — ISO 15118-2 vs ISO 15118-20 feature comparison

What engineering teams implementing PnC need to prioritize

Start Root CA enrollment in the design phase, not validation. Certificate provisioning infrastructure takes 12–18 months to test end to end across OEM, eMSP, and CPO chains. Programs that start this in the validation phase ship vehicles with known PKI gaps.

Mandate hardware HSMs on the EVSE. Require hardware security module certification in EVSE procurement specifications. Software-only TLS implementations are non-compliant with the security intent of the standard.

Test OCSP failure modes explicitly. What is your EVSE's behavior when it cannot reach the revocation server? Fail-secure (deny all sessions) has significant customer experience implications. Fail-open (allow sessions using cached CRL) has security implications. Make this a documented policy decision, not a default behavior.

Commission cross-network test scenarios. PnC compliance testing must include sessions across at least three different eMSP/CPO combinations to surface Root CA distribution gaps before deployment.

Architect for 15118-20 migration from day one. Infrastructure being deployed today will be in service for 10–15 years. V2G programs are commercially inevitable. Backend authorization systems should be designed to accommodate bidirectional energy metering and settlement from the start.

References

1. ISO 15118-2:2014 — Road vehicles: Vehicle to grid communication interface, Part 2: Network and application protocol requirements.

2. ISO 15118-20:2022 — Road vehicles: Vehicle to grid communication interface, Part 20: 2nd generation network and application protocol requirements.

3. CharIN e.V. — Plug and Charge Implementation Guide v1.1, 2023.

4. Hubject GmbH — V2G PKI Root CA Certificate Policy v2.3, 2023.

5. Mühlenfeld, J. et al. — "Security analysis of ISO 15118 Plug and Charge implementations." SAE Technical Paper 2022-01-0457, 2022.

6. NIST SP 800-57 Part 1 Rev. 5 — Recommendation for Key Management, 2020.

7. Secure Open Smart Charging Protocol (OSCP) working group — PnC Interoperability Test Specification v1.0, CharIN, 2023.

8. ACEA — "ISO 15118 deployment status: European OEM readiness survey," 2024.