ISO 15118 is the standard that defines how EVs and chargers talk to each other (coming soon). It has two editions in active use: ISO 15118-2 (published 2014) and ISO 15118-20 (published 2022). The two are distinct enough that they’re often called “Edition 1” and “Edition 2” informally, even though the numbering doesn’t suggest that relationship.
This article compares the two. What each can do, where the differences matter, and how adoption is playing out in 2026.
What 15118-2 delivers
ISO 15118-2 is the standard most current Plug & Charge deployments use.
Capabilities:
- Plug & Charge for AC and DC charging.
- Certificate-based mutual authentication between vehicle and charger.
- One-direction power flow (vehicle as energy load).
- Charging schedule negotiation (basic).
- TLS-based secure communication over PLC (powerline communication) carried on the CCS pilot pin.
- Message format: XML-based (specifically SOAP-style XML).
What it does NOT cover:
- Bidirectional power flow (no V2G, no V2H).
- Wireless charging.
- Modern scheduling primitives.
- Compact wire format (XML is verbose).
Deployment: Most production PnC in 2026 is 15118-2. Tesla, IONITY, Electrify America, Fastned, and most other major networks use it. Vehicle support is broad across the Volkswagen Group, Ford (some models), Mercedes, Lucid, Porsche, etc.
What 15118-20 adds
ISO 15118-20 is the newer edition. It builds on 15118-2’s foundation and adds:
Bidirectional power flow. The big one. 15118-20 explicitly supports power flowing from the vehicle to the grid or to a building. The protocol models V2G, V2H, and V2L (coming soon) with proper schedule and tariff support.
Wireless charging. Inductive charging gets first-class protocol support — identification, authentication, energy negotiation all work the same way as plugged charging.
Scheduled charging. The vehicle and charger can negotiate energy delivery over a schedule (“deliver 25 kWh by 7am, you choose when between now and then”). 15118-2 had basic scheduling; 15118-20 makes it much more powerful and grid-aware.
Smart charging integration. Tighter alignment with OCPP 2.0.1’s smart charging primitives (coming soon). The OCPI 2.3 ChargingProfiles module is designed to map cleanly to 15118-20 scheduling.
Efficient encoding. Messages use EXI (Efficient XML Interchange) — a compact binary form. Significantly faster and lower-bandwidth than 15118-2’s plain XML.
Updated security. Refined certificate flows, better handling of certificate lifecycle, improved cipher choices.
Energy services framework. The protocol can express different “energy services” beyond simple charging — V2G, V2H, dynamic load balancing, renewable preference, etc.
The protocol-stack comparison
Both editions sit on the same physical layer (CCS pilot pin) and use the same lower-level transport (HomePlug GreenPHY for the PLC).
[ Application: PnC, V2G, scheduling ]
[ 15118-2 messages (XML) | 15118-20 messages (EXI/binary) ]
[ V2GTP transport (TLS over TCP) ]
[ HomePlug GreenPHY (powerline communication on the pilot pin) ]The lower layers are identical. The difference is at the message and application layers.
Because the transport is shared, a vehicle and charger negotiate the highest edition they both support at session start, then fall back if they don’t match:
flowchart TD
A[Plug in] --> B{Both support<br/>15118-20?}
B -->|Yes| C[Use 15118-20<br/>V2G, wireless, EXI]
B -->|No| D{Both support<br/>15118-2?}
D -->|Yes| E[Use 15118-2<br/>one-way PnC]
D -->|No| F[Fall back to<br/>IEC 61851 signaling]
style C fill:#d4f4dd,stroke:#2e7d32
style E fill:#e3f2fd,stroke:#1565c0The vehicle and charger only use 15118-20 features when both sides support that edition.
What this means for the user experience
For an EV owner, the immediate difference is invisible. Plug & Charge feels the same whether the underlying protocol is 15118-2 or 15118-20.
The differences become visible in:
V2G/V2H availability. If you want to discharge your car back to the grid or home, your vehicle and charger both need 15118-20. A 15118-2 vehicle on a 15118-2 charger can’t do this no matter what other infrastructure is in place.
Wireless charging. If wireless charging becomes available in your area, 15118-20 is the standard that enables it. 15118-2 wireless charging isn’t a thing.
Scheduling sophistication. Smart charging that optimizes against tariff signals and grid conditions works better with 15118-20.
For the next several years, most EV owners’ practical experience will be on 15118-2. The 15118-20-specific features will roll out gradually as hardware refreshes.
Hardware reality in 2026
A snapshot of where things actually stand.
Vehicles with 15118-20 support:
- Ford F-150 Lightning (V2H-capable via the Charge Station Pro setup).
- Hyundai Ioniq 5/6, Kia EV6/EV9, Genesis GV60 (E-GMP platform with some 15118-20 features via firmware updates).
- Some Volkswagen Group models with bidirectional-charging firmware.
- Several Chinese-market EVs.
- A growing list as 2026-2028 model years roll out.
Most current EVs do NOT support 15118-20. They support 15118-2 (if PnC is enabled).
Chargers with 15118-20 support:
- Wallbox Quasar 2 (residential bidirectional).
- dcbel (residential V2G).
- Ford Charge Station Pro / Home Integration System (for F-150 Lightning).
- Some Wallbox Pulsar Plus units (with firmware updates).
- Most commercial DC fast chargers do NOT yet support 15118-20 V2G — the certification and grid-interconnection work is significant.
Networks with V2G via 15118-20 in commercial deployment:
- A small number of pilot programs (Octopus Energy in the UK, some California demand-response pilots, parts of Texas, several European grid-services programs).
- Broad commercial V2G is 1-3 years out for most markets.
The gap between “standard exists” and “real-world deployment” is years, sometimes a decade. This is normal for major protocol upgrades.
Migration considerations
If you’re operating chargers or building software that integrates with 15118:
For DC fast charger operators: continue with 15118-2 for now. Plan a 15118-20 firmware roadmap for 2027-2028 as your hardware suppliers ship support. Don’t rush 15118-20 rollout unless you have a specific V2G commercial partnership.
For residential V2H/V2G installers: 15118-20 is the future-aligned choice. Wallbox Quasar 2, dcbel, and similar all use 15118-20. Install with this in mind.
For CSMS developers: support both. Most of your fleet will be 15118-2 for years; some new chargers will be 15118-20. Your back-end should handle both message families.
For vehicle OEMs: 15118-20 should be in the 2027+ roadmap. Earlier if you have V2G or wireless charging ambitions. Backward compatibility with 15118-2 is essential.
The certificate angle
A few notes on the certificate world, which is part of both editions but evolved.
15118-2 uses a defined certificate hierarchy (coming soon) (V2G root → manufacturer → vehicle / mobility operator → contract certificate). This works well for current PnC.
15118-20 refines certificate lifecycle handling — better install/update/revoke flows, clearer separation of contract certificates and energy-service certificates, more flexibility in PKI structure.
Operators with mature 15118-2 PKI deployments will need to extend (not replace) their PKI for 15118-20. The roots may be the same; the operational tooling needs updates.
The XML-to-EXI shift
A technical detail worth mentioning.
15118-2 uses XML messages. A typical PnC exchange has many XML round-trips. Each XML message is verbose — hundreds of bytes for simple operations. The PLC bandwidth is limited (a few hundred kbps over the pilot pin), so XML transit time is a real constraint. Some Plug & Charge sessions take 30-60 seconds from plug-in to start-of-charging mostly because of XML overhead.
15118-20 uses EXI (Efficient XML Interchange) (coming soon) — a binary encoding of XML. The same logical message takes a fraction of the bytes. Session establishment is meaningfully faster.
For the user this might mean Plug & Charge sessions start in 10-15 seconds instead of 30-60. Significant in user experience even if the underlying protocol is conceptually similar.
What if I’m building 15118 today?
Practical advice for engineers working on either side of the protocol:
- Implement 15118-2 first. That’s the deployed reality. Get PnC working with the major networks.
- Plan 15118-20 second. When your product roadmap calls for V2G, wireless, or scheduling sophistication, that’s when 15118-20 becomes essential.
- Use the open-source SDKs where appropriate. EVerest, RISE-V2G, and similar open-source projects implement 15118-2 (and increasingly 15118-20). Saves you from rewriting the protocol from scratch.
- Test against multiple partners. PKI interoperability is the part that bites — your code may work with one root and break with another. Test broadly.
- Treat certificate management as a serious operational concern. It’s not “configure once and forget” — certificates expire, get revoked, need to be renewed. Build the operational tooling.
The honest summary
ISO 15118-2 is what’s deployed and works well for what it was designed for: one-direction Plug & Charge. ISO 15118-20 is the future, adding bidirectional charging, wireless charging, sophisticated scheduling, and more efficient encoding. Both will coexist for years. If you’re a user, you mostly don’t see the difference. If you’re a builder, you need both — 15118-2 for the current fleet, 15118-20 for the emerging capabilities.