Skip to main content
Back to Blog
engineeringMarch 15, 2026

Plug & Charge (ISO 15118): How EV Authentication Without RFID Works

Plug & Charge explained — how ISO 15118 lets EVs authenticate automatically. Certificate chain, contract certs, and OCPP integration.

At a glance

Plug & Charge is not only a better driver experience. It is a PKI, backend, charger, and commercial coordination project that should be piloted only when the ecosystem dependencies are in place.

CPO platform and roaming teamsEV charging infrastructure architectsTeams evaluating Plug and Charge rollout
  • Plug & Charge readiness depends on charger hardware, OEM support, PKI trust, and backend integration at the same time.
  • The hardest part is usually ecosystem coordination, not the handshake itself.
  • Teams should start with a controlled pilot and explicit readiness criteria.
  • Backend support should be evaluated together with certificate operations and roaming/commercial ownership.
Y
Yacine El Azrak
Co-founder & CEO
7 min read

Plug and Charge is a coordination project, not just a protocol feature

Plug & Charge is easy to like because the user experience is obvious.

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 is exactly what it sounds like: the driver plugs in the cable, and charging starts automatically. No app, no RFID card, no QR code. The vehicle and charger handle authentication and billing without any human interaction.

This is defined in ISO 15118, the international standard for vehicle-to-grid communication. Specifically, ISO 15118-2 (the current version) and ISO 15118-20 (the next generation).

Why it matters

Every extra step between "I want to charge" and "my car is charging" loses users. Today's typical flow:

  1. Find a charger
  2. Open the app
  3. Log in (or create an account)
  4. Select the connector
  5. Tap "Start"
  6. Wait for authorization
  7. Plug in

With Plug & Charge, it's:

  1. 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 it works: the certificate chain

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.

┌─────────────────────────────────────────────────────────┐
│                    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 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."

The Plug & Charge handshake

When you plug in a cable, here's what happens in milliseconds:

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.

Contract certificate installation

How does the contract certificate get into the vehicle? There are two methods:

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:

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 includes specific messages for Plug & Charge support:

Certificate management:

  • InstallCertificate — install V2G root or MO root certificates on the charger
  • DeleteCertificate — remove expired or revoked certificates
  • GetInstalledCertificateIds — list all certificates on the charger

Contract certificate provisioning:

  • Get15118EVCertificate — charger requests a new contract certificate on behalf of the vehicle
  • SignCertificate / CertificateSigned — CSR-based certificate enrollment

Authorization:

  • Authorize with idToken.type = "eMAID" — the charger sends the vehicle's eMAID (e-Mobility Account Identifier) to the backend for authorization

The OCPP flow looks like this:

EV ──► Charger                     CSMS (Backend)
          │                               │
          │── Authorize(eMAID) ──────────►│
          │                               │
          │   Backend validates the       │
          │   contract against the eMSP   │
          │                               │
          │◄── AuthorizeResponse ────────│
          │    (Accepted)                 │
          │                               │
          │── TransactionEvent ─────────►│
          │   (Started)                   │

Current adoption challenges

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. Cross-root trust is still being standardized.

Cost. Hardware-side, chargers need ISO 15118 compliant communication boards. Software-side, the PKI integration adds complexity.

Launch dependencies you must align

Before pilot, make sure each dependency has an owner:

  1. Charger readiness Which charger models and firmware versions are actually certified and field-proven?
  2. PKI trust chain Who installs and manages V2G Root, MO, and CPO trust material?
  3. Certificate provisioning Which service issues contract certificates, and how is failure handled?
  4. Backend authorization How is the eMAID resolved, authorized, logged, and reconciled?
  5. Commercial ownership Which team owns the customer, contract, and roaming relationship behind the certificate?
  6. 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.

ISO 15118-20: What's next

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:

  • V2G certificate management — install and manage V2G Root CA and MO certificates on your chargers
  • Contract certificate provisioning — handle Get15118EVCertificate requests 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.

Readiness checklist before pilot

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, continue with:

  1. OCPP security profiles explained for certificate and trust-layer planning.
  2. OCPI roaming guide if customer, contract, and interoperability workflows are also in scope.
  3. Talk to EV Cloud if your team needs help shaping a controlled pilot and backend readiness plan.
Previous
OCPP Charging Profiles 0, 1, 2, 3: The Complete Breakdown
Next
When to Add an OCPP Gateway Before Replacing Your CPMS

Frequently asked questions

Short answers for operators evaluating this topic in production.

Continue evaluation

Turn this topic into a buying decision

Use these pages to move from protocol research into shortlist design, migration planning, and commercial evaluation.

Scorecard

OCPP platform scorecard

Score vendors on migration path, data ownership, roaming readiness, and lock-in risk.

Buyer guide

How to evaluate an OCPP platform

Use a practical scorecard for protocol support, migration safety, and lock-in risk.

Architecture

OCPP gateway vs full CPMS replacement

Decide when a gateway-first architecture is safer than a full platform swap.

From content to rollout

Need help applying this in a live EV charging stack?

EV Cloud helps operators connect chargers, roaming partners, and internal platforms without rewriting their entire backend. Use the guide above for strategy, then use the product pages below for rollout planning.

Start free trialTalk to EV Cloud

Related posts

OCPP Security Profiles Explained: Securing Your EV Charging Network
engineering·February 5, 2026·6 min read

OCPP Security Profiles Explained: Securing Your EV Charging Network

OCPP security profiles 1, 2, 3 explained — basic auth, mutual TLS, signed firmware. Which profile fits your deployment.

Y
Yacine El Azrak
OCPI vs OCPP: What's the Difference and When to Use Each
ev-charging·March 5, 2026·5 min read

OCPI vs OCPP: What's the Difference and When to Use Each

OCPP vs OCPI — what each protocol does, how they interact, and when CPOs and eMSPs need them. Clear comparison with decision matrix.

Y
Yacine El Azrak
Introducing EV Cloud: The Universal OCPP Bridge
product·March 1, 2026·2 min read

Introducing EV Cloud: The Universal OCPP Bridge

Today we're launching EV Cloud — infrastructure that connects any EV charger to any CPMS without code changes, lock-in, or protocol translation headaches.

Y
Yacine El Azrak