ISO 15118 & Plug and Charge: How EV Authentication Works

What Is ISO 15118?

ISO 15118 is the international standard that defines digital communication between an electric vehicle and a charging station — covering things like vehicle authentication, charging schedule negotiation, and (in later parts of the standard) bidirectional power flow for V2G. It's developed and maintained through the international standards process (ISO, with strong input from the automotive and charging industry, including CharIN as an industry alliance driving interoperability testing). ISO 15118 is what makes a feature like Plug & Charge possible — it is the "language" the vehicle and charger use to identify each other and authorize a session automatically, without a human tapping an RFID card or opening an app.

What Is Plug & Charge?

Plug & Charge is a specific application built on ISO 15118: when a compatible vehicle is plugged into a compatible charger, the vehicle presents a digital certificate over the ISO 15118 communication link, the charger and backend verify it through a public key infrastructure (PKI), and the charging session starts automatically — no card, app, or PIN required. The experience is often compared to how a Tesla Supercharger session starts automatically, because that is functionally the same idea, implemented through an open, cross-vendor standard rather than a single manufacturer's proprietary system.

How Certificate-Based Authentication Actually Works

At a high level, a Plug & Charge session follows this sequence:

Physical connection — the driver plugs the CCS connector into the vehicle inlet.
High-level communication (HLC) starts — the vehicle (EVCC, the EV communication controller) and the charger (SECC, the supply equipment communication controller) begin talking over the ISO 15118 data link embedded in the CCS connector's control pilot signal.
Certificate exchange — the vehicle presents its contract certificate, issued by its mobility service provider (eMSP) or vehicle manufacturer's PKI, identifying the customer's charging contract.
Verification — the charger passes the certificate up through the backend (CPO's system) to validate it against the relevant certificate authority chain, confirming the contract is valid and not revoked.
Authorization and session start — once verified, the charger authorizes the session and begins delivering power, with no manual authentication step from the driver.
Billing — the session is billed against the contract identified by the certificate, typically through the driver's existing agreement with their eMSP/OEM, not a separate charge-point-specific account.

ISO 15118 vs OCPP: Solving Different Problems

This distinction gets confused constantly, so it's worth stating plainly: ISO 15118 governs vehicle-to-charger communication. OCPP governs charger-to-backend communication. They sit on either side of the charging station and solve different halves of the problem.

	ISO 15118	OCPP
Connects	Vehicle ↔ Charger	Charger ↔ Backend (CSMS)
Primary role	Vehicle authentication, energy negotiation, V2G signaling	Remote monitoring, session management, firmware, smart charging, billing data flow
Enables Plug & Charge	Yes — this is where it happens	Carries the resulting authentication data to the backend (natively in OCPP 2.0.1)

For the charger-to-backend half of the picture, see our guide on OCPP 1.6J vs OCPP 2.0.1 — Plug & Charge data flows through natively only on OCPP 2.0.1, not OCPP 1.6.

ISO 15118 and CCS

ISO 15118's data communication is carried over the same physical connector used for CCS (Combined Charging System) DC fast charging — specifically, over the control pilot line already present in the CCS connector, using power-line communication. This is why Plug & Charge is discussed almost exclusively in the context of CCS-based DC fast charging rather than basic AC charging: the standard and the connector were developed in step with each other. For more on CCS2 specifically (the region-specific variant used in India, Europe and most non-Japanese, non-North American markets), see our guide on CCS2 vs CHAdeMO.

Benefits of Plug & Charge

Frictionless experience — no card, app, or PIN required at the charger
Reduced hardware dependency — fewer failure points tied to card readers or connectivity for app-based authorization
Stronger security than shared RFID cards — certificate-based authentication is cryptographically tied to the vehicle/contract, harder to clone or share than a physical card
Consistent cross-network experience — a properly provisioned contract certificate can work across any compatible CPO's network, in principle, without separate sign-ups

Limitations and Adoption Realities (Including India)

Plug & Charge is not yet universal, and there are real practical limits:

It requires the vehicle, the charger, and the backend PKI infrastructure to all support ISO 15118 and be properly provisioned with valid certificates — a gap in any one of the three means it won't work.
Certificate provisioning requires an operational relationship between the vehicle's certificate issuer (often the OEM or an eMSP) and the CPO's backend — this "roaming trust" infrastructure is still maturing globally.
In India specifically, Plug & Charge adoption is at an early stage: most currently deployed vehicles and public charging networks rely on RFID or app/QR-based authentication (both of which UFCL's platform also supports), and ISO 15118 support in vehicles sold in India today is limited. [NEEDS UFCL CONFIRMATION: current OEM-level ISO 15118/Plug & Charge support in vehicles sold in India, which is a fast-moving and vehicle-model-specific fact best sourced from UFCL's own market tracking rather than assumed.]
Autocharge is a useful interim step some networks and vehicles support — it uses the vehicle's MAC address (transmitted over the same physical layer) as a simplified, non-PKI identification method, giving a similar "just plug in" experience without the full certificate infrastructure. It is not as cryptographically robust as full Plug & Charge, but it is far simpler to deploy today.

Hardware and Backend Requirements

For a charger to support Plug & Charge, it generally needs:

Communication hardware and firmware capable of ISO 15118 high-level communication over the CCS control pilot line
OCPP 2.0.1 (or a version with native Plug & Charge support) on the charger-to-backend link, so authentication data reaches the CSMS correctly
A backend integrated with, or able to reach, the relevant PKI/certificate infrastructure to validate contract certificates
CCS2 connector hardware (in the Indian/European context), since Plug & Charge's data link rides on the CCS control pilot signal

Security Considerations

Because Plug & Charge relies on a PKI, its overall security depends on the integrity of that certificate infrastructure: certificate issuance, revocation, and the trust relationships between OEMs, eMSPs, and CPOs all need to be managed correctly. Done properly, certificate-based authentication is considered more resistant to cloning and account-sharing abuse than RFID cards. Done poorly (weak certificate lifecycle management, unrevoked compromised certificates), it introduces its own risks — which is why OCPP 2.0.1's built-in TLS transport security for the charger-to-backend link matters as a complementary layer, not a substitute.

Fleet Use Cases

For a captive fleet (a single operator's own vehicles charging at its own depot), Plug & Charge can simplify operations significantly: vehicles authenticate automatically at the depot without drivers needing individual RFID cards, and usage data ties directly to the vehicle/contract for cost allocation. Because the vehicle fleet and charging infrastructure are both controlled by the same organization, the PKI/roaming-trust complexity that slows public rollout is much easier to manage in a closed fleet environment.

Public Charging Use Cases

For public CPOs, Plug & Charge's value is the frictionless, app-free experience for drivers whose vehicle and mobility contract already support it — but until vehicle-side adoption is broader, most public networks (including in India) will continue running RFID and app/QR authentication as the primary methods, with Plug & Charge as an additional option on capable hardware rather than a replacement.

KEY TAKEAWAYS

ISO 15118 governs vehicle-to-charger communication; OCPP governs charger-to-backend communication — they are complementary, not competing, standards.
Plug & Charge uses ISO 15118's certificate-based authentication to start a charging session automatically, with no card, app, or PIN.
Plug & Charge requires alignment across vehicle, charger, and backend PKI — a gap in any one breaks the experience.
Autocharge is a simpler, non-PKI interim alternative some networks support today.
ISO 15118/CCS Plug & Charge data reaches the backend natively only via OCPP 2.0.1, not OCPP 1.6.
In India, RFID and app/QR authentication remain the practical default in 2026; Plug & Charge adoption is early-stage and tied to vehicle-side ISO 15118 support.

FAQS

Q1. What is Plug and Charge in EV charging? Plug & Charge is a feature, built on the ISO 15118 standard, that lets a compatible vehicle authenticate and start a charging session automatically using a digital certificate — no card, app, or PIN needed.

Q2. Is ISO 15118 the same as OCPP? No. ISO 15118 governs communication between the vehicle and the charger; OCPP governs communication between the charger and the backend management system. They work together but are separate standards.

Q3. Does Plug and Charge require a special connector? It relies on the communication link embedded in the CCS connector's control pilot line, so it's used in the context of CCS-based DC fast charging rather than basic AC charging.

Q4. Is Plug and Charge available in India today? Adoption is early-stage. Most public and fleet charging in India currently relies on RFID or app/QR-based authentication; Plug & Charge depends on vehicle-side ISO 15118 support, which is still limited across vehicles sold in India as of 2026.

Q5. What is the difference between Autocharge and Plug and Charge? Autocharge identifies a vehicle using its MAC address over the same physical communication layer, without a full PKI certificate exchange — simpler to deploy but less cryptographically robust than full Plug & Charge.

Q6. What does a charger need to support Plug and Charge? ISO 15118-capable communication hardware/firmware, OCPP 2.0.1 (for native backend data flow), CCS2 connector hardware, and backend integration with the relevant PKI/certificate infrastructure.

Q7. Is Plug and Charge secure? Certificate-based authentication is generally considered more resistant to cloning and sharing than RFID cards, provided the underlying PKI (certificate issuance and revocation) is properly managed.

Q8. Can fleets use Plug and Charge more easily than public networks? Yes — a captive fleet controls both its vehicles and its charging infrastructure, which simplifies the PKI/trust relationships needed, compared with the broader cross-operator roaming trust required for public networks.

Q9. Does OCPP 1.6J support Plug and Charge? Not natively. Plug & Charge/ISO 15118 data is natively carried to the backend under OCPP 2.0.1, not OCPP 1.6J.

Q10. Who governs the ISO 15118 standard? It is maintained through the international ISO standards process, with strong industry involvement including CharIN, the industry alliance focused on CCS/ISO 15118 interoperability testing.

CTA

Deploying chargers with Plug & Charge or Autocharge in mind? UFCL's DC fast chargers support ISO 15118, Autocharge, RFID and QR-based authentication — talk to UFCL's team about the right authentication mix for your site.