Jan Figgener, Senior Visiting Scientist at RWTH Aachen and co-organiser of the conference, opened with a moment of reflection. Five years ago, the industry was still debating when smart charging would arrive. Three years ago, it was asking when V2G would follow. “Today”, Figgener said, “we are already discussing concrete business models.” Es geht spürbar voran — it is noticeably advancing.

And it is. By day two, Mike Evans from Octopus Energy was on stage showing live customer discharge graphs dated 13–14 April: real vehicles, real customers, real kilowatt-hours flowing back to the grid. The live product is Octopus’s UK bundle (BYD vehicles on Zaptec Go2 chargers). Germany, where the Ford Explorer and Capri will connect to Ambibox DC wallboxes on the Kraken platform, was on the roadmap as the imminent next step. Not a distant announcement. A product already live in one market, with the German launch in the pipeline.

The same tension ran through every session across both days: the products are real; the infrastructure to support them at scale is not yet ready. The gap isn’t just smart meters and harmonised grid codes — major utilities haven’t yet built the billing logic, compliance workflows, and internal processes to operate V2G commercially. Five things from those two days are worth understanding properly:

• Why Germany’s headline V2G revenue figure of ~€700/year may differ sharply from what customers are currently receiving, and what the November 2025 double-taxation reform actually changed

• Why 250,000 discharge sessions is the current price of entry for a single car OEM to approve a V2G charger, and what that demand says about where ISO 15118-20 standardisation actually stands

• What Utrecht Energized’s €60-per-car-per-month result reveals about the difference between grid congestion contracts and frequency balancing markets

• Why at least one established DC V2G charger manufacturer has decided not to take DC to the mass market, and what the inverter economics argument rests on

• Why the gap between the marketed ~€700/year and the live customer experience isn’t just a communications problem — and what the industry risks if it doesn’t close it

Latest articles:

If you haven’t subscribed yet, here’s what was covered in the past weeks:

• How OCPP 2.1 and ISO 15118-20 enable V2G grid code implementations

• V2G grid codes - When your EV becomes a power plant

• Grid codes, decoded — The EU rules that are finally coming for EV chargers

Subscribe now

The commercial map: where V2G is live today

Europe’s V2G commercial timeline has moved faster than many expected, and the geography tells its own story.

France, October 2024: Mobilize, Renault Group’s energy services sub-brand, partnered with The Mobility House to launch the first commercial V2G service in Europe. Built around the Renault 5 using AC architecture, the service is also available for the Alpine A290. Revenue in France averages €30–40 per month per vehicle, as reported at the conference by Renault’s Alain Thoral.

Netherlands, June 2025: We Drive Solar launched Utrecht Energized, Europe’s first large-scale V2G car-sharing scheme. More than 200 Renault 5 vehicles now operate on 7kW AC bidirectional chargers in Utrecht, generating revenue from wholesale energy arbitrage and, uniquely, contracted grid congestion services. More on this project in a dedicated section below.

United Kingdom, August 2025: Octopus Energy, already the operator of the world’s largest EV virtual power plant with 370,000 vehicles on smart tariffs in Great Britain, launched a V2G programme bundled with BYD. Zaptec brought the Go2, the first commercially available AC V2G charger in the UK, to market at the same time.

Germany, September 2025: BMW and E.ON launched Germany’s first residential V2G offer at IAA Mobility, followed in February 2026 by the full commercial package: iX3, dedicated DC wallbox from Compleo, and energy tariff.

Germany, forthcoming: Mike Evans (Octopus Energy) presented the German PowerDrive V2G tariff at the conference, with Ford Explorer and Capri vehicles connecting through Ambibox DC wallboxes on the Kraken platform. The German launch is the imminent next step following the live UK product.

The day after the conference opened, pv magazine reported that Volkswagen had announced its own V2G product through its energy subsidiary Elli: a DC bidirectional wallbox, launching in Germany in Q4 2026. Volkswagen estimates savings and earnings of €700–900 per year for participating customers, with registration opening in June 2026 and the service expanding across Europe thereafter. The statistic that gives the launch real commercial weight: approximately one million MEB platform vehicles are already on European roads and technically capable of bidirectional charging. They are waiting for the wallbox and the tariff.

Mercedes-Benz, meanwhile, announced its own V2G product through The Mobility House, completing what looks like a German OEM clean sweep in Q1 2026.

One thing worth stating explicitly: Germany’s current residential V2G market is predominantly DC. BMW/E.ON’s initial product, Ford/Octopus, and VW Elli’s forthcoming Q4 2026 offer all use DC architecture, in which the bidirectional inverter sits inside the charger rather than the vehicle. France and the Netherlands have deployed AC. The architecture question is not uniformly settled by geography or OEM strategy. More on this shortly.

The economics: what does €700 a year actually mean?

The number that defined the conference was €700. It came from Dr Axel Sprenger, Managing Director of Uscale, who presented findings from the 2026 Bidi Charging Study: 11,177 respondents across five markets (Germany, UK, France, Netherlands, Sweden), comprising 4,505 BEV (Battery Electric Vehicle) drivers and 6,672 ICE (Internal Combustion Engine) drivers from different EV adopter segments. Sprenger mentioned a minimum revenue threshold of approximately €700 per year — the point on Uscale’s price-sales curve at which roughly 70% of respondents plugged in for 8–16 hours per day said they would participate. Uscale measures adoption likelihood using a Pain-Gain-Index: for a consumer to cross the adoption threshold, perceived benefits must outweigh the new friction V2G introduces by at least 3:1.

The figure is notable for a second reason: €700 is precisely what every major German commercial V2G product targets. BMW/E.ON markets up to €720 per year. VW Elli’s announcement lands at €700–900.

The question the conference addressed more honestly than most public communications do is what customers are actually likely to receive.

Mike Evans (Octopus Energy) showed a worked calculation for the German tariff. Based on a customer plugged in for approximately 300 hours per month, benefiting from a −€30/month V2G bonus and a discounted EV charging rate of 15 ct/kWh, the net annual electricity cost comes to minus €90. After all charges and credits, that customer is €90 ahead for the year. That suggests a saving of €594 + €90 = €684 per year, roughly in line with the €700 savings per year advertised across the board.

For further context: one of Germany’s four major utilities, in a private conversation shared with me, assessed the realistic achievable revenue range for most residential V2G customers under current market conditions at €100–200 per year.

The gap between the marketed headline and the maybe more likely outcome has two structural explanations. The first, noted by one of Germany’s major utilities in conversation with me: the business cases underpinning current commercial V2G offers were often modelled on the extreme intraday price volatility of 2023, driven by the energy crisis. Those spreads were not expected to persist, and they have not.

The second explanation comes from Dr Johanna Bronisch of Neon Neue Energieökonomik, who presented the pre-reform economics with forensic clarity. In Germany, grid fees, levies, and taxes applied when buying electricity could consume most or all of the arbitrage value available from V2G — leaving little, if anything, to share with consumers. Without sufficient buy-sell spreads, the pre-reform arithmetic simply didn’t work.

The German Bundestag’s amendment to §118 EnWG (German Energy Act), passed on 14 November 2025, changed this. Bidirectional charge points are now treated like home batteries: round-trip energy is exempt from grid fees and electricity tax for the first time. The arbitrage economics are now real.

But there is a catch in the implementation. The metering rules that define how bidirectional energy flows are measured, colour-coded (grid-sourced versus PV-generated electrons), and billed — collectively known as MiSpeL (Marktintegration von Speichern und Ladepunkten, or Market Integration of Storage and Charge Points) — have not yet been finalised by the Federal Network Agency. MiSpeL ... German regulators have a remarkable talent for turning five words of compound-noun machinery into something that sounds like a mild cough drop.

Until they are, expected in June 2026, grid operators and energy suppliers cannot reliably implement the §118 exemption at scale. And a structural conflict that will not be resolved until at least 2029 remains: the §118 round-trip netting exemption and the §14a EnWG Modul 3 time-of-use grid fee reduction cannot currently be combined. Customers must choose one regime or the other. The AgNes framework initiated by the Federal Network Agency, which redesigns the entire German grid fee system and takes effect on 1 January 2029, is expected to address this through new “grid-serving” (Netzdienlichkeit) provisions.

The honest conclusion: €700 per year is probably achievable, but it requires the right customer (smart meter already installed, compatible vehicle, willingness to leave the car plugged in regularly and for long hours), the right market conditions, and the right offer. Under current conditions, it is the top end of a realistic range, not the baseline.

Three things still standing in the way

There was no shortage of commercial momentum at the conference. But the most useful sessions were the ones that refused to paper over the structural obstacles. Three blockers emerged clearly.

Smart meters: Germany at 5% when 90% is needed

Tina Hadler, SVP Sales & Partnerships at metrify, delivered the conference’s most uncomfortable statistic. Only approximately 5% of German metering points had an intelligent metering system (iMSys) installed by the end of 2025. Germany needs 25–30 million by 2032. Without an iMSys, a household cannot participate in dynamic electricity tariffs, V2G billing cannot be settled correctly, and the DSO cannot legally send control signals to the charger under §14a EnWG.

metrify is, according to Hadler’s presentation, Germany’s largest competitive smart meter operator, and a subsidiary of the solar company Enpal. With more than 140,000 iMSys installed and a rollout pace of around 2,500 per month, it is among the most active players in the market. And 2,500 per month against a target of 25–30 million by 2032 requires a very optimistic reading of what lies ahead.

The reasons run deep. Germany’s Federal Office for Information Security (BSI) specified an architecture that is unique in the world: a dedicated hardware security module — the Smart Meter Gateway (SMGW) — that encrypts all communications between the meter, grid operators, energy suppliers, and in-home devices at what the BSI describes as “intelligence service level”. No other country has built anything comparable. The certification requirements were so exacting that manufacturers spent years in disputes. The result is genuinely world-class cybersecurity for critical energy infrastructure. Whether that security premium was worth a decade of delay is a question the energy transition is now forcing into the open — the Netherlands deployed simpler meters first and addressed privacy concerns through iterative regulatory amendments.

The contrast with the Netherlands, where We Drive Solar operates Utrecht Energized on a grid with 90% smart meter penetration, is stark. The conditions that make Utrecht work, including granular metering data, real-time pricing signals, and DSO visibility of bidirectional flows, will take years to replicate in Germany. That contrast is not a reason to despair about the German trajectory; it is a reason to be realistic about the timeline.

The regulatory implementation lag

The legal architecture is largely in place. The execution is still catching up.

Grid operators have 9–12 months from the November 2025 amendment to update their IT systems, putting the window for practical implementation between August and November 2026. MiSpeL finalisation is expected in the coming weeks. The ToU-versus-netting conflict remains until AgNes takes effect on 1 January 2029. Three separate implementation horizons, none of which the industry can accelerate.

One development from the conference sidelines worth noting: a possible evolution in VDE 4105’s (German grid code) certification approach was verbally discussed, moving from system-level certification (each vehicle + cable + wallbox combination certified as a unit) towards unit-level certification (each V2G device certified independently). If adopted, unit-level certification would significantly ease AC V2G scalability in Germany, since a unit-certified wallbox could work with any unit-certified vehicle without requiring pairwise approval. The detail has not yet been officially confirmed. If it materialises before end of 2026, it would be a meaningful unlock for the residential AC market.

Interoperability: a language with many dialects

ISO 15118-20, the communication protocol between EV and charger that underpins V2G sessions, is “a language with many dialects”, as pv magazine put it adequately. The phrase circulated widely at the conference itself: different manufacturers implement the same standard differently, producing systems that are individually conformant but mutually incompatible.

The most concrete illustration of what this costs in practice came from the conference floor: one wallbox manufacturer completed 250,000 discharge sessions with a single car manufacturer before that OEM would approve them as a V2G hardware partner. That arithmetic applies per OEM, per charger brand, per country. It is not a criticism of any individual player; it is the state of the art. As one presenter put it plainly: “V2G is not standardised yet.”

The industry’s main instrument for narrowing this interpretation space is IEA EV-TCP Task 53, formally known as INBID — Interoperability of Bidirectional Charging for AC, DC, and wireless. Marco Piffaretti, its Operating Agent since May 2024 and a figure with 39 years in eMobility, presented the project’s progress at the conference. Task 53 is now supported by 18 countries and the European Commission, proposed originally by Switzerland. What distinguishes it from existing industry interoperability work — notably CharIN’s bilateral testing events — is scope. CharIN tests pair one EV with one EVSE; the results are private. Task 53 targets something more demanding: three EV manufacturers, three EVSE (charger) manufacturers, and five DSOs (Distribution System Operators, i.e. grid operators) all interoperating at once, with results shared among all project participants. The Golden Guidelines that Task 53 is developing are not a new standard and not a deviation from ISO 15118-20. They define a mandatory subset of the existing standard — the minimum required implementation for a prioritised set of use cases — specifically to close the space where “fully ISO-conformant but incompatible” implementations currently proliferate.

The project runs from 2025 to 2028. At the time of the conference, the initiative was moving from planning into actual multi-party cross-testing — DC results expected by late 2027, AC and the Final Golden Guidelines by late 2028. This is the honest timeline: serious, progressing, but the ISO 15118-20 mandate for charger manufacturers that takes effect on 1 January 2027 arrives well before the results are in.

AC or DC? Why the architecture question matters for cost

The AC versus DC debate that occupied earlier V2G conferences has not been settled uniformly. But the direction of travel is becoming clear.

In DC V2G, the bidirectional inverter lives inside the charging station. The vehicle contributes its battery; the charger handles the DC-to-AC conversion and connects to the grid. Grid code compliance is the responsibility of the charger manufacturer. Any compatible vehicle can, in principle, connect to a certified DC V2G charger. The pairing constraint is looser. The cost implication runs the other way: that inverter is significant hardware, and charger manufacturers build it in volumes measured in tens of thousands, not millions.

In AC V2G, the inverter is the vehicle’s own on-board charger (OBC). The wallbox becomes, in principle, a smart socket with communication capability: substantially cheaper hardware. The challenge shifts to certification. Grid code compliance now also belongs to the vehicle, and each specific vehicle–charger pairing must be certified separately as a grid-compliant unit. This is the paired certification constraint that currently limits AC V2G roaming. A Renault 5 approved for V2G with a LomboxNet charger is not automatically compliant when connected to a different wallbox brand.

The EU’s RfG (Requirements for Generators) 2.0 technical annex — discussed in my previous article — is expected in October 2026 and should define harmonised AC V2G grid compliance requirements that would eventually allow type-approval-level certification to decouple the EV from the specific EVSE, opening up the kind of roaming that makes a large AC V2G market viable. Until then, every AC deployment requires pairwise certification work.

Germany’s residential market in 2026 is predominantly DC: BMW/E.ON’s initial iX3 offer with a Compleo wallbox, Ford/Octopus via an Ambibox wallbox, and VW Elli’s Q4 2026 product all use DC architecture. AC is commercially live in France (Renault 5 and A290 via Mobilize), the Netherlands (Utrecht Energized), and the UK (Octopus/BYD, Zaptec Go2).

The most significant signal on the long-term direction came not from the presentations but from the conversations during the conference. At least one established charger manufacturer present at Münster — one that has already delivered DC V2G hardware commercially — has decided not to take DC V2G to the mass market. The reasoning is structural: vehicle manufacturers build inverters at automotive scale, amortising the unit cost across millions of vehicles. Those economics are orders of magnitude better than anything a charger company can achieve in dedicated wallbox volumes. When the inverter moves into the EV, it gets cheaper with every additional vehicle sold. The wallbox cost drops dramatically as a result. That is the mass-market AC proposition: cheaper hardware, powered by scale that no charger OEM can match.

The short-run picture is mixed between architectures. The long-run cost structure points clearly towards AC, at least in the residential space. For fleets, with heavy-duty vehicles carrying big batteries, a DC V2G charger with higher power throughput may still make more sense.

Utrecht Energized — what scaled V2G actually looks like

Everything discussed above (economics, architecture, bottlenecks) is easier to evaluate against a project where V2G is not a concept but an operating service.

Robin Berg, founder and CEO of We Drive Solar, presented eight-month results from Utrecht Energized at the conference. Launched in June 2025, the project places bidirectional Renault 5 vehicles into the Utrecht car-sharing fleet and operates them as grid assets in real time.

The current facts: 220 Renault 5 E-tech Electric vehicles on dedicated 7kW AC V2G charge posts operated by LomboxNet in Utrecht, with a target of 500 vehicles by end of 2026 (expanding to include Renault 4, Megane, Scenic, and Twingo). The technical architecture runs entirely on open standards: ISO 15118-20 (tested at Renault’s headquarters) and OCPP 2.1.

Over the first eight months of operation with a growing fleet of now 220 vehicles: 100,000 kWh discharged in total, approximately 2,000 kWh per car over 200 hours of V2G operation per vehicle. At the conference, Robin Berg stated verbally that the project generates approximately €60 per month per car in V2G revenues. This accrues to We Drive Solar as fleet operator, not to individual car-share users, who access the vehicles on a booking basis through MyWheels, the Netherlands’ largest car-sharing provider.

A University of Edinburgh research paper published in April 2026, drawing on interviews with We Drive Solar, Stedin (Dutch grid operator), the Municipality of Utrecht, and ELAAD, reports that the hourly electricity cost from EPEX Spot day-ahead prices serves as a proxy for grid congestion, with the two aligning approximately 95% of the time. This allows the project to optimise for both commercial arbitrage and grid congestion relief simultaneously, without needing separate congestion forecasting infrastructure.

Berg made a point at the conference that deserves more prominence than it received. We Drive Solar has signed the first V2G grid congestion services contract in the Netherlands, with Stedin (the local DSO). His assessment was unambiguous: grid congestion services are a better V2G revenue stream than aFRR (the automatic frequency restoration reserve market used for grid balancing). The reason is reliability. Congestion contracts are structured and predictable: you know when the grid is under stress, you know what volume is expected, and you can plan dispatch around driver bookings. The aFRR market, by contrast, requires short-notice response that complicates fleet scheduling. For a car-sharing operator, predictability wins over intermittent high-value calls.

Stedin’s own calculus sharpens the point further. The DSO calculates that for each EV charging station that is “off” during the evening peak, one additional home can be connected to the network. The Netherlands currently has 10,000 large users on grid connection waiting lists. Robin Berg’s view: with 10,000–20,000 bidirectional EVs and sufficient bidi chargers positioned in the right locations, the Dutch grid congestion problem is solvable. Companies blocked from grid connections can unlock capacity by committing to flexible V2G assets. That is a DSO willing to pay for exactly what We Drive Solar can provide.

We Drive Solar is scaling the model to Eindhoven, Rotterdam, and Amsterdam, and is beginning expansion into France. Its Solar Life home wallbox, winner of the NL Laadinfra Award 2025, signals ambition beyond the fleet segment.

Why Utrecht works — and why it may not transfer directly

The University of Edinburgh authors draw a conclusion that is probably the most transferable lesson from Utrecht: near-term viable V2G business models require bundled propositions: vehicle, charger, tariff, and fleet operator integrated into a single product. The vision of “any car, any charger, any tariff” remains a second-generation story.

Utrecht’s success rests on a specific set of enabling conditions. The Netherlands has 90% smart meter penetration (versus Germany’s 5%). The Dutch Energy Act, effective January 2026, requires all electricity suppliers to offer dynamic tariffs, giving We Drive Solar the pricing signals it needs. Stedin, as a publicly owned DSO, has a direct mandate to support grid innovation and has invested €8 billion in network expansion since 2023. The Municipality of Utrecht has mapped grid constraints at neighbourhood level and inserted V2G capability requirements into its EV charging procurement. ELAAD, the publicly funded testing body, provides free OEM certification services that would cost private operators significantly more to replicate.

None of these conditions assembled themselves. They were built over years by what the Edinburgh authors call “determined disruptors”: a small group of motivated actors in both public and private roles who were willing to navigate regulatory and technical barriers and who had access to decision-makers throughout.

The template exists. Replicating it requires the underlying infrastructure to catch up. And determined, pragmatic disruptors willing to go the extra mile to turn the V2G dream into reality.

The milestones that matter

From the conference discussions, a credible timeline of what must happen before Germany’s V2G mass market can function:

June 2026: MiSpeL finalised — the metering and billing rules for bidirectional energy flows that unlock §118 EnWG (German Energy Act) implementation at scale. The single most important near-term regulatory event for German commercial V2G.

August–November 2026: Grid operators complete the IT system updates required following the November 2025 amendment. The §118 round-trip tax and levies exemption begins to take practical effect in energy billing.

Q4 2026: Volkswagen Elli launches in Germany. Approximately one million MEB platform vehicles (already on European roads, already technically capable of bidirectional charging) gain access to a commercial offer.

October 2026: RfG 2.0 technical annex published — the EU-level harmonised AC V2G grid compliance requirements that should, eventually, reduce the paired certification burden and open up roaming for AC V2G across member states.

January 2027: AFIR mandate — all new public chargers installed in the EU must support ISO 15118-20. The communication standard that underpins V2G is (hopefully) embedded into millions of new chargers from this date.

2028–2029: AgNes takes effect on 1 January 2029, expected to address the structural conflict between §118 round-trip netting and §14a Modul 3 of EnWG time-of-use grid fees. This is when the incentive architecture for residential V2G becomes coherent enough to model reliably.

One question the conference pointedly left unresolved: data ownership. Vehicle manufacturers want direct access to vehicle data and the customer relationship. Wallbox manufacturers see themselves as the natural interface between the consumer and the energy market. Energy companies see the customer as theirs. All three positions reflect legitimate commercial interests, and the distribution of value in a V2G ecosystem is a direct function of who controls the customer touchpoint. Regulation will not resolve this quickly. Commercial negotiation will, over time, find its own equilibrium. The process will be visible in every product launch and partnership announcement between now and 2030.

The bottom line

The 5th Vehicle-2-Grid Conference in Münster marked a genuine crossing point. The industry has moved from pilots to products, and from “when will V2G arrive?” to “how quickly can the infrastructure and compliance regulation catch up?” Utrecht Energized answers the technical question: AC V2G at fleet scale works commercially, today, using available hardware and open protocols. Octopus’s live customer bill answers the economic question: the revenues are real, if smaller than the marketing suggests.

Three structural bottlenecks remain. Germany’s smart meter penetration is at 5% when the market needs Dutch-level coverage. The regulatory framework is sound but incomplete, with MiSpeL, grid operator IT updates, and AgNes spread across 2026–2029. ISO 15118-20 is the right protocol but still a language with too many dialects.

There is a quieter risk that the conference discussed less directly. If V2G revenues settle at €100–200 per year — and the product requires a dedicated V2G-capable charger costing maybe several thousand euros, potentially an OEM fee to unlock bidirectional capability, and a battery warranty conversation — many EV drivers will make a rational alternative choice: optimise for home solar self-consumption instead. A smart energy management system that charges the car from surplus rooftop PV and draws on that stored energy in the evening is a credible, straightforward substitute. No grid-services complexity. No aggregator relationship. No uncertainty about warranty. For any aggregator or energy supplier counting on residential V2G as a significant revenue stream, that substitution is a real competitive threat. The industry’s response cannot be a more persuasive marketing narrative. It needs to be a genuinely simpler product: one that earns revenue without the driver ever having to think about it, and one that is honest about what it actually pays. The gap between the marketed headline number and the live customer experience is not just a communications problem — it is a trust problem, and trust is harder to rebuild than it is to lose.

None of these are permanent obstacles. All of them carry timelines. The private assessment from the people closest to the German market is that the mass-market, meaning real volumes of residential customers earning meaningful V2G revenues, is before 2030, not before 2028. That is not a failure. It is a realistic sequencing of the work that remains to be done.

The next Vehicle-2-Grid conference in Aachen (April 2027) will have more live products to count. If MiSpeL lands on schedule and grid operators deliver their IT updates, it may have materially better economics to report as well.

Enjoyed this deep dive?
Then please share with your professional (social) network
and restack for your readers.

Share

But a rule written in a regulation is only the theory. To put the theory into practice, we need a way of reaching the power electronics inside an electric vehicle. Something has to carry each instruction from the grid operator’s systems into the on-board charger inside the car. That carrier is a chain of communication protocols, each layer passing the baton to the next. Understanding that chain is what this article is about.

The protocol names may be unfamiliar to some readers. The goal is not to leave you quoting message parameters, but to understand what each layer is responsible for, how they connect to one another, and where the chain is still being built.

In this article, you will learn:

• How grid code parameters travel from a grid operator all the way to your EV’s on-board inverter, via a three-layer protocol stack

• What OCPP 2.1’s two V2G sections do: Section Q (how bidirectional power is orchestrated) and Section R (how grid compliance parameters are delivered), and how they relate to each other

• What ISO 15118-20 offers for bidirectional charging: DC and AC power transfer services, message flows, and the difference between scheduled and dynamic control

• Why bidirectional power control alone is not sufficient for grid code compliance, and what ISO 15118-20 Amendment 1 adds to close that gap

• How the European and US approaches diverge, and what IEC 61851, IEEE 1547, and SAE J3072 each represent

• Where the certification landscape stands in 2026

What you are about to read is a summary of material spread across hundreds of pages in the OCPP 2.1 and ISO 15118-20 standards. I’ve done my best to be as accurate as possible while making it digestible. Given the complexity of the subject, this article runs longer than most, but I’ll guide you through it step by step.

Subscribe now

The three-layer chain

Grid code parameters need to travel from a utility control room to the inverter inside an EV. They do this in three hops, each handled by a different protocol:

Grid Operator
     ↓  IEC 61850 / IEEE 2030.5 / OpenADR
CSMS (Charging Station Management System)
     ↓  OCPP 2.1  (Sections Q and R)
Charging Station
     ↓  ISO 15118-20  (base standard + Amendment 1)
EV On-board Inverter

A quick note: I use CSMS (Charging Station Management System) here rather than CPMS as in previous articles. They mean the same thing. CSMS is the term OCPP uses, so I’ve followed the standard’s lead here.

The first hop — from grid operator to CSMS — uses utility-to-aggregator protocols. In Europe these are typically IEC 61850 or OpenADR; in North America, IEEE 2030.5 and OpenADR are widely used. This article will not go deep on those; the more important story is what happens in the next two hops.

The CSMS — the cloud backend that manages a fleet of charging stations — is the translator and aggregator. It receives grid signals from the operator (or an intermediary V2G aggregator that sits between a CSMS and the grid operator), interprets them, and pushes them to individual chargers. The OCPP 2.1 protocol, which has become an official IEC standard (IEC 63584-210) in 2025, handles both legs of this: Section Q defines how bidirectional power flow is controlled, and Section R defines how grid compliance parameters are delivered. From the charging station to the EV, ISO 15118-20 carries the baton — including a new addition, Amendment 1, that enables the last and hardest mile of all.

OCPP 2.1 Section Q: eight ways to orchestrate bidirectional power

OCPP is the language charging stations and their backend management systems use to communicate. Version 2.0.1, now being deployed across the globe, handles session management, authentication, metering, and smart charging, among other use cases. OCPP 2.1 extends this with bidirectional power transfer as a native, first-class capability, and is backwards-compatible to OCPP 2.0.1.

The central contribution of Section Q is a set of eight operation modes that define how the CSMS controls power flow at a bidirectional charging station:

• ChargingOnly: Default; no bidirectional operation. Also used as fallback when no mode is explicitly set.

• ExternalSetpoint: An external Energy Management System (EMS) controls the power target; the CSMS grants permission.

• ExternalLimits: An EMS controls power ceilings for charge and discharge, rather than a specific target.

• CentralSetpoint: The CSMS provides a specific power target, updated in real time.

• CentralFrequency: Similar to LocalFrequency, but frequency is measured centrally. A single calibrated meter feeds the CSMS, which continuously pushes updated setpoints to stations as frequency changes. Used where the cost of a precision meter in every charger is prohibitive. Falls back automatically to LocalFrequency if the CSMS stops sending updates.

• LocalFrequency: The charging station reads local grid frequency and responds autonomously using a pre-configured frequency-power curve. No CSMS instruction required per event.

• LocalLoadBalancing: The charging station monitors the building’s upstream power meter and adjusts output to stay within defined thresholds.

• Idle: The EV is connected but neither charging nor discharging. Used for preconditioning or standby.

For grid stability services, the two most relevant modes are CentralFrequency and LocalFrequency. The table above describes both; the key distinction is that LocalFrequency relies on nobody at all. The charging station reads frequency directly at the socket, compares it to a curve configured in advance, and adjusts its output immediately. No message, no round-trip, no delay.

This matters because frequency events happen fast. When a large power plant trips offline, grid frequency can drop within seconds. The industry uses two distinct tiers of frequency response to manage this:

FCR: Frequency Containment Reserve (also called primary frequency response) is the first line of defence. It must activate within seconds, automatically, without any external command. In LocalFrequency mode, the charging station holds a frequency-power lookup table — the same droop curve described in the previous article — and adjusts its output continuously as frequency deviates. When frequency falls, the station discharges more. When it rises, it charges more. The response is proportional and instantaneous, requiring no involvement from the CSMS.

aFRR: automatic Frequency Restoration Reserve (secondary frequency response) is the second tier. It begins gradually replacing FCR from around 30 seconds after a frequency event and must reach full contracted capacity within 15 minutes. Unlike FCR’s autonomous response, aFRR is coordinated: the CSMS sends an activation signal to the charging station, which then adds a power delta on top of its configured baseline. The spec also specifies a minimum ramp rate of around 20% of offered power per minute.

Section Q also extends the existing OCPP charging schedule mechanism with three new power-control fields:

• setpoint (signed, ±): the power target the EV should follow as closely as possible. Positive means charging; negative means discharging.

• limit (+): a ceiling on charging power. The EV must not exceed it.

• dischargeLimit (−): a ceiling on discharge power. The EV must not exceed it in the discharge direction.

The setpoint/limit distinction matters in practice. A setpoint is a target, i.e. the EV is expected to hit it. A limit is a boundary: the EV must not cross it, but has freedom to operate anywhere below. The CSMS uses setpoints for grid service delivery (where hitting a specific value matters) and limits for constraint management (where staying below a threshold is all that matters).

OCPP 2.1 Section R: delivering grid compliance parameters to the charger

Section Q handles power flow orchestration: the dispatch and scheduling layer. Section R handles something entirely different: delivering the technical grid code parameters that determine how a bidirectional asset behaves under grid stress.

These two sections are not alternatives. Section Q says “discharge at 8 kW between 5 pm and 7 pm.” Section R says “if voltage rises above 110% of nominal, trip within two seconds” and “if frequency drops below 49.8 Hz, increase discharge with a 2% droop.” One governs commercial dispatch; the other governs grid safety behaviour. Both are needed.

The central OCPP message in Section R is SetDERControlRequest. DER (Distributed Energy Resource) is the utility industry’s label for any small-scale generation or storage asset connected to the distribution grid. This message allows the CSMS to push grid code parameters directly to a charging station, where they are stored persistently, meaning they must survive a reboot or a power cycle.

The range of parameters it can carry maps directly to the grid code requirements covered in the previous two articles:

• FreqDroop: The autonomous frequency-power response curve — the LFSM/FCR mechanism in OCPP terms. Configures three things: the dead band (the frequency range around 50 Hz where no response is required), the droop factor (how much power changes per Hz of deviation — typically 2% for V2G), and the response time. Once set, the station responds to frequency events without any CSMS involvement.

• VoltVar: The Q(U) reactive power curve covered in the previous article. Defines how the inverter adjusts reactive power as local voltage rises or falls — injecting reactive power when voltage dips, absorbing it when voltage climbs. Configures the voltage breakpoints, the reactive power levels at each point, and a dead band around nominal voltage where no action is taken.

• VoltWatt: Active power as a function of local voltage. When voltage rises too high — typically because of excess solar generation on the local network — the inverter automatically reduces its active power output rather than continuing to push energy into an already-overvoltage network. Less commonly used than VoltVar, but important in high-PV neighbourhoods.

• HVMustTrip / LVMustTrip: The hard voltage trip thresholds for interface protection. If voltage exceeds the high-voltage (HV) limit or falls below the low-voltage (LV) limit and stays there beyond the defined hold time, the unit must disconnect from the grid. These are the UV1/OV1 thresholds (80% and 110% of nominal voltage, 2-second trip time) from the previous article, delivered here as configurable OCPP parameters.

• HFMustTrip / LFMustTrip: The hard frequency trip thresholds — equivalent to the voltage trips but for the frequency dimension. If frequency rises above the high limit or falls below the low limit beyond the defined hold time, the unit must disconnect. Under EN 50549-1 these are set at 47.5 Hz and 51.5 Hz; the exact values and timing are configured here per site.

• EnterService: Reconnection rules after a trip event. When a V2G unit disconnects because voltage or frequency went out of bounds, it cannot simply reconnect the moment conditions return to normal, since a mass simultaneous reconnection by thousands of devices would cause a fresh grid disturbance. EnterService defines the voltage and frequency window within which reconnection is permitted, a mandatory intentional delay before attempting it, and the ramp rate at which power must be restored gradually. It is the orderly queue that prevents the cure from becoming a second crisis.

• LimitMaxDischarge: A configurable ceiling on discharge power, expressed as a percentage of the station’s rated capacity. Used by grid operators to cap how much power a V2G asset — or a whole fleet of them — can export into a constrained network segment, without needing to stop the session entirely.

Getting confused with all the acronyms? Don’t worry, I got you covered with the Acronym Survival Guide.

Controls come in two varieties. Default controls have no expiry, they are always active and define the station’s permanent grid behaviour at a given site. Scheduled controls have a defined start time and duration; they activate at the specified moment, supersede any lower-priority default of the same type, and are automatically removed when their duration expires. This lets a grid operator push a temporary configuration change — tightening discharge limits during a congestion event, for instance — without permanently altering the site’s baseline settings.

Here is where the architecture forks depending on whether the deployment is DC or AC V2G.

For DC V2G, the inverter is inside the charging station. The station receives SetDERControlRequest, stores the parameters, and its own power electronics execute them directly. The EV’s role is to provide battery capacity; grid compliance responsibility sits entirely with the EVSE (Electric Vehicle Supply Equipment, i.e. the charging station’s device that controls the power flow). ISO 15118-20 tells the charger what power the EV can deliver, but the charger’s inverter is the regulated grid asset.

For AC V2G, the inverter is inside the EV. The charging station is, in grid compliance terms, a smart connection point. When the CSMS pushes DER parameters via SetDERControlRequest, the charger receives them. Active power limits — such as a maximum discharge ceiling — can be enforced by the charging station directly, by capping the target value it sends in each ChargeLoopRes (’Res’ = response) during the session. Inverter configuration parameters — frequency droop curves, Q(U) reactive power curves, trip thresholds — are different: those must be loaded into the EV’s own inverter, which is only possible via ISO 15118-20 Amendment 1’s AC DER services (AC_DER_IEC for Europe, AC_DER_SAE for North America). We’ll cover those in a second.

Section R also closes the reporting loop. When a grid event triggers a DER control — say, an over-voltage event activates the VoltWatt curve and the station reduces its discharge power — it sends a NotifyDERAlarmRequest to the CSMS, identifying which control was triggered and what grid fault caused it. When the event clears, it sends the alarm-ended notification. The CSMS has a live picture not just of what it instructed, but of what actually happened.

ISO 15118-20: the charger-to-EV conversation — BPT services

ISO 15118 is the standard that governs communication between an EV and a charging station over the charging cable. ISO 15118-2 — covering unidirectional AC and DC charging and Plug & Charge — became mandatory at newly installed EU public chargers in January 2026. ISO 15118-20 is the successor standard, adding bidirectional power transfer as a native capability.

As you can see, OCPP 2.1 and ISO 15118-20 both treat bidirectional power flow as first-class citizens and are essential to unlock V2X (Vehicle-to-Home and Vehicle-to-Grid) use cases.

For bidirectional charging, ISO 15118-20 defines two BPT (Bidirectional Power Transfer) services: AC_BPT and DC_BPT. The architectural difference mirrors the previous article’s AC/DC split.

In DC_BPT, the inverter is in the charging station. The EV connects via a DC link (e.g. a CCS plug), providing battery capacity. The EV declares its charge and discharge capabilities; the charger manages the DC-to-AC conversion. The EV and charger negotiate power envelopes at the start of the session and exchange updated limits during the (dis-)charging message cycle loop.

In AC_BPT, the inverter is in the EV’s on-board charger (OBC). The charging station is essentially a metered connection point. The EV must handle the AC-to-DC conversion in both directions, and its inverter is the grid-facing device.

Session setup

Both services follow the same session flow. Before power starts flowing, there is a four-step negotiation phase:

Service Discovery: the EV asks the charging station what services it offers. The charging station responds with its list of supported ServiceIDs. For a BPT-capable site, this list includes AC_BPT (ServiceID 5) or DC_BPT (ServiceID 6). For a site using Amendment 1, it will also include AC_DER_IEC (ServiceID 10) or AC_DER_SAE (ServiceID 11).

Service Detail: the EV requests the parameter set for each service it is interested in. The charging station responds with the service parameter list for that service. This is where operationally important choices are surfaced: the control mode (Scheduled or Dynamic, see below), the connector type, and — for the AC DER services — the DER capability requirements or supported functions. Selecting Dynamic control mode here is what enables real-time setpoint following during charging.

Service Selection: the EV confirms its chosen service and parameter set. From this point, both sides know exactly what the session will look like.

Charge Parameter Discovery: EVCC and SECC exchange their physical capabilities and limits for the chosen energy transfer service. In a BPT session, the EV declares its discharge capabilities — maximum and minimum discharge power, current limits — and the charger responds with its own discharge limits. For the AC DER services, this is also where the detailed DER configuration is delivered: droop curve parameters, voltage and frequency trip thresholds, Q(U) reactive power curve breakpoints, and enter-service settings. This mutual handshake establishes what the session will look like before a single watt moves.

Control modes and the ChargeLoop

After this exchange, the session enters one of two control modes.

Scheduled mode follows a pre-agreed power schedule, which is a time-indexed list of setpoints agreed at session start and applied throughout. This works well for predictable use cases: overnight energy arbitrage, for example, where the EV discharges during the evening peak and charges cheaply at night according to a schedule the CSMS prepared in advance.

Dynamic mode allows setpoints to be updated throughout the session without interrupting it. With every ChargeLoop message (continuously exchanged during power flow), the charger can send the EV a new power target. This is the mode required for genuine real-time grid services — frequency response, congestion management, direct grid operator setpoints — where the optimal power level may change every few seconds.

The ChargeLoop is the operational heartbeat of the session. Each cycle, the EV sends its current limits and status; the charger responds with updated targets. ISO 15118-20 governs both sides of each exchange: the charger must respond within 0.5 seconds of receiving the EV’s request (the message timeout), and the EV must send its next request within 0.5 seconds of receiving the response (the sequence timer). Taken together, these two constraints bound each full ChargeLoop cycle to under one second. This is a protocol guarantee, not just typical behaviour. For frequency response applications, where the relevant timescale is seconds, that guaranteed cycle rate sits right at the practical boundary of what is achievable over a software-based connection.

At this point, however, we reach the limit of what BPT services alone can do. DC_BPT and AC_BPT are power flow protocols. They can instruct an EV to “charge at 7 kW” or “discharge at 7 kW.” They can agree on power envelopes and exchange state-of-charge information. What they cannot do is say “configure your inverter with this frequency droop curve” or “enable Q(U) voltage support with these specific voltage breakpoints.” That is the domain of DER control. And for AC V2G, it requires a separate protocol extension. That extension is Amendment 1.

ISO 15118-20 Amendment 1: the DER layer reaches the car

Amendment 1 — currently in draft form, expected to be finalised in the second half of 2026 — adds two new AC DER services to ISO 15118-20. These are not replacements for AC_BPT; they are extensions of it that add the grid code compliance layer on top of bidirectional power control.

The two new services reflect a fundamental divergence in grid code standards between Europe and the United States:

• AC_DER_IEC is built on IEC 61851-1 Edition 4: the foundational IEC standard for EV conductive charging systems, the latest edition of which introduced specific DER behaviour requirements for bidirectional AC charging. This is the European path, aligned with EN 50549-1 across the EU and VDE 4105 for Germany, in particular.

• AC_DER_SAE is built on IEEE 1547-2018 and SAE J3072: the US standards for grid interconnection of distributed energy resources and V2G communication specifically. This is the path for North American deployments, aligned with state interconnection rules, California Rule 21, and UL 1741 certification.

The two services accomplish the same goal — configuring an EV inverter for grid code compliance — but they differ fundamentally in who declares what.

AC_DER_IEC is site-driven. During ServiceDetail — the second step of the pre-session negotiation, as discussed above — the charging station sends the EV a requirements bitmap (12 flags, one per DER function) declaring which grid compliance functions are required at this location. For instance, “you must support frequency-watt response, Q(U) reactive power support, and fault ride-through.” The EV can only select this service if it supports all the required functions. The site sets the bar; the EV qualifies or doesn’t.

AC_DER_SAE is EV-driven. The capability declaration comes later than in the IEC path: during ChargeParameterDiscovery — the fourth step — the EV sends a capabilities bitmap (SupportedModes, 27 flags) declaring which IEEE 1547 functions it supports. The charger responds in the same handshake with an EnabledModes bitmap confirming the subset it wants active for this session. The EV declares what it can do; the site configures accordingly.

The difference in bitmap size reflects the underlying standards. IEC 61851-1 Edition 4 defines a compact European DER function set; IEEE 1547-2018 is more granular: it treats may-trip, must-trip, and momentary cessation as distinct trip categories for both over- and under-voltage, and adds functions such as enter-service authorisation and constant setpoint modes that have no direct IEC equivalent. Both services then use ChargeParameterDiscovery to deliver the full DER configuration to the EV’s inverter.

In AC_DER_SAE, this means a complete set of IEEE 1547 trip curves: six voltage trip curves (overvoltage and undervoltage, in must-trip, momentary cessation, and may-trip variants) and four frequency trip curves (over and under, must-trip and may-trip). It means frequency droop settings. And it means an enter-service authorisation — a boolean flag that grants the EV explicit permission to discharge at this specific site. Not every site allows export, and this flag is the formal, protocol-level mechanism by which the site grants or withholds that permission.

In AC_DER_IEC, the equivalent block delivers fault ride-through parameters, reactive power support curves (Q(U), Q(P)), and active power response curves (frequency-watt, volt-watt) — all determined by the requirements bitmap the site set in ServiceDetail.

Once the session is active, both services extend the ChargeLoop heartbeat with DER reporting. With every cycle, the EV reports back: its operational state, its connection status relative to the grid, and a bitmap of any active alarm conditions — overvoltage, undervoltage, over-frequency, under-frequency, and several others. The charging station — and via OCPP 2.1 Section R, the CSMS — has a continuous live view of what each connected EV inverter is seeing and doing.

In AC_DER_IEC, the charger can additionally pass real-time DSO setpoints with every ChargeLoop cycle: a reactive power setpoint or a power factor setpoint, updated continuously as grid conditions evolve.

The two paths: static configuration and dynamic setpoints

This is what genuinely dynamic, remotely managed grid code compliance looks like — but it operates on two distinct timescales, through two distinct paths.

The static configuration path handles droop curves, trip thresholds, Q(U) curve shapes, and enter-service settings. These are pre-loaded onto the charging station by the CSMS via OCPP 2.1 Section R. When an EV connects and the session reaches ChargeParameterDiscovery, the charging station delivers this configuration to the EV’s inverter in full. From that point, the EV acts autonomously — no further signal from the grid operator is required for FCR droop response or fault ride-through.

The dynamic setpoint path handles real-time power targets and reactive power setpoints. In CentralFrequency or CentralSetpoint mode, the CSMS continuously pushes updated values to the charging station via OCPP 2.1 Section Q. The charging station embeds the current setpoint into each ChargeLoop response to the EV. This is the path used for aFRR activation and for DSO-dispatched reactive power instructions in AC_DER_IEC sessions.

A word of caution, though, on what “every cycle” means in practice. The 0.5-second figure is the heartbeat rate of the EV-to-charger conversation, not the latency of the full chain. A setpoint change originating at a grid operator must travel through IEC 61850 (or IEEE 2030.5, for example) to the CSMS, be translated into OCPP, travel over a WebSocket connection to the charging station, and then appear in the next ChargeLoop response to the EV. That full round-trip is measured in seconds, not milliseconds — and on a congested network it may be longer still. This is precisely why LocalFrequency mode in OCPP 2.1 exists, and why the autonomous frequency droop pre-configured via Section R is the practical mechanism for FCR: fast-response grid services cannot rely on a central command reaching the device in time. The 0.5-second cycle mentioned above for the ChargeLoop messages serves a different purpose: it keeps the EV and charger in tight synchronisation during an active session, so that when a locally-detected grid event triggers an autonomous response, the charger knows exactly what the EV’s inverter is doing.

The certification fork

The AC_DER services bring different certification requirements depending on which side of the Atlantic you are on.

In the United States:

• For DC V2G, the EVSE inverter is certified against UL 1741 SB (Supplement B), which implements IEEE 1547-2018 requirements for inverter-based DERs. This path is well-established and commercially available.

• For AC V2G, the vehicle’s on-board inverter is certified against SAE J3072 (the EV-specific IEEE 1547 compliance standard), and the EVSE against UL 1741 SC (Supplement C), finalisation expected in 2026. Stellantis demonstrated a complete SAE J3072-compliant AC V2G stack at the Detroit V2G Forum in October 2025, with NREL (the US National Renewable Energy Laboratory, a federal research lab under the Department of Energy) confirming IEEE 1547 ride-through compliance. This is the first public end-to-end US demonstration of the full stack.

In Europe:

• For either DC or AC V2G, the system is certified against EN 50549-1 using a test report based on EN 50549-10 (or VDE 0124-100 for Germany). Under VDE 4105, notably, certification is system-level: a specific vehicle model, charging cable, and wallbox must be certified together as an integrated unit.

• ISO 15118-20 conformance can, hopefully from 2026, be verified through ISO 15118-21 (common requirements), ISO 15118-22 (AC requirements), and ISO 15118-23 (DC requirements), the dedicated conformance testing standards.

The complete picture

Let me trace the full chain through a single concrete example. A German grid operator detects rising voltage in a residential network zone on a sunny July afternoon — rooftop solar is flooding the local grid. It needs the V2G fleet in that zone to absorb reactive power to bring voltage back down.

1. Grid operator → CSMS. The operator signals updated Q(U) reactive power requirements to the aggregator’s CSMS via IEC 61850. The CSMS translates this into OCPP.

2. CSMS → Charging Station (Section R). The CSMS sends a SetDERControlRequest carrying a VoltVar control with an updated Q(U) curve — specifying how much reactive power each station should inject or absorb at each voltage level. For DC V2G stations, this is executed directly by the EVSE inverter, immediately and autonomously.

3. CSMS → Charging Station (Section Q). Simultaneously, the CSMS sends a ChargingProfile with operationMode = CentralSetpoint, directing each station’s active power schedule for the afternoon. Commercial dispatch and grid compliance parameters travel through separate mechanisms but arrive at the same device.

4. Charging Station → EV (ISO 15118-20 Amendment 1, AC V2G). For AC V2G sessions, the VoltVar configuration — the Q(U) curve breakpoints and the reactive power levels at each voltage step — is delivered to the EV’s on-board charger during the ChargeParameterDiscovery phase, before power flows. Once loaded, the EV inverter applies the Q(U) profile autonomously in response to voltage it measures locally. Mid-session, the CSMS can push a real-time reactive power setpoint (a single scalar value) to the EV via the ChargeLoop response in Dynamic mode; this is not a curve change but a DSO dispatch instruction on top of the configured curve. Changing the Q(U) curve shape mid-session would require a service renegotiation.

5. EV → Charging Station → CSMS (reporting path). During every ChargeLoop cycle, the EV reports its DER operational state and any active grid events. Significant events — an over-voltage alarm, a frequency trip — are forwarded by the charging station to the CSMS via NotifyDERAlarmRequest. The operator has visibility of what each asset is doing.

This is what a fully instrumented, dynamically configurable V2G grid asset looks like. And it requires every link in this chain to function.

To tie it all together visually, here is the complete message flow — from grid operator signal to EV inverter response — as a sequence diagram.

Where things stand in 2026: OCPP 2.1 has been published; Sections Q and R are available for implementation. ISO 15118-20 is published and being deployed, though some commercial programmes today — including Ford/Octopus — are still running on ISO 15118-2 with proprietary extensions. Amendment 1 is in draft form, expected to finalise in H2 2026. The EU’s AFIR regulation mandates ISO 15118-20 compliance for bidirectional charging communication by 1 January 2027 — a tight window for charger manufacturers to have Amendment 1-capable hardware in production.

The commercial V2G market is running slightly ahead of its standardised communication layer, and that is not a problem in itself — pilots and bespoke arrangements are how the industry builds experience. What the completion of this chain unlocks is different: Section Q and Section R form the CSMS layer, ISO 15118-20 base is the power control layer, and Amendment 1 is the last mile from charger to inverter. The pieces are in place. The chain is not yet complete everywhere — but the direction is clear.

Here is the part that matters for grid stability: when a BMW iX3 feeds 11 kW back to the grid at six o’clock in the evening, it is no longer just a car. It is a generator. And generators do not play by the same rules as consumers.

In the previous article, I covered the Demand Connection Code (DCC) — the EU rulebook for devices that consume electricity from the grid. Fault Ride-Through, LFSM-UC, RoCoF: those requirements govern EV chargers as so-called demand facilities. The moment an EV discharges energy back into the grid, a completely different regulation takes over: the Requirements for Generators (RfG), Commission Regulation (EU) 2016/631.

In this article, you’ll learn what changes the moment your EV starts feeding power back to the grid, and what that means for the standards, protocols, and certifications shaping V2G today:

• Why AC and DC V2G have fundamentally different compliance architectures, and who is responsible for grid code certification in each case

• What the Requirements for Generators (RfG) demands from a V2G unit: frequency response, interface protection, and reactive power control

• How national grid codes in Germany, the Netherlands, and the UK differ — and why they are slowly converging

Subscribe now

AC or DC? The answer determines who gets certified

Before getting into what the grid codes require, there is an architectural question that changes everything: where is the inverter?

V2G requires converting between DC (Direct Current, the format in which a battery stores energy) and AC (Alternating Current, the format the grid runs on). The inverter is the device that does this conversion. In normal charging it runs in one direction; in V2G it must run in both. The critical question is where that inverter physically sits, and the answer differs between AC and DC V2G.

DC V2G (CCS DC, CHAdeMO): the inverter is built into the charging station. When the session reverses, it is the charger’s inverter that handles DC-to-AC conversion and connects to the grid. Grid code compliance — frequency response, reactive power control, interface protection — is the responsibility of the charging station manufacturer. The EV contributes its battery and nothing else. The Ford Explorer and Ford Capri are DC V2G vehicles: they connect via CCS Combo 2 to the Ambibox ambiCHARGE DC wallbox, which carries the inverter and bears the compliance burden.

AC V2G (Type 2 AC bidirectional, as used by the Renault 5, for example): the inverter is the EV’s own on-board charger (OBC). It already converts AC from the grid into DC to charge the battery. For V2G, it must also run in reverse: DC from battery back to AC into the grid. That means grid code compliance for the inverter functions is the responsibility of the vehicle manufacturer — but, as we will see, the charging station carries its own compliance obligations too.

In DC V2G, a charger manufacturer can build and certify a grid-compliant charging station independently of any specific vehicle. In AC V2G, the EV manufacturer must ensure the OBC meets all generator requirements. And because that inverter is inside the car, it must be certified as part of the vehicle itself.

The function split for AC V2G certification flows directly from this architecture. For a complete AC V2G system to be compliant, responsibilities are divided:

• The EV must handle: LFSM-U (increasing active power output during under-frequency) and LFSM-O (reducing active power output during over-frequency). These are the inverter functions that restore grid stability — the EV’s contribution to active power control. Quick reminder: LFSM-U stands for Limited Frequency Sensitivity Mode – Underfrequency, and the “-O” stands for Overfrequency.

• The charging station must handle: interface protection (automatic disconnection when voltage or frequency exceeds safe limits) and anti-islanding (detecting and disconnecting from an unintentionally isolated section of the grid). These are the grid protection functions, which are the EVSE’s responsibility, not the vehicle’s.

• Both must handle: Frequency Ride Through (staying connected during frequency deviations), RoCoF Ride Through (staying connected during rapid frequency changes), logic interface, and automatic (re)connection. And critically: the communication link. The EV inverter must stay connected during a voltage dip, but so must the ISO 15118-20 session running over the charging cable. If the charging station drops its Power Line Communication (PLC) session during a fault event, the EV loses its control signals and may trip off regardless of what its inverter would otherwise do. Ride-through is a system requirement, not just an inverter requirement.

The generator rulebook

When a V2G unit discharges to the grid, it falls under the Requirements for Generators (RfG), EU Regulation 2016/631. The RfG sets the principles: generating plants must meet certain technical requirements to connect. For the actual numbers — voltage thresholds, frequency ranges, protection settings — it points to European standards. Understanding the layering matters, because these three instruments are frequently conflated:

RfG is the EU legal instrument. It is the law that states “generating plants must comply with technical connection requirements.” It applies across all EU member states and cannot be overridden at national level. But it deliberately avoids specifying every parameter. Instead, it delegates specifics to European standards.

EN 50549-1 (a CENELEC standard) is where those specifics live for distribution-level generators at low voltage (≤1 kV). This covers most residential and commercial V2G: a BMW iX3 or Ford Explorer on a home wallbox, a Renault 5 fleet depot, a neighbourhood V2G hub. EN 50549-2 covers medium voltage (1–35 kV), relevant for larger fleet installations.

EN 50549-10 is the test standard. To prove compliance with EN 50549-1, you need a formal test report based on EN 50549-10. This is the compliance verification document. Without it, you cannot certify your V2G unit as grid-compliant.

ACER’s proposed amendments to the RfG introduce three dedicated V2G categories within this framework: EV1 (0.8–2.4 kW), EV2 (2.4–50 kW), and EV3 (50 kW–1 MW), with proportionate compliance requirements at each tier. Most residential V2G systems — Ford/Octopus at 11 kW, BMW/E.ON — fall into EV2.

V2G frequency response when discharging power

In the previous article, I explained LFSM-UC (Limited Frequency Sensitivity Mode – Underfrequency Control): when grid frequency drops below 49.8 Hz, V1G chargers must automatically reduce consumption to help stabilise the grid (5% droop). The “C” is deliberate — it is the demand-side variant, defined in the Demand Connection Code for units that control their consumption; the generator-side equivalent in the RfG drops the C and is simply called LFSM-U. V2G adds the mirror image, and it’s more demanding.

When frequency drops, a V2G unit must not just reduce consumption. It must increase discharge, i.e. act like a generator ramping up output to rescue the grid. The droop setting for this response is 2% — the value mandated by VDE 4105 and ElaadNL, and the tightest end of EN 50549-1’s 2–12% range.

“2% droop” sounds abstract. Here is what it means in practice.

Most electricity grids run at exactly 50 Hz (with the exception of e.g. the US, which runs on 60 Hz) because that frequency is what keeps generators, motors, and devices in sync. It is a constant tightrope walk between how much power is being generated and how much is being consumed. When demand spikes — everyone’s kettle on at half time — frequency starts to fall. Left uncorrected, that becomes a blackout.

V2G units are part of the answer. The moment they detect falling frequency, they discharge more power into the grid — automatically, with no command from anyone. But how much more? That’s what droop defines.

Think of it like a dimmer switch, not a light switch. A regular switch is binary: fully on or fully off. A dimmer gives a graduated response — push it a little, a little more light; push it further, much brighter. Droop makes a V2G unit behave the same way: the further frequency falls below the threshold, the more power it adds. Proportionally. Continuously. Without anyone touching anything.

At 2% droop, that proportionality works out to one simple rule:

For every 0.1 Hz the frequency falls below the 49.8 Hz threshold, the unit increases its discharge by 10% of its rated power.

In practice, for a 7.4 kW V2G unit currently discharging at 3 kW:

No operator call, no message from a control room. The inverter reads the frequency at the socket, in real time, and adjusts.

The “2%” label comes from the engineering definition of droop, for those who want it:

Plugging in the extreme case: a 1 Hz drop is exactly 2% of 50 Hz, demanding 100% of rated output. The droop setting is designed so the worst realistic emergency triggers maximum response. Everything between zero and 1 Hz scales linearly between those extremes.

The threshold is configurable between 49.5 and 49.8 Hz; the default is 49.8 Hz.

I’ve tried to capture the above in an illustrative example. Here’s the thing: I understand the protocols that carry these parameters better than the power engineering that defines them. If the diagram below is making a grid engineer somewhere reach for a red pen, please do reach out. I would rather be corrected than confidently wrong.

Multiply this across tens of thousands of V2G EVs connected across a country on a winter evening, and that autonomous response aggregates into gigawatts of fast-acting frequency support.

Interface protection: the emergency circuit breaker

Frequency response governs how V2G units behave during normal grid disturbances. Interface protection governs what they do during a full emergency.

When voltage or frequency goes outside safe limits and stays there long enough, the V2G unit must disconnect automatically. Not to protect itself primarily, but to prevent an inverter from continuing to energise a section of grid that may be isolated or under fault. This is the fail-safe that sits behind the ride-through requirements: Frequency Ride-Through says “stay connected through minor events”; interface protection says “when it is a real emergency, get off the grid fast.”

Under EN 50549-1, the disconnection thresholds for units rated between 0.8 and 11 kW are:

• UV1 (under-voltage): below 80% of nominal voltage → disconnect within 2 seconds

• OV1 (over-voltage): above 110% of nominal voltage → disconnect within 2 seconds

• UF1 (under-frequency): below 47.5 Hz → disconnect within 2 seconds

• UF2 (over-frequency): above 51.5 Hz → disconnect within 2 seconds

For units above 11 kW, there is an additional, faster threshold: UV2 at 70% of nominal voltage → disconnect within 0.2 seconds. The reasoning is proportionate: a higher-power unit can cause more damage if it keeps operating during a deep voltage sag, so it must trip faster.

To put this in context from my previous article: the ride-through curves (FRT, LFSM) describe where the unit must stay connected and contribute. Interface protection describes where it must finally let go. These are the same boundaries explored for demand units — now approached from the generator side.

Reactive power control: the part everyone finds confusing

Frequency and voltage are two different problems. We’ve just covered how V2G units respond to frequency deviations by adjusting active power — the real energy flowing in and out. Voltage is a separate challenge: it can drift and sag at the local level even when the wider grid is stable, and the tool for managing it is reactive power.

If reactive power, power factor, and the difference between “lagging” and “leading” are not already in your vocabulary, Paul from The Engineering Mindset explains all of it far better than I can in prose: Power Factor Explained. Ten minutes, very much worth it. The rest of this section picks up from there.

The reason V2G matters for reactive power is simple: an inverter that can push energy in both directions can also push reactive power in both directions. That makes it a voltage control device as well as a storage device.

EN 50549-1 specifies four modes through which V2G units can provide reactive power support. Think of them as a spectrum from fully manual to fully autonomous:

Q setpoint mode (manual). The grid operator sends a direct command: “inject 1 kVAr.” The inverter holds that value until told otherwise. Precise, but operationally intensive: every adjustment requires a new instruction.

Cos φ setpoint mode (set-and-forget). A fixed power factor is programmed in (e.g. 0.95 lagging), and the inverter maintains it automatically regardless of what is happening on the local network. No ongoing commands needed, but it cannot respond to changing conditions. It does what it was told, not what the grid currently needs.

Cos φ(P) mode (rule-based). The power factor shifts automatically depending on how much active power the unit is delivering: at low output, unity power factor; at high output, a lagging or leading contribution defined by a curve set at installation. Automatic, but the rules are fixed.

Q(U) mode (fully autonomous, and the most powerful of the four). A note on the notation first: in European power engineering, Q is the standard symbol for reactive power and U is the IEC symbol for voltage (European standards use U rather than V to avoid confusion with the unit volt). Q(U) simply means “reactive power as a function of voltage.”

Reactive power adjusts continuously based on the actual voltage the inverter measures at the socket. When voltage climbs above a threshold, it absorbs reactive power, pulling voltage back down. When voltage dips, it injects reactive power, pushing it back up. No command. No update. Just the inverter reading the voltage and acting.

Within a deadband around nominal voltage — typically ±5%, so 218.5–241.5 V on a 230 V network — the unit does nothing. Normal voltage requires no intervention. The response only activates outside that window.

The exact voltage breakpoints and deadband width are set by the distribution network operator and can be updated remotely — which is precisely what OCPP 2.1’s SetDERControlRequest enables, which we’ll cover in the upcoming article.

In practice: it is a sunny July afternoon, rooftop solar generation is high, and local voltage has climbed to 247 V — 7% above nominal 230 V. Every V2G EV on a home wallbox in the neighbourhood has Q(U) mode enabled. Each one automatically absorbs reactive power, attenuating the voltage rise without anyone issuing a command. By 6 pm when those same EVs begin discharging into the evening peak, the local voltage is already under control. That is distributed voltage regulation. No control centre, no communication overhead, no manual instruction.

A patchwork of national grid codes — converging slowly

The EU-level RfG amendment covering V2G is still progressing through the Commission's comitology process. Mandatory compliance is realistically around 2030. In the meantime, national grid codes govern V2G deployments — and they differ.

The table below represents my best effort to gather accurate data, but if you are an electrical / power engineer and spot an error, then please do reach out.

A note on the UK column: G99 Issue 2 (March 2025) extended coverage to storage-based generating units — including V2G — effective March 2026. Unlike Germany and the Netherlands, G98/G99 does not mandate a fixed droop value; the setting is configurable within the 2–10% range, determined by the DNO at connection approval. The voltage trip thresholds marked [VERIFY] should be confirmed against the current G99 Issue 2 text. If you happen to know more details, please let me know.

Germany’s VDE-AR-N 4105:2026-03, effective March 2026, deserves particular attention: it is the first national standard to formally include V2G and V2H requirements, making Germany the first EU country with an active, enforceable V2G grid code. As far as I know, Ford × Octopus and BMW × E.ON are both operating under it today.

One aspect of VDE 4105 stands out: unlike PV inverters — where only the inverter unit needs certification — V2G under VDE 4105 requires certification of the entire functional system: vehicle model, charging cable type, and wallbox model as an integrated unit. A specific Ford Explorer certified with a specific Ambibox wallbox does not automatically certify the same Explorer with a different wallbox. For V2G to scale across millions of vehicles and hundreds of charger models, this system-level certification requirement needs to evolve. It is part of what EU-level RfG harmonisation will eventually need to address. In the meantime: if you have a certified V2G system, cherish it. Don’t even change the cable (never touch a running system, remember?)

A notable point in the Dutch framework: the ElaadNL V2G Implementation Guide 2025 explicitly states that a unit certified under VDE 4105 (with a VDE 0124-100 test report) or Belgian C10/11 (with a C10/26 test report) is accepted as compliant in the Netherlands. This might seem surprising — why would a German national standard satisfy Dutch requirements?

The answer is that VDE 4105, C10/11, and the Dutch framework are all national implementations of the same underlying standard: EN 50549-1. Their core interface protection parameters — voltage trip thresholds, frequency limits — are harmonised to the same values. A device that passes VDE 0124-100 testing has effectively demonstrated compliance with EN 50549-1. The Netherlands recognises this equivalence explicitly, and it is EN 50549’s design working as intended: national codes with minimal technical divergence in the parameters that actually matter for grid safety.

The rulebook is ready. The wiring is almost there.

That, in brief, is where the grid code landscape stands today. I do realise that I’ve been focusing on the UK and EU and left out the US, Australia, or other parts of the globe in this article. Please feel free to reach out to me if you have information on grid codes in these regions and I’ll make sure to include this information in a future post.

V2G turns an EV from a consumer into a generator, and the regulatory apparatus that governs generators is catching up. The RfG provides the legal foundation. EN 50549-1 specifies the technical parameters. VDE 4105:2026-03 enforces them in Germany right now, with BMW × E.ON and Ford × Octopus both operating under it today. Other national codes are converging to the same baseline.

But grid codes on paper don’t configure inverters in cars. Getting those parameters — droop curves, Q(U) profiles, voltage trip thresholds — from a grid operator’s systems into the on-board charger inside a vehicle requires a protocol chain that most of the industry has barely started thinking about.

In the next article, we’ll cover OCPP 2.1’s DER (Distributed Energy Resource) control messages, the last-mile problem from charging station to EV inverter, and why ISO 15118-20 Amendment 1 is the piece that makes dynamic grid code compliance possible at all.

The answer: grid codes. These are the rulebook that every device connected to the electricity grid must follow. And yet, in the EV charging industry, very few people truly understand what they are, how they work, and why they’re about to become a lot more relevant.

In this article, I’ll explain what grid codes actually are, why they exist, what the key technical requirements look like (with concrete examples you can actually understand), and what’s changing with the upcoming amendments to the European Demand Connection Code — a regulation that directly impacts EV chargers and electric vehicles.

Subscribe now

Grid codes are building codes — for the electricity grid

Think of grid codes like building codes for a city’s electrical infrastructure. Just as building codes ensure that every structure can withstand earthquakes, support certain loads, and meet fire safety standards, grid codes ensure that every device connected to the electricity grid behaves in a way that keeps the system stable and safe.

Without building codes, one poorly constructed building could collapse and damage its neighbours. Without grid codes, one misbehaving device — or millions of them — could destabilise the entire electricity system.

Grid codes define the technical rules that equipment (like EVs and charging stations) must follow to connect to and operate on the electricity grid. They cover things like:

• What voltage and frequency ranges equipment must tolerate without disconnecting

• How equipment must behave during grid faults (e.g. a short circuit on a transmission line)

• What power quality standards equipment must meet

• What information must be exchanged between the equipment owner and the grid operator

These aren’t guidelines or recommendations, they’re binding regulations. Grid codes exist in every country.

In this article, we’re focusing on the European grid code regulation as there are important changes underway that will help harmonise the integration of EVs and chargers into the European electricity grid across all member states.

The European grid code family

Europe has developed a comprehensive set of grid codes under the Third Energy Package. The three core connection codes are:

1. Requirements for Generators (RfG): Commission Regulation (EU) 2016/631. Covers power plants, wind farms, solar parks — anything that generates and feeds electricity into the grid.

2. Demand Connection Code (DCC): Commission Regulation (EU) 2016/1388. Covers everything that consumes electricity from the grid: factories, buildings, EV chargers, heat pumps, data centres — all demand-side equipment.

3. High Voltage Direct Current Code (HVDC): Commission Regulation (EU) 2016/1447. Covers HVDC systems and the DC-connected power park modules used in subsea cables and long-distance interconnectors.

Together, these codes form a coherent regulatory architecture. Generators, consumers, and interconnectors each have their own rulebook — but all three are designed to work in harmony to keep the grid stable.

For EV charging, the relevant code is the Demand Connection Code.

The Demand Connection Code: what it covers

The DCC, formally Commission Regulation (EU) 2016/1388, was adopted in August 2016. It establishes harmonised technical requirements for connecting demand facilities to transmission and distribution networks across the EU. In plain English: it defines the technical minimum standard that any electricity-consuming equipment must meet to be allowed onto the grid.

The DCC applies to:

• Transmission-connected demand facilities: large industrial consumers connected directly to high-voltage transmission networks

• Distribution-connected demand facilities: anything connected to the lower-voltage distribution grid, including commercial buildings, EV charging sites, and residential connections above certain thresholds

• Closed distribution systems: private networks like airports, ports, or large campuses

• Demand units providing demand response services: equipment that actively participates in grid balancing (though this is changing — more on that below)

So where does EV charging fit in? EV chargers are demand facilities connected to the distribution grid. As charging infrastructure scales up — large charging hubs with dozens of high-power chargers drawing hundreds of kilowatts — these installations become significant grid assets. The grid code ensures they play by the rules.

Grid codes in practice: what the technical requirements actually look like

This is where most explanations of grid codes lose people. Let me try to make this tangible with concrete examples from the DCC.

Frequency: staying in the safe zone

The European electricity grid operates at a nominal frequency of 50 Hz. This frequency is a direct indicator of the balance between electricity generation and consumption across the entire interconnected system. When supply and demand are perfectly matched, frequency sits at 50.00 Hz. When demand exceeds supply (more power consumed than generated), frequency drops. When supply exceeds demand, frequency rises.

The DCC requires demand facilities to remain connected and operational across a frequency range of 47.5 Hz to 52.0 Hz. That might sound like a small window, but in grid terms, even a 0.5 Hz deviation from 50 Hz signals a serious imbalance.

Think of grid frequency like a resting heart rate. A healthy grid beats at exactly 50 Hz. A drop of just 0.5 Hz — one percent — already signals a serious imbalance. A drop to 47.5 Hz is a full-blown emergency. It’s like a resting heart rate that’s supposed to sit at 60 bpm — if it dips to 57, most people wouldn’t worry. But the grid is far less forgiving. In grid terms, that same 5% deviation is the difference between normal operation and the threshold where equipment is allowed to disconnect. Every fraction of a Hertz matters. The grid code says: your equipment must stay connected and ride through these events, not trip and disconnect — because mass disconnection of loads would make the problem worse, not better.

You can actually trace the current and past frequency of the European, British, and the Nordic electricity grid at Gridradar.

Voltage: keeping it within bounds

The DCC also specifies voltage requirements. Equipment must remain connected and operational across a voltage range of 0.85 pu to 1.10 pu at the connection point. The unit “pu” stands for per unit — it’s a normalised way of expressing voltage relative to the nominal value. So 1.0 pu = nominal voltage (e.g. 230V for low-voltage or 400V for three-phase), 0.85 pu = 85% of nominal, and 1.10 pu = 110% of nominal.

Why does voltage fluctuate? Every time a large load switches on or off — a factory starting a production line, a charging hub ramping up — the local voltage dips or rises. The grid code says: your equipment must handle these fluctuations without tripping. If your EV charger shuts down every time the voltage dips to 210V (0.91 pu), that’s a problem.

Fault Ride-Through: don’t abandon ship

Fault Ride-Through (FRT) is one of the most important and least understood grid code requirements. Here’s the scenario: a tree falls on a transmission line, causing a short circuit. The voltage at the fault point drops to near zero. This voltage dip propagates through the network, reaching your EV charging hub as a brief but significant voltage drop.

The old behaviour of connected equipment was simple: detect low voltage, disconnect, protect yourself. But when millions of devices all disconnect simultaneously during a grid fault, the sudden loss of load creates a massive imbalance that can cascade into a wider blackout. That’s exactly what grid codes are designed to prevent.

FRT requires equipment to remain connected during short-duration voltage dips — riding through the fault rather than disconnecting. The DCC defines a voltage-against-time profile: how deep the voltage can drop and for how long the equipment must stay connected.

Under the proposed ACER (EU Agency for the Cooperation of Energy Regulators) amendments to the DCC, there will be a harmonised, binding FRT profile specifically for EV chargers, V1G electric vehicles, heat pumps, and power-to-gas units. This means a single European-wide standard — no more varying national requirements. Manufacturers can design one product that works everywhere.

The diagram shows the minimum voltage behaviour required at the connection point during and after a grid fault, expressed as a fraction of normal voltage (1.0 pu). Voltage drops to U_ret when the fault strikes and holds there until the fault is cleared at t_clear. Recovery then happens in stages: voltage rises to U_rec1 by t_rec1, briefly plateaus, then climbs to U_rec2 by t_rec3. Equipment must remain connected for any voltage path that stays on or above this curve.

The voltage parameters (in pu, i.e. per unit — see above) for the fault-ride-through capability of V1G (unidirectional charging) EVs and associated EV chargers are:

• U_ret: 0.05

• U_clear: 0.15

• U_rec1: 0.15

• U_rec2: 0.85

The time parameters (in seconds) are:

• t_clear: 0.15

• t_rec1: 0.15

• t_rec2: 0.15

• t_rec3: 3.0

LFSM-UC: automatic power reduction when the grid is stressed

Limited Frequency Sensitive Mode – Underfrequency Control (LFSM-UC) is a requirement for certain demand equipment to automatically reduce its power consumption when grid frequency drops below a threshold. This is particularly relevant for EV chargers.

Here’s how it works for EVs, chargers, and power-to-gas units under the proposed amendments:

• Frequency threshold: 49.8 Hz (or 49.5 Hz for the Irish and Nordic synchronous areas)

• Droop setting: 5% — this defines how aggressively power is reduced per Hz of frequency deviation

• Response time: 0.5 seconds or less

• When frequency drops below 49.8 Hz, the charger must automatically reduce its power consumption, scaling down proportionally until it reaches its minimum operating level

• If the minimum operating level exceeds 20% of rated power, the unit must disconnect entirely

• After disconnection, a random reconnection delay of up to 5 minutes prevents all devices from reconnecting simultaneously (which would cause a second frequency dip)

Think of this like a thermostat for the grid. When the system is under stress (frequency dropping), every connected device needs to ease off — automatically, without waiting for a human command. Your EV charger might slow down from 11 kW to 6 kW for a few minutes. You probably wouldn’t even notice, but multiplied across millions of chargers, that reduction can prevent a blackout.

RoCoF: riding out rapid frequency changes

Rate-of-Change-of-Frequency (RoCoF) measures how quickly the grid frequency is changing — expressed in Hz per second. During sudden imbalances (e.g. a large power plant tripping offline), the frequency doesn’t just drop — it drops fast. Equipment must be able to withstand these rapid changes without disconnecting.

The proposed DCC amendments specify binding RoCoF withstand values for EVs, EV chargers, and heat pumps:

• ±4,0 Hz/s over a period of 0,25 s

• ±2,0 Hz/s over a period of 0,5 s

• ±1,5 Hz/s over a period of 1 s

• ±1,25 Hz/s over a period of 2 s

The faster the frequency change, the shorter the equipment needs to withstand it — but it must not disconnect during these transients. This is a new, harmonised EU-wide requirement that replaces previously varying national specifications, giving manufacturers a single design target.

What’s changing: the ACER amendments and why they matter

ACER submitted Recommendation 03-2023 to the European Commission in December 2023, covering amendments to two of the three grid connection regulations: the Requirements for Generators (RfG) and the Demand Connection Code (DCC).

The RfG — which covers power plants, wind farms, and anything that generates electricity — was written in 2016, before EVs and battery storage became serious grid players. ACER’s proposals bring them into scope: updated definitions to reflect today’s technology mix, a process for modernising older generation equipment rather than forcing it through the full new compliance regime, and dedicated technical requirements for EVs, EV charging parks, and electricity storage modules.

The DCC proposals follow the same logic on the demand side: expand scope to include EVs, EV chargers, heat pumps, and power-to-gas units (none of which featured meaningfully in the 2016 original), create a similar modernisation pathway for existing connected facilities, and introduce updated technical requirements for transmission-connected demand facilities and distribution systems.

This article focuses on the DCC. Within those amendments, the most significant structural change is a separation of concerns:

• The DCC retains all technical connection requirements — the rules your equipment must meet to physically connect to the grid (frequency, voltage, FRT, RoCoF, etc.)

• Service-related provisions (demand response participation, flexibility market access, aggregation) are being moved out of the DCC and into the System Operation Guideline (SO GL) and the forthcoming Network Code on Demand Response (NC DR)

Why does this matter? Because it creates a clean distinction between two things that were previously tangled together:

1. Grid-compliant: your equipment meets the baseline technical connection standards. It can safely connect to the grid.

2. Grid-service capable: your equipment has enhanced functionalities — it can actively participate in frequency support, demand response, and flexibility markets.

For EV charger and vehicle manufacturers, this is significant. The amended DCC explicitly includes V1G (uni-directional charging) electric vehicles and EVSEs (Electric Vehicle Supply Equipments, i.e. charging stations in DCC terminology) for the first time as a distinct category with dedicated technical requirements. You’ll know exactly what your product must do to be grid-compliant across all EU Member States — and anything beyond that (like participating in flexibility markets) is governed by a separate regulation.

This is also the first time the DCC introduces harmonised, binding technical requirements (FRT, LFSM-UC, RoCoF) for EV/EV chargers that override national variations. One set of rules. One compliance target. One product for the whole EU market.

What the EV charging industry should do now

This isn’t a distant regulatory exercise. The amendments are being finalised, and manufacturers, charge point operators, and facility owners need to start preparing:

• Manufacturers: verify that your hardware and power electronics can meet the harmonised FRT, LFSM-UC, and RoCoF requirements. Start preparing compliance documentation — certificates and Demand Unit Documents (DUDs) will be required for equipment connected above 1,000V.

• Charge point operators: assess your existing charging sites against the new technical thresholds. Early compliance avoids costly retrofits.

• Facility owners: understand the separation between connection compliance (mandatory) and market participation (optional). Plan your investments accordingly.

Important caveat: The ACER amendments described in this article are currently at the recommendation stage — they are not yet adopted EU law. ACER submitted its Recommendation 03-2023 to the European Commission in December 2023, proposing amendments to both the RfG and DCC. A separate Recommendation 01-2025 on the new Network Code on Demand Response (NC DR) followed in March 2025. The Commission must still run its comitology process (Member State vote) before adoption — no date has been set. Once published in the Official Journal, moreover, most technical requirements don’t apply immediately: Article 59 of the draft specifies they take effect three years after publication. As an EU Regulation rather than a Directive, there’s no national transposition step — it applies directly in all Member States — but that built-in lead time means manufacturers and CPOs wouldn’t face compliance obligations until around 2030 at the earliest. You can read the full proposed amended DCC text in Annex 2 of ACER Recommendation 03-2023, and the original Demand Connection Code on EUR-Lex.

None of this means the industry is standing still waiting for the regulation to catch up. Commercial V2G (Vehicle-to-Grid, bidirectional charging) — far more technically demanding than V1G — is already live in Europe: in France (Renault Mobilize and The Mobility House), Germany (BMW and E.ON, and Octopus Energy with Ford), and the Netherlands (the Utrecht Energized V2G car-sharing fleet). These work through bespoke arrangements with individual utilities and grid operators, negotiating existing national codes project by project.

What the DCC amendments would change is not whether V1G or V2G can happen — clearly they already can — but whether they can scale across all 27 EU member states without every deployment requiring its own regulatory workaround.

On EU regulatory speed. Macron himself acknowledged at Davos that Europe is “sometimes too slow, for sure, and needs to be reformed, for sure“ (see min 21:45). The ACER amendment was submitted in December 2023. It might be adopted in 2027. Under Article 59 of the draft, technical requirements then apply three years after publication — so mandatory compliance is realistically closer to 2030. That’s seven years from proposal to enforcement — not exactly a speedy process, for sure (it’s worth watching this amusing video, here’s the context for the uninitiated 😁).

Much of the technical analysis in this article draws on an excellent white paper the CharIN Focus Group Grid Integration & Energy (in collaboration with P3 Group) released end of February: ACER’s amendment proposals for the European Grid Codes (2026). It provides a detailed, EV/EVSE-focused breakdown of the proposed DCC amendments and is well worth reading if you want to go deeper.

The bottom line

Grid codes are invisible to the end user — and that’s exactly the point. They’re the rules that keep the lights on when millions of devices are pulling power from the same system. As EV charging infrastructure scales, these rules are becoming more specific, more harmonised, and more relevant to our industry than ever.

The ACER amendments to the Demand Connection Code mark a turning point: for the first time, EV chargers and electric vehicles have their own dedicated set of EU-wide technical requirements. One standard. No national patchwork. That’s good for manufacturers, good for operators, and good for the grid.

The grid doesn’t care about your brand or your business model. It cares about physics. And grid codes are how we make sure physics wins.

You may wonder: but what about grid codes for V2G? And what role does OCPP and ISO 15118 play in relation to these grid codes? That, my dear friend, is a story for future articles. So stay tuned and watch out for more grid code / V2G related news in the coming weeks and months (and subscribe, if you haven’t done so yet).

Learn more about Plug & Charge in my five-part articles series. It covers everything from market actors to cryptographic foundations and the complete workflow to create, install and use the all-important digital contract certificate that enables and secure seamless EV charging. All you need to know to master Plug & Charge.

The panel brought together perspectives from across the EV charging ecosystem: a standards expert (myself), two leading European charge point operators (CPOs), and a charger manufacturer’s R&D lead. Here’s what they had to say.

Subscribe now

Meet the panellists

Marc Mültin (myself): Director of Technology Strategy & Innovation at Believ in the UK. I’m a globally recognised expert and co-author of ISO 15118 and OCPP 2.0.1. With a PhD in Computer Science and over 15 years in e-mobility, I have trained 80+ companies worldwide on EV communication standards and run this popular Current Affairs newsletter educating the industry on what’s really happening behind the scenes.

Daniel Porubcsánszki: Charging Solutions Engineer at Allego in The Netherlands. Daniel works at one of Europe’s top CPOs, which operates over 34,000 public charging points across 16 countries. He brought the real-world deployment perspective — having personally driven the rollout of OCPP 2.0.1 and Plug & Charge across Allego’s high-power DC charging network.

Kasper Dahl: Responsible for Product Strategy and Portfolio at Clever in Denmark. Clever is the leading CPO in Denmark, operating both AC and DC chargers across public and semi-public locations. Kasper joined remotely and brought the market and user experience lens, particularly from a market where 90% of new car sales are already fully electric.

Matej Anzin: Head of R&D at Etrel in Slovenia. With over seven years at Etrel, first as R&D Manager and now heading the department, Matej brought the charger manufacturer’s perspective on implementing ISO 15118 and the practical challenges of making it work in hardware.

The panel was moderated by Erazem Štancar, Regional Sales Manager at Etrel.

Key insights from the discussion

You can listen to the full panel discussion in the audio recording linked above. Unfortunately, the video recording was corrupted — but look on the bright side: for once you get to hear my voice instead of just reading another one of my lengthy articles.

Below are the 11 highlights summarised.

1. Regulation is driving adoption faster than expected

One of the biggest drivers of ISO 15118 adoption is regulation and compliance. Since January 2026, all newly installed charging stations in the EU must support ISO 15118-2. As Daniel from Allego noted, Plug & Charge interest and usage “is picking up and it’s more popular than we expected.” What was once a nice-to-have is now becoming a must-have, and the industry is responding.

2. “Following the standard” isn’t enough for interoperability

In theory, everyone implementing the same standard should guarantee interoperability. In practice, different interpretations of ISO 15118 — plus gaps in implementation — still cause systems that should work together to fail. I illustrated this with a concrete example: one message in ISO 15118 called PowerDeliveryReq (request message the EV sends to the charger) contains a parameter for the ChargingProfile that communicates how the EV intends to charge, and it’s marked as “optional.” But it’s only optional because the same message is used both to start and stop a session. When starting, the parameter is actually required. Some less diligent implementers skip it because it says “optional” — and interoperability goes down the drain.

3. Compliance testing is only 50% of the effort

Getting certified against the conformance test specifications (ISO 15118-4 and -5) is important, but it’s only half the battle. The other half is real-world interoperability testing, because you can be fully compliant with the standard and still run into issues. The interoperability testing events, also known as “Testivals”, have been running since around 2016 and hosted by CharIN since 2019 — since then also known as CharIN Testivals. These events remain the best venue for discovering edge cases, until a comprehensive “golden test device” exists that covers all possible scenarios.

4. Collaboration is the real bottleneck

Plug & Charge isn’t built by one player. It requires tight coordination between vehicle and charger manufacturers (aka OEMs), Charge Point Operators (CPOs), Mobility Service Providers (MSPs), and public key infrastructure (PKI) providers like Hubject or Irdeto. Daniel shared how it took significant cross-company effort to get Plug & Charge working across Allego’s network with even just one charger vendor. The message: start working together as early as possible. Don’t wait until you think your implementation is “ready” — get it into testing with real partners immediately.

5. Smart charging is a massive (and underappreciated) value driver

While Plug & Charge gets most of the attention, the panellists highlighted that smart charging — already possible with ISO 15118-2 — is an equally important value driver. I stressed that ISO 15118 is the only way to know how much energy the EV needs and when the driver intends to leave the charging station. Without these data points, real smart charging is impossible. And you don’t need the newer ISO 15118-20 for this — it’s already built into the existing standard.

6. V2G is the biggest long-term business case

For Kasper at Clever, the biggest value proposition of ISO 15118 is the potential for Vehicle-to-Grid services. Bidirectional charging, energy arbitrage (charging during cheap hours), and providing grid stability services represent a “very positive business case.” ISO 15118-20 is the key enabler for V2G, alongside wireless charging and Megawatt Charging. While some grid-side standardisation still needs to mature, the potential is enormous.

7. Cybersecurity matters more than people realise

Daniel emphasised that one of Allego’s primary motivations for moving to ISO 15118 was cybersecurity. The TLS-based security in ISO 15118 is a significant step up from RFID cards, which are trivially cloneable. As Daniel put it: “It’s just not that marketable to say we are doing the move because of cybersecurity” — but it’s becoming increasingly critical as the charging infrastructure scales.

8. The charger screen is crucial for the user experience

When Plug & Charge goes wrong, the CPO often doesn’t know who the user is (since authentication failed), and therefore can’t send them a message via their app. The charger’s display becomes the only communication channel. I stressed that charger manufacturers need to enable CPOs to surface meaningful error information — not just “computer says no” but specific guidance like “your certificate has expired, please check with your mobility service provider.” I also noted the CharIN initiative on unified error codes across ISO 15118 and OCPP, which could be a significant step forward for troubleshooting.

9. The RFID vs. Plug & Charge conflict is real — and tricky

A practical challenge the panellists discussed at length: what happens when a user plugs in their EV and it starts the Plug & Charge process, but they actually want to use their RFID card? Or when someone swipes their card first and then plugs in? This can lead to “interruption errors” and even double-charging customers. One approach is once the cable is plugged in, the RFID reader is blocked for a period to avoid conflicts. But this creates its own UX problems. I suggested that chargers could prompt users on screen: “Your car supports Plug & Charge. Do you want to use it? Yes/No”, giving them a 30-second window before defaulting to Plug & Charge.

10. Multi-contract handling is key for user convenience

Not all charging sessions should go to the same billing account. I highlighted BMW as a good example: they support up to five different MSP contracts for Plug & Charge, so drivers can choose which one to use — similar to selecting a different card in Apple Pay. This is particularly relevant for company car drivers who sometimes charge privately and sometimes on the company account. Some OEMs do a much better job than others at making Plug & Charge activation intuitive in their in-car HMI. Some drivers don’t even know the feature exists in their car.

11. Don’t reinvent the wheel

ISO 15118 and OCPP 2.0.1 are becoming baseline capabilities, not differentiators. I pointed out that there are now a handful of proven software stack providers for charger manufacturers, including the open-source EVerest from Pionix, EcoG OS from EcoG, and vSECClib from Vector. Plus charge controllers you can get from vendors like chargebyte (for both EV and charger). The advice: use what’s proven, integrate it, and differentiate on other things — like user experience, hardware design, and smart services on top.

The Bottom Line

ISO 15118 is transitioning from a niche technical standard to a foundational layer of the EV charging experience. The panellists agreed that we are likely just one to two years away from widespread rollout across Europe and the UK, and possibly also the US. But getting there requires more than technical compliance — it demands cross-industry collaboration, rigorous real-world testing, and an unrelenting focus on making the user experience seamless.

As Kasper from Clever put it: “If we start requiring customers to educate themselves or do things in a particular way, I think we’ve failed as an industry”.

The tech can be complex. The experience can’t be.

Below is also a short presentation from Etrel with some high-level insights from the panel discussion.

Re Charging Days 2026 Iso 15118 Insights

4.96MB ∙ PDF file

Download

Download

In this article, I’ll walk you through exactly how smart charging works when ISO 15118-2 (EV-to-charger communication) meets OCPP 2.0.1 (charger-to-backend communication). By the end, you’ll understand:

• The complete message flow from when an EV states its charging needs (ChargeParameterDiscoveryReq) through to the backend’s response (SetChargingProfileRequest) and back to the vehicle

• What data the EV actually shares — and critically, what it doesn’t (spoiler: SOC is mandatory, but energy capacity and need are optional, which can create a real problem for CPOs)

• How charging schedules are built — the layered profile system, composite schedules, and the “minimum of all limits” rule that guarantees safety

• Mid-session renegotiation — what happens when grid conditions change or the driver updates their departure time

• Why this matters commercially — from fleet depot optimisation to future V2G revenue streams

I’ll use a VW ID.4 as our example vehicle throughout, with actual message structures and realistic parameters. Whether you’re a CPO trying to implement smart charging, an EV or charger manufacturer working on protocol compliance, or just a curious techie wanting to understand the mechanics, this should give you a solid foundation.

Subscribe now

The cast of characters

Before we dive in, let’s meet our three protagonists:

The Electric Vehicle (EV) knows how much energy it needs, when you want to leave (provided that you input this information in the car OEM’s in-car or mobile app), and what its battery can handle. It communicates this through ISO 15118 — a protocol that runs over the charging cable itself (yes, the cable carries both power and data).

The Charging Station is the intermediary. It speaks ISO 15118 to the car and OCPP to the cloud. ISO 15118 actually refers to that specific communication component inside the charger as the SECC (Supply Equipment Communication Controller).

The Charge Point Management System (CPMS) is the brains of the operation. It sits in the cloud, monitors the entire network, and decides how much power each charger can deliver based on power available at the site, grid constraints, energy prices, or whatever other factors the operator cares about.

Act one: the EV states its case

When your EV plugs in and high-level communication (via ISO 15118) kicks off, the first substantive exchange is the ChargeParameterDiscovery. This is where your car essentially says: “Here’s what I need, what I can handle, and when I’d like to be done.”

In ISO 15118-2, the EV sends a ChargeParameterDiscoveryReq message containing its charging parameters. For DC charging, this looks something like:

ChargeParameterDiscoveryReq (ISO 15118-2)
EV → Charging Station
├─ RequestedEnergyTransferMode: DC                        [MANDATORY]
├─ MaxEntriesSAScheduleTuple: 12                          [optional]
└─ DC_EVChargeParameter:
    ├─ DC_EVStatus:                                       [MANDATORY]
    │   ├─ EVReady: true                                  [MANDATORY]
    │   ├─ EVErrorCode: NO_ERROR                          [MANDATORY]
    │   └─ EVRESSSOC: 20%                                 [MANDATORY]
    ├─ EVMaximumCurrentLimit: 350 A                       [MANDATORY]
    ├─ EVMaximumVoltageLimit: 408 V                       [MANDATORY]
    ├─ EVMaximumPowerLimit: 135000 W                      [optional]
    ├─ EVEnergyCapacity: 77000 Wh                         [optional]
    ├─ EVEnergyRequest: 54000 Wh                          [optional]
    ├─ DepartureTime: 7200 (seconds from now)             [optional]
    ├─ FullSOC: 100%                                      [optional]
    └─ BulkSOC: 80% (when to start reducing power)        [optional]

Let’s unpack these values and use the example of a mid-size EV, the ID.4. It has a 400 V-class battery architecture with a nominal voltage around 352V (96 cells in series at 3.67 V nominal).

The EVMaximumVoltageLimit of 408 V represents the upper voltage when nearly full. The EVMaximumCurrentLimit of 350 A combined with voltage gives us roughly 125-135 kW peak charging power (P = V x A) .

Educate your EV drivers on available charging power — they’ll thank you

There’s a lack of communication and education about the maximum power available at a charger and the maximum power the vehicle’s battery can be charged with. In my last article on A clear guide to load management, phase rotation, and smart charging, I explained that the actual delivered power will be the minimum of the charger’s capability, the cable capacity, and the vehicle’s acceptance rate.

If you’re charging at a 350 kW charger but the maximum charging power doesn’t climb beyond the 135 kW mark, then maybe it’s not the charger or CPO (Charge Point Operator) at fault — maybe it’s just your EV not being able to take more power in.

The CPO who clearly communicates (and explains) the real available charging speed via the charger’s display, app, and roaming partners will be rewarded with the trust and high CSAT rating of their EV drivers. Keep that in mind.

Alright, sorry for that slight detour, let’s get back to the elements of the ChargeParameterDiscovery message.

Notice something frustrating here? EVRESSSOC1 (the current state of charge) is mandatory, but EVEnergyCapacity and EVEnergyRequest are optional. This can create a real problem for smart charging decisions.

If you’re a CPO trying to calculate how much energy a vehicle needs, the ideal information is the energy amount directly — either through EVEnergyRequest (the energy the EV needs for a full charge) or by calculating it from EVEnergyCapacity (the size of the vehicle’s battery in kWh, e.g. 77 kWh for an ID.4) and EVRESSSOC. But if an EV implementation only sends the mandatory EVRESSSOC of 20% without the battery capacity, you’re stuck. Is that 20% of a 45 kWh battery (needing ~36 kWh) or a 77 kWh battery (needing ~62 kWh)? You simply don’t know.

Why did ISO 15118-2 make this design choice? The thinking was likely around vehicle manufacturer concerns — battery capacity can be commercially sensitive information, and some OEMs preferred not to expose it. But the practical result is that CPOs sometimes receive “I’m at 25% SOC” without any way to translate that into an actionable energy need. To be honest, beats me why EVEnergyRequest wasn’t made mandatory. (Once you start working in standardisation, you realise that not every decision is logical — there’s often corporate politics involved.)

Well, in any case, I hope EV manufacturers do opt to send at least EVEnergyRequest, otherwise you’re doing the world a big disservice.

For AC charging, the situation is actually better. The AC_EVChargeParameter includes EAmount (energy amount) as a mandatory parameter, which means the EV directly states how much energy it wants in Wh. This is far more useful for scheduling:

AC_EVChargeParameter:
├─ DepartureTime: 7200                                    [optional]
├─ EAmount: 54000 Wh                                      [MANDATORY]
├─ EVMaxVoltage: 400 V                                    [MANDATORY]
├─ EVMaxCurrent: 16 A                                     [MANDATORY]
└─ EVMinCurrent: 6 A                                      [MANDATORY]

The lesson for CPOs: when DC charging without EVEnergyRequest or EVEnergyCapacity, you may need fallback strategies — perhaps making conservative assumptions. And when evaluating EVSE implementations, check whether they’re configured to request and forward these optional-but-critical parameters.

The parameter MaxEntriesSAScheduleTuple tells the charging station how many charging schedule entries (basically the maximum amount of time intervals and associated max. power values) it can computationally handle.

The rest of the message should be rather self-explanatory.

One more parameter deserves attention: DepartureTime. If you’ve ever told your car “I’m leaving at 7 AM,” this is where that information gets used. The EV communicates when you intend to unplug, which opens up possibilities for spreading your charge across off-peak hours rather than blasting your EV with maximum power immediately. The value is given in seconds, as an offset from the moment the message is sent.

If no departure time is provided, the standard says to assume the driver wants charging to start immediately without delay. Fair enough, most people do want their car charged sooner rather than later.

Act two: the charger phones home

Here’s where things get interesting. The charging station receives the EV’s wish list and immediately needs to check with the cloud-based CPMS that manages the EV charging network. In OCPP 2.0.1, it does this by sending a NotifyEVChargingNeedsRequest to the CPMS:

NotifyEVChargingNeedsRequest (OCPP 2.0.1)
Charging Station → CPMS
├─ evseId: 2                                           [MANDATORY]
├─ chargingNeeds:                                      [MANDATORY]
│   ├─ requestedEnergyTransfer: DC                     [MANDATORY]
│   ├─ departureTime: "2026-02-08T16:30:00Z"           [optional]
│   └─ dcChargingParameters:
│       ├─ evMaxCurrent: 350                           [MANDATORY]
│       ├─ evMaxVoltage: 408                           [MANDATORY]
│       ├─ evMaxPower: 135000                          [optional]
│       ├─ stateOfCharge: 20                           [optional]
│       ├─ evEnergyCapacity: 77000                     [optional]
│       └─ energyAmount: 61600                         [optional]
│       ├─ fullSOC: 100                                [optional]
│       └─ bulkSOC: 80                                 [optional]
└─ maxScheduleTuples: 12                               [optional]

The CPMS now knows what kind of charging is requested (DC), the departure time, and all the electrical parameters. Note that OCPP 2.0.1 makes most DC charging parameters optional — inheriting the same limitation from ISO 15118.

How to capture the vehicle’s energy need if the EV won’t tell (DC charging)

A CPMS might receive just the SOC without the battery capacity or requested energy need (please, dear car manufacturers, don’t do that), making it impossible to calculate the actual energy need. Robust implementations handle this by using vehicle identification data to look up typical battery sizes for known models — if you’re able to identify the EV make and model, which is not communicated via ISO 15118. One way would be to capture this information in the CPO’s mobile app if the EV driver uses the CPO’s app to start the charging session and provides the vehicle details in their user profile. Another way could be a smart integration with vehicle telematics data.

The CPMS has about 60 seconds to respond — that’s the ISO 15118 timeout constraint. It’s tighter than you might expect for a system that needs to potentially coordinate with grid operators or dynamic pricing systems. At the same time, you don’t want to let the EV driver wait for too long before power delivery starts.

During this waiting period, the charging station will send interim ChargeParameterDiscoveryRes messages back to the EV with the parameter EVSEProcessing set to “Ongoing” — essentially saying “hang on, still working on it.” This keeps the ISO 15118 session alive while the CPMS does its calculations.

This is a game-changer compared to OCPP 1.6. Previously, the CPMS could send charging schedules to stations but had no visibility into what vehicles actually needed. It was like a restaurant kitchen cooking without knowing what customers ordered. Now, the CPMS can see the difference between a driver who needs 10 kWh before leaving in 30 minutes versus one who needs 50 kWh but has 8 hours available — assuming the EV provides that information.

Act three: the CPMS calculates a schedule

The CPMS now has everything it needs to compute an optimised charging schedule. It evaluates the request against current conditions: other active sessions at this site, forecasted grid capacity, energy prices over the charging window, and — crucially — the vehicle’s stated needs and flexibility.

In our example, the ID.4 requested 61.6 kWh (from 20% on a 77 kWh battery) with a 2-hour window. That’s an average of 31 kW minimum — but the schedule can be cleverer than a flat line. The CPMS might see that grid prices are high for the next 30 minutes but drop significantly after that. Or it might know that another vehicle at the same site is about to finish, freeing up capacity.

Example CPMS calculation:

Vehicle: VW ID.4 (77 kWh battery, 135 kW max DC)
Energy need: 61.6 kWh before departure at 16:30
Current time: 14:30

Time: 14:30-15:00 → Grid constrained, price HIGH
  Schedule: 50 kW × 0.5h = 25 kWh

Time: 15:00-15:30 → More capacity available, price MEDIUM  
  Schedule: 100 kW × 0.5h = 50 kWh

Time: 15:30-16:30 → Ample capacity, price LOW
  Schedule: 30 kW × 1.0h = 30 kWh

Total: 105 kWh capacity offered (exceeds 61.6 kWh need ✓)
Peak: 100 kW (within vehicle's 135 kW limit ✓)

Why not just blast 100+ kW continuously? Because the grid operator might have signalled capacity constraints, because electricity costs more during peak hours, or because another vehicle on the same site connection needs power too. Smart charging is about finding the optimal path, not the fastest one.

Communicate active smart charging to your EV drivers

Again, the CPO who transparently communicates that smart charging is active wins brownie points. How many times have I pulled up to a 350 kW HPC charger in an EV capable of 250+ kW peak — needing a quick top-up — only to watch the display frustratingly max out at around 100 kW. Not great at all.

The CPMS then sends a SetChargingProfileRequest back to the charging station.

SetChargingProfileRequest (OCPP 2.0.1)
CPMS → Charging Station
├─ evseId: 2                                           [MANDATORY]
└─ chargingProfile:                                    [MANDATORY]
    ├─ id: 7891                                        [MANDATORY]
    ├─ stackLevel: 1                                   [MANDATORY]
    ├─ chargingProfilePurpose: TxProfile               [MANDATORY]
    ├─ chargingProfileKind: Absolute                   [MANDATORY]
    ├─ transactionId: "TXN_20260208_001"               [optional]
    └─ chargingSchedule:                               [MANDATORY]
        ├─ id: 1                                       [MANDATORY]
        ├─ startSchedule: "2026-02-08T14:30:00Z"       [optional]
        ├─ chargingRateUnit: W                         [MANDATORY]
        └─ chargingSchedulePeriod:                     [MANDATORY]
            ├─ { startPeriod: 0, limit: 30000 }        
            ├─ { startPeriod: 1800, limit: 100000 }     
            └─ { startPeriod: 3600, limit: 30000 }     
└─ status: Accepted                                    [MANDATORY]

This profile tells the charging station that it applies to EVSE 2 (probably the charger’s right socket) as follows: start at 30 kW for the first 30 minutes (1800 seconds), ramp up to 100 kW for the next 30 minutes, then back down to 30 kW. The charging station is expected to adjust its output as each period begins.

Remember that this is a DC charging session. In case of an AC charging session, the chargingSchedule can contain optional numberOfPhases and phaseToUse parameters to allow for more fine-grained, phase-specific load balancing.

The parameters stackLevel and chargingProfilePurpose are foundational concepts that have been adopted from the previous version OCPP 1.6. I’ve introduced them in my last article but we’ll recap them briefly further down.

Translating back to the EV

Once the charging station has its marching orders from the CPMS, it needs to communicate this back to the EV in ISO 15118 terms. It does this through the SAScheduleList in the ChargeParameterDiscoveryRes message:

ChargeParameterDiscoveryRes (ISO 15118-2)
Charging Station → EV
├─ ResponseCode: OK                                                  [MANDATORY]
├─ EVSEProcessing: Finished                                          [MANDATORY]
└─ SAScheduleList:                                                   [MANDATORY]
    └─ SAScheduleTuple:                                              [MANDATORY]
        ├─ SAScheduleTupleID: 1                                      [MANDATORY]
        ├─ PMaxSchedule:                                             [MANDATORY]
        │   ├─ Entry 1: start=0s, PMax=50000W, duration=1800s
        │   ├─ Entry 2: start=1800s, PMax=100000W, duration=1800s
        │   └─ Entry 3: start=3600s, PMax=30000W, duration=3600s
        └─ SalesTariff:                                              [optional]
            ├─ Entry 1: start=0s, EPriceLevel=3 (HIGH)
            ├─ Entry 2: start=1800s, EPriceLevel=2 (MEDIUM)
            └─ Entry 3: start=3600s, EPriceLevel=1 (LOW)
├─ DC_EVSEChargeParameter:                                           [MANDATORY]
│   ├─ DC_EVSEStatus:                                                [MANDATORY]
│   │   ├─ EVSEIsolationStatus: Valid                                [optional]
│   │   ├─ EVSEStatusCode: EVSE_Ready                                [MANDATORY]
│   │   └─ EVSENotification: None                                    [MANDATORY]
│   │   └─ EVSENotificationMaxDelay: 0                               [MANDATORY]
│   ├─ EVSEMaximumCurrentLimit: 400 A                                [MANDATORY]
│   ├─ EVSEMaximumPowerLimit: 150000 W                               [MANDATORY]
│   ├─ EVSEMaximumVoltageLimit: 500 V                                [MANDATORY]
│   ├─ EVSEMinimumCurrentLimit: 0 A                                  [MANDATORY]
│   ├─ EVSEMinimumVoltageLimit: 150 V                                [MANDATORY]
│   ├─ EVSECurrentRegulationTolerance: 5 A                           [optional]
│   ├─ EVSEPeakCurrentRipple: 2 A                                    [MANDATORY]
│   └─ EVSEEnergyToBeDelivered: 54000 Wh                             [optional]

ISO 15118 uses the concept of Secondary Actor Schedule Tuples (SA = Secondary Actor, meaning schedules from an external source like the CPMS). Each tuple contains a PMaxSchedule, which is a list of time periods with maximum power values.

The EV can be offered up to three different schedule options. The first schedule in the list is defined as the default. If the EV isn’t sophisticated enough to optimise (or just doesn’t care), it picks this one.

Remember the MaxEntriesSAScheduleTuple value from the previous ChargeParameterDiscoveryReq message? If this PMaxSchedule had more than 12 entries, the EV might not be able to process this message or simply ignore anything but the first 12 entries of the schedule. But in our example, we’re safe with just three schedule entries.

Notice the SalesTariff? ISO 15118-2 intentionally uses relative price indicators like levels 1-3 (level 1 indicates cheaper than level 3) or percentage-based indicators (such as “this interval is 75% of the reference energy price”) rather than actual currency values to enable the EVs to optimise charging based on cost signals. This abstraction was intentionally designed to shield actual tariff details from the Charge Point Operator (CPO), keeping what was back in the days considered as commercially sensitive pricing information between the Mobility Service Provider (MSP) and the driver. In practice, I haven’t encountered anyone who has implemented SalesTariff-based smart charging optimisation. If you have, I’d be genuinely interested to hear about it. The design reflects the market assumptions of 2010–2014 when ISO 15118-2 was developed, a period when the relationships between CPOs, MSPs, and grid operators were envisioned quite differently than they’ve evolved today.

ISO 15118-20 goes further, introducing actual currency amounts for truly transparent pricing.

The EV makes its choice

This is where smart charging gets properly smart. The EVSE isn’t forcing anything — it’s presenting options. The EV evaluates the offered schedule against its battery management needs and commits to a plan in the PowerDeliveryReq message:

PowerDeliveryReq (ISO 15118-2)
EV → Charging Station
├─ ChargeProgress: Start                            [MANDATORY]
├─ SAScheduleTupleID: 1                             [MANDATORY]
└─ ChargingProfile:                                 [MANDATORY if ChargeProgress=Start]
    ├─ ProfileEntry 1: start=0s, power=25000W      (ramp-up: 10 min × 25 kW = 4.17 kWh)
    ├─ ProfileEntry 2: start=600s, power=30000W   (at limit: 20 min × 30 kW = 10.0 kWh)
    ├─ ProfileEntry 3: start=1800s, power=95000W    (ramp-up: 5 min × 95 kW = 7.92 kWh)
    ├─ ProfileEntry 4: start=2100s, power=100000W   (peak: 15 min × 100 kW = 25.0 kWh)
    ├─ ProfileEntry 5: start=3000s, power=80000W    (taper: 8 min × 80 kW = 10.67 kWh)
    └─ ProfileEntry 6: start=3480s, power=48000W    (final taper: 4.75 min × 48 kW = 3.8 kWh)

Notice something interesting? The EV’s actual ChargingProfile has more granular periods than the offered PMaxSchedule. The vehicle’s battery management system creates an optimal profile that respects the constraints but ramps power up and down smoothly. As long as it stays within the offered envelope, the charger must accept it.

This is a key principle: the charger offers constraints, but the vehicle controls the actual charging behaviour within those constraints. The EV might choose to charge more gently to preserve battery longevity, or it might push harder early in the session when the battery can accept more current. That’s the vehicle’s decision to make.

The charging station then reports this actual schedule back to the CPMS via NotifyEVChargingScheduleRequest, so the backend knows what’s really going to happen — not just what was offered. This enables accurate load forecasting: if the CPMS offered 30 kW but the vehicle committed to only 25 kW, that 5 kW difference might be available for another session.

The charging loop: a continuous dialogue

Once charging starts, the conversation doesn’t stop. For AC charging, the EV periodically sends ChargingStatusReq messages, which are empty messages just to keep the communication loop alive. For DC charging, it’s CurrentDemandReq, which carries real information about what the vehicle is actually drawing:

CurrentDemandReq (ISO 15118-2)
EV → Charging Station
├─ DC_EVStatus:                                              [MANDATORY]
│   ├─ EVReady: true                                         [MANDATORY]
│   ├─ EVErrorCode: NO_ERROR                                 [MANDATORY]
│   └─ EVRESSOC: 45%                                         [MANDATORY]
├─ EVTargetCurrent: 280 A (current the EV requests now)      [MANDATORY]
├─ EVTargetVoltage: 380 V (voltage the EV requests now)      [MANDATORY]
├─ EVMaximumVoltageLimit: 408 V                              [optional]
├─ EVMaximumCurrentLimit: 350 A                              [optional]
├─ EVMaximumPowerLimit: 135000 W                             [optional]
├─ BulkChargingComplete: false (true when reaching 80% SOC)  [optional]
├─ ChargingComplete: false                                   [MANDATORY]
├─ RemainingTimeToFullSoC: 2700 s (45 min)                   [optional]
└─ RemainingTimeToBulkSoC: 1200 s (20 min)                   [optional]

All these values should be rather self-explanatory. EVMaximumVoltageLimit, EVMaximumCurrentLimit, and EVMaximumPowerLimit can change during charging (e.g. as battery heats up, the BMS may reduce limits).

The EV sends this message cyclically during DC charging (typically every 250ms to 1s), continuously updating its current request based on battery state. The EVSE responds with CurrentDemandRes containing the actual voltage and current being delivered.

All this time, the charging station sends TransactionEventRequest messages with eventType=Updated to the CPMS, keeping the backend up to date about the latest measured meter values:

TransactionEventRequest (OCPP 2.0.1)
Charging Station → CPMS
├─ eventType: Updated                                                      [MANDATORY]
├─ timestamp: "2026-02-08T14:45:00Z"                                       [MANDATORY]
├─ triggerReason: MeterValuePeriodic                                       [MANDATORY]
├─ seqNo: 5                                                                [MANDATORY]
├─ transactionId: "TXN_20260208_001"                                       [MANDATORY]
└─ meterValue:                                                             [optional]
    ├─ timestamp: "2026-02-08T14:45:00Z"                                   [MANDATORY]
    └─ sampledValue:                                                       [MANDATORY]
        ├─ { value: 25500, measurand: Power.Active.Import, unit: W }
        ├─ { value: 380, measurand: Voltage, unit: V }
        └─ { value: 67, measurand: Current.Import, unit: A }

This three-way conversation continues until someone decides to end the session — whether that’s the driver unplugging, the EV reaching its target state of charge, or an external event forcing a stop.

To tie everything together mentally (and visually), I’ve created a sequence diagram illustrating the ISO 15118-2 messages between the EV and charger and OCPP 2.0.1 messages between charger and cloud-based CPMS during a smart charging session. Note that I left any external charging limits (e.g. from an energy management system or DSO) or renegotiation of charge parameters out to keep the diagram cleaner.

The layered world of charging profiles

OCPP 1.6 introduced a sophisticated system of layered charging profiles, which OCPP 2.0.1 continues to build upon. There are four profile purposes, each serving a different role:

ChargingStationMaxProfile sets the absolute ceiling — typically based on the grid connection’s physical limits. Set at evseId=0 (station level), this caps total power across all EVSEs.

TxDefaultProfile provides default schedules for new transactions — site-wide policies like reducing power during peak hours.

TxProfile is transaction-specific and overrides TxDefaultProfile for that particular session. This is what the CPMS sends in response to the EV’s charging needs.

ChargingStationExternalConstraints has been newly introduced in OCPP 2.0.1 and captures limits from external systems like a home energy management system, a DSO (Distributed System Operator) signal, or any source outside OCPP. The CPMS cannot create these; they’re reported to it via NotifyChargingLimitRequest.

These charging profiles are all layered together to determine, at any moment, the effective power limit: it is the minimum across all applicable profiles:

Active profiles at 14:30:
├─ ChargingStationMaxProfile: 100 kW
├─ TxDefaultProfile: 50 kW (but overridden by TxProfile)
├─ TxProfile: 30 kW
└─ ExternalConstraints (from DSO): 30 kW

Composite schedule = min(100, 30, 30) = 30 kW

The DSO’s external constraint becomes the binding limit. Safety and grid stability trump individual preferences, as they should.

Each profile type also supports stack levels, allowing multiple profiles of the same purpose to coexist. Higher stack levels override lower ones within the same purpose. Want to limit charging during peak hours on weekdays but not on Christmas Day? Stack a holiday exception at a higher level.

Visibility: the composite schedule

With all these layers, how does anyone know what’s actually happening? The CPMS can query the effective schedule via GetCompositeScheduleRequest:

GetCompositeScheduleRequest (OCPP 2.0.1)
CPMS → Charging Station
├─ duration: 7200                               [MANDATORY]
├─ chargingRateUnit: W                          [optional]
└─ evseId: 2                                    [MANDATORY]

GetCompositeScheduleResponse
├─ status: Accepted                             [MANDATORY]
└─ schedule:                                    [MANDATORY if status=Accepted]
    ├─ evseId: 2                                [MANDATORY]
    ├─ duration: 7200                           [MANDATORY]
    ├─ scheduleStart: "2026-02-08T14:30:00Z"    [MANDATORY]
    ├─ chargingRateUnit: W                      [MANDATORY]
    └─ chargingSchedulePeriod: [merged result of all profiles]  [MANDATORY]

One subtlety: the composite schedule reflects expected consumption, not just offered limits. If the EV indicated it will taper to 20 kW as its battery fills, that’s what appears in the composite — useful for accurate load forecasting at the grid level.

When things change mid-session

Real grids are dynamic. A cloud passes over a solar installation. Another EV plugs in at a shared connection. The grid operator issues a demand response event. What happens?

Say a DSO sends a curtailment signal at 15:15:

NotifyChargingLimitRequest (OCPP 2.0.1)
Charging Station → CPMS
├─ chargingLimit:                             [MANDATORY]
│   ├─ chargingLimitSource: EMS               [MANDATORY]
│   └─ isGridCritical: true                   [optional]
├─ evseId: 0                                  [optional]
└─ chargingSchedule: [updated constraints]    [optional]

The charging station recalculates its composite schedule. For ISO 15118 sessions, this may trigger a renegotiation with the EV — looping back to ChargeParameterDiscovery to establish new parameters.

The EV can also initiate renegotiation if the driver changes their departure time or the battery reaches unexpected conditions. When this happens, the charging station sends a NotifyEVChargingScheduleRequest to keep the CPMS informed.

One practical detail: not every fluctuation triggers notifications. The configuration variable LimitChangeSignificance — part of the controller component SmartChargingCtrlr2 — defines a threshold (as a percentage) below which changes need not be reported. This prevents message floods when e.g. a home energy management system makes minor adjustments every few seconds.

What happens when the network goes down?

Charging stations need to handle offline scenarios gracefully. All ChargingProfiles set via OCPP must persist across reboots and power cycles. If the station loses connectivity to the CPMS:

• TxProfile: Continues executing until the transaction ends

• TxDefaultProfile: Applies to any new transaction started while offline

• ChargingStationMaxProfile: Always enforced — these are safety limits

For authorisation during offline periods, stations can use local authorisation lists (pre-provisioned tokens) or an authorisation cache of previously-approved tokens. The transaction proceeds with whatever profiles were last installed, and events are queued for upload when connectivity returns.

A note on AC charging and phase management

While I’ve focused mostly on DC examples, AC charging has its own wrinkles — particularly around phase management, as explained in detail in my last article.

In three-phase AC charging, the CPMS can specify not just the power limit but also how many phases to use and which specific phase for single-phase charging. Why does this matter? Consider a site with a 100A grid connection split across three phases. When multiple single-phase vehicles are charging, distributing them across L1, L2, and L3 prevents any single phase from overloading.

One gotcha: when chargingRateUnit is set to Amperes, the limit applies per phase, not total. Setting a 32A limit on a three-phase connection means 32A on each phase — about 22 kW at European voltages, not the ~7 kW you might expect if you thought it meant 32A total.

Why smart charging is so important

This might seem like a lot of complexity for something that “just works” from the driver’s perspective. But as EV adoption grows, this complexity is what prevents the grid from collapsing.

A neighbourhood of homes each with an EV, all plugging in after work at 6 PM, could easily overwhelm a local transformer. Smart charging allows that load to be spread across the evening, prioritising the EV whose driver has an early meeting while letting the work-from-home neighbour’s car charge at 2 AM when more renewable wind power is available and the price is cheaper.

The economics are compelling too. In markets with time-of-use pricing, smart charging shifts consumption to periods when electricity is cheapest — often when renewable generation is highest.

Fleet depots face an even more dramatic version of this challenge. Picture a delivery company with 50 electric vans returning to base between 5 and 7 PM, each needing 40–60 kWh before their 6 AM departures. Without smart charging, they'd need massive grid connections — perhaps 5 MW or more — to handle the theoretical peak if every vehicle charged simultaneously at full power. With smart charging, the CPMS knows each vehicle's energy need and departure time, and can orchestrate the entire fleet through a single 500 kW connection. The van leaving at 5 AM gets priority; the one not needed until noon charges last. As vehicles reach their target SOC, their power allocation shifts to others still charging. The result: the same fleet, the same service level, but a grid connection one-tenth the size — and the capital expenditure savings to match.

At scale, this becomes Vehicle-Grid Integration. The same protocols can enable V2G (vehicle-to-grid), turning parked EVs into a distributed battery resource. ISO 15118-20 already adds bidirectional power parameters like EVMinimumV2XEnergyRequest (the minimum energy the vehicle must retain for driving) and EVMaximumV2XEnergyRequest (how much it’s willing to discharge). I’ll probably dedicate another article to ISO 15118-20’s smart charging and V2G capabilities.

For charge point operators, mastering these protocols isn’t just about compliance — it’s about participating in future flexibility markets. Aggregated charging networks can function as Virtual Power Plants, responding to grid operator signals in real time, which helps stabilise the grid and opens up a significant revenue stream for CPOs.

But that only works with the precise control and monitoring that OCPP 2.0.1 (and its next version OCPP 2.1 for V2G) and ISO 15118-2 / -20 enable.

That was a lot to digest if you’re not deeply entrenched in these protocols in your day-to-day work. But now you see that real smart charging is a carefully choreographed dance between protocols years in the making. ISO 15118 handles the conversation between EV and charger, negotiating what’s needed and what’s possible. OCPP 2.0.1 extends that conversation to the cloud, where network operators can optimise across thousands of charge points.

The message flow we’ve traced — from ChargeParameterDiscoveryReq through NotifyEVChargingNeedsRequest to SetChargingProfileRequest and back — represents a genuine engineering achievement. Multiple stakeholders with different priorities can all influence the outcome through well-defined interfaces, while safety is mathematically guaranteed through the composite schedule’s minimum-of-all-limits rule.

The next time you plug in your EV, spare a thought for the silent negotiations happening on your behalf. Your car is advocating for your travel plans, the charger is balancing its local constraints, and somewhere in a data centre, an algorithm is working out how to keep everyone happy — including the grid that powers it all.

That’s smart charging. And now you know how it actually works.

This article provides the foundational knowledge needed to understand the principles behind load management (or load balancing), how it differs from smart charging, which factors impact load balancing and smart charging, and why proper planning and documentation of phase rotation for AC charging networks is so important for an efficiently operating charging network. We’ll also look at how the tools the Open Charge Point Protocol (OCPP) provides to implement smart charging across your managed network of EV chargers.

Think of a charging network like an airport terminal. Without coordination, all planes would try to land simultaneously, overwhelming the runways. Similarly, without load management and smart charging, all EVs would draw maximum power the moment they connect, potentially overwhelming the electrical infrastructure. The protocols and techniques we’ll explore act as the air traffic control system for electrons.

Subscribe now

Load management vs smart charging: what’s the difference?

While these terms are often used interchangeably, they represent distinct but complementary concepts in the EV charging ecosystem.

Load management (static and dynamic)

Load management focuses on distributing available electrical capacity across multiple charge points to prevent infrastructure overload. It operates at the site level, ensuring the total power drawn by all chargers never exceeds the capacity of the grid connection, building wiring, or upstream protection devices.

Static load management (SLM) allocates a fixed portion of available capacity to each charger based on predetermined rules. For example, a workplace car park with a 70kW grid connection installs ten 11kW three-phase chargers for employees. To guarantee all ten can operate simultaneously without tripping the supply, static load management limits each charger to just 7kW permanently – only 64% of its capability and the vehicles’ acceptance rate.

Consider what happens at 8am when only three employees have arrived and plugged in: under static load management, each still receives only 7kW, leaving 49kW of available capacity sitting idle. Those three vehicles could each be charging at their full 11kW (33kW total), completing their charges in two-thirds of the time. By 10am, when all ten vehicles are connected, the static allocation makes sense. But by 1pm, five vehicles have already reached 80% state of charge and their battery management systems have reduced acceptance to 3kW each. The static system continues reserving 7kW for each of those sessions, wasting 20kW that could accelerate charging for the remaining vehicles. Over the course of a typical workday with staggered arrivals, departures, and varying charge states, static allocation routinely delivers just 50-60% of the site’s potential charging throughput.

Dynamic load management (DLM) continuously monitors actual power consumption and redistributes available capacity in real-time. In our workplace example, when only three vehicles are connected at 8am, DLM allocates the full 11kW to each, using 33kW of the 70kW available and charging each vehicle at maximum speed. As more employees arrive and plug in, the system automatically reduces individual limits to stay within the site’s capacity. By 10 am, with all ten vehicles connected, each receives 7kW. When five vehicles reach 80% and reduce their acceptance to 3kW, DLM immediately reallocates that freed capacity to the remaining five vehicles, boosting them from 7kW back towards 11kW each. This continuous optimisation can increase daily charging throughput by 40-50% compared to static allocation, without any grid upgrade.

Advanced dynamic load management extends beyond the charging infrastructure to monitor the entire site’s electrical consumption. Our workplace might have a 100kW grid connection shared between 30kW of office operations (lighting, HVAC, equipment) and the 70kW nominally allocated to EV charging. During business hours, the office draws its full 30kW, leaving 70kW for vehicles. But from 6pm onwards, as lights switch off and air conditioning winds down, office consumption drops to just 5kW. Sophisticated DLM detects this and redirects the surplus 25kW to EV charging, effectively providing 95kW for the remaining vehicles – enough to charge eight vehicles at their full 11kW simultaneously.

This building-integrated approach requires energy meters at the grid connection point and communication between the building’s energy management system (EMS) and the charge point management system (CPMS). The payoff is substantial: infrastructure sized for daytime constraints can deliver significantly higher charging capacity during off-peak hours, all without upgrading the grid connection.

Smart charging

Smart charging extends beyond simple load management to incorporate external factors such as energy pricing, renewable energy availability, grid demand response signals, and individual driver preferences. While load management asks “how do we share the available power?”, smart charging asks “when and how fast should each vehicle charge to optimise outcomes for drivers, operators, and the grid?”

A smart charging system might delay or slow charging during peak electricity pricing periods, accelerate charging when solar or wind generation is high, respond to utility demand response events, or ensure a fleet vehicle reaches 80% state of charge by its scheduled departure time. The intelligence lies in balancing multiple competing objectives while respecting hard constraints like vehicle departure times, minimum charge requirements, and overall power capacity on site.

Factors impacting load balancing and smart charging

Effective charging optimisation must account for constraints at every point in the electrical chain, from the grid connection down to the vehicle’s battery management system.

Site power capacity

The grid connection represents the top-level, ultimate limit on total charging power. This capacity may be shared with other building loads (lighting, HVAC, equipment), meaning available EV charging capacity fluctuates throughout the day. Advanced systems integrate with building energy management systems to dynamically allocate surplus capacity to EV charging while protecting critical loads, as mentioned above.

Solar power generation

On-site generation, in particular solar PV, adds another variable to load management calculations. When solar panels generate power, that energy can offset grid consumption, effectively increasing the capacity available for EV charging. Dynamic systems can prioritise charging during peak solar production, maximising the use of free, zero-carbon energy. This solar-aware charging becomes increasingly important as sites deploy larger PV arrays and seek to minimise both energy costs and carbon footprint.

Charger power rating

Each charging station has a maximum power output, typically 7.4kW, 11kW, or 22kW for AC chargers, and 50kW to 400kW for DC fast and HPC (High Power Charger) chargers – aka Rapid and Ultra-Rapid chargers in the UK. The charger’s rated power represents an upper bound; actual delivered power will be the minimum of the charger’s capability, the cable capacity, and the vehicle’s acceptance rate.

Power cable capabilities

Charging cables have current-carrying limits based on their conductor cross-section. Type 2 cables are rated for different maximum currents (typically 16A, 32A, or 63A per phase). The cable’s proximity pilot (PP, more details on plug pins here) resistor communicates its rating to the charger, which must respect this limit regardless of the charger’s own capability.

For DC fast charging, cables are typically rated for 200A to 500A, with newer high-power charging (HPC) installations supporting up to 500A at voltages up to 1000V for charging rates exceeding 400kW. DC cables are liquid-cooled at these higher ratings to manage heat dissipation within a manageable cable diameter and weight.

EV battery and on-board charger limits

Every electric vehicle contains an on-board charger (OBC) that converts AC power to DC for battery charging. The OBC’s power rating and phase support determine the vehicle’s maximum AC charging rate. A vehicle with a 7.4kW single-phase OBC cannot benefit from connecting to a 22kW three-phase charger; it will draw only what its OBC can handle. (We’ll get to the concept of ‘phases’ in a minute)

Battery management systems (BMS) further modulate charging rates based on temperature, state of charge (SOC), and battery cell health. Most lithium-ion batteries charge most efficiently in the 20–40°C range; below this, chemical reactions slow and the BMS reduces charging current to prevent lithium plating, while above this range, charging is throttled to prevent thermal degradation.

Charging typically slows significantly above 80% SOC to protect battery longevity. Think of it like filling a bathtub: you can run the tap at full blast when the tub is empty, but as the water level rises toward the rim, you need to reduce the flow to avoid overflow. Similarly, the BMS reduces charging current as the battery approaches full capacity to prevent overcharging individual cells, which could cause irreversible damage or safety hazards.

AC wiring and phase configuration

Three-phase AC power is the standard for commercial and industrial electrical installations across Europe. Unlike single-phase power (which uses one live wire plus neutral), three-phase power delivers electricity through three live wires, commonly labelled L1, L2, and L3 (or sometimes R, S, T in older notation). Each wire carries current that peaks at a different time, 120 degrees apart, creating a smoother and more efficient power delivery.

If you want to understand the concept behind three-phase electricity in more detail, then I highly recommend this great explainer video from The Engineering Mindset:

In a typical EV charging installation, power flows from the grid through a distribution board (sometimes called a feeder pillar) to individual chargers. Each charger receives a five-core cable containing:

• L1 (Line 1 / Phase 1)

• L2 (Line 2 / Phase 2)

• L3 (Line 3 / Phase 3)

• N (Neutral)

• PE (Protective Earth / Ground)

The charger’s internal wiring connects these incoming lines to its charging socket. When a vehicle plugs in, it draws power from one or more of these phases depending on its on-board charger’s capability.

Crucially, each phase has its own protection (circuit breaker or fuse) in the distribution board. If a charger draws 32A on L1 while L2 and L3 are lightly loaded, the L1 circuit breaker could trip even though the total site capacity isn’t exhausted. This is why load management must protect and balance each phase individually, not just monitor total power.

Phase rotation for AC charging

Phase rotation is a critical but often overlooked aspect of multi-charger installations. Understanding and properly implementing phase rotation can dramatically improve charging efficiency and prevent load imbalances.

The challenge: single-phase vehicles on three-phase infrastructure

Here’s the problem: many EVs – particularly plug-in hybrids and smaller-battery EVs like the Nissan Leaf, Hyundai Kona (base model), or Jaguar I-PACE – have single-phase on-board chargers. These vehicles can only draw power from one phase, typically L1, regardless of how many phases the charger or installation supports.

Think of it like a three-lane motorway where certain vehicles can only drive in the left lane. If all vehicles are restricted to the left lane, you get congestion there while the middle and right lanes sit empty.

When multiple single-phase vehicles charge simultaneously on chargers with identical phase wiring, all the load concentrates on L1. The result? An unbalanced electrical installation where one phase is overloaded while the others are underutilised.

A concrete example: four chargers, four single-phase EVs

Consider a charging site with:

• 4 bay × 2 socket chargers (4 charge points total)

• 22kW chargers rated at 32A per phase

• 69kVA with 100A site capacity (shared across all phases)

• Four 7kW single-phase vehicles connected (each drawing 32A from L1 only)

Scenario 1: No phase rotation

Result: 128A on L1 exceeds the 100A site limit. The L1 circuit breaker trips, or load management must aggressively curtail all charging (e.g. to 16A instead of 32A), even though L2 and L3 have zero load.

Scenario 2: Phase rotation to charger

By rotating the phase connections at each charger, the electrician connects different chargers' L1 input to different grid phases:

Result: 64A on L1 and 64A on L2, both well under the 100A limit. However, L3 is still unused (unbalanced). Unbalanced phases can lead to increased power losses, increased neutral conductor current, and reduced equipment lifespan.

Germany’s VDE-AR-N 4100 regulation, for example, explicitly limits phase imbalance to a maximum of 4.6 kVA (approx. 20 A) – meaning EV charging operators must actively manage load distribution across phases to remain compliant and avoid grid connection issues.

The UK takes a less prescriptive approach: BS 7671 addresses phase balance primarily in the context of earthing safety rather than grid stability, and DNOs manage network-level balance through their own operational practices rather than imposing specific kVA limits on individual charging installations.

Scenario 3: Phase rotation between sockets and to charger

Some charger manufacturers offer phase rotation between the two sockets on a dual-socket charger. Combined with rotation at the charger level:

Result: Load is distributed across all three phases (64A, 32A, 32A), now much more balanced than scenario 1’s 128A on a single phase. All vehicles charge at full speed without exceeding any phase limit.

However, this still leaves a 32A difference between L1 and the other phases. In Germany, where VDE-AR-N 4100 limits phase imbalance to 4.6 kVA (approximately 20A at 230V), this configuration alone wouldn't be compliant. Dynamic load management would need to actively curtail charging current on the more heavily loaded phase to bring the imbalance within the permitted limit, thereby trading some charging speed for regulatory compliance.

How phase rotation works in practice

When an electrician installs a three-phase charger, they connect the incoming five-core cable to the charger’s internal connection points (often labelled L1, L2, L3, N, PE on a terminal block inside the charger). In a standard installation, they match the cable’s phases to the charger’s labels: Grid L1 → Charger L1, Grid L2 → Charger L2, Grid L3 → Charger L3.

To implement phase rotation, they deliberately mismatch these connections:

Now, when a single-phase vehicle connects to Charger 2 and draws from "L1" (from the charger's perspective), it's actually drawing from Grid L3. The load is spread across all three grid phases.

Phase rotation notation in OCPP

The Open Charge Point Protocol (OCPP) defines phase rotation using a three-letter code describing how grid phases R (L1), S (L2), and T (L3) map to the charger’s connector. The possible values are:

• RST: Standard reference phasing (Grid L1→Charger L1, L2→L2, L3→L3)

• RTS: Grid L1→Charger L1, Grid L2→Charger L3, Grid L3→Charger L2

• SRT: Grid L1→Charger L2, Grid L2→Charger L1, Grid L3→Charger L3

• STR: Grid L1→Charger L2, Grid L2→Charger L3, Grid L3→Charger L1

• TRS: Grid L1→Charger L3, Grid L2→Charger L1, Grid L3→Charger L2

• TSR: Grid L1→Charger L3, Grid L2→Charger L2, Grid L3→Charger L1

• NotApplicable: Single-phase or DC charge points

• Unknown: Phase rotation not yet determined

The ConnectorPhaseRotation configuration key (OCPP 1.6) and PhaseRotation variable (OCPP 2.0.1 device model) reports this information to the CPMS, allowing smarter load management that accounts for actual phase distribution.

Why this matters for load management systems

Here’s the critical point: the load management system must know each charger’s phase rotation to function correctly.

When a charger reports it’s drawing 32A on “L1”, the CPMS needs to know whether that’s actually Grid L1, L2, or L3. If the system assumes standard RST rotation when the charger is wired as TRS, all its phase balancing calculations will be wrong.

Some chargers don’t offer phase rotation between sockets, meaning both sockets share the same phase mapping. Others rotate between sockets, with L1 and L3 swapped between the two sockets on a single unit. This affects both installation planning and load management configuration.

Critical considerations and best practices

Phase switching during charging: Some charging profiles may include switching between single-phase and three-phase charging during a session. This is dangerous as not all EVs support mid-session phase changes, and attempting this can cause physical damage to the vehicle’s on-board charger. The OCPP 1.6 configuration key ConnectorSwitch3to1PhaseSupported indicates whether a charger supports this capability. Operators should exercise extreme caution with phase switching features.

Documentation and commissioning: Accurate phase rotation configuration is essential for load management systems to function correctly. If the CPMS believes a charger uses standard RST rotation when it’s actually wired as TRS, phase-aware load balancing calculations will be wrong. Document all phase rotations during installation and verify they’re correctly configured in the management system. Some charger manufacturers offer internal phase rotation between sockets, others don't. Factor this into your planning.

Monitor and verify during operation: After installation, use phase-level metering to confirm loads are distributed as expected.

OCPP 1.6: The foundation of smart charging

Open Charge Point Protocol (OCPP) 1.6, released in 2015, established the smart charging framework that remains widely deployed today. Understanding its capabilities and limitations is essential for anyone working with charging infrastructure.

Charging profiles: the core concept

A charging profile is essentially a schedule of power or current limits over time. Each profile contains a ChargingSchedule – a sequence of periods, each specifying a limit (in watts or amps) and its duration. The charge point applies these limits by either modulating the control pilot signal that communicates maximum current to the vehicle – in case of analogue AC charging based solely on the IEC 61851 standard – or by translating the schedule into an ISO 15118-equivalent data structure if the EV communicates with the (AC or DC) charger using IP-based, digital communication. We'll explore how OCPP and ISO 15118 work together to enable smart charging in one of my next articles.

OCPP 1.6 defines three profile purposes, each serving a distinct use case:

ChargePointMaxProfile: Sets limits for the entire charge point, shared across all its connectors. This profile represents hard infrastructure constraints like site’s grid connection or distribution panel capacity. It can only be applied to ConnectorId 0 (meaning “all connectors” or sockets). Think of this as the site-level constraint: no matter how individual sessions are scheduled, total power cannot exceed this limit.

TxDefaultProfile: Defines default charging schedules that apply to new transactions. These profiles implement charging policies. For example, preventing high-power charging during peak electricity pricing periods, or defining “night mode” that allows full power only between 10 PM and 6 AM. TxDefaultProfile can apply to all connectors (ConnectorId 0) or to a specific connector.

TxProfile: Transaction-specific profiles that override TxDefaultProfile for a particular charging session. The CPMS sends these during or at the start of a transaction to implement real-time smart charging decisions. When the transaction ends, the TxProfile is deleted. This enables per-session optimisation based on vehicle energy needs, driver preferences like departure time, or grid conditions.

Profile stacking and the composite schedule

Multiple profiles of the same purpose can coexist using the stackLevel parameter. Higher stackLevel profiles take precedence, which is useful for creating complex calendars with base schedules and exception overlays (holidays, special events, etc.).

The charge point calculates a Composite Schedule by combining the active ChargePointMaxProfile with either the TxProfile (if one exists for the transaction) or the applicable TxDefaultProfile. At each moment, the applied limit is the minimum of all relevant limits. This ensures infrastructure constraints are always respected while allowing flexibility in individual session management.

Smart charging use cases in OCPP 1.6

The specification describes three typical smart charging architectures:

Internal load balancing: The charge point itself manages load distribution across its connectors without involvement from a cloud-based backend, or CPMS. A ChargePointMaxProfile defines the total allowed power, and the charge point internally distributes this among active sessions. This works well for simple installations where per-session optimisation isn’t required.

Central smart charging: The central system (aka CPMS) calculates and sends charging profiles based on external information like grid capacity forecasts from the distribution system operator (DSO), energy prices, renewable generation availability, or fleet scheduling requirements. TxProfile messages allow the CPMS to adjust limits dynamically throughout each session.

Local smart charging: A local controller manages a group of charge points at a site, distributing available capacity among them. The local controller communicates with the CPMS using standard OCPP and acts as a proxy for the charge points it manages. This architecture suits parking garages or fleet depots where local responsiveness with minimal latency is important but central visibility is still required.

Local controllers are particularly important for sites with unreliable internet connectivity or where sub-second response times are required to prevent fuse trips or to provide time-critical grid services like frequency containment reserve (a topic we’ll explore in future articles). Many operators deploy hybrid architectures: a local gateway handles time-critical load balancing decisions while the cloud-based CPMS manages business logic, reporting, and optimisation across multiple sites.

OCPP 1.6 laid the groundwork for smart charging, but it has limitations.

You might have noticed that everything we've covered so far treats the vehicle as a passive load whereby the charging station makes all the decisions. But what if the vehicle could tell the network exactly what it needs, when it needs it, and how flexible it can be? That's where ISO 15118 and OCPP 2.0.1 come in, and we'll unpack how they work together in the next article.

I'm curious: have you encountered load management challenges at your site, whether at work or a public charging location? What worked, and what didn't? Let me know in the comments.

This is one example of a broader limitation. OCPP 1.6 gives operators a keyhole view into charging stations: transaction events, status changes, periodic meter values. What it doesn’t provide is a way to ask questions the protocol designers didn’t anticipate, or to configure monitoring based on what matters to your operation rather than what the manufacturer deemed important.

OCPP 2.0.1 introduces the Device Model concept: a structured representation of charging station internals that operators can query, configure, and monitor on their own terms. If OCPP 1.6 gave you a check engine light, the Device Model gives you the full OBD-II diagnostic port. It's the difference between scaling a charging network and being scaled by it.

Subscribe now

From key-value chaos to structured intelligence

Let’s start with what we’re leaving behind.

OCPP 1.6 stores charging station configuration as a flat list of key-value pairs. Think of it as a dictionary where HeartbeatInterval = 900 (the charger saying “Hi, I’m still here” every 15 minutes) sits alongside MeterValuesSampledData = Energy.Active.Import.Register. Simple? Yes. Standardised? Partially. Useful for understanding what your charging station actually contains? Not particularly.

The problem isn’t that key-value pairs don’t work. The problem is they work the same way for every charging station, whether you’re managing a simple 7kW AC charger at a residential complex or a sophisticated 350kW DC fast charger with liquid cooling, multiple connectors, temperature sensors, and integrated payment terminals.

Consider these real-world scenarios that OCPP 1.6 handles poorly:

Scenario 1: The Unknown Station
A technician installs a new charging station. Your CSMS (Charging Station Management System) connects to it successfully, but what exactly did you just add to your network? How many EVSEs (Electric Vehicle Supply Equipment)? What connector types? Is there a display? A card reader? You’ll need to consult the manufacturer documentation, hope someone entered the data correctly in your asset management system, or send someone to physically inspect it.

Scenario 2: The Silent Failure
A charging station’s internal temperature sensor detects that the cooling system is struggling. The hardware knows there’s a problem brewing. But since there’s no standardised way to report component-level status or configure alerts on arbitrary measurements, you find out when a customer calls to report the station is offline.

Scenario 3: The Configuration Drift
You manage 500 charging stations from three different manufacturers. Each vendor implemented the optional configuration keys differently. Some support LocalPreAuthorize, others don’t. Some return values in different formats. Your CSMS code is littered with manufacturer-specific exceptions. Scaling to 5,000 stations means scaling your technical debt proportionally.

The Device Model in OCPP 2.0.1 addresses each of these scenarios through a fundamentally different architecture. One built around the principle that a charging station should be able to fully describe itself.

The three-tier model: structure that reflects reality

The Device Model introduces a hierarchical structure that mirrors how charging stations actually exist in the physical world.

Tier 1: The Charging Station
At the top level sits the charging station itself – the complete physical unit with its own identity, network connection, and overall status. This is where station-wide attributes live: supply phases, overall availability, the main electricity meter, environmental sensors.

Tier 2: The EVSE
Below the station are EVSEs (Electric Vehicle Supply Equipments) – the actual power-delivering unit. A dual-socket charging station that allows for charging two EVs at the same time has two EVSEs. Each EVSE has its own power capacity, its own availability state, and potentially its own characteristics (one might support 11kW while another handles 22kW).

Tier 3: The Connector
At the bottom level are connectors, which are the physical sockets drivers plug into. A single EVSE might have multiple connectors (a CCS and a CHAdeMO or Type 2, for instance, though typically only one can be used at a time). Each connector has a type, a phase rotation, and a physical state.

This hierarchy seems obvious when you think about it. Of course a charging station has EVSEs, and EVSEs have connectors. But OCPP 1.6 didn’t represent this structure in its data model, whereas the Device Model makes this explicit.

The illustration below shows various possible configurations of one or more EVSEs and its connectors.

Example A is the simplest possible setup. The charging station is what you would recognise as a typical single-socket AC charger: one car plugged in and charging, nothing else happening in parallel.

Example B looks similar on the outside – two sockets – but the internal structure is different. Here the charging station contains two separate EVSEs, each with its own connector. That means two cars can charge at the same time at full, independent power. This is what people usually call a dual-socket charger.

Example C is where things get interesting. This station has three connectors, but only two EVSEs behind them. One EVSE feeds an AC socket, while the other feeds two DC fast-charge connectors (for example CCS and CHAdeMO). Even though three cars could physically plug in, only two can charge at once: one on AC, and one on DC. The two DC plugs are effectively sharing the same power-delivery source.

Example D follows the same principle, but for modern DC fast charging in the US. The station has two EVSEs, and each EVSE feeds two connectors – CCS and NACS (North American Charging Standard). That allows drivers of different vehicle types to plug in, but again only two cars can actually charge simultaneously: one per EVSE.

Components and variables: the building blocks

Within this three-tier structure, the Device Model organises everything into components with variables.

Components are the logical or physical parts of a charging station. Some are obvious: EVSE, Connector, TokenReader, Display. Others are more specialised: AirCoolingSystem, LiquidCoolingSystem, RCD (Residual Current Device), OverCurrentProtection, EmergencyStopSensor. The specification defines over 70 standard component types, covering everything from cable breakaway sensors to ground isolation protection.

Each component can have multiple variables, which are named attributes with values. A TemperatureSensor component might have a Temperature variable. An EVSE component has variables like AvailabilityState, Power (with sub-types for actual and maximum), and SupplyPhases.

Here’s where it gets interesting. Variables aren’t just single values. They support multiple “attribute types”:

• Actual: The current measured or operational value

• Target: The desired value (for controllable components)

• MinSet/MaxSet: The limits within which the value can be configured

• Default: The value used if no other is specified

A fan speed variable might show Target = 2000 RPM (rotations per minute) and Actual = 1950 RPM, telling you both what you’ve asked for and what’s actually happening. A power limit (in W) might have maxLimit = 22000 (what the hardware can support) and Actual = 11000 (what you’ve configured) – information that was simply unavailable in the old world.

Self-description: plug-and-play installation

When a charging station connects to your CSMS under OCPP 2.0.1 and the Device Model is fully implemented, something remarkable happens. Your management system can request a “Full Inventory” report, and the station responds with a complete description of its structure, capabilities, and current configuration.

The exchange works like this:

1. Your CSMS sends GetBaseReportRequest with reportBase = "FullInventory"

2. The charging station responds with acceptance

3. The station then sends one or more NotifyReportRequest messages containing its complete Device Model

4. Your CSMS now knows exactly what it’s working with

The report includes not just current values but metadata about each variable: what data type it uses, what values are valid, whether it supports monitoring, whether it’s read-only or configurable. A well-implemented charging station sends enough information for your CSMS to auto-generate appropriate UI elements without any prior knowledge of that specific hardware.

This is the “plug and play” vision realised. A technician installs a new charging station, the device connects, identifies itself, sends its full inventory, and your CSMS can immediately display an accurate representation of its capabilities. No manual data entry. No consulting PDFs, spreadsheets or asset management systems. No surprises when someone tries to configure a feature the hardware doesn’t support.

Beyond configuration: monitoring and events

The Device Model isn’t just about reading and writing values. It introduces a sophisticated monitoring system that transforms how you handle operational intelligence at scale.

Hardwired monitoring

Charging stations can have built-in monitors that are always active. Examples are error conditions, fault states, and critical thresholds. When these trigger, the station sends a NotifyEventRequest that identifies exactly which component and variable is affected. This replaces the generic StatusNotification and the sometimes cryptic vendorErrorCodes from OCPP 1.6 with precise, actionable information.

Configurable monitoring

If supported by the station, your CSMS can set up custom monitors on any variable:

• Threshold monitors: Alert when a value exceeds an upper limit or drops below a lower limit

• Delta monitors: Alert when a value changes by more than a specified amount

• Periodic monitors: Report a value at regular intervals

Imagine configuring your network so that every station alerts you when internal temperature exceeds 60°C, or when the actual delivered power deviates from the target by more than 10%. You’re not waiting for failures – you’re detecting anomalies before they become outages.

That’s preventive maintenance and avoided customer frustration – which directly translates into higher consumer trust, higher utilisation, and a reduced amount of reactive (and costly) field engineer callouts.

Summary of the Device Model data concept

The diagram below shows how these concepts fit together. A component contains one or more variables, each variable has one or more attributes (e.g. the actual and target values) plus characteristics (metadata describing the variable’s type, limits, and capabilities). If supportsMonitoring is true, operators can attach monitors to receive alerts when values cross thresholds or change significantly.

Let’s apply this concept and make it more tangible. Say we want to inspect the charger’s AirCoolingSystem component, specifically the current power output of Fan 2 in EVSE 1’s cooling system. The data could be structured like this:

Component

• name: “AirCoolingSystem” ← Standardised component name

• evse: {id: 1} ← Which EVSE (tier location)

• instance: null ← Only one cooling system per EVSE

Variable

• name: “FanSpeed” ← Standardised variable name

• instance: “Fan2” ← Which fan (multiple fans exist)

Variable attributes

• Actual: 1980 RPM ← What it’s doing now

• Target: 2000 RPM ← What we asked for

• MinSet: 200 RPM ← Lowest configurable

• MaxSet: 3000 RPM ← Highest configurable

Variable characteristics

• dataType: integer

• unit: “RPM”

• minLimit: 0 ← Physical minimum

• maxLimit: 5000 ← Physical maximum

• mutability: “ReadWrite” ← We can read and change the configuration

• supportsMonitoring: true ← We can attach monitors

Practical implications for network management

Let’s revisit our earlier scenarios with the Device Model in place:

The Unknown Station (Revisited)
When a technician installs that new charging station, your CSMS requests the Full Inventory report. Within seconds, you know: two EVSEs, each with a single AC Type 2 connector, 11kW maximum per EVSE, no display but has an RFID reader, equipped with an air cooling system and emergency stop sensor, phase rotation RST on EVSE 1 and STR on EVSE 2 (we’ll touch upon phase rotation in a future article about load management). Your management system automatically adds this structure to your network visualisation. The technician moves on to the next installation.

The Silent Failure (Revisited)
Before deploying the station, you configure a monitor on the AirCoolingSystem component’s FanSpeed variable with an upper threshold alert and a delta monitor for sudden changes. You also set a threshold on the station-level Temperature variable. Three months later, the fan starts struggling. You receive an alert before the temperature becomes critical, schedule preventive maintenance, and the station never goes offline.

The Configuration Drift (Revisited)
Your CSMS requests the Configuration Inventory from each station, which is a report limited to settable parameters. Because components and variables follow standardised naming, you can build generic interfaces that work across manufacturers. When a variable uses an OptionList data type, the report includes the valid options. When it’s a numeric range, you get minLimit and maxLimit. Your code handles what the station actually supports, not what you assume it might support.

Controller components: where configuration lives

For those managing configuration at scale, the Device Model’s Controller (Ctrlr) components deserve special attention. These are components specifically for configuration parameters, grouped logically. Here are a few examples:

• AuthCtrlr: Authorisation behaviour settings

• SmartChargingCtrlr: Smart charging capabilities and limits

• SecurityCtrlr: Security profiles and certificate management

• LocalAuthListCtrlr: Local authorisation list settings

• OCPPCommCtrlr: Network and communication parameters

• ISO15118Ctrlr: Information exchange and Plug & Charge settings for ISO 15118

• SampledDataCtrlr: Meter value sampling configuration

• TxCtrlr: Transaction behaviour settings

Each controller groups related variables together. SmartChargingCtrlr might expose ChargingProfileEntries (how many profiles the station can store), PeriodsPerSchedule (the granularity of charging schedules), and supported profile types. LocalAuthListCtrlr reports both the maximum entries supported and the actual count currently stored.

This structure means you can query specifically for authorisation-related configuration, or specifically for smart charging capabilities, without parsing through a flat list of hundreds of keys.

Extensibility without fragmentation

One of OCPP 1.6’s underappreciated problems was vendor-specific keys. Need to expose a feature that’s not in the standard? Invent your own key name. Want to understand another vendor’s stations? Reverse-engineer their proprietary keys. The result was fragmentation dressed up as flexibility.

The Device Model handles extensibility more thoughtfully. Manufacturers can define additional components and variables beyond the standardised list, but the structure remains consistent. More importantly, the CustomizationCtrlr component provides a standardised way to expose and manage custom features.

A vendor implementing V2G (vehicle-to-grid) capabilities before the standard covers it can create a CustomizationCtrlr instance with their vendor ID, expose it through the standard reporting mechanism, and allow CSMSs to discover and potentially enable/disable the feature. Custom features become visible, documented, and controllable through the same interfaces as standard ones.

Implementation realities

For CPOs evaluating OCPP 2.0.1 adoption, here’s the practical picture.

On the CSMS side

The Device Model requires rethinking your data model. You’re moving from “a charging station is a thing with some key-value pairs” to “a charging station is a tree of components, each with typed, attributed variables”. Your database schema needs to accommodate this hierarchy. Your user interface (UI) needs to present it meaningfully. The payoff is a system that genuinely understands your hardware rather than just storing configuration strings.

The specification recommends building a “flexible DM repository” that uses the self-description in reports to scale graphs (MinSet & MaxSet), populate drop-downs (OptionList), and validate inputs (numeric, boolean). This is more work upfront but dramatically reduces per-station integration effort.

On the charging station side

Manufacturers vary significantly in Device Model implementation depth. A minimal implementation includes only mandatory components and variables – functional but limited. A full implementation exposes comprehensive self-description, supports configurable monitoring, and allows remote management of most operational parameters.

When evaluating hardware, ask vendors specifically about their Device Model implementation. Request sample reports. Verify which controller components are supported and how completely. The difference between minimal and full implementation is the difference between “OCPP 2.0.1 compatible” and “actually leveraging OCPP 2.0.1.”

How an implementation could look like

Imagine you need to represent a 350kW High Power Charger (HPC) with dual power modules, multiple temperature sensors, liquid and air cooling systems, and a full suite of configured monitors.

With everything you’ve learned about the Device Model’s capabilities, how would you structure this in your CSMS and present it to your operations team?

Lacking the design chops to mock this up myself (my Figma skills peaked at drawing rectangles and lines), I turned to Claude with that exact challenge. Here’s what my friend Opus 4.5 produced – feel free to steal liberally or judge harshly. ;)

You can download the Full Inventory report for this example charger below. Substack doesn’t allow uploading JSON or ZIP files. However, CBZ files work, which are literally just ZIP archives. So go ahead and download the file, rename the file ending to “.zip”, and unzip it to see the JSON content.

Hpc350 Notifyreport Mock Example

2.08KB ∙ CBZ file

Read now

Read now

Best practices for adoption

Based on implementation experience across the industry, several patterns emerge for successful Device Model deployment:

Start with Full Inventory reports when onboarding any station, but verify against your asset management system. In an ideal world, you'd build your internal representation entirely from what the station reports. In reality, many manufacturers implement the Device Model minimally, so the report may be incomplete. Use the Full Inventory as a baseline, flag gaps where the station reports less than your asset records indicate, and treat those gaps as integration debt to address with the vendor.

Use Configuration Inventory reports for audit and drift detection. Periodically request these reports from your charger infrastructure and compare against your expectations. Discrepancies indicate either unauthorised local changes or sync issues.

Implement monitoring progressively. Begin with critical thresholds (temperature, error states) and expand based on operational learnings. The stations will tell you what they can monitor – listen to them.

Build UI that adapts. When the Device Model reports that a variable is an OptionList with specific valid values, generate a dropdown. When it’s a number with minLimit and maxLimit, generate a bounded slider or input. Your interface becomes self-documenting.

Plan for the hierarchy. Station-level components behave differently from EVSE-level components. A power limit on the station affects all EVSEs. A power limit on an EVSE affects only that charging point. Your management logic needs to understand this inheritance.

The gap between specification and reality

The Device Model described in this article represents what OCPP 2.0.1 makes possible, not necessarily what you’ll encounter in the field today. Many charging station manufacturers implement the Device Model minimally, exposing only mandatory components and variables while keeping richer telemetry behind proprietary interfaces. The reasons range from legitimate (implementation complexity, verbosity of the Device Model, and resource-constrained hardware) to strategic (maintaining differentiation and vendor leverage).

This gap matters. The Device Model’s value scales with adoption depth. A network where every station fully self-describes, exposes configurable monitoring, and reports component-level status is fundamentally easier to operate than one where you’re stitching together partial OCPP data with manufacturer-specific APIs and manual asset records.

For CPOs, the path forward is twofold: demand comprehensive Device Model implementation in procurement, and design your CSMS to leverage it fully when it’s available while gracefully handling gaps when it isn’t. The stations that report more will cost less to operate. Make that a selection criterion.

If you want to know which charger manufacturers and CSMS providers have already been certified by the Open Charge Alliance (OCA) for properly implementing the Device Model, then head over to the OCA’s certification page and filter the protocol version for OCPP 2.0.1 and the certificate type for “D: Advanced Device Management”. You’ll only see a handful of companies as a result.

The Device Model is, in my opinion, the most powerful and important feature of OCPP 2.0.1. If you have a bit of time and want to learn more about all the wonderful new goodies this version brings to the table – such as better transaction handling, stronger cybersecurity, native ISO 15118 support – then I highly recommend watching the Open Charge Alliance (OCA)’s OCPP 2.0.1 tutorial webinar:

Hopefully this analysis has been useful – maybe even a catalyst for rethinking your approach. If you’re a charging station vendor, the Device Model isn’t just a compliance checkbox; it’s a competitive differentiator. The manufacturers who expose rich, queryable infrastructure that can be easily monitored will win the CPOs who are serious about scaling. If you’re a CPO, this is your leverage: demand implementation depth, not just certification logos, and make it a weighted criterion in every tender.

Yes, the Device Model comes with a learning curve and upfront investment. But the payoff is real: vendors who implement it fully will close deals with sophisticated operators; CPOs who require it will build networks that scale without scaling their headcount. That’s not a theoretical benefit – it’s the difference between infrastructure you manage and infrastructure that manages you.

In my next article (Part 2), we’ll examine why full adoption has been slow, including the role of MQTT as a parallel telemetry channel, the “Shadow OCPP” phenomenon where manufacturers maintain proprietary backchannels alongside your CSMS, and what it will take for the industry to realise the Device Model’s full potential.

In Part 1 of my Plug & Charge article series, we mapped out the market roles, the state of play of Plug & Charge in 2025, and the regulatory dynamics (e.g. AFIR, NEVI) across the globe. In Part 2, we went down into the cryptographic engine room: the foundational cybersecurity concepts that enable confidentiality, authenticity and data integrity, like public-private key cryptography and digital signatures. And in Part 3, we explored what “trust” really means in a machine-to-machine world and got introduced to the concept of digital certificates and public key infrastructures (PKIs). These PKIs form the architecture that facilitates trust and authentic communication between all market roles involved in making Plug & Charge a reality, worldwide.

In last week’s Part 4, we explored how the all-important contract certificate finds its way into your vehicle. This contract certificate is the EV’s charging identity or “passport”, and it’s linked to a billing account of your chosen mobility service provider (MSP).

The final missing piece in this Plug & Charge article series is what actually happens at the charger when you plug in the cable and the EV automatically authenticates and authorises itself for energy delivery without you having to do anything.

No apps. No cards. No QR codes needed to start charging. This is where it all finally comes together.

Subscribe now

How a Plug & Charge session actually works

Once a contract certificate is inside the vehicle, the magic of Plug & Charge plays out in three choreographed phases every time you plug in.

1. First, the car and charger build trust

It starts with the EV and the charger establishing a secure communication channel. After you plug in and the digital communication link is set up, they negotiate the version of TLS (Transport Layer Security) to use: TLS 1.2 for ISO 15118-2 or TLS 1.3 for ISO 15118-20.

The charger then presents its certificate chain – the SECC certificate and the CPO Sub CA certificates – to identify itself to the EV as a trustworthy charger. The same principle is at play when you surf any https-secured website these days. The charger is basically the equivalent of a web server in this analogy. In case you need a refresher on the various certificates that belong to each EV charging market role, check out my section on the ISO 15118 PKI ecosystem.

The EV then checks the entire chain against its pre-installed trust anchor, which is the V2G root certificate that was installed in the car before it was delivered to a customer – just like your browser checks a website’s certificate before loading a page. You may also want to refresh your understanding on the chain of trust from leaf certificate to trust anchor if that concept still feels a bit unclear.

Only ISO 15118-20 supports mutual authentication, whereby the vehicle also authenticates itself to the charger sending a Vehicle Certificate chain.

The EV also performs revocation checks: ISO 15118-2 relies on short-lived (2-3 months) SECC certificates and uses OCSP (Online Certificate Status Protocol) validation for the CPO Sub CA certificates, while ISO 15118-20 mandates OCSP for all certificates.

Once everything checks out, the EV accepts the charger as trustworthy and the rest of the conversation is encrypted.

2. The car and charger agree on the identification method

ISO 15118 supports two ways to identify the driver during a charging session:

• EIM (External Identification Means): RFID, credit card, app, QR code

• Plug & Charge: Fully automated certificate-based authentication

The crucial detail: the charger must not identify the driver twice.

If a driver taps an RFID card first and then plugs in, the charger should not offer Plug & Charge anymore; otherwise, the EV might also authenticate using its contract certificate, creating the risk of duplicate billing.

A sensible approach is:

• If the driver authenticates via EIM first → disable Plug & Charge for this session.

• If the cable is plugged in first → offer both.

• If Plug & Charge fails due to an expired or invalid certificate → fall back gracefully, reset, and give the EV another chance or offer EIM as backup.

Designing this identification logic well makes the difference between effortless charging and user confusion.

Step 3: The car proves who it is

Once Plug & Charge is selected, the EV presents its contract certificate – along with the MSP Sub CA certificates, all packaged up nicely in a certificate chain – to the charger, and this is where the real authentication happens. Behind the scenes, several security checks unfold, each designed to ensure the session is legitimate, the billing account is valid, and no one is trying to impersonate the vehicle.

1. The charger verifies the certificate chain

The charger or CPO backend checks:

• Validity: none of the certificates in the chain have expired

• Authenticity: every signature from the contract certificate up to the root is valid

These checks can – and should – be performed locally on the charger. A prerequisite for that is that the charger has the correct root certificates installed – typically one of the V2G root CAs provided by the PKI operators, or in rarer cases an MSP’s own root CA (less likely). If those certificates aren’t available locally, the charger must send the contract certificate chain to the CPO backend for verification, usually via OCPP 2.0.1 (or, less ideally, via OCPP 1.6 with security extensions, which can introduce interoperability issues).

I highly recommend doing this verification step locally (on the charger) as these certificate chains are several kilobytes in size and can delay the charging process depending on the charger’s internet connectivity and data congestion. Otherwise, you risk negatively impacting the user experience.

2. The charger checks for revocation

Some checks must be online. One of them is certificate revocation. The charger queries the OCSP responder listed in the certificate to make sure that:

• the CPO Sub CA certificates (ISO 15118-2 and -20), and

• the contract certificate (ISO 15118-20 only),

have not been revoked. Without this, a compromised or invalid certificate could still authenticate.

Hubject’s Requirements EVSE CHECK for Plug & Charge with ISO 15118-2

Hubject currently provides a Plug & Charge (PnC) certification program for EV chargers called EVSE Check, which has helped accelerate early adoption.

As such, Hubject published a requirements document that every charger manufacturer and CPO must study closely because it defines the exact security and process steps required for a seamless, interoperable Plug & Charge experience across the ecosystem.

For example, section 2.8 “Performing PnC related OCPP messages” stipulates that a charger should verify the contract certificate chain locally because it already holds the V2G / MSP root certificates needed for validation, making the process faster without burdening the network.

The CPMS does not need the full certificates, only their (significantly smaller) hash data, which uniquely identifies each certificate and is sufficient for OCSP responders to check their revocation status. Sending the full certificate chain would add no security value while significantly increasing message sizes and communication overhead.

The OCPP configuration key CentralContractValidationAllowed specifies whether the backend is allowed to receive full certificates; if this key is not set, the charger must default to local validation of all the signatures along the certificate chain and send only hash data in the AuthorizeRequest to check each certificate’s revocation status. This ensures consistent behaviour, reduced bandwidth usage, and a smoother, faster Plug & Charge flow.

3. The charger verifies the billing account

Trust in the certificate alone, which represents the charging identity, is not enough. The charge point operator (CPO) also needs to know that the billing contract is still active.

Using the provider ID inside the E-Mobility Account Identifier (EMAID), the CPO’s backend – also known as Charge Point Management System (CPMS) – contacts the correct MSP to confirm that the account hasn’t been suspended or cancelled. This is a crucial business step: no CPO wants to deliver energy without knowing they’ll be paid for it.

And how does the CPO get in contact with the right MSP, based on this EMAID?

That’s where roaming protocols comes into play. The CPO uses either a roaming hub like Hubject (which currently only supports their proprietary OICP protocol) or the peer-to-peer roaming protocol OCPI (Open Charge Point Interface). The latter is becoming more and more an industry standard, which is why Hubject finally announced their support of OCPI in September 2025. According to my sources, it’ll probably take until the end of 2026 until Hubject fully supports OCPI as well.

4. The system prevents replay attacks

To ensure no attacker can “replay” a previously captured authorisation message, ISO 15118 uses a challenge-response mechanism. The charger sends a secure and randomly generated 128-bit value (the “challenge”). The EV must include this challenge in its Authorization Request message and sign the message using the private key linked to its contract certificate.

The charger verifies this signature using the contract certificate’s public key. No backend is needed here – just proper cryptography and a secure random number generator. For data privacy and security, the EV’s contract certificate must not remain stored on the charger once the session ends.

5. And then charging can finally begin

Once all checks pass – certificate chain validation, revocation, billing account status, and replay protection – the EV is authenticated. Only then do the EV and charger continue with the ISO 15118 message flow to negotiate charging parameters and charging schedules.

The sequence diagram below summarises the relevant steps of the authentication and authorisation flow we just discussed. It illustrates the activities of each involved party – EV, charger, CPMS backend, OCSP responder, mobility service provider – and the communication protocols used to exchange the data.

Does Plug & Charge work if the charger is offline?

Technically yes, but not without disregarding the above mentioned security checks.

A charger can authorise offline, but it’s risky: the billing account might later turn out to be suspended.

A pragmatic approach is:

• allow Plug & Charge when offline only if the certificate has not previously caused a failed billing validation,

• otherwise fall back to EIM (e.g. using a local RFID allowlist) until the charger is online again.

This approach keeps drivers charging while still protecting the CPO against repeated losses.

Operational takeaways for OEMs and CPOs

Let’s clarify what cryptographic material must live inside an EV and a charging station to establish a secure TLS 1.2 (ISO 15118-2) or TLS 1.3 (ISO 15118-20) connection and to provision, store, and validate the contract certificate(s) for Plug & Charge.

In TLS (Transport Layer Security), each side needs two distinct sets of data: identity material (often called a keystore) and trust material (often called a truststore).

The keystore holds the device’s private key and its corresponding leaf certificate, usually together with any required intermediate (Sub CA) certificates, and represents “who I am.”

The truststore contains trusted CA certificates (trust anchors) used to verify the other party’s certificate and answer “who do I trust” (see my explainer on chain of trust).

While the terms keystore and truststore are common (and well known from Java), you may also see the same concepts described as private key + certificate chain, identity, CA bundle, root store, or trust anchors in C, C++, Rust, and embedded TLS stacks.

The image below illustrates where each cryptographic key material and digital certificates need to sit. This becomes an important consideration when determining how much memory your EV or charger should include before it goes to market.

It is difficult to specify an exact number of certificates that must be stored in a Plug & Charge-enabled EV or charger brought to market. Instead, the following guidelines can be used to size the required certificate storage appropriately:

General considerations

• While ISO 15118-2 allows for maximum certificate sizes of 800 bytes, in ISO 15118-20 the maximum allowed certificate size increased to 1,600 bytes. This change was introduced to accommodate the richer data (e.g. more detailed subject/issuer fields) and modern cryptographic algorithms required (e.g. stronger elliptic curves such as secp521r1 or Ed448).

• Certificates issued for ISO 15118-2 cannot be reused for ISO 15118-20. Each standard version requires its own dedicated certificate hierarchy, including separate leaf and Sub CA certificates.
  

  For example, an OEM provisioning certificate issued for ISO 15118-2 is valid only for that version and must not be used for ISO 15118-20. Supporting both standards therefore requires installing and managing two parallel certificate sets – one for ISO 15118-2 and one for ISO 15118-20.

• All cryptographic key material on the EV or charger should be stored in a hardware-backed secure element – e.g. TPM 2.0-compliant device or Hardware Security Module (HSM) – that enforces non-exportable keys and protected cryptographic operations.

Memory storage for EVs

• The OEM provisioning certificate only needs to be stored on the EV if the vehicle manufacturer intends to support contract certificate installation via the charging station using ISO 15118. If the contract certificate is provisioned exclusively via over-the-air (OTA) updates, the OEM provisioning certificate only needs to reside in the cloud-based Provisioning Certificate Pool (PCP) (see here for a refresher on PCP).

  The same applies to the OEM Sub CA certificates. These certificates must be installed on the EV only if the vehicle supports ISO 15118-20 and contract certificate installation via the charging station is enabled as a feature. Otherwise, they can remain solely in the PCP.

  According to Steffen Rhinow, Director Plug & Charge at Hubject, the prevailing trend is to provision contract certificates exclusively via OTA updates rather than through the charging station.

• The Vehicle Certificates were introduced with ISO 15118-20 to enable mutual TLS authentication. Mutual authentication means that authentication now happens in both directions – the EV must also prove its identity to the charger, not just the other way around. Vehicle certificates are not used in ISO 15118-2.

• The more MSP contracts an EV driver is allowed to use with their EV, the more contract certificate chains (leaf + two Sub CA certificates) need to be stored on the EV.
  
  For example, if a vehicle allows up to five MSP contracts and supports both ISO 15118-2 and -20, then worst case you need to account for a maximum of

  • 5 x 3 x 800 bytes (five ISO 15118-2 contract certificate chains)

  • + 5 x 3 x 1600 bytes (five ISO 15118-20 contract certificate chains)

  • = 36 kilobytes for contract certificates.

• Each EV must have sufficient storage to hold all relevant V2G root CA certificates for the region in which it is sold. OEMs do not embed all global V2G root CAs by default; instead, the selection is driven by the vehicle’s target market.
  
  For example, an EV sold in Europe typically does not require North American trust anchors, and vice versa. Based on the illustration above, an EV sold in Europe should be capable of storing at least three V2G root CA certificates – one each from Hubject (current market leader), Irdeto, and Gireve. In addition, storage must account for a transitional period of roughly one year during which an expiring trust anchor and its replacement coexist. I’d say storage for five to six trust anchors should be sufficient.

  
  The current reality is that only Hubject’s V2G root CA is installed in Plug & Charge enabled EVs. Time will tell when Iredto, Gireve, and other PKI providers’ trust anchors will find their way into the EVs of various vehicle brands.

  
  Note that the industry is moving toward Certificate Trust Lists (CTLs) – a simpler way to publish trusted Root CAs. The EU’s Sustainable Transport Forum (STF) is currently defining a PKI interoperability governance directive, which defines the guidelines for operating such a CTL. Current timelines hint at a publication by earliest 2026, more likely 2027.

• Remember that the corresponding private keys must also be stored for each leaf certificate, because they are needed to create the digital signatures: one for every contract certificate, potentially one for the OEM provisioning certificate (if contract certificate installation via the charging station is enabled), and one for the vehicle certificate (mutual authentication for ISO 15118-20 only).

Memory storage for chargers

• In practice, most CPOs integrate with only a single PKI provider for issuing their SECC certificate chain. The dominant provider today is Hubject, whose V2G root CA is embedded in virtually all Plug & Charge-enabled EVs. As a result, ensuring regional interoperability seems to largely fall to vehicle OEMs, which must install all relevant V2G root CA trust anchors for the markets in which their vehicles are sold.

• Building on the previous point, the CPO must install the V2G root CA trust anchor on the charger so that the charger can validate the SECC certificate chain during installation via OCPP.

• To enable local validation of the contract certificate chain received from the EV during Plug & Charge authentication, the CPO must ensure that the trust anchors of all relevant MSPs are installed on the charger. While many MSPs are likely to rely on one of the existing V2G root CAs – like Digital Charging Services (DCS), used e.g. by BMW – some vehicle manufacturers who offer their own MSP service also operate a dedicated MSP root CA. Examples are Tesla, Rivian, Lucid, and Volkswagen (using Elli).

• Finally, to support mutual authentication in ISO 15118-20 and verify the EV’s identity, the CPO must install all relevant trust anchors used by different vehicle brands. These trust anchors may be OEM-specific root CA certificates (if operated by the vehicle manufacturer, like Tesla, Rivian, Lucid, VW etc.) or V2G root CA certificates provided by a PKI provider – most commonly Hubject, which is currently the market leader.

The costs of maintaining SECC certificates

One note on the cost of issuing SECC certificates for CPOs: the price is about €0.99 per SECC certificate per year (Hubject’s price, may be similar with other PKI providers), effectively per charging station, as each charger typically has one ISO 15118 communication controller (the SECC, stands for Supply Equipment Communication Controller).

Although an SECC certificate must be renewed multiple times per year (typically three to four times), the fee is charged only once annually. As a result, the total cost of issuing and maintaining SECC certificates scales directly with the number of Plug & Charge-enabled charging stations deployed in the field.

Plug & Charge Direct – ISO 15118 & credit cards

Before we close this chapter on Plug & Charge, I want to make you aware of a recent new development: Plug & Charge Direct.

Plug & Charge Direct was introduced by Hubject and fundamentally expands the classic contract-based Plug & Charge model by adding direct payment via credit card, without breaking the ISO 15118 flow. In short: drivers no longer need a pre-existing MSP contract. Instead, they can register a credit card once via the OEM app or vehicle HMI, after which charging works exactly like Plug & Charge today – just plug in and charge. Behind the scenes, a contract certificate is still generated and installed in the vehicle, but it is now linked to a payment token rather than an MSP account, preserving the familiar PKI-based authentication model.

What makes this interesting is how seamlessly it integrates into the existing ecosystem. The EV still authenticates via ISO 15118, the charger still talks OCPP to the CPO backend, and authorisation and clearing continue to flow through Hubject’s platform. The difference is that authorisation now also involves a Plug & Charge Direct service that matches the vehicle’s EMAID to a payment token and triggers credit-card-based settlement in parallel. For CPOs, this means broader access specifically to vehicle OEM fleet cars that may not be enabled for an MSP-based Plug & Charge experience. For drivers, it means Plug & Charge convenience, no contracts required, and full price transparency right in the car or app.

Mer and BMW were the first to implement this concept, let’s see how the market will evolve in this direction.

Thanks to Steffen Rhinow from Hubject for providing the slide deck, which explains this concept in more detail (see download link below).

2025 Plug & Charge Direct

3.83MB ∙ PDF file

Download

Download

And that’s a wrap for today.

If you’ve followed the full five-part Plug & Charge series – congratulations. You’re now pretty much an expert. You should have everything you need to be dangerous in the best possible way and to confidently support your team in bringing Plug & Charge products to market.

If you have any follow-up questions, feel free to drop them in the comments below or reply directly to this email (and don’t forget to sign up for the newsletter if you haven’t already).

I wish you a wonderful holiday break and some well-deserved days to recharge with friends and family. I’ll be taking a short break as well and will be back in January with a brand-new article series. Spoiler alert: we’ll dive into the exciting world of load balancing – and eventually vehicle-to-grid – analysed with the same level of detail and depth you’ve come to expect (and hopefully cherish) from this newsletter.

See you in 2026.

How a physical vehicle becomes a digital charging identity. How a billing relationship is transformed into a cryptographic contract. How that contract is securely delivered into your car – sometimes quietly in the background, sometimes live at the charging station – so your EV can use it to authenticate and authorise on your behalf in a matter of seconds.

Bringing home the same “just plug and go” experience Tesla drivers have experienced for a long time – but enabled across all EV and charger brands.

Throughout this article, I’ll link back to the first three chapters of this five-part Plug & Charge series. Those earlier pieces introduced the market roles, the cryptographic building blocks, and the digital certificate ecosystem (think PKI) that make everything work. This article brings those threads together so the “magic” of Plug & Charge finally feels tangible and real.

Subscribe now

You plug in your car. And charging just… starts.

To the driver, this feels effortless. You don’t even need to go inside the kiosk to pay for the electricity.

To the system behind it, this is one of the most carefully choreographed trust exchanges in the entire energy and mobility ecosystem. What looks like a single moment of convenience is actually the result of a multi-party cryptographic provisioning process that began long before that cable ever touched the socket.

Let’s unpack what really happens before Plug & Charge ever becomes “just plug in and go”.

How your EV turns into a digital charging identity

One of the most important steps in Plug & Charge doesn’t happen at a charging station. It happens before the car is even sold.

Step 1: Create vehicle identity & install trust anchors

When a vehicle leaves the factory, it already carries:

• A unique digital identity called Provisioning Certificate ID (PCID), which is tied to that exact physical vehicle

• A public–private key pair generated securely inside the car

• An OEM provisioning certificate issued by the manufacturer, which contains both the PCID (in its Subject attribute1) and the newly created public key – this certificate is basically the vehicle’s own “digital passport”

• And one or more V2G root CA certificates that tell the car which charging infrastructure it is allowed to trust. Go check this section in the previous article if you don’t know or remember what I mean by V2G root CA certificate.

This is the EV equivalent of pre-installing trusted website identities into your web browser. Without these trust anchors, the car would have no way of knowing whether a charger is legitimate or a fake designed to intercept data.

The vehicle manufacturer also uploads the OEM provisioning certificate, along with its OEM Sub CA certificates, to a database called the Provisioning Certificate Pool (PCP), operated by the PKI provider. The MSP will need access to this certificate chain, as you’ll see in the next step.

The illustration below focuses on the vehicle manufacturer’s steps to create an OEM provisioning certificate and to store it in the vehicle for which it was issued.

There are several Plug & Charge PKI providers operating globally, each offering their own V2G root certificate authority (CA). In Europe, we have Hubject, Irdeto, and Gireve. In North America, the landscape includes Hubject, Irdeto, SSI, and DigiCert.

From what I understand, car manufacturers don’t install all of these by default. Instead, the choice of which V2G root CAs to embed is largely driven by where the vehicle is sold. A car delivered in Europe is unlikely to need the North American trust anchors, and vice versa.

All right, let’s move on. At this stage, the car doesn’t yet know who will pay for charging.

Step 2: Linking the MSP to the vehicle’s unique identity

The mobility service provider (MSP) is the market role that provides the billing account for the energy your vehicle charges during a Plug & Charge session. The single most important piece of information the MSP needs from the vehicle owner is the PCID – the provisioning certificate ID that uniquely identifies the specific vehicle being enabled for Plug & Charge.

In the cleanest implementation, the vehicle owner retrieves this PCID directly from the car’s app or from documentation supplied by the manufacturer. But in practice, some MSPs deliberately abstract this complexity away from the user and accept more familiar identifiers instead, such as the vehicle registration number or even the VIN (vehicle identification number). Octopus Electroverse, a pioneer on Plug & Charge on the MSP side, follows this approach in its Plug & Charge onboarding flow.

In the UK, this works because MSPs can – under tightly regulated conditions – query the DVLA (Driver and Vehicle Licensing Agency). The DVLA is the government body that holds the authoritative register of all vehicles and registered keepers. By resolving a number plate against DVLA records, the MSP can indirectly determine the underlying PCID it actually needs.

Why does that PCID matter so much?

Because it is the lookup key that allows the MSP to retrieve the car’s OEM provisioning certificate and related OEM Sub CA certificates from a dedicated database called the Provisioning Certificate Pool (PCP).

And crucially, the MSP uses the public key inside the OEM provisioning certificate later to establish a secure encryption key with the vehicle (using an ECDH-style key agreement). That shared key is then used to encrypt the vehicle’s private signing key when the contract certificate is created. This signing key is the private counterpart to the public key embedded in the contract certificate itself.

Step 3: Turning the billing contract into a cryptographic ID

Once the MSP has both:

• a confirmed PCID, and

• proof that the driver is entitled to use the vehicle,

it can begin creating the digital object that actually enables seamless Plug & Charge: the contract certificate.

The first thing the MSP generates is the E-Mobility Account ID (EMAID). This is the globally unique identifier that’s tied to the charging contract, think of it as the billing account ID. The structure of an EMAID is defined in ISO 15118 and it encodes:

• the country the mobility service provider is registered in,

• the MSP’s provider ID,

• and the unique billing account instance.

Several countries have established identifier registries for businesses where you can look up both operator IDs (for CPOs) and provider IDs (for MSPs). In the UK, for example, it’s the EV Roam registry, in Germany it’s the Energy Codes & Services GmbH.

To stay with the Octopus Electroverse example from above, a valid EMAID could be GB-OCT-C1234ABCD (with GB-OCT being Octopus’ provider ID in the UK).

At this point, the EMAID represents a commercial relationship. Next, the MSP:

1. Requests the OEM provisioning certificate (and the connected OEM Sub CA certificates2) from the provisioning certificate pool, using the PCID supplied during signup as a lookup key.

2. Generates a brand-new public–private key pair that will represent the cryptographic identity of the charging contract.

3. Issues and signs the contract certificate (see an example here), binding together:

   • the newly generated public key,

   • and the EMAID (in the Subject attribute).

Now comes one of the most security-critical steps in the entire system.

The private key must be transferred to the vehicle – but in a way that ensures only that specific EV can ever use it.

To achieve this, the MSP:

• takes the public key from the OEM provisioning certificate,

• uses it to establish a secure encryption key with the vehicle in order to encrypt the newly created private signing key that’s mathematically linked to the contract certificate’s public key3,

• and then permanently deletes its own unencrypted copy of that private key.

From this moment onward, the MSP is cryptographically locked out. The EV alone will be able to use that private key to create digital signatures for Plug & Charge authentication at the charging station.

The contract certificate (plus the linked MSP Sub CA certificates) and the encrypted private key are now, together with a few other data elements, assembled into a data package called contract certificate bundle, which is then sent to the certificate provisioning service (CPS).

The illustration below summarises the MSP’s role outlined in steps 2 and 3 above. I’ve intentionally abstracted a few details of the contract certificate bundle that aren’t essential to understanding the flow and only really matter during implementation.

(Update 17/12/2025: The image below and description above were slightly updated to reflect that the MSP does not need to verify the OEM’s certificate chain itself, as it relies on the provisioning certificate pool to have already performed that validation.)

Step 4: Certificate Provisioning Service & transitive trust

In deregulated markets like Europe, the charge point operator (CPO) and the mobility service provider (MSP) must be legally separate entities. That separation makes trust a bit more complicated.

In theory, every MSP could operate its own root certificate authority (as discussed in the last article) but that would force car manufacturers to preload potentially dozens or hundreds of MSP trust anchors into every vehicle. The resulting memory and update management would quickly become impractical, especially given the high cost and strict optimisation requirements in automotive electronics.

The CPS solves this through transitive trust.

It operates under a V2G root CA that the EV already trusts (pre-installed) and:

• verifies the MSP’s contract certificate chain, for which it uses the V2G (or MSP) root CA certificate that’s stored in a database called Root Certificate Pool (RCP) – every PKI provider, be it Hubject, Irdeto, Gireve or others, operate an RCP, which stores the relevant Plug & Charge root CA certificates,

• re-packages and digitally signs the contract certificate bundle,

• and stores the final, signed contract certificate bundle – which also contains the CPS certificate chain for the signature verification later on – inside another database called Contract Certificate Pool (CCP).

From the EV’s point of view, this means: “I don’t need to trust every MSP on earth, only the one I already know.”

And that single design decision is what allows Plug & Charge to scale globally without collapsing under certificate chaos.

The illustration below summarises the CPS’s steps we just discussed.

Step 5: How the certificate actually enters the car

By the time we reach this stage, the heavy lifting is done. The contract certificate exists. The associated private key has been generated, encrypted specifically for one single vehicle, and wrapped into a signed data package by the certificate provisioning service. All of this now sits ready inside the contract certificate pool, which is a database operated by the PKI provider (like Hubject, Irdeto, or Gireve).

What remains is the final and most visible step: getting that cryptographic identity into the vehicle itself. And interestingly, the ecosystem supports two fundamentally different installation paths.

Path A: Over the air via the car manufacturer

If a vehicle manufacturer supports over-the-air (OTA) installation via its telematics backend, it can subscribe directly to updates from the contract certificate pool. The moment a new certificate becomes available for one of its vehicles, the OEM backend is notified immediately – implemented either via a publish-subscribe mechanism or webhooks.

From there, the manufacturer:

• retrieves the signed contract certificate bundle (signed by the CPS),

• checks the authenticity of this data package by verifying its digital signature with the CPS certificate chain (included in the data package) and the right V2G root CA certificate (received from the PKI provider’s Root Certificate Pool),

• retrieves the encrypted private key, contract certificate, and the extra information the vehicle needs to decrypt that private key – the ECDH public key generated by the MSP during encryption,

• securely transfers them to the vehicle via its own cloud infrastructure,

• and lets the vehicle perform the final step locally: decrypting the private key and storing it alongside the contract certificate inside the car.

The car manufacturer controls the entire user journey and can integrate Plug & Charge activation seamlessly into the app and/or in-car user experience.

From the driver’s perspective, Plug & Charge simply “appears” one day, no charger interaction required.

Here’s a great video from BMW on how to activate and use Plug & Charge. BMW has gladly understood the importance of letting the vehicle owner decide which MSP contract they prefer to use, and when. They support up to five contracts, including their own MSP service which is facilitated through Digital Charging Solutions.

Path B: Live installation at the charging station

The second path is the classic ISO 15118 flow, using the Certificate Installation Request / Response message pair specifically designed for this scenario.

Here, the installation happens in real time, at the moment the vehicle is plugged in – if the charging station supports contract certificate installation, which is one of several possible value-added services the charger can offer. The Certificate Installation Response basically carries all the data elements contained in the signed contract certificate bundle, just packaged in the right ISO 15118 message format.

But because of the tight timing constraints in ISO 15118, this method is far from ideal in my opinion. As soon as the EV sends its Certificate Installation Request, a five-second timer starts. If the response doesn’t arrive within that time window, the procedure fails. In ISO 15118-2 this is especially brittle, because the vehicle must abort after five seconds, even though the Certificate Installation Response can be several kilobytes in size and may take longer to retrieve over a slow or congested network. ISO 15118-20 softens this behaviour: instead of giving up after five seconds, the vehicle is allowed to keep waiting for the response.

As this path is likely going to be less common in the future (to the point that I assume all car manufacturers will converge to OTA installation), I’ll not dive into any further details about this installation path.

To bring it all together – and untangle any knots this deep dive might have created – I’ve put together a visual summary of the flow we just covered in Step 4 and Step 5. I’ve left out smaller details like the ECDH public key to keep the illustration readable, but you’ll find those explained in the text above.

When all of this disappears into a single moment

Once the contract certificate is installed – whether via the vehicle’s telematics link or live at the charger – the system finally reaches the state the driver always assumed it was in from the beginning:

• the car now holds a valid cryptographic charging identity (contract certificate),

• it can authenticate automatically upon plugging in the cable (using the private key to create digital signatures that can then be verified with the contract certificate),

• and the vehicle owner’s billing account (identified via the EMAID) can be billed without any further human interaction.

From that moment onward, Plug & Charge feels simple.

But what makes it remarkable is how much coordination, cryptography, and infrastructure silently converge just to make that simplicity – enabled by automated and secure machine-to-machine communication – possible.

Congratulations! You now know all the steps that need to happen prior to a Plug & Charge session. In my next article, which will conclude this Plug & Charge series, we’ll finally go through how a Plug & Charge session actually works.

One language to coordinate all market roles

Now that you know what the car manufacturer, mobility service provider, certificate provisioning service, and charge point operator need to do orchestrate the provisioning and installation of a digital contract certificate, the question becomes: how are they going to communicate with each other?

What does this mean for you, as someone tasked with “making Plug & Charge work”. Is there a standardised “language”, an agree-upon unified protocol you can leverage?

An open Plug & Charge testing environment

Thankfully, there is. Or at least we’re on the way to creating one.

Early 2022, Hubject introduced an open-source protocol called Open Plug and Charge Protocol (OPCP). The purpose of the OPCP protocol is to provide an open, international, supplier-agnostic API framework that enables seamless interoperability across Plug & Charge systems, linking multiple PKI ecosystems, CPOs, MSPs and OEMs so that EVs, chargers and backend networks can operate together smoothly.

To help familiarise yourself with OPCP, Hubject created a public Plug & Charge testing environment where you can freely interact with their PKI ecosystem. It’s a testing playground where you can impersonate any of the market roles we discussed above and create various kinds of certificates, access the data pools that store these certificates, and explore the API interface of OPCP to interact with their PKI system.

OPNC: The path to a fully interoperable solution

In 2024, CharIN e.V. established a task force to take over the governance of this open-source project and changed the protocol name to Open Plug & Charge Network Communication Protocol, or OPNC (link to GitHub repo) for short.

I know, it’s becoming a bit of a joke with all those protocol acronyms that all have an ‘O’, ‘P’, and ‘C’ in it. But fear not, I’ve prepared an Acronym Survival Guide for you.

The OPNC task force is currently paused until March 2026 while Hubject, Irdeto, and Gireve run their interoperability pilot – a phase meant to generate real-world insights before any new protocol work continues. OPNC 1.0 was never implemented by the industry, largely because it offered no practical value over OPCP and supposedly suffered from robustness and security issues. The hope is that this pilot will inform a completely reworked OPNC 2.0 that is genuinely secure, multi-supplier compatible, and worth implementing.

What the Hubject–Irdeto–Gireve partnership actually delivers

The partnership between Hubject, Irdeto, and Gireve effectively allows CPOs, MSPs and vehicle OEMs to simply choose which Plug & Charge PKI provider they want to work with out of the three, and they’ll gain access to the other two Plug & Charge ecosystems as well. Technically, mutual API integrations connect the PKI pools into one interoperable network, allowing all three partners to exchange provisioning certificates (PCP), contract certificates (CCP), and root certificates (RCP) seamlessly.

For MSPs, this is a major win: they can now create contract certificates on any of the three PKI providers, regardless of where the vehicle’s OEM provisioning certificate is stored. The system takes care of the rest: it makes sure the contract certificate is signed by the CPS that’s linked to the same V2G root CA the vehicle already trusts, and finally delivered to the vehicle either via CPO-triggered installation or through existing OEM telematics integrations.

Car OEMs see little day-to-day change, except that all their vehicles’ provisioning certificates become visible across all three PKI providers. And CPOs gain the ability to perform contract certificate installations for any contract certificate, no matter which PKI provider’s contract certificate pool (CCP) issued or stores it.

In summary, all three providers have connected their PCP and CCP data pools, audited one another, and also retrieve each other’s root CA certificates on demand. The partnership dissolves the old PKI silos, enabling true cross-provider Plug & Charge certificate creation and installation.

And that brings us to the end of today’s story — a look at how Plug & Charge comes to life through the carefully choreographed collaboration of all the e-mobility players involved.

My next article will conclude this five-part Plug & Charge series. In this final missing piece you’ll find out what actually happens at the charger when you plug in the cable and the EV automatically authenticates and authorises itself for energy delivery without you having to do anything.

You never know when this stuff will come in handy – your next job interview, a tricky internal project, or that conference where you get to wow people with unexpectedly deep Plug & Charge knowledge. (I’d be keen to hear some anecdotes from you).

So stay tuned, and please do share this newsletter with anyone who you believe could benefit from it. Let’s work together to make Plug & Charge ubiquitous!

This week, we shift from how messages are protected to how identities are proven.

Because behind every Plug & Charge session lies a sophisticated public key infrastructure (PKI), a system of digital certificates and trust anchors that ensures every actor in the ecosystem is exactly who they claim to be.

Think of PKI as the backbone of trust: issuing digital “passports”, validating identities, and ensuring that an EV doesn’t just connect to a charger, but to a trusted one. Without this “chain of trust”, Plug & Charge simply wouldn’t work. And as EV charging infrastructure grows into a critical part of our energy and mobility infrastructure, it’s becoming an increasingly attractive target for attackers. This is why it’s essential that cybersecurity is designed in from day one, not patched on later as an afterthought.

In this article, we’ll explore:

• How a digital certificate actually looks like

• How the chain-of-trust principle works, from a root CA down to leaf certificates

• The different digital certificates that make the Plug & Charge ecosystem function

• Where each certificate must live – in the EV, in the charger, or in the backend

At the end of the day, a digital certificate is nothing more than a high-security ID card – one that expires, can be revoked, and must be maintained. And understanding how that system works is the key to understanding how Plug & Charge truly stays secure.

Once you understand these basic principles, it’ll be a walk in the park to follow next week’s article where we’ll explore the complete lifecycle of a Plug & Charge session.

Let’s get to it.

Subscribe now

Basic principles: a PKI’s chain of trust

In a PKI system, a trusted third party known as a certificate authority (CA) issues digital certificates that contain public keys and identifying information about the certificate holder, such as an EV or a charging station.

Let’s take the charging station as an example.

A charger first generates a digital key pair: a private key (kept securely inside the charger) and a matching public key. The charger then uses that public key, along with its identifying details, to create a Certificate Signing Request (CSR), which it signs with its newly created private key and sends to a certificate authority – using the charge point operator’s backend, or CPMS. The CA verifies the request and, if valid, issues a signed certificate that binds the charger’s identity to its public key, allowing the charging station to authenticate securely towards an EV during Plug & Charge sessions.

Anyone who wants to verify that authenticity of a digital certificate simply checks the CA’s digital signature using the CA’s public key, which is stored in the CA’s own certificate. This creates what’s known as a chain of trust: a tree-like structure that starts with an end-entity or “leaf” certificate (such as the one held by an EV or charger) and ultimately leads back to a root CA certificate, the final trust anchor. Computer scientists love this analogy – a root at the top, leaves at the bottom – because it perfectly captures how trust flows downward through the system.

In the EV charging world, this trust chain spans multiple players who all depend on one another to make Plug & Charge work smoothly:

• The electric vehicle (EV)

• The EV manufacturer (OEM)

• The charging station

• The charge point operator (CPO)

• The mobility service provider (MSP)

• The certificate provisioning service (CPS)

• The operators of the V2G Root CA

• And the operators of the various data pools and cloud services required for certificate provisioning

If you want to read more about the purpose of all these roles in the wider e-mobility ecosystem, then I highly recommend the article Plug & Charge: The technology, the ecosystem, and the road ahead of seamless charging.

A coordinated effort between all these stakeholders, across different industries and regions, is essential to delivering a truly seamless and secure charging experience – no matter which MSP or location a driver chooses to charge their EV.

How does a digital certificate look like?

Alright, so we know there’s a certificate authority that has the power to create a digital certificate, and that digital “passport” carries a public key and the CA’s digital signature, among other pieces of information.

Let’s have a look at an example. In particular, let’s examine a contract certificate, the one the EV uses to identify and authorise itself at the charger to receive energy.

Let’s analyse this certificate step-by-step:

1. Version: This indicates we’re looking at a standard X.509 version 3 certificate, the foundation of modern PKIs and transport layer security (TLS).

2. Serial Number: A unique identifier issued by the certificate authority for tracking and revocation.

3. Signature Algorithm: This certificate is signed using ECDSA (Elliptic Curve Digital Signature Algorithm) with SHA-256 hashing. Check out the previous article in case you need a quick refresher on digital signatures and hashes.

4. Issuer: This tells us who issued the certificate. Hubject GmbH is the operator (‘O’ = Organisation), based in Germany (‘C’ = Country), who issued this certificate. The CN (Common Name) ‘MO Sub2 CA QA G1.2.1’ is the name of the certificate authority operated by Hubject that issued and digitally signed this contract certificate.

5. Validity: This certificate starts to be valid on November 30, 2025 at 10 am and expires exactly 2 years later.

6. Subject: This is the leaf certificate (lowest end of the chain of trust), representing the e-mobility account ID (EMAID) DEHUBCONTRACT1, which is the identifier of the MSP’s billing account – the contract number to which all charged energy will be billed.

7. Subject Public Key Info:

   1. Public Key Algorithm: This public key uses ECDSA and was created with the elliptic curve (‘ec’) NIST P-256 (aka secp256r1 or prime256v1, as mentioned in the previous article), which is the mandatory curve for ISO 15118-2.

   2. Public Key: The long hex blob represents the public key. It’s what the charger uses to verify signatures created by the EV with its matching private key, which the EV securely stored when the contract certificate was installed. Elliptic curve public keys are represented as 04 (indicates an uncompressed key) followed by X and Y coordinates of the point on the elliptic curve.

8. Extensions:

   1. Basic constraints (critical): ‘CA=False’ means that this certificate cannot act as a certificate authority (CA) and, therefore, not issue any child certificates (because it’s already a leaf certificate at the bottom end of the chain of trust). The critical flag means clients must process this extension, or reject the certificate.

   2. Subject Key Identifier (SKI): A hash-like identifier for the CA’s public key. Used to link certificate chains efficiently.

   3. Authority Key Identifier: Similar to an SKI

   4. Authority Info Access: This is where you can contact the OCSP (Online Certificate Status Protocol) responder to check the revocation status of this certificate. We’ll cover OCSP further down in this article.

   5. Key Usage (critical): Specifies what cryptographic operations the public key contained in the certificate is allowed to perform. This public key can verify digital signatures, prove the sender’s identity, and securely establish shared session keys.

9. Signature Value: This is the ECDSA signature over the certificate body.

In ISO 15118-2, each X.509 certificate is capped at 800 bytes, with its exact contents defined by what’s known as a certificate profile – basically a recipe for what goes inside. I won’t drag you down that rabbit hole just yet, but it’s worth knowing that this is how every (Plug & Charge) certificate gets its structure and purpose.

Step by step: the chain of trust from leaf to trust anchor

OK, now that we know more about the content of a digital certificate, we can make sense of how the “chain of trust” principle in a PKI actually works, meaning: how trust flows from a Root Certificate Authority (Root CA) down to an end-entity or “leaf” certificate through one or more intermediate (Sub CA = Subordinate Certificate Authority) certificates.

The diagram below captures the hierarchical flow. Let’s go through it step by step to make sure it really clicks.

1. Root CA Certificate (trust anchor)
   The Root CA is the highest authority in the hierarchy which every participant in this PKI ecosystem needs to trust. It self-signs its own certificate, meaning its issuer and subject are the same. Its public key is trusted implicitly (pre-installed in browsers, operating systems, or EVs and chargers). It uses its private key to sign subordinate (Sub CA) certificates.

2. Sub CA 1 Certificate (first intermediate CA)

   The Root CA uses its private key to sign the certificate of Sub CA 1. Sub CA 1’s certificate contains:

   • Its own name and public key (subject fields)

   • The Root CA’s name as the issuer

   • A digital signature created using the Root CA’s private key

   Anyone who has access to the Root CA’s certificate can verify this signature using that Root CA certificate’s public key, confirming that Sub CA 1 was legitimately issued by the Root CA.

3. Sub CA 2 Certificate (second intermediate CA – optional)

   Where a PKI uses more than one Sub CA: The Sub CA 1 now acts as an issuer for Sub CA 2. Sub CA 1 uses its private key to sign Sub CA 2’s certificate. Verification of Sub CA 2’s certificate uses Sub CA 1’s public key. This adds another layer in the trust chain but still maintains verifiable continuity back to the Root CA.

4. Leaf (end entity) Certificate (the final link)

   Sub CA 2 uses its private key to sign the Leaf Certificate, which includes its own public key and identifies the end entity. In the world of Plug & Charge, this belongs to and identifies a vehicle, charger, or mobility service provider. Verification of the leaf certificate is performed using Sub CA 2’s public key.

5. Chain of trust verification

   When, for example, an EV receives the leaf certificate alongside the corresponding Sub CA certificates of a charging station during a TLS handshake:

   1. It verifies the leaf’s signature using Sub CA 2’s public key.

   2. It then verifies Sub CA 2’s signature using Sub CA 1’s public key.

   3. Finally, it verifies Sub CA 1’s signature using the (already pre-installed) Root CA’s public key.

   4. Because the Root CA is trusted a priori, the entire chain is trusted, thereby verifying the authenticity of the charging station it’s connected to.

Trust flows downward: the Root CA grants trust to Sub CAs by signing them.
Verification flows upward: the client (e.g. EV or charging station) verifies each certificate’s signature using the public key of the issuer above it, until it reaches the trusted Root CA (the “trust anchor”).

Remember: this is standard PKI practice, not specific to ISO 15118. You can check this out yourself: just click the little icon next to the website address in your browser’s address bar to open the certificate viewer.

In Chrome, a popup appears. Click “Connection is secure”, then “Certificate is valid”. You’ll see two tabs:

• General, which summarises this website’s certificate

• Details, which reveals the full certificate hierarchy

In this case, GTS Root R4 is the Root CA, WE1 is the Sub CA, and currentaffairs.io is the leaf certificate.

If you expand the fields, you’ll notice they use elliptic curve cryptography (ECDSA) for digital signatures and SHA-256 as the hashing algorithm – the same modern cryptographic standards used in Plug & Charge.

Why we are using Sub CAs in a PKI

In a PKI, subordinate certificate authorities (Sub CAs) act as a buffer between the all-powerful Root CA and the everyday certificates used in the field. The Root CA’s private key is the ultimate trust anchor. If it were ever compromised, the entire ecosystem could collapse. That’s why it’s kept offline and used only rarely to sign Sub CA certificates. These Sub CAs then handle the operational work of issuing certificates for vehicles, charging stations, or mobility service providers (MSPs). This setup lets the Root CA remain untouched and protected, while any compromised Sub CA can simply be revoked without bringing the whole system down.

In ISO 15118 Plug & Charge, this hierarchy is taken one step further. The Root CA (the V2G Root CA) signs a first-level Sub CA, often operated by a global trust provider like Hubject or Irdeto, which then signs second-level Sub CAs for regional or organisational entities – say, a national MSP, a car manufacturer, or a charge point operator. This two-tier model balances security, governance, and scalability: it allows the ecosystem to expand internationally while maintaining clear lines of control and trust. Think of it as a carefully pruned tree: the Root stays safe underground, while each branch (Sub CA) can grow, operate, or, if necessary, be cut off without harming the entire organism.

The ISO 15118 PKI ecosystem

Alright, if that all made sense so far, then you’re ready for an overview of the ISO 15118-specific public key infrastructure.

The illustration below summarises the Plug & Charge PKI specifically defined in ISO 15118-2, showing how trust and certificate management work across all market roles. We’ll also briefly cover the difference to an ISO 15118-20 PKI, but let’s first unpack this one step by step in plain language.

The common root of trust

At the center is the V2G Root CA Certificate. This is the trust anchor for the entire Plug & Charge ecosystem. Every other certificate – whether for a CPO, CPS, MSP, or OEM – is ultimately signed (directly or indirectly via intermediate Sub CAs) by this Root CA.

The charge point operator (CPO) and certificate provisioning service (CPS) are required to use the V2G Root CA as their trust anchor when issuing their Sub CA 1 certificates.

In contrast, car manufacturers (OEMs) and mobility service providers (MSPs) have the flexibility to either rely on the common V2G Root CA or operate their own root CA to issue and sign their Sub CA certificates, depending on their security, compliance, and operational needs.

Running your own root CA is costly and complex. It requires secure infrastructure, dedicated experts, strict procedures, and carries high risk if mismanaged – which is why most MSPs prefer to rely on the shared V2G Root CA instead.

Car manufacturers, on the other hand, often operate their own root CA to maintain full control over vehicle identities, meet strict security and compliance requirements, and protect their brand and customers from external trust dependencies.

A walk through the role-specific PKIs and leaf certificates

Each major market actor has its own PKI branch, with one or more Sub CAs under the Root CA.

Charge Point Operator (CPO)

The CPO manages chargers and issues an SECC certificate for each charging station. SECC stands for Supply Equipment Communication Controller and is ISO 15118 speak for the communication device that sits inside the charger and manages the secure, digital communication with the EV.

The charger sends the SECC certificate alongside the Sub CA certificates to the EV during a TLS handshake to identify itself and establish a trusted and confidential communication channel. The EV verifies the authenticity of the CPO Sub CAs using the V2G Root CA certificate that was pre-installed – either during manufacturing or before vehicle delivery to the customer – ensuring that the charging network it connects to is legitimate and trusted.

Certificate Provisioning Service (CPS)

When ISO 15118-2 was published in 2014, the authors couldn’t predict how many MSPs would choose to operate their own Root CAs instead of relying on the shared V2G Root CA. If every EV had to store and manage the Root CA certificates of potentially dozens or even hundreds of MSPs, memory and update management would quickly become impractical – especially given the high cost and strict optimisation requirements in automotive electronics.

To solve this, the Certificate Provisioning Service was introduced as a trusted intermediary, always operating under the V2G Root CA (originally expected to exist in only a handful instances worldwide). The CPS verifies a contract certificate issued by an MSP, re-signs it with its own private key, and stores it in a data pool called Contract Certificate Pool (more on that in next week’s article) from where it can be sent to the EV – establishing transitive trust: if the EV trusts the CPS (via the pre-installed V2G Root CA) and the CPS trusts the MSP, then the EV can safely trust the MSP’s contract certificate without needing to store every MSP’s Root CA.

Thanks to the CPS’s digital signature, the EV can verify that the contract certificate and its encrypted private key are authentic. This is done using the CPS Leaf Certificate, which – together with the CPS Sub CA certificates – is included in the signed contract certificate bundle the EV receives to install the contract certificate and the associated private key securely. That private key can only be decrypted by the EV itself, using the Elliptic Curve Diffie-Hellman (ECDH) key agreement protocol – which we briefly discussed in the previous article – and the OEM Provisioning Certificate’s public key.

Once installed, the EV presents its contract certificate during a Plug & Charge session to the charger and uses the corresponding private key to generate digital signatures.
The charger verifies these signatures using the public key contained in the contract certificate, confirming the EV’s authenticity and authorisation for charging.

Mobility Service Provider (MSP)

The MSP provides the EV’s billing contract and issues the Contract Certificate tied to that contract. As mentioned before, it uses the service of the CPS to help the EV verify the authenticity of the contract certificate and to eventually store what is called a signed contract certificate bundle to a data pool called Contract Certificate Pool. That data pool is managed by the PKI ecosystem provider, such as Hubject, Irdeto or Gireve. A car manufacturer subscribes to this data pool to get notified of newly created contract certificates that were provisioned specifically for one of their EVs.

Vehicle Manufacturer (OEM)

In ISO 15118 terminology, the vehicle manufacturer is referred to as the OEM.
The OEM issues an OEM Provisioning Certificate for every Plug & Charge-capable vehicle, serving as the identity of the EV.

Each EV has at least one such certificate, while vehicles that support multi-contract handling – allowing multiple contract certificates from various MSPs to be stored – may have a corresponding number of provisioning certificates to manage those separate contracts securely.

This OEM provisioning certificate allows the vehicle to securely request and install (i.e. provision) a new contract certificate from the Contract Certificate Pool – either via the OEM’s secure over-the-air (OTA) update link, or via a charging station. Although ISO 15118 offers a dedicated mechanism to install these contract certificates, it appears that car manufacturers prefer their own OTA communication link to safely store them in their EVs.

Private Environment

A private environment refers to a physically controlled charging setting, such as a private fleet depot or a restricted-access car park.

This concept was introduced to offer a simpler, more cost-effective Plug & Charge setup for non-public charging scenarios. I won’t dive deeper into it here, as it’s unclear whether this concept has ever been implemented in practice. However, if your company has, please reach out. I’d be glad to update this article and explore how it works in reality, along with its advantages and drawbacks.

If that sounded like a mouthful, I feel you. But don’t worry – in the upcoming finale of this Plug & Charge series, we’ll break it all down step by step: how a contract certificate actually finds its way into your EV, and how a full Plug & Charge session unfolds from start to finish. I’ll also include a clear, visual walkthrough that ties everything together and makes the whole process click.

Checking a certificate’s revocation status with OCSP

You probably have noticed the OCSP Responder certificates on the left in the illustration above and asked yourself: what’s that?

Let me explain.

OCSP, short for Online Certificate Status Protocol, is a way for systems to check in real time whether a digital certificate is still trustworthy (i.e. has not been revoked). For example, a certificate might be revoked if its private key was compromised, the organisation’s details or ownership changed, or the device was retired.

In the past, the old method was to download long Certificate Revocation Lists (CRLs), files published by the CA that contained every certificate that had been revoked. OCSP made this process much faster: instead of downloading and parsing an entire list, a device simply asks the CA’s OCSP responder about one specific certificate and gets a quick “good,” “revoked,” or “unknown” reply.

To make this possible, the certificate authority issues a dedicated OCSP responder certificate to a server that’s authorised to sign these status responses on the CA’s behalf. This allows the responder to prove that its answers are genuine without exposing the CA’s private key.

By checking both validity dates and OCSP revocation status, systems like Plug & Charge ensure they only trust certificates that are both current and still approved by the CA.

Note that OCSP responder certificates are used by all entities in the Plug & Charge ecosystem – including CPS, MSPs, and OEMs – but are shown only once in the diagram for simplicity and clarity.

Additional certificates in ISO 15118-20

ISO 15118-20 brings several notable cybersecurity enhancements, which we briefly covered in the previous article. For now, let’s focus on the changes affecting the digital certificates.

Additional Vehicle Certificates for mutual TLS

You’ll notice an additional blue strain in the vehicle manufacturer PKI hierarchy. Those additional Vehicle Certificates were introduced to enable mutual TLS authentication, meaning that authentication now happens in both directions – the EV must also prove its identity to the charger, not just the other way around.

OCSP responder certificates for leaf certificates

It always seemed like an odd design choice that ISO 15118-2 used OCSP responder certificates only for Sub CAs, not for the leaf certificates such as SECC or contract certificates. The rationale was that some leaf certificates are typically short-lived – e.g. SECC certificates are valid for just a few months – making the overhead of maintaining and querying OCSP responders less justified.

Still, to close this potential revocation blind spot, ISO 15118-20 now includes OCSP responder certificates at all levels, ensuring that even short-lived leaf certificates can have their revocation status checked if needed.

Note that OCSP responder certificates are used by all entities in the Plug & Charge ecosystem in ISO 15118-2 and -20 – including CPS, MSPs, and OEMs – but are shown only once in the diagram for simplicity and clarity.

Cross-certification and Certificate Trust Lists (CTLs)

In ISO 15118-20, cross-certificates were introduced to bridge trust between separate PKI hierarchies – for example, when two different V2G Root CAs need to recognise each other. When one V2G Root CA cross-signs another’s public key, an EV that only trusts e.g. a V2G Root CA from Hubject can still authenticate a charger whose certificate chain originates from Irdeto’s V2G Root CA.

As a result, the updated standard permits certificate chains of up to four certificates instead of three: the leaf certificate, two Sub CAs, and additionally one optional cross-certificate.

Wait, but what about the Root CA certificate? Isn’t that part of the certificate chain?

Ahh, now that’s important to remember: a Root CA certificate is never sent as part of a certificate chain, because Root CAs are trust anchors that need to be pre-installed on the verifying device – such as an EV or charger – to enable the verification of the received certificate chain (leaf → Sub CA 2 → Sub CA 1).

However, this cross-certification setup adds significant complexity to trust validation and certificate management, which is why the industry is moving instead toward Certificate Trust Lists (CTLs) – a simpler way to publish trusted Root CAs. The EU’s Sustainable Transport Forum (STF) is currently defining a PKI interoperability governance directive, which we’ll probably touch on in next week’s article.

Certificate size increased

In ISO 15118-20, the maximum allowed X.509 certificate size increased to 1,600 bytes (previously 800 bytes in ISO 15118-2). This change was introduced to accommodate the richer data (e.g. more detailed subject/issuer fields) and modern cryptographic algorithms required (e.g. stronger elliptic curves such as secp521r1 or Ed448).

This becomes an important consideration when determining how much memory your EV or charger should include before it goes to market.

And that’s a wrap for today. Or, as Master Yoda would say: “A PKI mastered, you have.”

You’re now armed with the essentials to understand how a Plug & Charge session unfolds – from signing that EV electricity contract all the way to plugging in and watching the electrons flow.

Next week, we’ll peek into the ISO 15118-20 PKI (spoiler alert: it adds a few extra certificates) and unpack the storage requirements for EVs and chargers to manage both PKIs – an important design decision you want to get right in order to support both ISO 15118-2 and -20. We’ll also trace the full journey of a contract certificate – from issuance to installation to authentication at the charger – and watch a Plug & Charge session in action, start to finish.

Stay tuned, it’s going to the be finale of the Plug & Charge article series for now – before I take you onto the next journey: smart charging and vehicle-to-grid (V2G).

You may have heard these terms before, or even worked with some of them. But for most people, cryptography feels like a dense and abstract topic with little connection to daily life. So in this article, I’ll walk you through what actually happens under the hood and how ISO 15118 uses modern cryptography to make Plug & Charge both seamless and secure. If you happen to be a software engineer implementing this, or a test engineer trying to debug why a secure handshake keeps failing or Plug & Charge doesn’t work as expected, this will be especially useful.

My goal isn’t to turn you into a cryptographer, and I’ll spare you the level of depth I usually go into during my two-day advanced training sessions on this topic (part of CharIN’s Charging Communication with ISO 15118 program). Instead, I’ll explain just enough so you can see how Transport Layer Security (TLS), public and private keys, and digital certificates work together to prevent anyone from eavesdropping, tampering, or impersonating when data flows through the charging cable to control the flow of energy.

Let’s get started!

Subscribe now

Let’s start by quickly revisiting the three basic principles that allow the EV and charger to ‘talk’ to each other in a secure way: confidentiality, data integrity and authenticity.

1. Confidentiality: When your EV exchanges information with a charging station (or wall box) it needs to make sure that no unauthorised third party can listen in on the conversation.

2. Data Integrity: The data that the EV and charging station exchange must be secure, and any malicious third-party attempts to manipulate the conversation

   must be detected on both sides.

3. Authenticity: The EV must identify and be able to verify the charger to which it is physically connected as a trustworthy charger, and vice versa.

Data encryption ensures confidentiality, digital signatures and certificates are the tools to ensure data integrity and to verify the authenticity of the communicating counterpart. Managing these digital certificates securely requires an entire system of roles, policies, and procedures for issuing, validating, and revoking certificates. This system is known as a public key infrastructure, or PKI, which will be the focus of next week’s article.

So, let’s unpack this from the ground up.

Encrypting the conversation with TLS

The moment your ISO 15118-enabled EV and charger connect through the charging cable, they establish a communication link using the Transmission Control Protocol (TCP), the same reliable transport layer that keeps most of the internet running. TCP makes sure every message between the EV and the charger arrives intact, in the right order, and without loss, even if the physical connection isn’t perfect. It’s what guarantees that no data packets go missing or get scrambled while travelling through the cable. That’s important because ISO 15118 describes a strict sequence of messages to orchestrate a successful charging session. If one message is sent out of order or is not received in time, the session immediately terminates.

Once that reliable foundation is in place, Transport Layer Security (TLS) steps in to secure the conversation itself. While TCP ensures that the data arrives, TLS ensures that it arrives privately and unaltered. Before any sensitive information is exchanged – like authorisation data or charging schedules to influence the EV’s charging behaviour – the EV and the charger perform what’s called a TLS handshake: a rapid back-and-forth where they identify each other, agree on which cryptographic algorithms to use (the so-called cipher suite), and generate a shared secret key which then becomes the basis for the encryption key that will be used to encrypt everything that follows.

From that moment on, every message is wrapped in a layer of encryption that only the EV and charger can understand, creating the foundation for a secure Plug & Charge session.

Let’s decipher a TLS cipher suite

During that TLS handshake, the EV and charging station tell each other which set of cryptographic algorithms they support to enable confidentiality, data integrity, and authenticity. Together, these algorithms form what’s called a cipher suite. It’s essentially a recipe for secure communication, made up of four main components.

We’ll first look at the cryptographic algorithms used in ISO 15118-2, released back in 2014, and then briefly compare how they’ve evolved in ISO 15118-20, published in 2022. The shift reflects the industry’s natural move toward higher security and efficiency as both computing power and the sophistication of potential cyber attacks increase.

1. Key exchange algorithm: The big question is: how can the EV and the charger agree on a shared secret key (based off which the communication shall be encrypted) without anyone listening in, copying that key, and decrypting all their messages? That’s exactly what the Diffie–Hellman key agreement solves: it lets both sides start with their own private number (or digital private key), exchange only a derived public key, and then combine those keys in such a way that both end up with the same secret key, while an eavesdropper watching the exchange can’t reverse the math to uncover it.
   In practice, ISO 15118 doesn’t use the original Diffie–Hellman method but a more efficient and modern variant called Elliptic Curve Diffie–Hellman (ECDH). It works on the same principle, but instead of using large prime numbers, it relies on the elegant mathematics of elliptic curves, a topic we’ll revisit further down to show why it’s especially well-suited for embedded systems like EVs and chargers.

2. Authentication algorithm: The authentication algorithm ensures that both parties (the EV and the charger) can prove who they really are before exchanging any sensitive data. It prevents someone from impersonating a trusted device in the communication chain. In ISO 15118, this is done using the Elliptic Curve Digital Signature Algorithm (ECDSA), which allows each side to sign messages with its private key and verify them with the corresponding public key (embedded in a digital certificate), confirming authenticity without ever revealing the private key itself. I’ll walk you through a practical example of a digital signature in a minute.

3. Bulk encryption algorithm: Once the secure session is established, the bulk encryption algorithm takes over to keep the actual data exchange between the EV and the charger private. In ISO 15118-2, this is handled by AES-128-CBC (Advanced Encryption Standard, 128-bit, Cipher Block Chaining). The 128 indicates the length of the encryption key – long enough to make brute-force attacks practically impossible – while CBC describes how each block of data depends on the one before it, ensuring that even identical message blocks produce completely different encrypted outputs.

4. Message authentication algorithm: It makes sure that the EV and the charger can detect whether the data exchanged has been altered on its way – be it by accident or by someone trying to interfere. It works by creating a short, unique fingerprint of each message, called a message digest or hash, which the recipient can recalculate and compare to verify integrity. In ISO 15118-2, this is handled by SHA-256 (Secure Hash Algorithm, 256-bit), meaning each message is represented by a 256-bit hash value that changes completely even if a single bit of the original data is modified, making undetected tampering virtually impossible. Try it out yourself with this online hash generator. Hashes are used in digital signatures, I’ll explain this more further down in the article.

Why we need elliptic curve cryptography

For those electronic control units (little microchips and memory chips) embedded in EVs and charging stations, memory footprint and performance matter as much as security. That’s why ISO 15118 relies on elliptic curve cryptography (ECC), a modern variant of public key cryptography – which we’ll touch upon in a minute – that achieves top-tier security with much smaller keys and less computation as compared to e.g. the large prime numbers traditionally used in RSA.

ISO 15118-2 demands the use of a specific elliptic curve called secp256r1 (aka prime256v1) for the following well-established ECC algorithms:

• Elliptic Curve Diffie-Hellman (ECDH) key agreement protocol to generate the symmetric TLS session key during the TLS handshake

• Elliptic Curve Digital Signature Algorithm (ECDSA) to generate digital signatures with the private key and verify digital signatures with the corresponding public key

Visual example of a TLS cipher suite in ISO 15118-2

In ISO 15118-2, there are only two cipher suites to choose from:

• TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256

• TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256

At first sight, they look almost identical. However, only the latter one facilitates Perfect Forward Secrecy (PFS), which is a desired characteristic in secure communications.

The ‘E’ in ECDHE stands for Ephemeral, meaning short-lived or temporary. It forces the EV and the charging station to create a new, unique private–public key pair for every charging session, and discard it once the TLS session ends. This way, even if an attacker somehow obtained the TLS session key used in a previous charging session, they couldn’t use it to decrypt any past or future communication. Each session has its own one-time key, ensuring that every conversation between car and charger stays secure on its own. That’s the essence of Perfect Forward Secrecy.

The cipher suite with ‘ECDH’ should have never made it into the ISO 15118-2 standard and is, hopefully and for good cyber security practice’s sake, not implemented in any EV or charging station these days1, even if the perceived risk may be low.

To summarise, each ISO 15118-2 communication session should only use the following cipher suite, which specifies the particular key agreement algorithm, signature and hashing algorithm, and encryption algorithm to use:

Increasing cybersecurity resilience in ISO 15118-20

ISO 15118-20 proposes a new set of cipher suites to enhance data security and be more resilient against cyberattacks. Whether these algorithms will stand the test when quantum computers become more widely available is still to be seen. But then again, commercially available quantum computers (not just prototypes) are likely still at least 10 years away.

The new cipher suites for ISO 15118-20, which demands the use of TLS 1.3, are:

• TLS_AES_256_GCM_SHA384: Uses the same AES algorithm but with a 256-bit key for strong encryption, combined with GCM mode (Galois/Counter Mode) for speed and built-in integrity checks, and SHA-384 for hashing.

• TLS_CHACHA20_POLY1305_SHA256: Offers a modern, lightweight alternative optimised for devices with limited hardware acceleration, using the ChaCha20 stream cipher for encryption, Poly1305 for message authentication, and SHA-256 for hashing.

In TLS 1.3, the handshake is quicker because the key exchange algorithm (ECDHE) is known from the start. That’s why it no longer appears in the beginning of the cipher suite name.

Beyond the updated cipher suites, ISO 15118-20 brings several notable cybersecurity enhancements, such as

• a new default elliptic curve called secp512r1 (doubling the size of private and public keys),

• a backup elliptic curve called Curve448 (for when the default curve gets hacked sometime in the future),

• additional vehicle certificates to enable mutual TLS authentication, meaning that authentication now happens in both directions – the EV must also prove its identity to the charger, not just the other way around, and

• a strong recommendation to use Trusted Platform Module (TPM 2.0) for storing private keys and certificates securely on tamper-resistant hardware.

Interoperability between ISO 15118-2 and -20 isn’t always straightforward. One common stumbling block is the EV and charger not supporting the same TLS version (TLS 1.2 vs TLS 1.3). If they don’t handle this gracefully, their attempt to “speak securely” can fail. When that happens, both sides may simply give up on Plug & Charge altogether and fall back to regular methods like an RFID card, an app, or a payment terminal. This is probably worth exploring further in a separate article. If that’s of interest to you, then let me know in the comments or drop me a message.

How do you secure the encryption key?

We’ve covered quite a bit about digital signatures, certificates (specifically in last week’s article), and the use of private and public keys, along with asymmetric (ECDHE, ECDSA) and symmetric (AES) cryptographic algorithms.

To keep things clear, let’s step back for a moment and untangle these terms so you can see the bigger picture and understand why we need both symmetric and asymmetric encryption in the first place.

Symmetric algorithms like the above mentioned block cipher AES use the same key – in our example: the TLS session key – to both encrypt and decrypt data (hence the term symmetric), making them fast and efficient for protecting large amounts of information once a secure connection is established.

But what if someone was tapping the communication channel (say, the charging cable between the EV and a hacked charging station) remotely during the TLS handshake? Wouldn’t that person then be able to intercept the symmetric TLS session key? If that’s the case, then the eavesdropper would be able to listen in on the communication, and the whole purpose of TLS would be rendered useless.

The eavesdropper could manipulate the communication by modifying the intercepted data for some malicious purpose like manipulating charging schedules (to induce a blackout) or authentication data (to charge on behalf of someone else’s account). How would the EV or charger know if they’re actually talking to a trustworthy party and not falling prey to this kind of man-in-the-middle attack?

That’s where public key cryptography, also known as asymmetric cryptography, comes to the rescue.

It’s called asymmetric cryptography because it uses two mathematically linked but distinct keys – a private key kept secret and a public key shared openly – which perform opposite functions, such as encrypting and decrypting or signing and verifying messages.

The private key must be kept secret at all times, otherwise the key pair is considered to be compromised. It’s a versatile tool that can be used for various cryptographic applications. In ISO 15118, we use asymmetric cryptography only for agreeing on the shared secret key needed for a TLS session key and for digital signatures.

1. Key Agreement: Back in 1974, two distinguished mathematicians, Whitfeld Diffie and Martin Hellman, invented the Diffie-Hellman key agreement protocol that uses public key cryptography. In this protocol, two parties can agree on a shared secret key without ever transmitting that secret key directly. Instead, they create a temporary private-public key pair, exchange their corresponding public keys, and use a mathematical function to generate the same shared secret key on both sides. This provides a secure way to establish a shared secret key that can be used for encryption and decryption of the following message flow.

2. Digital Signatures: A digital signature is a way to ensure the authenticity and integrity of a message. To create a digital signature, the EV, for example, uses the SHA-256 hash function to calculate a hash value (also known as the ‘message digest’) and encrypts the hash value with its private key. That encrypted hash value is then attached to the actual message it sends to the charger.

   The charger can then verify the signature using the EV’s corresponding public key, which is embedded in a digital certificate to which the charger has access. To verify the message, the charging station basically follows these three steps:

   1. Decrypt the encrypted hash value that the EV attached to its message, using the public key that matches the EV’s private key

   2. Calculate the hash value of the received message

   3. Compare the received (and decrypted) hash value with the calculated one.

   If the hash values match, the signature is valid. This means that the charger can be sure that the message has not been tampered with by an unauthorised third party and that it was indeed sent by the EV, who is the only one in possession of that private key that fits to the public key to which the charger has access.

   
   The same principle applies vice versa, of course, when the charger sends a digitally signed message to the EV.

How to create and verify digital signatures

Digital signatures, specifically the XML-based ones used in ISO 151182, can make your head spin and be a bit tricky to understand when you read about them the first time. Let me help you visualise the concept first with the diagram below, and then I’ll guide you through each step one by one.

In this example, we’re assuming that the EV is about to send a digitally signed AuthorizationReq (Req for Request) message to the charging station. This is one of the seven messages in ISO 15118 that need to be digitally signed. Here, the private key is the one that’s mathematically linked to the public key in the contract certificate. The EV has already shared that certificate – not the private key – with the charging station in a previous message called PaymentDetailsReq3:

1. EXI-encoding and hashing: The message body of an ISO 15118 message is converted into a compact, binary data stream using an EXI codec (see footnote 2 for a brief explanation on Efficient XML Interchange, or EXI). We need this binary representation as input for the SHA-256 hash function, which creates a 256 bit message digest. In the image above, those 256 bits are represented in 64 hexadecimal characters (1 hex character = 4 bits; 64 x 4 bits = 256 bits).

2. Store message digest in header: The resulting hash value is then stored in the DigestValue element of the message header’s Signature. This Signature contains the two fields SignedInfo and SignatureValue. The SignedInfo element includes several data fields, but for our purposes here, the key one to focus on is DigestValue.

3. EXI encode SignedInfo: The SignedInfo data field (which contains the message digest, or hash) is then also EXI encoded.

4. Hash EXI-encoded SignedInfo: The binary, EXI-encoded SignedInfo is then also hashed using SHA-256, producing yet another hash value that represents the SignedInfo data field.

5. Encrypt hashed and EXI-encoded SignedInfo: Using its private key, the EV will encrypt the hash value of the EXI-encoded SignedInfo data field. This, my friend, is finally the digital signature.
   
   Important note: Step 4 and 5 are both part of the Elliptic Curve Digital Signature Algorithm (ECDSA). DO NOT hash the SignedInfo data field before you apply ECDSA, as this would result in a double hashing operation and failed signature verification on the other side. I ran into this issue when I first implemented digital signatures in ISO 15118 many years ago. Took me a while until I understood why.

6. Store digital signature in message header: The final step of creating the digital signature is to actually place this value into the SignatureValue field of the message header’s Signature.

7. EXI encode signed ISO 15118 message: Now, before the EV sends the message across the wire to the charging station, the message needs to be transformed into a compact, digital data stream using the EXI codec once again.

8. Encrypt ISO 15118 message: The final step is to encrypt the now EXI-encoded and digitally signed AuthorizationReq message with the symmetric block cipher AES-128-CBC, using the 128-bit TLS session key that the EV and charger agreed on during the TLS handshake (remember Elliptic Curve Diffie-Hellman?).

OK, so what does the charging station now do once it receives this message?

As the saying goes, images speak more than 1000 words. So let’s first summarise the actions visually before I walk you through each step.

Verifying a digital signature is actually a two-step process:

• Part 1: Verify the digest value(s) of the message body (elements)4

• Part 2: Verify the signature value

Let’s go through the steps of Part 1 first:

1. Decrypt EXI-encoded message: Upon receiving the AuthorizationReq via the charging cable, the charging station will first try to decrypt the message using the same, symmetric 128-bit TLS session key which the EV used for encryption.

2. EXI decode the message: To be able to read the message header and body, the charger needs to use the EXI codec for decoding the AuthorizationReq.

3. EXI encode and hash message body: Then the charger does the same what the EV did previously: EXI encode and hash the message body. This is a step towards checking whether the message has been altered on its way to the charger.

4. Check if digest values match: The result from step 3 represents the message digest of the AuthorizationReq. If that message digest is the same as the one stored in the message header’s DigestValue field, then that’s already a good sign. But we’re not done yet. The charger still needs to check the authenticity of the received digest value (which we discuss in Part 2 below).

We’re almost there. The final steps of verifying a digital signature in ISO 15118 are:

5. EXI encode Signed Info: In order to verify the digital signature value, the charger needs to basically go through the same calculation steps as the EV did. Meaning: EXI encoding the SignedInfo element first before …

6. Hash EXI-encoded Signed Info: … hashing the resulting binary data stream, resulting in (hopefully) the same value the EV calculated before it sent the message across.

7. Decrypt Signature Value: Now the charging station needs to use the public key that is linked to the contract certificate’s private key in order to decrypt the data field SignatureValue, which is stored in the AuthorizationReq’s message header. Remember that the charger received the contract certificate (including the public key) from the EV in the previous PaymentDetailsReq message.

8. Check if values match: The finale: if the decrypted SignatureValue matches the calculated (EXI-encoded and hashed) SignedInfo value, then the message is definitely authentic and can be trusted.

That was a lot to digest, I know.

But it’s the only way to truly understand how XML-based digital signatures work in ISO 15118. The good news? You’ve just worked through one of the toughest parts of Plug & Charge. If it all clicked – congratulations, that’s a real achievement. And if it didn’t fully land yet, grab a coffee, take a breather, and give it another read. It’ll make sense the second time around.

Symmetric vs asymmetric – the big picture

To summarise: asymmetric cryptography is ideal for the initial trust-building and key exchange (where confidentiality is critical but speed matters less), while symmetric cryptography takes over once the secure session is set up, efficiently encrypting and decrypting all the data that follows. Asymmetric ciphers require long key lengths compared to symmetric ciphers, which is computationally more expensive and requires a higher memory footprint. That’s the reason why symmetric ciphers (like AES) are used for encrypting the actual communication.

Below is a visual summary that captures the essence of what we discussed regarding symmetric and asymmetric ciphers.

Note that the shared secret key isn’t used directly as the symmetric TLS session key for encrypting and decrypting messages. Instead, there’s an intermediate step called a Key Derivation Function (KDF), which transforms the shared secret into a properly sized TLS session key. One reason for this is that ISO 15118-2 mandates the use of the elliptic curve secp256r1 (also known as prime256v1), which was considered state-of-the-art when the standard was published in 2014. This curve produces a 256-bit shared secret, while the symmetric cipher used in ISO 15118-2 – AES-128-CBC – operates on 128-bit keys. The KDF bridges this mismatch by deriving a 128-bit session key from the 256-bit shared secret.

ISO 15118-20 works in much the same way, but it uses larger key sizes and introduces additional signature algorithms in its cipher suites, as mentioned above.

Is your hardware ready for Plug & Charge?

Understanding the interplay of the various symmetric and asymmetric ciphers is essential to a) implement and b) debug Plug & Charge sessions in your test lab or later in the field when you introduced your (battle-tested) solutions to the market.

These days, we don’t need to reinvent the wheel when it comes to the various ciphers at play. OpenSSL is a mature, widely used open-source cryptographic library that already implements all the major symmetric and asymmetric algorithms needed – from AES and SHA-256 to ECDHE and ECDSA. It’s a solid foundation for handling TLS, digital signatures, and key exchange without having to build these components from scratch. However, it’s important to verify which OpenSSL version your system is using, as older releases may not yet support all the cipher suites required by ISO 15118-2 and especially ISO 15118-20 – which will become mandatory under AFIR in Europe by January 2027.

Also, keep in mind that there are mature, ready-to-use implementations that are battle-tested, certified, and have survived countless interoperability events. From open-source projects like Pionix’s EVerest to closed-source platforms such as EcoG OS (which, for those who remember, incorporates Switch’s former Josev stack) and Vector Informatik’s vSECClib for charging stations.

Also, make sure that you are sourcing the right crypto chips and hardware security modules (HSM). Ask yourself:

• Are they compliant with the Trusted Platform Module (TPM 2.0) reference design?

• Do they support TLS 1.2 and TLS 1.3?

• Do they support all cipher suites required for ISO 15118-2 and -20?

• What are the lead delivery times for those crypto chips?

• What do you want to build in-house and what do you source from third-party vendors? (which can also have an effect on lead delivery times)

I’m by no means an expert in sourcing crypto chips, but I do know that companies like STMicroelectronics – and, I believe, Intel as well – offer hardware that meets the necessary security requirements. Take the ST33KTPM2I, for example. Just a couple of weeks ago, I spoke with both a charger manufacturer and a supplier of communication controllers, who mentioned that this particular chip currently (as of mid-November 2025) has a lead time of around 40 weeks. That’s quite a lead time…

It may be a good idea to source complete communication controllers and modules from solutions providers like Chargebyte, who already have these crypto chips integrated into their products.

If your company does provide the right kind of crypto chips, please do reach out to me by commenting on this article or sending me a message, and I’ll include your information in this section.

It’s a wrap!

Cryptography is one of those topics that can make even seasoned engineers’ heads spin. This was probably one of the more technical deep dives in this newsletter – so if you’ve made it this far, bravo. Seriously. That means you’ve either just wrapped your head around one of the toughest parts of Plug & Charge, or you’ve refreshed and deepened what you already knew.

I hope this breakdown helped make the moving parts of ISO 15118’s cryptography click — without drowning in jargon — and gave you a clearer sense of how all these algorithms work together under the hood.

If something didn’t quite click, feel free to let me know in the comments – or drop me a note via email or LinkedIn – so I can revise for more clarity. And if you did enjoy this one, I won’t say no to a bit of positive feedback either. 😉

Next week, we’ll build on this foundation and explore digital certificates and the public key infrastructure (PKI) that underpins Plug & Charge – from leaf certificates all the way up to the root trust anchors. We’ll also look at what CPOs, EV and charger manufacturers need to know about managing and updating their certificates.

See you next week.

Any sufficiently advanced technology is indistinguishable from magic

declared Arthur C. Clarke, the renowned co-author of “2001: A Space Odyssey.”

That sentiment applies to much of modern technology, but it hasn’t fully reached the world of EV charging – at least not for everyone. There is, however, one group of drivers who’ve been living that “it just works” experience for years: Tesla owners.

Tesla operates a closed ecosystem with complete control over the hardware and software of their EVs and chargers, delivering a seamless and convenient charging experience to their users.

What if there was a way to expand this seamless experience to all EV manufacturers and charger manufacturers, regardless of brand or geographic location? This is where Plug & Charge, or PnC, enters the stage, an innovative and advanced technology that wholeheartedly embraces the notion of “magic”.

A helpful way to think about Plug & Charge is to compare it to Apple Pay. With Apple Pay, your device already holds a secure credential, so payment happens automatically when you tap. Plug & Charge works the same way for EV charging: the vehicle carries a secure contract certificate that represents your charging contract, so when you plug in, authentication and billing happen automatically in the background. No RFID cards, no apps, no payment screens – just plug in and charging starts.

And it enables true machine-to-machine automation that is not only convenient, but also more reliable than RFID readers or card terminals, and it’s highly secure by design. The outcome is a noticeably smoother and more reliable charging experience. And, for operators embracing this technology, better driver loyalty and retention.

In fact, it can be more convenient than filling up a petrol car. There’s no kiosk to walk to, no payment terminal to deal with. The authorisation is already done for you as soon as you plug your EV into the charger. And in many cases, it’s also cheaper than paying with a credit or debit card.

Doesn’t that sound like the charging experience we’ve all been waiting for?

Let me walk you through the tech behind it, where Plug & Charge is being rolled out around the world, and which network operators and car manufacturers already support it (spoiler: it’s probably more than you think).

In this article, we’ll break down how Plug & Charge actually works: the trust model behind it, the roles each player in the ecosystem performs, where it’s being deployed today, and how different markets affect adoption.

Subscribe now

The trust model and roles behind Plug & Charge

The user-convenient Plug & Charge technology is based on the EV-to-charger communication standard ISO 15118.

The reason you don’t need RFID cards, apps, or payment terminals to start a charging session (although these are still supported in ISO 15118) is because the EV and charger can identify and trust each other automatically. They do this using digital certificates – essentially cryptographic ID cards that prove a device or service is who it claims to be.

By placing a digital certificate called the contract certificate inside the EV, we eliminate the need for manual authentication methods. The EV can now prove your identity and authorise charging and billing on your behalf, silently in the background, within a few seconds. The contract certificate links the vehicle to your energy billing account, which is provided by the mobility service provider (MSP) of your choice. Authentication (verifying identity) and authorisation (checking that you’re allowed to charge) both happen automatically – no apps, no cards, no friction.

To do Plug & Charge justice, we need more than a single article. There’s the cryptography behind it, the public key infrastructure (PKI) that keeps it secure, and the question of how certificates actually make their way into the EV, the charger, and the wider ecosystem. So we’ll take this step by step.

This would be a great time to tell me what part of Plug & Charge you’re particularly interested in. Leave a comment or send me an email, and I’ll make sure your questions will be answered.

This article focuses on the core idea: how Plug & Charge works in principle, where it stands in terms of market rollout, and who supports it today. In the following articles, we’ll go deeper, layer by layer, so you’ll come away with a full, 360-degree understanding of the ecosystem – and what it really takes to make Plug & Charge work reliably at scale.

CIA – The three pillars for seamless & secure EV charging

No, it’s not the CIA you may be thinking of. I’m referring to the acronym that represents three pillars of secure digital (machine-to-machine) communication. The basic principles that allow the EV and charger to ‘talk’ to each other in a secure way: confidentiality, data integrity and authenticity.

1. Confidentiality: When your EV exchanges information with a charging station (or wall box) it needs to make sure that no unauthorised third party can listen in on the conversation.

2. Data Integrity: The data that the EV and charging station exchange must be secure, and any malicious third-party attempts to manipulate the conversation

   must be detected on both sides.

3. Authenticity: The EV must identify and be able to verify the charger to which it is physically connected as a trustworthy charger, and vice versa.

The big value of Plug & Charge lies in the fact that businesses can offer their customers not only the most seamless, reliable, and convenient but also the most secure charging experience without compromising on data security.

A quick word on Autocharge

You may have heard of Autocharge, which is a mechanism that resembles the seamless experience of just plugging in, using simply the car’s MAC address as an identifier. A MAC address is a unique hardware identifier assigned to a network interface, and Autocharge relies on each EV exposing a stable, vehicle-unique MAC address so the charger can recognise and authorise it – but not all manufacturers enable this, which limits Autocharge compatibility. Autocharge also lacks a sufficient level of data security. I wouldn’t recommend it for public charging and tamper-proof billing, but it does have its place in e.g. fleet depots. It’s often used by charging networks as a stopgap solution until Plug & Charge has been thoroughly implemented, tested, and rolled out. I’ll dive deeper into Autocharge and how it compares to Plug & Charge in a future article.

OK, now you know what confidentiality, data integrity and authenticity means. But the question still remains: How do we facilitate this seamless, secure charging experience?

That’s where we enter the realm of cryptography – symmetric and asymmetric ciphers, digital signatures, and digital certificates. Data encryption ensures confidentiality, digital signatures and certificates are the tools to ensure data integrity and to verify the authenticity of the communicating counterpart. Managing these digital certificates securely requires not just technology, but an entire system of roles, policies, and procedures for issuing, validating, and revoking certificates. This system is known as a public key infrastructure, or PKI.

If that piqued your curiosity, you’ll enjoy next week’s article – we’ll dig into the underlying crypto principles and how a PKI actually works.

PKIs are nothing new. You’ve been relying on them for decades without even noticing – every time you browse the web, message someone on WhatsApp or Signal, or search on Google, the same cryptographic principles are at work. What’s unique in ISO 15118 isn’t the cryptography itself, but the way digital certificates are issued, managed, and trusted across all the players in the EV charging ecosystem.

While the structure of the Plug & Charge-specific PKI is defined in ISO 15118, its governing rules are set in the application rule VDE-AR-E 2801-100-1, which I co-authored and is titled “Handling of certificates for electric vehicles, charging infrastructure and backend systems within the framework of ISO 15118.”

The “Plug & Charge-magic” only works because several parties across the EV charging ecosystem trust each other – and that trust is established and verified using digital certificates. Each participant plays a distinct role in enabling that seamless experience.

The market roles behind the Plug & Charge ecosystem

The electric vehicle (EV) is the one initiating the process. When you plug in, the EV presents its contract certificate – essentially a cryptographic ID linked to your energy contract – to the charger. This certificate tells the charger which billing account to use, referred to as the e-mobility account identifier (EMAID). That EMAID itself contains a three-character sequence, called the provider ID, which identifies the mobility service provider who issued and digitally signed this contract certificate.

The EV manufacturer (OEM) installs two key certificate types during production: one or more V2G Root CA (CA = Certificate Authority) certificates and OEM provisioning certificates. The Root CA certificates allow the EV to recognise and trust authorised charging stations – much like your web browser comes with pre-installed root certificates that allow it to verify secure websites. The OEM provisioning certificate, in turn, is used to securely request and receive (i.e. provision) the contract certificate that links the vehicle to the driver’s (or vehicle owner’s) billing account.

The charging station presents its own digital identifier called SECC certificate during the Transport Layer Security (TLS) handshake, which is what establishes the confidentiality mentioned above. The EV verifies its validity by following the certificate chain: the SECC certificate is signed by a Sub-CA, and that Sub-CA certificate is sent along with it. The Sub-CA is, in turn, signed by the V2G Root CA. Because the EV already stores the V2G Root CA certificate, it can validate each signature in the chain and confirm that the charger belongs to the trusted Plug & Charge ecosystem.

How exactly this whole chain-of-trust mechanism works is something we’ll have to explore in one of my next articles when we dig a bit deeper into the cryptographic principles behind a PKI.

After secure communication is established, the EV sends its contract certificate, which the charging station then needs to validate before granting access to energy. Some parts of the verification can be performed directly on the charger (e.g. verifying the digital signature of the certificate and checking it’s expiry date), while others are passed to the backend – the charge point management system (CPMS).

That backend belongs to the charge point operator (CPO), who runs the charging network. The CPO’s platform contacts the mobility service provider (MSP) who issued the contract certificate to check whether or not the billing account is still active and valid before before energy can start flowing.

Quick sense check: remember how the CPO knows which MSP to contact?

If you’re still with me, you’ll recall the three-letter provider ID embedded in the EMAID, which in turn sits inside the contract certificate. That small identifier is what links the vehicle to your chosen mobility service provider. Several countries have established identifier registries for businesses where you can look up both operator IDs (for CPOs) and provider IDs (for MSPs). In the UK, for example, it’s the EV Roam registry, in Germany it’s the Energy Codes & Services GmbH.

OK, back to our market roles.

The CPO is also responsible for making sure the charger has up-to-date SECC certificates installed to establish the trusted, TLS-encrypted communication with the EV. There are actually a couple more certificates required on the charger, but let’s cover the cryptographic principles and concept behind a chain-of-trust PKI first before we go down this rabbit hole. Next week’s article will cover this in more depth.

The driver is ultimately authenticated by the mobility service provider (MSP)1, the company providing their charging contract. You may have noticed by now that there are no payment details transmitted between EV and charger, only identification details. The payment method (such as your bank account or credit card) is linked to the MSP’s energy contract, which you eventually sign up for once you choose an MSP of your liking.

The MSP issues the contract certificate in the first place and is ultimately the party that pays the CPO for the energy, based on a B2B (business-to-business) tariff negotiated between CPO and MSP. The MSP may bill the driver a different price for the same amount of energy, depending on the B2C (business-to-customer) plan or tariff it offers to the driver. The MSP uses a technical integration (see Open Plug & Charge Network Communication Protocol) with the car OEM to notify them of a newly created contract certificate so that the car OEM can install said certificate via an over-the-air update into the electric vehicle.

To make all of this secure and interoperable, we need a trusted anchor. That role is fulfilled by the V2G Root Certificate Authority (Root CA) – the highest level of trust in the Plug & Charge ecosystem. Many certificates the EV and charger use must ultimately trace back to this root authority to verify their validity in this chain of trust.

Finally, there are the organisations that manage the data pools and public key infrastructure (PKI) to issue, distribute, update, and revoke certificates. These are the behind-the-scenes trust-service operators that make sure each party receives the right certificate at the right time – and that compromised or outdated certificates are removed from circulation. Without them, Plug & Charge would simply not work.

Need a refresher on the various market roles in the EV charging world, and their responsibilities beyond Plug & Charge? Then this article is just what you need:

The state of play of Plug & Charge in 2025

As of November 2025, the technology is gaining traction across multiple markets, though adoption rates vary significantly by region and stakeholder type.

A great source of information is Hubject’s ecosystem overview, which shows an ever growing variety of companies that are either currently onboarding or have already launched products with live (and Hubject-certified) implementations.

You’ll find the providers organised by category: CPOs, backend platforms, MSPs, charger and vehicle manufacturers, and even test system providers.

Here are some examples of well-known EV charging networks (CPOs) supporting Plug & Charge across the globe:

• Europe: Allego, Aral Pulse, Atlante, Electra, IONITY, Mer, Shell Recharge, Smatrics, Vattenfall

• United Kingdom: IONITY, Shell Recharge

• United States: Chargepoint, Electrify America, IONNA

On the vehicle manufacturer side, you’ll find Audi, BMW, Cupra, Ford, Genesis, Hyundai, Kia, Lucid, Mercedes, MAN, Mini, Nissan, Polestar, Porsche, Renault, Vinfast, Volkswagen, Volvo and more.

If you’re looking for charger manufacturer who are up to the game, you might want to talk to ABB, Alpitronic, Autel, Defa, Delta, Ekoenergetyka, Enersys, Huawei, i-Charging, IOCharger, Kempower, Liteon, Mennekes, Power Electronics, StarCharge, Vestel, XCharge, or Zerova, to name just a few.

Some of the MSPs already embracing Plug & Charge are Deftpower, Digital Charging Solutions, Elli, Ford, Mobilize, Octopus Electroverse, Plugsurfing, Porsche, and Shell Recharge.

According to my sources at Hubject, more than 3.5 million EVs and about 30% of DC fast (150 kW+) chargers in Europe already support Plug & Charge.

And the list of CPOs, EV OEMs, charger manufacturers, and MSPs is growing by the day as more companies embrace this technology and understand the benefits it brings to their customers – and to their own business.

PKI operators on the rise

Hubject is currently the most widely adopted Plug & Charge PKI operator in the market, but it’s no longer alone. Irdeto and roaming platform Gireve are also building Plug & Charge PKI operator capabilities. In June 2025, the three companies announced a partnership enabling mutual platform access, so CPOs, MSPs, and even vehicle OEMs can choose any of the three to issue their certificates while still maintaining interoperability across the others.

In parallel, the Sustainable Transport Forum (STF) is working on an EU-wide governance framework to ensure that Plug & Charge remains interoperable across all market players, regardless of which PKI operator they use.

Car OEMs and MSPs: Ensuring a level playing field

A truly open Plug & Charge ecosystem depends on one key capability: every EV must be able to store and manage multiple contract certificates, so drivers can choose their preferred MSP just as easily as they choose an energy supplier or mobile network today. That means EVs must offer simple controls for installing, updating, removing, and prioritising these certificates, ideally directly via the in-car display or companion app. This gives the driver full autonomy and ensures that any EV can charge at any public charging station using any compatible service provider.

Several OEMs already support this approach. BMW and the Volkswagen Group have offered multi-contract Plug & Charge for years, and Porsche has adopted an open model in the Macan. Volvo and Polestar also allow drivers to install the contract certificate of their choice, even if the onboarding flow still varies in polish. Other OEMs are preparing to follow, refining their customer journeys before switching these capabilities on at scale.

The direction is clear: the market is moving toward open Plug & Charge by design. And with the Sustainable Transport Forum (STF) working on EU-level guidance to guarantee non-discriminatory access, we’re likely to see multi-contract support become an expected baseline. That’s reassuring for MSPs who have been concerned that OEM-controlled in-car interfaces could otherwise be used to steer customers toward proprietary charging services. The momentum – both regulatory and intrinsic – now points firmly toward a level playing field where drivers decide who they charge with, not the car.

Bolted-on vs built-in: Plug & Charge in OCPP 1.6 vs 2.0.1

If you browse Hubject’s ecosystem overview you’ll see a mix of OCPP 1.6 and OCPP 2.0.1 in the wild. That matters because only OCPP 2.0.1 natively supports ISO 15118 Plug & Charge. OCPP 1.6 implementations bolt it on via the DataTransfer mechanism, essentially tunneling 2.0.1-style certificate and authorisation messages through 1.6 based on an application note published by the Open Charge Alliance. However, know that using DataTransfer for overlapping features can create interoperability issues across vendors, complicate certification, and make future upgrades bumpier. This approach also excludes ISO 15118 smart-charging use cases unless you move to OCPP 2.0.1. In practice, 1.6-based Plug & Charge can work – but it increases the chance of CPMS/charger mismatches (e.g. differing message wrapping or vendor IDs), whereas 2.0.1 gives you the standardised, end-to-end path.

OCPP 2.0.1 has been around since 2020. It’s time to say goodbye to OCPP 1.6 and embrace the benefits this new version brings to the table.

Why this matters: If you’re planning large-scale Plug & Charge rollout, prioritise OCPP 2.0.1 to reduce edge-case behaviour and ease certification and upgrades. Use 1.6+ DataTransfer only if necessary, and with tightly controlled vendor combos and extensive interoperability testing.

Key challenges

While Plug & Charge works in the field today, the ecosystem is still maturing – especially when it comes to ensuring seamless interoperability across all EV and charger combinations. Hubject currently provides a certification program, which has helped accelerate early adoption, but the industry still lacks a unified, neutral certification framework backed by a central test system. CharIN has been developing such a program for several years, and once it becomes widely available, it will provide the common reference point the market needs to ensure that “Plug & Charge just works,” everywhere.

Until that framework is fully rolled out, interoperability relies on periodic CharIN Testivals and bilateral testing between OEMs and charger manufacturers. These efforts are valuable – they show what works, reveal edge cases, and build shared implementation experience – but they don’t yet guarantee seamless behaviour across the entire ecosystem. Closing this gap is one of the key remaining challenges to date.

Plug & Charge is most commonly found on high-power DC chargers today because DC charging requires Power Line Communication (PLC) to operate at all. Since this specific PLC modem (HomePlug Green PHY) is already part of every DC charger’s hardware stack, adding the extra memory and secure hardware needed for certificate handling has a relatively small impact on the overall bill of materials – especially given the already higher cost of DC fast chargers.

AC chargers are a different story. AC charging uses a simple, analogue PWM duty-cycle signal and does not require PLC to deliver energy, so many AC chargers were originally designed without PLC hardware, without space to store multiple certificates, and without a secure element for fast cryptographic operations. Most of them run on low-cost microcontrollers with limited RAM and no hardware acceleration for asymmetric crypto, which means they cannot perform certificate validation quickly enough to meet ISO 15118’s tight timing requirements, leading to message timeouts.

This isn’t something firmware can fix; the limitation is purely hardware. To support Plug & Charge, legacy AC chargers would need a HomePlug Green PHY PLC modem and a controller upgrade – typically to a Linux-class processor paired with a dedicated hardware security module (HSM) capable of performing cryptographic operations at the required speed. The next generation of professional AC chargers should be planned with those hardware components in mind.

Regulatory adoption in Europe, the UK, and the US

Europe has emerged as the primary regulatory driver of Plug & Charge deployment through the Alternative Fuels Infrastructure Regulation (AFIR), which became effective in April 2024. This sweeping mandate requires all newly installed or renovated public DC chargers to support ISO 15118-2 from summer 2025, with an accelerated timeline for full ecosystem adoption. The regulation escalates further on January 1, 2027, when both public and private chargers across Europe must support the advanced ISO 15118-20 standard, effectively forcing a continent-wide infrastructure transformation. This regulatory approach has already spurred network operators to front load deployments and push manufacturers to achieve compliance ahead of deadlines.

AFIR requires the ISO 15118 standard, not Plug & Charge per se, which is one application of that standard. A charger could theoretically be ISO 15118-20 compliant but not specifically implement the Plug & Charge authentication feature. However, this distinction may be rather academic as it just makes little sense to support the newest ISO 15118-20 without any Plug & Charge support.

However, the AFIR regulation does state:

Where such recharging points offer automatic authentication and authorisation services, such as plug-and-charge, they shall comply, for interoperability and security purposes, with both standard EN ISO 15118-2:2016 and standard EN ISO 15118-20:2022

Interoperability between ISO 15118-2 and -20 isn’t always straightforward. One common stumbling block is that the newer ISO 15118-20 expects a more modern security setup than the older standard (i.e. TLS 1.3 vs TLS 1.2). If the car and charger don’t handle this gracefully, their attempt to “speak securely” can fail. When that happens, both sides may simply give up on Plug & Charge altogether and fall back to regular methods like an RFID card, an app, or a payment terminal.

Note that all newly installed or renovated publicly accessible AC and DC charge points must comply with EN ISO 15118-2 from 8 January 2026. In practical terms, this means every new AC and DC charger in Europe will need to be equipped with (HomePlug Green PHY) PLC modem and fully functional ISO 15118 capability from early 2026, effectively accelerating the transition and closing the gap between the 2025 and 2027 milestones.

It’s easy to get confused about the various timelines and what is required when, so here’s a quick summary of the AFIR mandate regarding ISO 15118:

• Summer 2025: Public DC only, ISO 15118-2:

  All new or renovated public DC fast chargers must support ISO 15118-2. AC chargers are not yet included, and ISO 15118-20 is not required.

• 8 January 2026: Public AC & DC, ISO 15118 base stack:

  All new or renovated publicly accessible AC and DC chargers must comply with ISO 15118-2 (including HPGP). This is the first time AC chargers are pulled fully into the ISO 15118 mandate.

• 1 January 2027: All chargers, public & private, ISO 15118-20:

  Every newly installed charger – AC or DC, public or private – must support ISO 15118-20, bringing the entire market (including home and workplace charging) into next-generation Plug & Charge–ready infrastructure.

That doesn’t leave too much time, so make sure you’re ready when the deadline hits!

The United States has adopted a similar but slightly less prescriptive approach through the National Electric Vehicle Infrastructure (NEVI) program, which conditions federal funding eligibility on Plug & Charge capability. NEVI requirements mandate that all chargers conform to ISO 15118-3 standards and possess hardware capable of implementing both ISO 15118-2 and ISO 15118-20 protocols. However, the US timeline is more flexible: charger software must initially conform to ISO 15118-2 with Plug & Charge capabilities operational within one year of the final regulatory rules, allowing manufacturers a grace period for full compliance compared to Europe’s immediate mandates.

Both regulatory regimes underscore that Plug & Charge has transitioned from an optional premium feature to a mandatory infrastructure requirement. This regulatory pressure is the primary factor driving CPO investment and manufacturer development priorities, particularly for charger hardware redesigns and backend system migrations. Without these regulatory mandates, market-driven adoption would likely remain concentrated among premium vehicle manufacturers and flagship networks, leaving much of the charging network without Plug & Charge support.

The United Kingdom has, so far, adopted a distinctly non-prescriptive approach to Plug & Charge, with no explicit ISO 15118 mandates in its regulatory framework. The Public Charge Point Regulations 2023 and oversight by the Office for Zero Emission Vehicles (OZEV) focus on contactless payment access, reliability, pricing transparency, and open data – but contain no requirements for ISO 15118 or Plug & Charge support. Unlike AFIR’s January 1, 2027 deadline for ISO 15118-20 across the EU, the UK has no equivalent legal requirement – yet.

That’s it for today. We’ve covered the core idea: Plug & Charge relies on digital certificates and a public key infrastructure to create a secure chain of trust between the EV, the charger, and the services behind them. But there’s much more to explore. We haven’t yet looked at how these certificates find their way into the vehicle and charger, how the authentication handshake unfolds step-by-step, or how the trust chain is managed and maintained across the ecosystem.

We’ll also look at the practical side: what technical requirements you should consider when bringing a Plug & Charge–ready product to market. For example, how many certificates your EV or charger needs to store to remain future-proof, which secure hardware modules are available, and what their lead times look like.

We’ll dive into those topics in the next articles, building up your understanding layer by layer. And because I’m writing this for you, I’d love to know what you want to go deeper on. Reply, comment, or message me with what you’re most curious about, and I’ll shape the next part of the series around the questions that matter most to you.

But that conversation doesn’t end at the charger.

Today, we’re following the data as it travels deeper into the charging ecosystem. We’ll look at the kind of conversation that unfolds between charger and the cloud-based Charge Point Management System (CPMS), and how the CPMS orchestrates everything from authentication and billing via MSPs and roaming partners to responding to grid signals from the DSO to make sure the EV drivers’ mobility needs are balanced with the needs to operate a stable electricity grid. We’ll also shed light on the role of PKI operators (and what a PKI is) who ensure the entire communication chain remains secure and trustworthy.

This is where the industry’s complexity truly reveals itself: a multi-party digital network working behind the scenes so that, for drivers, charging remains as simple as “plug in and walk away.”

Let’s dive in and complete the picture, one protocol at a time.

Subscribe now

Charging Station Management

A charging station needs to speak several languages flawlessly in order to deliver a pleasant charging experience.

On one side, we have the analogue or digital communication with the electric vehicle, which we explored in the previous article, Behind the plug: What really happens when your EV talks to the charger.

Each of these digital communication protocols spans hundreds of pages of technical requirements that both parties – the EV and the charger – must implement and interpret in exactly the same way for data to flow flawlessly. (And yes, no standard is ever perfect, there’s always room for interpretation.)

A decade of interoperability testing events – since 2019 orgainsed by CharIN under the name CharIN Testivals, focusing on CCS communication – proves just how challenging it is to get everything working flawlessly.

On the other side, the charger maintains a constant connection with a cloud-based Charge Point Management System (CPMS). This allows the system to monitor, control, and update the charger remotely – a crucial capability when it’s part of a wider network operated by what the industry calls a Charge Point Operator (CPO).

Over the past 15 years, the number of “languages” – or communication protocols – used for this charger-to-CPMS conversation has distilled from a mix of vendor-specific, proprietary solutions into a single de-facto global standard: the Open Charge Point Protocol (OCPP).

OCPP – The backbone between charger and cloud

Originally developed by the Dutch foundation ElaadNL, OCPP was created to ensure chargers and backends (a CPMS is often referred to as a ‘CPO backend’ or ‘backend’) from different vendors could communicate using an open, vendor-neutral protocol. It’s now maintained and governed by the Open Charge Alliance (OCA).

OCPP allows a Charge Point Operator (CPO) to:

• Monitor station health, availability, and transaction data

• Authenticate (who is it) and authorise (is he/she allowed to charge) the driver

• Start or stop sessions and unlock connectors remotely

• Push firmware updates and configuration changes

• Reserve connectors for drivers

• Change the availability status of a charger or connector

• Exchange dynamic pricing information

• Influence charging behaviour to optimise costs and/or help balance the grid (think: smart charging profiles)

The Evolution of OCPP

• OCPP 1.6 was published in 2015 and remains the most widely deployed version today. Its implementation has matured over time and it’s supported by basically all existing networks.

• OCPP 2.0.1, published in 2020, represents a major leap forward. It adds richer monitoring and control of all charger components (called the ‘device model’), enhanced event handling, a robust security framework, and native integration with ISO 15118 / Plug & Charge. It’s the version most networks are now transitioning toward, and I’ll unpack more about the benefits of OCPP 2.0.1 in a future post.
  
  If you have some time and want to dig deeper into the changes and benefits, then check out this OCPP 2.0.1 video tutorial published by the OCA.
  
  OCPP 1.6 follows a different application logic and isn’t compatible with OCPP 2.0.1, which has slowed down industry adoption. Unfortunately, many charger manufacturers seem to treat software development like a dentist appointment: they delay it until the pain is too big to ignore. Instead of embracing OCPP 2.0.1, a familiar pattern emerged: patching OCPP 1.6 with extensions that pretend to behave like it. Spoiler: that’s not how you build interoperable, future-proof solutions.

  Or, to borrow a perfectly fitting meme from the Electric Avenue newsletter:

  

  However, I’m now seeing clear signals that the pace is slowly picking up. In my view, one of the biggest advantages of OCPP 2.0.1 for CPOs is its new device model and native support for ISO 15118. I’ll likely dedicate one or more upcoming articles to exploring these benefits, it’s simply too important to overlook.

• OCPP 2.1, released in 2025, builds on 2.0.1 and introduces support for bidirectional power flow, making it the first OCPP version capable of managing Vehicle-to-Grid (V2G) and Vehicle-to-Home (V2H) use cases. It also brings improvements in smart-charging orchestration, enhanced extensibility for energy services, and tighter alignment with the new ISO 15118-20 features.

OCPP 2.1 extends OCPP 2.0.1 with additional functionality, so it’s 100% backwards-compatible. Care has been taken to make sure that all application logic developed for OCPP 2.0.1 will continue to work in OCPP 2.1.

In October 2024, OCPP 2.0.1 Edition 3 was officially adopted by the International Electrotechnical Commission (IEC) as IEC 63584, giving OCPP finally a full international standard status.

A word on EV charging software stacks

A charging station these days has to speak an impressive number of “languages” – from various versions of ISO 15118 to DIN SPEC 70121, and sometimes even CHAdeMO or NACS (North American Charging Standard)1, depending on the region, to OCPP 1.6 and newer. These protocols are complex enough to implement, but the real challenge begins afterward: interoperability testing. Every car manufacturer may have interpreted a technical requirement just a little differently, and ironing out those differences takes far more effort than writing the initial implementation. In fact, most of the work lies in testing, not in coding the standard itself.

And standards never stand still. Revisions, new editions, and feature-packed versions continue to emerge – each one nudging the industry forward but adding to the engineering load.

So it’s fair to ask: how much effort should a charger manufacturer really invest in reinventing the wheel, especially if software development isn’t part of their DNA? Today, there are mature, ready-to-use implementations that are battle-tested, certified, and have survived countless interoperability events. From open-source projects like Pionix’s EVerest to closed-source platforms such as EcoG OS (which, for those who remember, incorporates Switch’s former Josev stack).

EV drivers, and CPOs, will be thankful for a wider adoption of these battle-tested and certified solutions, as the impact will be a much more seamless charging experience.

Roaming – Charging everywhere with one contract

In the early days of e-mobility, the industry experimented with several roaming protocols, each trying to make EV charging networks talk to each other.

There was eMIP (promoted by Gireve) and the Open Clearing House Protocol (OCHP) used by e-clearing.net, and until early September 2025, Hubject had only supported its own Open InterCharge Protocol (OICP). Each worked well within its own ecosystem, but none achieved true universal coverage.

Over time, the industry converged on a single, open protocol that everyone could adopt: OCPI – the Open Charge Point Interface.

Maintained by the EVRoaming Foundation, OCPI has become the de facto global standard for roaming interoperability, enabling a consistent way for Charge Point Operators (CPOs) and Mobility Service Providers (MSPs) to exchange data, authorise sessions, and settle payments directly, without relying on a central clearing house.

Apparently, there’s an unwritten rule in the EV charging world: if your protocol name doesn’t contain O, C, and P, it’s not real.

OCPP, OCPI, OICP, OCHP, OCSP, OPNC… somewhere, there’s a secret committee ensuring we stay alphabetically confused. To clear up that confusion, check out my Acronym Survival Guide. Your go-to cheat sheet for all acronyms in the EV charging world.

Why roaming exists

In many regions, especially in Europe, the EV charging market is deregulated.
That means the CPO (who operates the chargers) and the MSP (who sells access to charging stations for drivers via electricity contracts) must be separate legal entities.

As an EV driver, you sign up with an MSP of your choice, much like choosing an electricity supplier for your home. The MSP gives you an electricity contract for your EV, together with an app or RFID card with which you can access hundreds of thousands of chargers through roaming agreements with CPOs.

The concept is similar to the mobile phone world: you can make calls abroad because your provider has roaming contracts with others.

What’s actually exchanged

Roaming protocols handle a wide range of data:

• Authentication tokens (to identify the driver or vehicle)

• Static data (charger location, type, power rating, amenities, accessibility)

• Dynamic data (real-time availability and pricing)

• Charge Detail Records (CDRs) for billing and reconciliation

This ensures a driver can find the right charge point along their way, possibly even reserve a charge point, plug in upon arrival, start charging, and get billed accurately – whether you’re charging in your home country or abroad.

Centralised vs peer-to-peer roaming

There are two main models for roaming:

1. Centralised platforms (clearing houses):
   Roaming platforms like Hubject or e-clearing.net act as intermediaries, brokering connections between many CPOs and MSPs.

   This saves everyone from negotiating endless bilateral contracts, which dramatically speeds up time-to-market and has proven especially useful in markets like Germany, where Hubject has deep roots among municipal utilities2. Enterprise SLAs and Hubject’s financial settlement offer may also be an incentive to join their hub, given their global footprint of 1,000,000+ connected charging stations.
   

   As a CPO, you have the option to set up offer-to-all pricing arrangements that apply to all MSPs on the roaming platform. You can also establish bilateral agreements with select MSPs, where those specific terms override the general offer-to-all pricing.

2. Peer-to-peer connections:
   OCPI takes a more decentralised approach, allowing CPOs and MSPs to connect directly. This streamlines communication for specific features they may want to enable, and provides more control over their data and commercial agreements. MSPs also save the transaction handling fees that come with a roaming hubs.

So which roaming protocol should you implement?

If you’re a CPO or MSP, the practical answer so far been depending on your target market. Most major players today implement OCPI for peer-to-peer interoperability, but many also keep OICP to access Hubject’s network of partners.

However, in September 2025, Hubject finally announced their support of OCPI. Their dual-stack approach allows their customers to leverage both OCPI and OICP protocols and protocol versions. Hubject’s long-term goal is to help foster one global roaming standard – OCPI – while helping companies transition away from OICP in their own speed.

Roaming may sound like a niche technical detail, but it’s one of the biggest enablers of driver convenience and network growth. Without it, EV charging would still be a patchwork of closed networks.

Like the early days of mobile phones, when you couldn’t call outside your carrier’s network. Thankfully, just as telecom roaming made global communication effortless, EV roaming is doing the same for electric mobility.

Grid operator link – DSOs and the protocols that keep the power balance

The Distribution System Operator (DSO) – sometimes just called the utility or grid operator – plays the unsung role of maintaining the “traffic lights” for electricity. They watch the load on the low-voltage grid (to which most chargers connect), and ensure that power generation equals consumption, so the frequency stays within safe bounds (50 Hz in Europe, 60 Hz in the U.S.).

Picture the grid as a see-saw that must stay perfectly level: every car plugged in, every charging station active, adds weight. But leveraged smartly, EV’s can act as essential mobile batteries that reduce the stress on the grid or even power the grid when needed (think: smart charging and Vehicle-to-Grid – or V2G – technology). The rules that govern this balance are called grid codes, which is an exciting topic of its own and one I’ll make sure to cover as well.

Since the CPMS (the CPO’s backend) is managing large clusters of chargers, there must be a communication link between the CPMS and the DSO to exchange forecasts, capacity constraints, and control instructions. After all, charging needs to fit into the grid without triggering a blackout.

In practice, three main protocol families are currently being used for this DSO ←→ charger/aggregator link, depending on the region:

• OpenADR (Open Automated Demand Response)

• IEEE 2030.5 (formerly known as Smart Energy Profile 2.0)

• IEC 61850‑90‑8 (a data exchange profile of IEC 61850 tailored for EV charging/grid-interaction)

OpenADR

OpenADR is the go-to standard for communicating demand response events. Think: “Please reduce your power draw now” or “You may resume”. Especially in the U.S. and increasingly in Europe (e.g., Dutch DSOs implementing Grid-Aware Charging), OpenADR enables DSOs to send signals to CPOs or aggregators, who then throttle or schedule EV charging to avoid overloads.

It’s like the DSO telling the chargers: “Hey, ease up, traffic’s piling up on the power highway.”

IEEE 2030.5 (SEP 2.0)

While OpenADR is focused on demand response messaging to coordinate energy usage, IEEE 2030.5 provides a comprehensive communication standard for directly controlling and managing a wide range of smaller distributed energy resources (DERs), such as solar, battery storage, or EV chargers.

It’s particularly strong in the U.S., where utilities are pushing for secure, two-way communication with chargers that can act as grid resources — for example, in Vehicle-to-Grid (V2G) use cases. U.S. power grids are notoriously vulnerable to weather events such as wildfires and blizzards, often leaving millions without electricity because much of the infrastructure is built above ground. That’s why the ability to use your EV to power your home — known as Vehicle-to-Home (V2H) — has attracted so much attention. Ford’s F-150 Lightning, for instance, became a hit after a Super Bowl commercial showed it instantly lighting up a house during a (fictional) blackout.

IEC 61850-90-8

This lesser-known standard is part of the IEC 61850 family (used in substations), with profile 90-8 tailored for EV charging/data exchange between DSOs and charging infrastructure. It’s mainly European in traction.

Bottom line for CPOs

The industry has not yet settled on a single communication standard for the DSO ←→ CPO link. Meaning: if you’re operating chargers at scale, you’ll want to be compatible with at least one of these protocols (depending on region) because:

• DSOs increasingly mandate smart-charging behaviour (e.g. grid-aware profiles, dynamic curtailment).

• Being “grid-friendly” means you avoid bottlenecks, get quicker access to power infrastructure without needing to wait for capacity upgrades, and can even monetise flexibility (see for example Pacific Gas & Electric’s Flex Connect program).

• These protocols turn chargers from passive consumers into active grid participants. This is a key enabler to unlock timely buildout of EV infrastructure and, as a result, accelerate EV uptake. Additionally, this capability adds new revenue streams for CPOs as they can bundle their EV chargers into what we call virtual power plants (VPPs) to participate in the energy and flexibility markets (e.g. intraday and day-ahead trading, or frequency containment reserve).

Public Key Infrastructure operator

The last part of the EV charging ecosystem shown in the map above has become an increasingly important one, both with respect to user convenience and cybersecurity.

With ISO 15118’s Plug & Charge adoption rising quickly, user convenience is taking centre stage, providing the same seamless experience that Tesla drivers have enjoyed for years. And as EV charging networks increasingly form part of critical infrastructure that must be protected from malicious actors at all times, cybersecurity is shifting from a nice-to-have feature – often overlooked in the early days – to a key topic on industry and government agendas.

A Public Key Infrastructure (PKI) is the framework that makes secure digital communication possible. It relies on cryptographic key pairs – one public, one private – and digital certificates issued by trusted authorities to prove that each party in a communication is who they claim to be.

In the context of EV charging, PKI ensures that the information exchanged between the EV and the charger (such as authentication credentials, contract certificates or charging profiles) and between the charger and the backend system (like charging data, pricing, or firmware updates) remains encrypted, tamper-proof, and verifiable.

This system of digital certificates allows all actors — the vehicle, the charger, and the backend — to trust one another automatically, without manual intervention. It’s the foundation that enables secure features such as Plug & Charge, where the EV identifies itself and authorises payment seamlessly the moment it’s plugged in.

The charging-related information exchanged between EV and charger is encrypted via Transport Layer Security (TLS), guaranteeing confidentiality. Additionally, sensitive information that is exchanged between the charging station and its cloud-based CSMS is digitally signed to guarantee both the integrity of the information and the authenticity of the sender. Confidentiality, data integrity and authenticity are the three cornerstones of a secure charging and billing process. All this is made possible through a PKI.

The Plug & Charge ecosystem actually comprises several market roles which, for brevity’s sake, I subsumed under the term “Public Key Infrastructure operator”. As I’m writing this article, there’s only one established PKI operator, namely Hubject. Hubject currently takes on several roles from issuing, distributing and revoking digital certificates to operating data pools that are necessary to guarantee a smooth and secure exchange of information between the stakeholders in a Plug & Charge ecosystem.

There are other PKI operators coming to the e-mobility market, namely Irdeto and roaming hub operator Gireve. In June 2025, the three companies announced a Plug & Charge partnership, providing mutual access and integrations to each other’s platforms. In practice, this means CPOs, EMPs, and even vehicle OEMs are free to pick whichever Plug & Charge provider they prefer, while still gaining interoperability with the other two ecosystems.

The Sustainable Transport Forum (STF), an expert body advising the European Commission on e-mobility, is working to define a common EU-wide governance framework that will ensure truly interoperable EV charging infrastructure across all market players.

There’s a lot to unpack when it comes to Plug & Charge and the underlying PKI. The image above shows just how many entities are involved in this ecosystem. Enough material to fill an entire day of training, as I’ve done in the past. I’ll dive deeper into this diagram and share that knowledge in my upcoming articles dedicated to Plug & Charge. If there’s a particular aspect you’d like me to cover, let me know – I’d love to tailor it to what you find most interesting.

Open Plug & Charge Network Communication Protocol (OPNC)

Early 2022, Hubject introduced an open-source protocol called Open Plug and Charge Protocol (OPCP). The purpose of the OPCP protocol is to provide an open, international, supplier-agnostic API framework that enables seamless interoperability across Plug & Charge systems, linking multiple PKI ecosystems, CPOs, MSPs and OEMs so that EVs, chargers and backend networks can operate together smoothly.

In 2024, CharIN e.V. established a task force to take over the governance of this open-source project and changed the protocol name to Open Plug & Charge Network Communication Protocol, or OPNC (link to GitHub repo) for short. Did I mention already that this industry just loooves using O’s, P’s and C’s in protocol names?

All right, you now have a pretty complete overview of the market roles and communication protocols at play, working in concert around the clock to ensure you have the most seamless and secure charging experience possible.

It’s not perfect, and I’m sure there are people out there who may wonder why it appears to be so complex. Although I tried to shed some light and reduce any confusion, I’m sure your head is still spinning with all the roles, protocols, and acronyms.

If anything remains unclear, please don’t hesitate to leave a comment on this article, or respond directly to my email. I’ll be happy to explain further.

In next week’s article, we’ll start pulling back the curtain on the magic behind Plug & Charge. Stay tuned, and have a great week!

But the more actors involved, the more chances there are for something to go wrong. A single weak link in the chain – whether it’s the EV, the charger, the network operator’s Charge Point Management System (CPMS), a roaming hub, or a payment provider – can derail the entire experience. No energy. Frustrated driver. Lost revenue.

To avoid that, every system in this chain needs to speak the same language. That language is defined by communication protocols.

You might think: “What’s there to talk about? I want my car to be fully charged asap, here are my payment details, plug in and done!”

In reality, delivering electricity to your EV is a carefully choreographed digital conversation. So let’s break down what information needs to flow between all these components, and how communication protocols make the magic work.

Today, we focus on how the EV and the charger talk to each other. In the next edition, we’ll venture deeper into the protocol jungle and explore the rest of the ecosystem.

Subscribe now

What are they even talking about?

Once an EV plugs into a charger, the real work begins. Not through sparks and cables, but through data. Before a single electron flows, the car and the charger start exchanging information like two strangers figuring out how to dance together.

The EV says things like:

• How much energy I need

• My max charge power

• What voltages and currents I can safely handle

• When I plan to leave – so no need to rush, or please do rush!

• What energy contract I want to use at this location (if Plug & Charge is enabled)

In return, the charger reports to the EV:

• What power it can deliver right now, and how this may change over the next hours

• Confirmation that the driver is actually allowed to charge here

• Whether all safety checks are complete to start charging

Then there’s the wider ecosystem. The charger usually not acting alone, it’s constantly checking in with the Charge Point Management System (CPMS), sending operational and health status updates, keeping track of the energy delivered to the EV, and receiving smart-charging instructions that align power delivery with grid needs.

And further down the chain, the CPMS coordinates with a Mobility Service Provider (MSP) or roaming hub to sort out:

• Where the charger is located and whether it’s available for energy delivery

• Who the driver is and whether he or she is allowed to charge

• Which price to apply and how the session will be billed

So while you’re casually plugging in and walking away, there’s a multi-party negotiation unfolding in seconds. Everyone in this chain – the EV, the charger, the backend systems, the payment platforms – must quickly agree on what’s happening, what’s allowed, and what comes next.

That’s the conversation. Next, we’ll explore the languages they use to have it: the communication protocols that intend to keep charging simple for drivers. But boy can they be incredibly complex under the hood.

EV to charger communication protocols

If you’ve ever tried to make sense of all the acronyms flying around in the EV charging world – OCPP, OCPI, OICP, OCHP, OPNC – you’re not alone.

The list of communication protocols can make your head spin (and yes, the fact that so many start with O and include a C and a P is not lost on anyone). I guess protocol nerds are not the most creative bunch of people when it comes to naming…

Let’s start with the EV itself and follow the data trail outward, step by step.

When an EV connects to a charging station, they need a shared language to coordinate the flow of energy. This can happen in one of two ways:
through analogue signalling or digital communication.

IEC 61851

The IEC 61851 standard governs the analogue communication between the EV and the charger. It defines the basic safety mechanisms that ensure power only flows when it’s safe, i.e. when the vehicle is stationary and correctly connected.

When the charging cable is plugged in, the station sends what is called a pulse width modulation (PWM) signal along the control pilot (CP) line of the charging cable. The EV reads the duty cycle of this PWM signal (expressed as a percentage) to determine how much current it’s allowed to draw.

If you’re thinking “duty what now?”, you’re not alone. The first time I saw the term, I assumed it was one of those insider phrases electricians knowingly toss around over a bottle of cold beer. In reality, the duty cycle is simply the ratio of how long a signal is ON vs. OFF during each tiny pulse. It’s expressed as a percentage, and the higher that percentage, the more current the EV is allowed to draw. Think of it like the charger saying: “I’m 53% ‘on’, feel free to take up to 32 amps.”

A duty cycle between 10% and 96% represents a theoretical charging range from 6 A to 80 A per phase, though in practice, most AC chargers are limited to 11 kW (16 A) or 22 kW (32 A) per phase.

A phase is basically one live wire carrying power in a rhythm (a sine wave), like a lane on an electrical highway; using three phases means three live wires working together to deliver more power at once, which charges your car faster.

The image below illustrates the concept of this analogue “communication” between the EV and the charger on the Control Pilot wire of the charging cable. This example is specifically relevant for slower AC charging, DC charging works slightly different. (Hold on, you eager beaver, we’ll get to that in a minute. )

Let’s run through how the Control Pilot signal guides the charging process, as defined in IEC 61851:

• Charger waiting (State A: +12 V)

  • No car plugged in

  • Control Pilot sits at a steady +12 volts

  • Meaning: “I’m here and ready, but no vehicle connected”

• Car plugs in → voltage drops (State B: +9 V)

  • The EV adds a resistor to ground when inserted

  • Voltage drops from +12 V → +9 V

  • Meaning: “A vehicle is present and communication can start”

  • Charger begins sending a 1 kHz square-wave (the PWM signal)

  • Positive part of the wave encodes max current available

• Car requests charging → clipped signal (State C: +6 V)

  • The EV changes the resistance again to show it is ready to draw power

  • The positive peak is clipped to +6 V

  • Meaning: “Ready to charge” → “Charging in progress”

  • The width of the positive pulses (duty cycle) tells the EV how many amps it may pull

  • The -12 V portion keeps confirming grounding and line integrity

• Charging stops → signal returns

  • EV stops power draw → positive peak goes back to +9 V

  • Driver unplugs → solid +12 V again

  • Meaning: “Session over, no EV connected”

Beyond States A to C, IEC 61851 also defines additional safety-related states:

• State D: Vehicle connected and charging possible, but ventilation required (not used anymore, was only relevant for old lead-acid batteries)

• State E: Supply fault, Control Pilot power lost, charging disabled

• State F: Ground fault, PE issue detected, charging prohibited

Does that make sense? Hope so. If not, let me know.

Now, you might think: “What’s this ‘Control Pilot’ wire he’s talking about?”

Great question, and a perfect moment to quickly decode what’s actually hiding inside these charging plugs. Below you’ll see the CCS 2 connector used for DC fast charging (left), the matching vehicle inlet (middle), and the familiar Type 2 AC plug (right). You’ve probably used these countless times without thinking about what each pin does. But after this, you’ll know exactly how they work and can impress the next EV driver you meet at the charger.

What all those pins actually do (Type 2 & CCS2 connectors)

Every pin has a very specific job:

• L1, L2, L3: the power lanes
  These are the three phases that carry the actual AC charging power. The car can use one of them (single-phase) or all three at once (three-phase) to charge faster.

• N: Neutral
  Completes the electrical AC circuit, working together with the phases.

• PE: Protective Earth (ground)
  A safety connection to the ground. If something ever goes wrong, this gives the electricity a safe path away from you and the car.

• CP: Control Pilot
  The communication lifeline between car and charger. It tells the EV how much current it’s allowed to draw and whether charging is permitted. It’s also how the system detects when the plug is inserted or removed.

• PP: Proximity Pilot
  A simple but important safety pin: it detects that a cable is plugged in and prevents the car from driving away with the cable still attached. It also tells the charger how thick the cable is, and therefore how much current the cable can safely handle.

By the way, CCS stands for Combined Charging System – “combined” because it merges the Type 2 AC interface at the top with the two larger DC+ and DC– pins below for fast DC charging. Type 2 and CCS2 are the standard in e.g. Europe, the UK, Australia, and India, while the slightly different Type 1 / CCS1 interface (built around a single-phase AC design) dominates in the U.S., Canada, and Japan.

Since its introduction in the early 2010s, CCS has been adopted as the de facto global standard for DC fast charging in Europe, North America, and much of the world. It’s supported by virtually all major automakers and infrastructure providers and governed by the Charging Interface Initiative (CharIN) e.V. Have a look at their website to learn more about their initiatives, members, white papers and organised industry events.

I could happily keep diving into the nuances of global charging connectors, but that would lead us deep down the hardware rabbit hole. And this article is really about communication protocols. So let’s shift gears from plugs and pins to the digital language that makes EV charging smart.

ISO 15118 and DIN SPEC 70121

After mastering the electrical handshake, the industry needed something smarter. A way for the car and charger to actually talk. That’s where ISO 15118 and DIN SPEC 70121 step in. CCS builds on the basic safety handshake defined in IEC 61851, and adds ISO 15118 and DIN SPEC 70121 on top of it to enable digital communication.

These digital communication standards run over Power Line Communication (PLC), using the same Control Pilot wire that already handles the PWM signal. In other words: without adding any extra wires, the EV and charging station can now exchange real data, from basic status updates to fully automated Plug & Charge experiences.

IEC 61851 dictates that if a digital protocol is used, the duty cycle should drop to 5%, signalling the start of “high-level communication”. From that point on, it’s all data: bits and bytes defining authentication credentials, charging parameters, and energy flow.

DIN SPEC 70121 is focused on DC charging and was originally conceived as a temporary bridge when it was first released in 2012, until ISO 15118 was finalised in 2014. But as the saying goes, nothing is as permanent as a temporary solution. It’s still widely used today.

ISO 15118, by contrast, supports both AC and DC charging and forms the foundation for modern innovations like Plug & Charge, Vehicle-to-Grid (V2G), and solid cybersecurity measures, which we’ll explore more in future articles.

It’s also worth noting that ISO 15118 itself has evolved: from the foundational ISO 15118-2 published in 2014 (covering AC and DC charging) to the newer ISO 15118-20 published in 2022, which extends capabilities such as bi-directional power flow (enabling your car to power your home or stabilise the grid when needed and getting paid for it), better support for multi-contract handling for Plug & Charge, and advanced cybersecurity enhancements. I’ll unpack these differences and what they mean for CPOs, OEMs, and utilities in future posts.

At its core, ISO 15118-2 upgrades charging from a simple power delivery experience to a smart, secure, and fully automated one. For drivers, it enables Plug & Charge: you just plug in, and the car and charger authenticate each other automatically, no apps or RFID cards needed. This magic is powered by digital certificates and cryptographic signatures that ensure both sides can truly trust who they’re talking to. For charge point operators and energy companies, it unlocks smart charging features like scheduling, price-responsive charging, and load balancing to protect the grid and reduce costs.

I literally wrote the book on this – the ISO 15118 Manual back in 2017 – so believe me, there’s a lot more to explore. We’ll start with the essentials here, and save the deeper magic for upcoming articles.

CHAdeMO, GB/T, ChaoJi, and Tesla / NACS

The Combined Charging System (CCS) has probably the biggest adoption worldwide, but it’s not the only DC-based charging system.

CHAdeMO, for example, is a Japanese DC charging and communication standard that came to market with early Nissan and Mitsubishi vehicles. It also enabled some of the world’s first vehicle-to-grid (V2G) trials, thanks to its built-in bi-directional power flow capability. While many stations still support CHAdeMO, its relevance outside Japan is fading since Nissan’s 2020 decision to move to CCS for the European and U.S. markets.

GB/T is China’s national DC charging and communication standard, used exclusively for EVs and chargers sold within China. Like CHAdeMO, it relies on CAN bus communication rather than PLC and therefore does not use PWM signalling.

ChaoJi (also known as CHAdeMO 3.0) is the next-generation DC charging system jointly developed by the CHAdeMO Association and the China Electricity Council (CEC). It supports ultra-high-power charging (up to ~900 kW) and is designed for backward compatibility with both CHAdeMO and GB/T connectors. ChaoJi still uses CAN-based communication but represents a more coordinated step toward a globally harmonised DC standard.

Tesla’s North American Charging Standard (NACS) – now formalised as the SAE J3400 standard – has rapidly become the dominant connector type in North America. Unlike Tesla’s original proprietary CAN-based setup, J3400 uses Power Line Communication and supports ISO 15118 / DIN 70121 messaging. This makes it technically compatible with Plug & Charge, aligning it with CCS communication layers and paving the way for full interoperability as automakers and networks adopt ISO 15118-compliant firmware and PKI integration.

That’s all folks. You now have a solid overview of the charging systems used around the world, the communication protocols involved, and the capabilities they unlock.

If an acronym ever slips your mind, bookmark the Acronym Survival Guide. Future you will be grateful.

Next week, in Part 3 of the Behind the Plug series, we’ll explore the communication protocols that connect the rest of the e-mobility ecosystem. The ones working behind the scenes beyond the plug. Stay tuned!

And trust me, even the engineers who invented half these acronyms occasionally have to look them up.

• AC: Alternating Current

• ACER: Agency for the Cooperation of Energy Regulators

• CA: Certificate Authority

• CCS: Combined Charging System

• CP: Control Pilot

• CPMS: Charge Point Management System (synonym for CSMS)

• CPO: Charge Point Operator

• CSMS: Charging Station Management System (synonym for CPMS)

• DC: Direct Current

• DCC: Demand Connection Code

• DER: Distributed Energy Resource

• DSO: Distribution System Operator

• ECC: Elliptic Curve Cryptography

• EMAID: E-Mobility Account Identifier

• EVCC: Electric Vehicle Communication Controller

• EVSE: Electric Vehicle Supply Equipment

• FRT: Fault Ride-Through

• LFSM-U(C): Limited Frequency Sensitive Mode – Underfrequency (Control)

• LFSM-O(C): Limited Frequency Sensitive Mode – Overfrequency (Control)

• MO: Mobility Operator (synonym for MSP)

• MSP: Mobility Service Provider

• OBC: On-Board Charger

• OCHP: Open Clearing House Protocol

• OCPI: Open Charge Point Interface

• OCPP: Open Charge Point Protocol

• OCSP: Online Certificate Status Protocol

• OICP: Open InterCharge Protocol

• PKI: Public Key Infrastructure

• PSP: Payment Service Provider

• PLC: Power Line Communication

• RfG: Requirements for Generators

• RoCoF: Rate of Change of Frequency

• SAE: Society of Automotive Engineers

• SECC: Supply Equipment Communication Controller

• VAr: Volt Ampere reactive

• V2G: Vehicle-to-Grid

• V2H: Vehicle-to-Home

• VPP: Virtual Power Plant

Welcome, and thank you for being here.

If you’ve just joined from the old Switch EV newsletter – welcome back! This marks the first issue of my new publication, Current Affairs.

This is my very first Substack article. A new beginning, and a new space for me to continue my mission as a technical guide through the complex world of EV charging.

If you’re a charge point operator, EV or charger manufacturer, mobility service provider, utility, consultant, researcher, or simply someone who wants to really understand how the EV ecosystem fits together – this space is for you.

For over a decade, I’ve been building this ecosystem from the inside and teaching companies the ins and outs of complex EV charging standards. And now I’m here to continue sharing that experience with everyone else who needs to truly understand how it all fits together.

My goal is to make this publication your go-to source for:

• Clear explanations of complex standards like ISO 15118 and OCPP

• Behind-the-scenes perspectives from industry professionals

• Reflections on innovation, policies, and the future of EVs as mobile batteries

• Operational insights from a Charge Point Operator’s view

• Practical explorations of how AI and automation can make EV charging networks more reliable and smarter

This is a shared journey, not a monologue. Your feedback will directly shape what I write about next. What questions are you trying to answer? What’s most interesting to you? Just hit reply and let me know.

I’ll be here (bi-)weekly with new posts, and with your input, this will become an essential resource for anyone navigating the charging space.

All right, let’s dive into the world of EV charging – starting with the main market roles.

Subscribe now

Charging an electric vehicle (EV) shouldn’t be harder than filling up a car with fuel. In fact, it should even be easier. Plug in, wait a few minutes (while you maybe eat a snack or use the bathroom), unplug, drive away - done! No need to even go inside to pay for the charged energy because it’s all paid for automatically. That’s the Tesla experience, and guess what – the same experience is achievable for ALL EV drivers.

Yet in practice, EV charging often feels anything but straightforward. And that’s puzzling, because EVs themselves are far less complex than the combustion cars they’re replacing.

But behind the scenes of a charging session unfolds a whole orchestra of market roles and communication protocols that must act in concert to make charging seamless. Although the first early-adopter phase of modern EVs began around 2010-2012, the EV charging ecosystem is still in the process of standardising and aligning its many moving parts. Comparisons with the telecommunications industry are common: both depend on interoperable networks, shared standards, and reliable data exchange. The difference is that EV charging can build on the lessons telecom learned over decades of standardisation and integration, allowing our industry to reach maturity much faster.

In today’s article (Part 1), we start off by explaining the main market roles:

• Charge Point Operator (CPO)

• Mobility Service Provider (MSP)

• Roaming Platform / Hub

• Payment Service Provider (PSP)

• Payment Terminal Provider

• Distribution System Operator (DSO)

• Public Key Infrastructure (PKI) Operator

• EV and Charger Manufacturer (OEMs)

Part 2 will then dive into the actual communication protocols used to exchange data between these market roles in order to facilitate interoperability, scalability, and – ultimately – a seamless charging experience for EV drivers.

So let’s dive right in.

Market roles in EV charging

When you plug in your car, you’re not just connecting to a charger. You’re entering a complete ecosystem.

Behind that simple action sits a web of companies, contracts, and communication layers, all working together (or at least trying to).

The image below shows the key players and how they interact through various communication protocols. Let’s unpack who does what and why it matters.

Charge Point Operator

Whether it’s the charger on your street, the one at your office, or a rapid charger on the motorway, someone needs to make sure it’s alive, available, and behaving.
That’s the job of the Charge Point Operator (CPO) – the company responsible for keeping chargers running smoothly, monitoring their health, and ensuring drivers can actually charge when they arrive.

To do this, CPOs use a Charge Point Management System (CPMS) – also called a Charging Station Management System (CSMS) – typically a cloud-based platform that talks to each charger in real time. These CPMS platforms are either built in-house or provided by specialised Software-as-a-Service (SaaS) companies like Ampeco, Monta, Driivz, Greenflux, Spirii, or Chargepoint, to name just a few.

Communication happens via a WebSocket connection using the Open Charge Point Protocol (OCPP – more on that in Part 2 of this article), most often over Ethernet or a cellular network through a SIM card inside the charger.

In short, if a charger is the hardware, the CPMS is the central nervous system connected to a wider set of market roles, and the CPO is the one making sure it doesn’t have a breakdown.

Mobility Service Provider

There’s more than one way to start a charging session. You might download an app from the CPO directly, register your name, address, and payment details, and start charging through that app. Or you might simply tap your credit card at a contactless payment terminal – no registration, no contract, completely anonymous.

But behind many public charging experiences sits another, often invisible layer: the Mobility Service Provider (MSP).

The MSP gives you an electricity contract for your car, linked to a digital identity: your authentication token. That token might be:

• an RFID card you tap at the charger,

• your user account within an MSP’s mobile app, or

• a digital certificate embedded directly in your vehicle (for the Plug & Charge experience defined in ISO 151181).

In the ISO 15118 standard, this role is called the Mobility Operator (MO) – but the idea is the same: the MSP connects your identity, contract, and payment method to the charging infrastructure and authenticates your session (enabling the CPO to grant access to its charging infrastructure after the MSP confirmed that the EV driver is a valid customer) and ensures billing happens correctly, even when you’re roaming across networks run by different CPOs.

Roaming Platform

Imagine driving across Europe and being able to charge your EV anywhere, without juggling half a dozen apps or RFID cards from various CPO networks. That’s the idea behind EV roaming: enabling drivers to charge at stations operated by different CPOs using a single credential.

To make that happen, CPOs and MSPs need to exchange a lot of information automatically. Things like driver authentication, session authorisation, billing data, and real-time station details such as location, pricing, and availability.

A roaming platform (or roaming hub) acts as a digital marketplace, a broker of sorts, where CPOs and MSPs can connect and form roaming agreements based on pre-defined legal contract templates. These agreements let an MSP’s customers access a much wider network of chargers, and let CPOs make their infrastructure available to many more drivers, which results in increased utilisation and revenues.

Instead of managing dozens of one-to-one contracts, both sides can join a roaming hub that offers what’s known as “offer-to-all” functionality. This allows every CPO on the platform to publish its tariffs to all participating MSPs, and vice versa. They can still make bilateral deals on top of that if they want special commercial terms, but the hub takes care of the messy part: contractual agreements & interoperability at scale.

Some of the most established European roaming platforms today are Hubject and Gireve. Hubject remains the dominant global player, connecting over a million charging points through thousands of partner networks across 70+ countries, and serving as a de facto backbone for cross-border interoperability. Meanwhile, Gireve is especially active across France and greater Western Europe. Its roaming barometer showed around 659,000 connected stations as of October 2025. Thirdly, there is also e-clearing.net, another early player in the market, with a strong German foundation and active across Europe. More recently, newer entrants such as ENAPI are gaining momentum in Europe: for instance, Driivz (a prominent SaaS provider for CPOs) has partnered with ENAPI to leverage its network of 350,000+ connected points.

In the United States, Hubject is extending its footprint through integrations (e.g., with Blink), and ChargeHub is a key local roaming hub via its Passport Hub. Meanwhile, in markets like the US and UK, peer-to-peer (bilateral) roaming – direct agreements between CPOs and MSPs without a hub – continues to be widespread.

Which Roaming Partners & Hubs Should a CPO Focus On?

That, my friend, is a question that needs to be answered on a case by case basis. It depends on the region you operate in, your individual network, your in-house legal expertise (and appetite to negotiate terms), and your need for flexibility when it comes to implementing specific roaming functionalities. However, at least for Europe and the UK, I can point out a few big players in the market that give you instant access to a big network of EV drivers:

• Roaming hub: The biggest and most well-established player across the globe is Hubject. Their intercharge CPO solution costs you a one-off technical integration fee of €5,000 and then €99 per month. No caps on the number of charge points you integrate, no other hidden fees, and instant access to hundreds of MSPs.

• Peer-to-peer roaming: Some of the bigger MSPs on the market include Octopus Electroverse, Plugsurfing, Shell Recharge, Maingau Energie, DCS (Digital Charging Solutions) and Elli (Volkswagen’s e-mobility service).

Particularly DCS and Elli are interesting MSP solutions, as they offer white-labelled MSP apps for major automotive brands and fleet operators. This means the charging stations they provide access to are automatically integrated into the vehicle’s onboard navigation system. The moment a driver searches for a charger, your charging site could appear right on their dashboard.

For CPOs, this kind of integration is gold: it boosts charger visibility, drives more sessions without additional marketing spend, and ensures that their network is part of the seamless charging experience drivers now expect.

Payment Service Provider

A Payment Service Provider (PSP) facilitates financial transactions between EV drivers and CPOs by securely processing card or digital payments. PSPs like Adyen or Stripe handle the authorisation (this includes pre-authorising an amount on your credit or debit card up to which you’re allowed to charge energy), capturing the pre-auth amount and settlement, and compliance aspects of payments. This ensures that funds flow correctly between customers, charge point operators, and intermediaries.

They enable multiple payment methods (contactless, app-based, or web payments) and ensure adherence to standards such as PCI DSS and PSD2, often integrating directly with CPO or MSP platforms via proprietary APIs to streamline the payment experience.

Payment Terminal Provider

Those are the manufacturers of card/contactless terminals embedded in or paired with charging stations via a standalone kiosk solution. Some of the more well-known players in this market are Payter, Nayax, CCV, Worldline, and Castles. They supply the hardware, device management, and payment processing interfaces used for ad-hoc EMV payments. Those are card payments that follow the global standard developed by Europay, Mastercard, and Visa – hence the name EMV. Integration typically follows two patterns:

1. OEM-managed: the charger manufacturer integrates the terminal locally via the vendor’s SDK/protocol and calls the vendor’s cloud (common with Payter’s local “PSP” or cloud “CPS/MyPayter” flows)

2. CPO-managed (cloud): the CPO integrates directly with the terminal provider’s cloud, sometimes via a proprietary API, and – increasingly – via OCPI-based payment/kiosk integrations where offered (e.g. CCV “Cloud-Connect” and Nayax OCPI). Choice of model affects who controls the user flow on the terminal screen, receipting, pre-auth/settlement logic, and telemetry.

In short, Payment Terminal Providers bridge the charger to the card schemes, while CPOs decide whether that bridge is handled by the charger OEM or by the CPO backend for greater control.

Distribution System Operator

The Distribution System Operator (DSO) is the quiet force keeping electricity flowing where it’s needed: from power plants, solar farms, and wind parks all the way to homes, offices, and charging stations. DSOs manage the low- and medium-voltage grids that connect end consumers to the larger transmission network.

In practice, this means they balance supply and demand on local grids, maintain network stability, and ensure that the energy your EV draws is delivered safely and reliably, whether you’re charging at home, at work, or at a public station on the corner.

Public Key Infrastructure Operator

When it comes to secure EV charging, trust is everything. And that trust is built on cryptography.

At the heart of it all sits the Public Key Infrastructure (PKI), the system that manages the digital identities used by electric vehicles, charging stations, and back-end systems to authenticate one another.

This infrastructure enables what’s known as Plug & Charge, a technology defined in ISO 15118 that allows an EV to automatically identify itself and start charging securely, without the driver needing an app, RFID card, or credit card.

In the diagram above, I refer to the entity operating this ecosystem as the PKI Operator. The role is complex and consists of multiple sub-roles (like certificate authorities, registration authorities, and data pool providers for various types of digital certificates), often run by different organisations. For simplicity, I’ve grouped them together here under one umbrella.

The PKI Operator ensures that when an EV connects to a charger, both sides can verify each other’s identity, encrypt their communication, and prevent fraud or cyberattacks across what is increasingly recognised as critical national infrastructure.

This is a vast and fascinating topic, and one I’ve spent years exploring. I even wrote an entire book about it, The ISO 15118 Manual, which I’ll be breaking down into a series of posts over the coming weeks and months. We’ll look at how cryptography keeps EV charging secure, how Plug & Charge really works, and what it takes to build digital trust at scale.

EV and Charging Station Manufacturer

This one’s fairly self-explanatory – someone has to build the cars and the chargers. 😉
But it’s worth remembering that vehicle manufacturers (often referred to as the OEMs) and charging station manufacturers play a crucial role in ensuring interoperability. Each must implement communication protocols like ISO 15118 and OCPP correctly so that EVs and chargers can speak the same digital language. When they do, charging feels seamless; when they don’t, we all notice.

That’s it. These are the main roles working behind the scenes to make a seamless charging experience possible. To be fair, this isn’t an exhaustive list of every player involved in the charging and payment process. I could go on about financial roles like the acquiring bank, issuing bank, and merchant of record; or grid-related roles like the energy supplier, flexibility service provider, transmission system operator (TSO), or energy management system (EMS) within a building. Not to mention site hosts, installation and maintenance service partners, and navigation or mapping services.

At some point, though, the ecosystem diagram turns into spaghetti – and this first part is meant to give you a clear overview of the core actors before we dive into the communication protocols that connect them in Part 2.

Abbreviations

As you probably start to realise, this industry comes with its own set of abbreviations, and it’s easy to get lost if you’re new to this world. To save you from acronym overload, I’ve created a handy cheat sheet for the key terms used throughout all my articles: welcome to my Acronym Survival Guide. Keep it handy, you’ll need it.