Plug & Charge is a coordination project, not just a protocol feature
Plug & Charge is a coordination project across hardware, PKI, backend, and commercial teams, not a single protocol switch you flip on. The handshake is the easy part. Getting every dependency ready at the same time is the hard part.
Plug & Charge is easy to like because the user experience is obvious. In practice, the sessions that fail in the field rarely fail on the cryptography. They fail because one link in the chain, a firmware version, a missing trust anchor, an unowned support path, was never validated before launch.
For deployers, the harder question is whether the surrounding ecosystem is ready:
- charger hardware and firmware
- backend authorization flow
- certificate provisioning
- roaming and commercial ownership
- support procedures when the certificate flow fails
That is why Plug & Charge should usually start as a controlled rollout decision, not a blanket product promise.
What is Plug & Charge?
Plug & Charge lets a driver plug in the cable and start charging automatically, with no app, RFID card, or QR code. The vehicle and charger authenticate each other and resolve billing without any human interaction, using digital certificates exchanged over the charging cable.
This is defined in ISO 15118, the international standard for vehicle-to-charger communication. Two versions matter for deployers today. ISO 15118-2 is the widely fielded version that introduced contract-based authentication. ISO 15118-20 is the next generation, adding bidirectional power and cleaner certificate handling. Authentication and billing identity ride on the certificate, so the driver never selects a connector or taps a card. The charger reads who the car is, asks the backend whether that contract is valid, and starts the session.
Why does Plug & Charge matter?
Plug & Charge matters because every extra step between intent and energy flow leaks users, and a contactless start removes almost all of those steps. Friction at the connector is one of the most common reasons a session never begins. Today's typical flow:
- Find a charger
- Open the app
- Log in (or create an account)
- Select the connector
- Tap "Start"
- Wait for authorization
- Plug in
With Plug & Charge, it's:
- Plug in
That's the entire user experience. Tesla has had this since day one on their Supercharger network. ISO 15118 makes it possible on any charger from any manufacturer.
How the certificate chain works
Plug & Charge trust flows down a certificate hierarchy: a single V2G Root CA anchors trust, two sub-CAs sign for the mobility and charging sides, and the leaf certificates live in the car and the charger. Each party validates the chain up to the shared root before energy flows.
Plug & Charge relies on a Public Key Infrastructure (PKI) — a hierarchy of digital certificates that establish trust between the vehicle, the charger, and the backend systems. Read the diagram below top to bottom: the root delegates to two sub-CAs, and each sub-CA issues one leaf certificate.
The chain has four roles. The table after the diagram restates the same hierarchy as text, which is useful if the ASCII art does not render in your reader.
┌─────────────────────────────────────────────────────────┐
│ V2G ROOT CA │
│ (Root of trust for the ecosystem) │
│ │
│ Operated by a trusted third party (e.g., Hubject) │
└───────────────┬──────────────────────┬──────────────────┘
│ │
┌─────────▼────────┐ ┌────────▼─────────┐
│ MO SUB-CA │ │ CPO SUB-CA │
│ (eMSP / Mobility│ │ (Charge Point │
│ Operator) │ │ Operator) │
└────────┬─────────┘ └────────┬─────────┘
│ │
┌─────────▼────────┐ ┌────────▼─────────┐
│ CONTRACT CERT │ │ SECC CERT │
│ (stored in the │ │ (installed on │
│ vehicle's EV │ │ the charger) │
│ Communication │ │ │
│ Controller) │ │ │
└──────────────────┘ └──────────────────┘
The same hierarchy, as a table:
| Certificate / CA | Issued by | Lives where | Proves |
|---|---|---|---|
| V2G Root CA | Self-signed trust anchor | Trust store of all parties | The root everyone agrees to trust |
| MO Sub-CA | V2G Root CA | eMSP / mobility operator | Authority to issue contract certs |
| CPO Sub-CA | V2G Root CA | Charge point operator | Authority to issue charger certs |
| Contract certificate | MO Sub-CA | Vehicle (EVCC) | This car belongs to a customer of eMSP X |
| SECC certificate | CPO Sub-CA | Charger (SECC) | This charger belongs to CPO Y |
The key players
V2G Root CA — The root certificate authority that anchors the entire trust chain. Everyone in the ecosystem trusts this root. Currently, Hubject operates the largest V2G Root CA.
MO Sub-CA (Mobility Operator) — The eMSP's intermediate certificate authority. Issues contract certificates for their customers' vehicles.
CPO Sub-CA — The charge point operator's intermediate CA. Issues SECC certificates for their chargers.
Contract Certificate — Stored in the vehicle. Proves "this car belongs to a customer of eMSP X." Contains the contract ID, expiry date, and the customer's public key.
SECC Certificate — Installed on the charger's Supply Equipment Communication Controller. Proves "this charger belongs to CPO Y."
What happens during the Plug & Charge handshake?
The handshake runs an eight-step exchange between car and charger: discover the link, open a mutually authenticated TLS session, present the contract certificate, validate it against the V2G root, and then negotiate power. The driver sees none of it.
When you plug in a cable, the sequence below runs in seconds. If the ASCII diagram does not render, read it as this ordered list: (1) the EV sends an SDP request and (2) the charger answers with its address and security protocol; (3) both sides complete a mutual-auth TLS handshake using their certificates; (4) the vehicle selects "Contract" as the payment method; (5) it sends its contract certificate chain; the charger validates that chain against the V2G Root CA; (6) authorization is granted; (7) the two negotiate charge parameters; and (8) power delivery starts.
EV (Vehicle) SECC (Charger)
│ │
│──── 1. SDP Request ────────────────────►│
│ │
│◄─── 2. SDP Response ───────────────────│
│ (charger's IP + security protocol) │
│ │
│──── 3. TLS Handshake ──────────────────►│
│ (mutual authentication using │
│ SECC cert + vehicle cert) │
│◄────────────────────────────────────────│
│ │
│──── 4. PaymentServiceSelection ────────►│
│ (vehicle selects "Contract") │
│ │
│──── 5. PaymentDetailsReq ──────────────►│
│ (sends Contract Certificate chain) │
│ │
│ ┌─────────────────────────────┐ │
│ │ Charger validates the │ │
│ │ contract cert chain against │ │
│ │ the V2G Root CA │ │
│ └─────────────────────────────┘ │
│ │
│◄─── 6. PaymentDetailsRes ──────────────│
│ (authorization granted) │
│ │
│──── 7. ChargeParameterDiscovery ───────►│
│ (voltage, current, energy needs) │
│ │
│──── 8. PowerDelivery (Start) ──────────►│
│ │
│ ⚡ CHARGING BEGINS ⚡ │
The entire handshake takes 2-5 seconds. The driver sees nothing — just the charging indicator turning on.
How does the contract certificate get into the vehicle?
The contract certificate reaches the vehicle in one of two ways: the OEM installs it at the factory and binds it to the VIN, or the car requests it over the air through a charger during a session. Factory install is simpler; over-the-air install is what lets drivers switch eMSPs later.
There are two methods, and the practical difference is who handles certificate renewal and contract switching.
Method 1: Factory installation
The OEM installs the certificate during manufacturing. The driver's eMSP contract is linked to the vehicle's VIN. This is how most automakers handle it today.
Method 2: Over-the-air installation
The vehicle requests a new contract certificate through the charger. In text, the request flows in one direction and the signed certificate returns along the same path: the EV asks the charger, the charger forwards to the CPO backend, the CPO backend calls the Certificate Provisioning Service (CPS), the CPS reaches the eMSP backend that generates the contract certificate, and the signed certificate then travels back through the CPO backend and charger to the car.
EV ──► Charger ──► CPO Backend ──► Certificate
Provisioning
Service (CPS)
│
▼
eMSP Backend
(generates
contract cert)
│
▼
EV ◄── Charger ◄── CPO Backend ◄── Signed
Contract
Certificate
This allows drivers to switch eMSPs or add new contracts without visiting a dealer.
How OCPP fits in
OCPP 2.0.1 carries Plug & Charge between the charger and the backend (CSMS) through a defined set of certificate-management, provisioning, and authorization messages. The ISO 15118 exchange happens on the cable; OCPP is how the charger asks your backend to install trust material, fetch contract certificates, and authorize the eMAID. For background on the protocol itself, see our OCPP guide.
The OCPP 2.0.1 specification includes specific messages for Plug & Charge support:
Certificate management:
InstallCertificate— install V2G root or MO root certificates on the chargerDeleteCertificate— remove expired or revoked certificatesGetInstalledCertificateIds— list all certificates on the charger
Contract certificate provisioning:
Get15118EVCertificate— charger requests a new contract certificate on behalf of the vehicleSignCertificate/CertificateSigned— CSR-based certificate enrollment
Authorization:
AuthorizewithidToken.type = "eMAID"— the charger sends the vehicle's eMAID (e-Mobility Account Identifier) to the backend for authorization
The OCPP flow looks like this. As text: the charger sends Authorize(eMAID) to the CSMS; the backend validates the contract against the eMSP; the CSMS replies with AuthorizeResponse (Accepted); and the charger then reports TransactionEvent (Started) once power begins.
EV ──► Charger CSMS (Backend)
│ │
│── Authorize(eMAID) ──────────►│
│ │
│ Backend validates the │
│ contract against the eMSP │
│ │
│◄── AuthorizeResponse ────────│
│ (Accepted) │
│ │
│── TransactionEvent ─────────►│
│ (Started) │
What blocks Plug & Charge adoption today?
Adoption is held back by uneven vehicle support, real PKI complexity, immature cross-root roaming trust, and hardware cost, not by the standard being unfinished. In mixed-fleet rollouts the failure usually shows up as a subset of cars that simply will not start a contract session, even though the chargers and backend are correct.
Vehicle support is limited. Not all EVs have ISO 15118-capable communication controllers. Many older vehicles only support ISO 15118-2 for basic communication, not the Plug & Charge feature.
PKI complexity. Setting up and managing the certificate infrastructure is non-trivial. You need relationships with a V2G Root CA, certificate provisioning services, and your roaming partners' PKI.
Roaming interoperability. Plug & Charge across different networks requires all parties to trust the same V2G Root CA, on top of the OCPI roaming connections between CPOs and eMSPs. Cross-root trust is still being standardized.
Cost. Hardware-side, chargers need ISO 15118-compliant communication boards. Software-side, the PKI integration adds complexity.
Which launch dependencies must you align?
Six dependencies need a named owner before a pilot is real: charger readiness, the PKI trust chain, certificate provisioning, backend authorization, commercial ownership, and support fallback. When a Plug & Charge pilot stalls, it is almost always because one of these six had no clear owner and quietly fell between teams.
Before pilot, make sure each dependency has an owner:
- Charger readiness Which charger models and firmware versions are actually certified and field-proven?
- PKI trust chain Who installs and manages V2G Root, MO, and CPO trust material?
- Certificate provisioning Which service issues contract certificates, and how is failure handled?
- Backend authorization How is the eMAID resolved, authorized, logged, and reconciled?
- Commercial ownership Which team owns the customer, contract, and roaming relationship behind the certificate?
- Support fallback What should the driver, field team, and support team do when Plug & Charge fails and RFID or app fallback is needed?
If those six items do not have owners, the pilot is not ready.
What does ISO 15118-20 add?
ISO 15118-20 extends the standard with bidirectional power, wireless charging support, streamlined certificate management, and richer pre-session pricing. For most operators, the practical near-term value is the cleaner provisioning flow and clearer tariff communication, while V2G remains a longer-horizon capability tied to grid and contract readiness.
The next generation standard adds:
- Bidirectional charging (V2G) — the vehicle can feed energy back to the grid
- Wireless charging support — Plug & Charge without the plug
- Improved certificate management — streamlined provisioning flows
- Better pricing transparency — detailed tariff communication before charging starts
How EV Cloud supports Plug & Charge
EV Cloud provides the OCPP-side infrastructure for Plug & Charge: certificate management on the charger, contract-certificate provisioning, eMAID authorization against roaming partners, and certificate lifecycle handling. The charger vendor owns the hardware and ISO 15118 stack; the backend coordination is where this work concentrates.
- V2G certificate management — install and manage V2G Root CA and MO certificates on your chargers
- Contract certificate provisioning — handle
Get15118EVCertificaterequests and route them to the CPS - eMAID authorization — validate contract certificates against roaming partner databases
- Certificate lifecycle — automated monitoring, renewal, and revocation
The charger hardware and ISO 15118 stack are the charger vendor's responsibility. EV Cloud handles everything on the backend.
What should you check before a pilot?
Validate one full path end to end before committing to rollout: one charger model, one backend authorization route with real contract data, an auditable trust chain, a defined fallback journey, a briefed support team, and aligned billing owners. We have found that teams who skip the fallback test are the ones who get caught when the first contract certificate is rejected in the field.
Use this before you commit to rollout:
- one charger model validated end to end
- one backend authorization path tested with real contract data
- trust chain installed and auditable
- fallback journey defined for failed authorizations
- support team briefed on expected failure modes
- roaming and billing owners aligned on post-session reconciliation
If the checklist is still incomplete, keep the project in pilot mode.
Next step for rollout teams
If Plug & Charge is on your roadmap, treat it as a backend and PKI readiness exercise first, then continue with:
- OCPP security profiles explained for certificate and trust-layer planning, building on the message-level detail in our OCPP 2.0.1 deep dive.
- OCPI roaming guide if customer, contract, and interoperability workflows are also in scope; see the OCPI overview for how contract identity moves between networks.
- Talk to EV Cloud if your team needs help shaping a controlled pilot and backend readiness plan.
