Plug and Charge is the feature description - plug in and start charging, no app, no card, no tap. ISO 15118 is the standard that actually makes it possible, and it's a different layer of the stack than OCPP entirely. Confusing the two is a common source of overpromising what a given piece of hardware or software can actually deliver.
ISO 15118 vs. OCPP: two different conversations
OCPP is the protocol between the charger and the CSMS - it's how the platform knows a charger's status and controls a session. ISO 15118 is the protocol between the vehicle and the charger - it's how the car and the charger identify each other, negotiate charging parameters, and exchange the security certificates that authorize a session without a driver doing anything manually. A charger can be fully OCPP compliant with no ISO 15118 support at all, and vice versa - they solve different problems and neither one implies the other.
Plug and Charge vs. Autocharge: not the same thing
| Plug and Charge (ISO 15118) | Autocharge | |
|---|---|---|
| How the vehicle is identified | Digital certificate exchanged over the ISO 15118 communication channel | The vehicle's MAC address or VIN, matched against a pre-registered list |
| Security model | PKI-based, certificate-signed - built for payment-grade trust | No cryptographic verification - relies on the identifier not being spoofed |
| Standardization | A published ISO standard, implemented consistently across compliant hardware | An informal industry workaround, implemented differently by different vendors |
Autocharge emerged as a stopgap before ISO 15118 support was widespread, and it's still common in the field - but it's worth knowing it's not the standardized, security-audited mechanism that Plug and Charge is, when a vendor uses “plug and charge” as a loose marketing term rather than the specific ISO 15118 feature.
What ISO 15118 actually requires to work end to end
- Vehicle support. The car's onboard communication controller must implement ISO 15118, not just be electrically compatible with the connector - a growing but still incomplete share of EVs on the road today support it.
- Charger support. The charger's hardware and firmware need to implement the ISO 15118 communication stack, which is a different (and newer) requirement than basic OCPP compliance.
- A certificate infrastructure. Contract certificates tying a vehicle to a payment method or account have to be provisioned and trusted by the charging network - typically through a V2G root certificate authority the CPO's platform participates in.
- CSMS-side support for the resulting authorization. Once the vehicle and charger complete the ISO 15118 handshake, the CSMS still needs to receive and act on that authorization the same way it would an RFID tap or app-initiated start.
All four pieces have to be in place - a Plug and Charge-capable vehicle at a charger that doesn't support ISO 15118 falls back to whatever authorization method is available, same as the reverse.
Why this matters beyond driver convenience
Removing the app-or-card step doesn't just improve the driver experience, it removes a real source of failed-start sessions - a driver who can't get an app to load or a card to read is a session that doesn't happen, which shows up directly in the session-success-rate metric covered in charger uptime and reliability metrics. For roaming scenarios specifically, ISO 15118's certificate-based identity is also what makes cross-network authorization cleaner - see what OCPI does for EV roaming for how that pairs with a driver charging on a partner network.
Where adoption actually stands
ISO 15118 support is real and shipping, but it is not yet universal across either vehicles or charging hardware - treat any specific vehicle or charger's support as something to verify against current manufacturer specifications rather than assumed. A CSMS built to accept ISO 15118 authorization when it's available, while still supporting RFID and app-based starts as the fallback, is the realistic state of the market rather than betting a whole network on Plug and Charge alone.
See how CarChargeOS handles authorization methods, including Plug and Charge alongside RFID and app-based starts, on the platform page.
Frequently asked questions
Do I need ISO 15118 to offer Plug and Charge today?
Yes - Plug and Charge specifically refers to the ISO 15118 mechanism. Vehicle-matching approaches like Autocharge can offer a similar driver experience without it, but aren't the same standardized, certificate-secured feature.
Does ISO 15118 replace OCPP?
No - they operate on different links in the chain. ISO 15118 governs vehicle-to-charger communication; OCPP governs charger-to-CSMS communication. A platform needs OCPP regardless of whether it also supports ISO 15118.
What happens if a Plug and Charge-capable car plugs into a charger without ISO 15118 support?
The session falls back to whatever authorization method the charger does support - typically RFID or an app-initiated start - rather than failing outright.