ISO 15118 describes an application-layer communication standard between an EV and an EVSE — what happens over the CAN-to-PLC connection once the cable is plugged in. Its most visible application is Plug&Charge (PnC): the vehicle authenticates automatically using an X.509 certificate provisioned to the vehicle's onboard system, without requiring the driver to tap a card or open an app. For CPOs, the infrastructure readiness question isn't just "does my charger support 15118?" — it's whether the full certificate chain, key management, and OCPP integration needed to validate a Plug&Charge transaction is operational.
This post covers what ISO 15118 Plug&Charge actually requires from the CPO infrastructure side, where the certificate management complexity lives, and what "network-ready" realistically means for operators preparing for the OEM rollout currently underway.
ISO 15118: Two Parts That Matter for CPOs
ISO 15118 covers more than authentication. It also defines the communication protocol for AC and DC charging parameter negotiation, and it provides the transport-layer foundation for future V2G (vehicle-to-grid) bidirectional energy exchange. For CPOs in the near term, the relevant subset is Part 2 (AC and DC charging with ISO 15118-2) and the emerging Part 20 (advanced DC charging, including bidirectional capabilities).
ISO 15118-2 defines Plug&Charge authentication via the Contract Certificate workflow. The vehicle carries a Contract Certificate issued by a Certificate Provisioning Service (CPS) — typically managed by the OEM or a mobility service provider like Hubject's eMSP certificate infrastructure. The EVSE validates the Contract Certificate against a root certificate chain during the PaymentDetailsReq exchange over the HLC (High-Level Communication) link. If validation succeeds, the session is authorized without any driver action.
The CPO infrastructure piece is: the EVSE needs to have the correct root certificates loaded, and the certificate validation result needs to propagate back to the CPMS for authorization recording and billing.
The Certificate Chain Architecture
ISO 15118 Plug&Charge uses a layered public key infrastructure. At the top is the V2G Root Certificate Authority — in the Hubject-operated PKI (the most widely deployed PnC infrastructure in Europe and increasingly in North America), this is the V2G Root CA whose root certificate must be present on every EVSE that wants to validate PnC sessions. Below that are Sub-CAs, OEM Provisioning Certificate Authorities, and the individual Contract Certificates provisioned to vehicles.
For a CPO, the practical implication is: every charge point in the network needs to have the current V2G root certificate (and relevant sub-CA certificates) loaded in its trust store. OCPP 2.0.1 provides the InstallCertificate.req message for this purpose — the CPMS can push certificate updates to chargers. But this requires that the charger hardware and firmware actually support OCPP 2.0.1 Security Profile 3 (the profile that enables certificate management), and that the CPMS has a certificate lifecycle management workflow — monitoring certificate expiry dates, staging updated certificates, and pushing them to the fleet before expiry.
Certificate expiry on deployed infrastructure is a genuine operational risk. If the V2G Sub-CA certificate on a charger expires and the CPMS doesn't push an updated certificate in time, PnC sessions on that charger will fail — the vehicle will present a valid Contract Certificate, but the charger won't be able to validate the chain. The fallback is typically to another authentication method (RFID or app), but this defeats the PnC user experience and creates driver friction that's hard to diagnose at scale.
OCPP Integration: How PnC Connects to Your CPMS
In an OCPP 2.0.1 deployment, the ISO 15118 Plug&Charge authentication result flows back to the CPMS via the Authorize.req message. The charger includes the Contract Certificate (or a hash of it) in the authorization request, and the CPMS validates it against the certificate chain or delegates validation to a connected certificate validation service. The CPMS then responds with authorization status and, in some architectures, with a session pricing profile to apply.
Consider a CPO preparing for PnC on a 60-charger DC fast charging corridor deployed across 8 highway sites. All chargers are running OCPP 2.0.1 firmware with Security Profile 3 enabled. The CPMS needs to: maintain an updated V2G root certificate store, handle AuthorizeRequest messages containing ISO 15118 Certificate IDs (rather than RFID idTags), map those Certificate IDs to pricing tiers (the Contract Certificate identifies the driver's eMSP, which determines the applicable roaming or retail tariff), and ensure that failed PnC authentications fall back gracefully to the charger's RFID reader without session interruption.
The fallback behavior is particularly important. Not every driver approaching a 15118-capable charger will be in a PnC-capable vehicle. RFID and app-based authentication need to remain fully functional on the same charger. The charger firmware should support concurrent HLC and RFID session initiation, with the HLC path taking precedence if a valid Contract Certificate is presented.
Where OEM Support Currently Stands
ISO 15118 Plug&Charge vehicle-side support is rolling out, but it's not uniform across the OEM landscape. Several major OEMs have deployed ISO 15118-2 PnC support in recent model years, primarily on their DC fast charging-capable platforms. The rollout in North America has been slower than in Europe, partly because of different utility tariff structures and partly because RFID infrastructure maturity in Europe made the PnC migration path more natural.
We're not saying PnC readiness should be the top infrastructure priority for every CPO in 2025. For operators focused on residential and workplace L2 charging, PnC is a longer-horizon capability. For CPOs operating DC fast charging corridors where OEM-facing driver experience matters — particularly as vehicle OEMs compete on frictionless energy services — building PnC readiness into new deployments is materially less expensive than retrofitting it later.
What "Ready" Actually Requires
For a CPO to credibly claim Plug&Charge readiness for a network, the minimum infrastructure requirements are: OCPP 2.0.1 with Security Profile 3 deployed on hardware; CPMS with certificate management workflow (install, monitor, renew); V2G root and sub-CA certificates loaded on charge points and kept current; CPMS handling of ISO 15118 Certificate ID authorization requests; and a tested fallback to RFID/app when PnC authentication fails. Optionally, for CPOs participating in roaming, the OCPI token list should include Contract Certificate-based token entries so roaming eMSPs can pre-whitelist their certificates on the CPO's network.
The certificate management workflow is typically the item that requires the most platform-side development work for CPOs whose CPMS was built without PnC in mind. OCPP 2.0.1's certificate management messages provide the mechanism; building the operational workflow on top of them — expiry monitoring, rotation scheduling, automated push to field hardware — is platform engineering that most early OCPP implementations didn't prioritize.
ISO 15118 is not a single feature switch. It's a PKI management discipline applied to field hardware at scale. CPOs who understand that framing, and build their platform capabilities accordingly, will be positioned to deliver PnC without the operational surprises that certificate expiry events reliably produce for those who don't.