What Is ISO 15118? Plug & Charge Explained Simply

ISO 15118 is the international standard that defines how an electric vehicle and a charging station talk to each other. It’s the technology that makes “Plug & Charge” possible — plug the cable in, the car identifies itself, billing starts, and you walk away. No card, no app, no fumbling.

The standard has been around for a while (the first edition in 2014), but real-world Plug & Charge deployment is only recently becoming mainstream. This article explains what ISO 15118 actually does, how Plug & Charge works, and where the standard fits in the broader EV charging stack.

The basic idea

When you plug an EV into a charging station, several things need to happen:

1. The car and charger need to physically connect (the plug).
2. They need to electrically agree on what’s possible (voltage, current, AC or DC).
3. The user needs to authenticate (am I allowed to charge here?).
4. Billing needs to happen (someone is paying for this electricity).
5. Energy needs to flow safely (monitoring, limiting, stopping).

ISO 15118 covers steps 2-4 (and provides the framework for 5). Before ISO 15118, these steps were a mix of low-level electrical signaling (the basic pilot pin) and out-of-band user interaction (RFID card, mobile app). ISO 15118 enables the vehicle and charger to handle them automatically over a richer communication channel.

The protocol stack, simplified

ISO 15118 sits in a layered stack:

[ Application: Plug & Charge, V2G, smart charging ]
[ ISO 15118-2 or 15118-20 messages              ]
[ V2GTP transport (TLS over TCP)                ]
[ HomePlug GreenPHY (powerline communication)   ]
[ The same pilot pin used for basic signaling   ]

The clever bit at the bottom: ISO 15118 communication runs over the CCS connector’s ^{(coming soon)} existing pilot pin. The same wire used for low-level signaling (IEC 61851) carries higher-frequency PLC (powerline communication) for the richer ISO 15118 protocol. No extra physical wires needed — the connector you’ve been using all along just acquired a new capability.

What “Plug & Charge” actually does

Imagine you pull up to a charging station with your EV. With Plug & Charge:

1. You plug the cable in. That’s the only physical action.
2. Behind the scenes, your car and the charger establish a secure connection.
3. The car presents a digital certificate that identifies you / your charging contract.
4. The charger sends that certificate to its back-end, which forwards to your charging network (your “eMSP”).
5. Your eMSP confirms the contract is valid and authorizes charging.
6. The charger starts charging.
7. Total elapsed time: 5-15 seconds, all invisible to you.

Compare to the non-PnC flow:

1. Plug in.
2. Pull out RFID card and tap.
3. Wait for the charger to recognize it.
4. Charger queries the back-end, validates, authorizes.
5. Charging starts.

PnC removes the card-tapping step. That’s all it does, on the surface. But under the hood it requires a sophisticated certificate-based identity system because the vehicle is presenting cryptographic credentials, not just an RFID number.

The certificate world

This is where ISO 15118 gets technical. Plug & Charge runs on a hierarchy of digital certificates. There are three main ones to know about.

The contract certificate. Installed on the vehicle. Represents the user’s charging contract with their eMSP. When the car presents this to a charger, the charger forwards it through the back-end stack and the certificate proves who’s paying for this session.

The OEM provisioning certificate. Installed by the vehicle manufacturer at the factory. Used to bootstrap trust — the vehicle proves it’s a genuine vehicle from manufacturer X, which allows the contract certificate to be installed later.

The charger certificate. Each charger has its own certificate. Vehicle uses it to verify the charger is legitimate (you don’t want to give your contract certificate to a rogue charger).

These certificates are issued by Certificate Authorities (CAs). Several CAs operate in the EV space — Hubject’s “EUROPE” PKI is widely used, V2G Root operated by other entities, manufacturer-specific roots for OEM provisioning, etc. The CA landscape is one of the trickier operational aspects of running PnC.

Why this is more secure than RFID

A short list of why certificates beat RFID for authentication.

• RFID can be cloned. A skilled attacker with a card reader can copy an RFID card’s number. Cryptographic certificates can’t be cloned without access to the private key, which the vehicle keeps secure.
• Certificates are revocable. If a vehicle is stolen or a contract is cancelled, the contract certificate can be revoked centrally. RFID is harder to revoke — you have to depend on every charger’s deny-list being current.
• Certificates are mutual. The vehicle authenticates the charger and the charger authenticates the vehicle. RFID is one-way (charger reads card; card has no way to verify the charger).
• Certificates are bound to a specific vehicle. The contract certificate is provisioned to a specific vehicle’s secure storage. Tying a contract to a vehicle (not a card the user holds) prevents some categories of fraud.

In practice, both RFID and PnC are “good enough” for normal use. PnC’s security advantages are real but usually not the reason it gets adopted — convenience is.

The two editions: 15118-2 and 15118-20

ISO 15118-2 (2014)

The first widely-deployed edition. Covers:

• Plug & Charge for AC and DC charging.
• Certificate-based authentication.
• The XML-based message format (verbose by modern standards).
• One-direction power flow (vehicle as load).

Most current PnC deployments use 15118-2. If you’ve used Plug & Charge in 2025-2026, it was almost certainly 15118-2.

ISO 15118-20 (2022)

The evolution. Adds:

• Bidirectional power flow. Foundation for V2G and V2H — the vehicle can act as a generator, sending power back to the grid or to a building.
• Wireless charging support. Inductive charging with all the same identification and authentication semantics.
• Better scheduling. More granular control over when and how much to charge.
• More efficient encoding. The XML messages from 15118-2 became more compact in 15118-20.
• Refined security. Updated certificate flows.

Adoption is just starting. Most vehicles with V2G ambitions (Ford Lightning, Hyundai/Kia E-GMP platform, the new Tesla bidirectional capable models) require 15118-20 support to actually do V2G into a grid-services context. Charger support is also early — most current DC chargers in the field are 15118-2 only.

A common mental model: 15118-2 is “Plug & Charge done”; 15118-20 is “Plug & Charge plus V2G plus wireless plus modernization.”

Where ISO 15118 sits in the broader stack

ISO 15118 is one layer in a stack that includes other protocols.

[ End user / OEM ]
       |
[ Vehicle <-- ISO 15118 --> Charger <-- OCPP --> CSMS <-- OCPI --> Roaming partners ]
       |                                            |
   [ Physical: CCS pilot pin, PLC, contactors ]   [ Billing, app, ops ]

• ISO 15118: vehicle-to-charger. Authentication, energy management, certificates.
• OCPP: charger-to-CSMS. Operations, configuration, transactions.
• OCPI: CSMS-to-eMSP / roaming. Authorization queries, session and CDR exchange.

In a Plug & Charge session, all three of these protocols participate. The vehicle presents its certificate to the charger (ISO 15118). The charger sends an Authorize request to its CSMS (OCPP). The CSMS asks the appropriate eMSP whether this contract is valid (OCPI). The answer flows back the same way.

sequenceDiagram
    participant V as Vehicle
    participant C as Charger
    participant S as CSMS
    participant E as eMSP
    V->>C: Present contract cert<br/>(ISO 15118)
    C->>S: Authorize request<br/>(OCPP)
    S->>E: Validate contract<br/>(OCPI)
    E-->>S: Contract valid
    S-->>C: Authorized
    C-->>V: Start charging

The reality of PnC adoption in 2026

A few honest observations.

Coverage is uneven. A user with a PnC-capable car may have PnC work on some networks (Electrify America, EVgo, ChargePoint, IONITY, Fastned, some Tesla third-party stalls) and not others. The coverage map is improving but is not yet “PnC works everywhere.”

Manufacturer matters. Tesla, Porsche, Mercedes-EQ, Lucid, and some Ford models have shipping PnC. Volkswagen Group beyond Audi is patchy. Japanese and Korean automakers have been slower. Adoption is accelerating but uneven.

Onboarding friction is real. Setting up PnC involves the user signing up for a charging contract with an eMSP, having the contract certificate provisioned to their vehicle, and the vehicle being capable of using it. Many users never go through this setup, even if their car supports it.

Network politics are a factor. A given network may favor its own PnC roots over a “neutral” PKI. Cross-network PnC sometimes requires multiple contract certificates installed on the vehicle, one per network. This is solvable but not always solved.

The user experience when it works is excellent. Plug in, walk away, get billed. The complexity is all hidden. When PnC works, it’s the best EV charging UX there is.

Why ISO 15118 matters even if you don’t drive an EV

For the EV ecosystem, ISO 15118 is foundational because:

• It’s the standard that enables V2G. Real bidirectional charging at scale requires 15118-20.
• It’s the trust layer for high-value automation. As more of the charging experience becomes automated (autonomous vehicle robotaxis, fleet operations, smart grid integration), certificate-based identity becomes essential.
• It’s the protocol that brings vehicle and charger into a real conversation, not just “I am here, give me power.” That enables a whole class of features (scheduling, tariff communication, dynamic limits) that simpler protocols can’t.

The protocols you use as a daily EV driver (CCS, OCPP, the charging network’s app) all rest on ISO 15118’s foundation, even when you don’t see it directly.

What to learn next

If you’re starting from this overview:

• A deep comparison of ISO 15118-2 vs ISO 15118-20 ^{(coming soon)} explains the differences in detail.
• The OCPI vs OCPP vs ISO 15118 explainer fits this into the bigger protocol picture.
• The OCPP article covers how the charger talks to its back-end, which is the next layer up from ISO 15118.

If you’re building software in this space, the practical advice is: support 15118-2 well first (that’s what’s deployed), design for 15118-20 (it’s the future), and don’t underestimate the certificate-infrastructure complexity. PKI is the part of ISO 15118 that breaks most often in production.