Nothing in ISO 15118 asks who owns your software. Plug and Charge is the part of that standard that lets a driver push a cable into a socket and have the session authenticate, authorize, and bill itself, with no app, no card, and no tap. It works because the vehicle carries a digital contract certificate issued against the driver’s mobility account, and the charge point, backed by the operator’s platform, validates that certificate against a chain of signatures running back to a root authority both sides already trust. The check is cryptographic. It confirms a signature, an expiry date, and a chain of trust. It has no field for the commercial model of the backend performing it.

That absence collides with something operators still believe. The assumption that owning your charging platform costs you network reach tends to surface late in procurement, once the cost case has already landed: if the operator holds the software itself, will its drivers still plug in and charge in the next country, on somebody else’s network? The question is fair. The inherited answer is wrong, and its origins are commercial rather than technical.

Plug and Charge Is a Protocol Obligation Before It Is a Product Feature

ISO 15118 is the International Organization for Standardization’s specification for communication between a vehicle and a charge point. Its 2014 edition, ISO 15118-2, defined certificate-based authentication and made automatic session authorization possible in the first place. Its 2022 successor, ISO 15118-20, carried that forward and extended the standard to bidirectional power transfer, which is why it now sits at the center of every serious vehicle-to-grid conversation. Both editions describe message flows, security architecture, and certificate formats. Neither describes a subscription tier. The wider protocol stack an operator has to run alongside it, including the Open Charge Point Protocol (OCPP) that carries these exchanges between charger and backend, is set out in our analysis of multi-protocol compliance across charging platforms.

The distinction matters because a standard creates obligations that attach to roles, and function defines those roles. Whoever operates the charge point validates the certificate. Whoever holds the driver relationship issues the contract certificate. The standard is indifferent to whether either party wrote the software, licensed it, or rents it by the month.

Who issues, signs, and validates the certificate

Four parties touch a Plug and Charge session, and each does a distinct job.

The vehicle manufacturer provisions the car at the factory with an original equipment manufacturer certificate, the credential that proves the vehicle is what it claims to be. The e-Mobility Service Provider (eMSP) that holds the driver’s account issues or procures a contract certificate tied to that account, and that certificate is what turns a plug-in into a billable, authorized session. A root operator anchors the trust chain and runs the public key infrastructure (PKI) that lets parties who have never met validate one another’s signatures; in Europe that role sits with a small number of V2G root operators, Hubject’s Plug&Charge Ecosystem among them, and it functions as shared industry infrastructure rather than as any single vendor’s feature. The Charge Point Operator (CPO), through its platform, then performs the validation: checking the signature chain, the expiry, and the revocation status before the contactors close.

At no point in that sequence does the protocol ask who wrote the CPO’s software.

The four roles in a single ISO 15118 Plug and Charge session, and the point that none of them is defined by who owns the software. The vehicle manufacturer provisions the car at the factory with an OEM certificate proving the car is what it claims to be. The e-Mobility Service Provider issues or procures the contract certificate tied to the driver's mobility account, at sign-up and renewed before expiry, and that certificate is what turns a plug-in into an authorized, billable session. The root operator and PKI ecosystem anchor the trust chain continuously as shared industry infrastructure, such as Hubject's Plug and Charge Ecosystem in Europe. The Charge Point Operator platform validates the certificate at plug-in, checking signature chain, expiry date and revocation status before the contactors close. The outcome is a session that is authorized, identified and billable, from a check that is cryptographic and has no field for the commercial model of the backend performing it.
Four parties, four jobs, one cryptographic check. Not one of the roles is assigned by who wrote the software underneath it.

Where the Own-It-and-Lose-the-Network Belief Came From

The belief is not irrational. It was manufactured, quite innocently, by the way charging software was packaged for a decade.

Under the software-as-a-service model that shaped the market, roaming hub membership, Open Charge Point Interface (OCPI) connectivity, and Plug and Charge enablement arrived inside the platform subscription. The operator never signed a hub agreement, never held the PKI relationship in its own name, and never saw those capabilities as separate line items. When a capability only ever arrives through a subscription, it starts to look like a property of the subscription. Cancel the subscription and the reach disappears, which is precisely what an operator observes at renewal and precisely the wrong inference to draw from it.

What actually disappeared was the vendor’s contract. The operator’s eligibility was never in question. The hub membership sat with the platform provider, the certificates were provisioned under the provider’s credentials, and leaving meant re-papering agreements the operator had never held. That reads on the way out as a technical barrier and is in fact an exit cost, which is the same mechanism our companion analysis of what it costs to leave a charging platform examines from the commercial side. It rests on the same foundation as the question of why ownership was out of reach for most operators in the first place.

What ISO 15118 Actually Requires of Whoever Owns the Stack

Dismantling the myth does not make the work vanish. An operator that owns its core inherits a real bill of obligations, and it is worth itemizing before anything else.

The platform has to handle certificate installation and renewal on vehicles, keep trust stores and revocation lists current, and fail safely when a certificate is expired or withdrawn. It has to carry the ISO 15118 exchange over OCPP correctly, whether through OCPP 1.6 with extensions or natively in 2.0.1. It needs OCPI or Open InterCharge Protocol (OICP) connections to hubs or bilateral partners, plus the Charge Detail Record (CDR) and tariff plumbing that lets a roamed session settle; the mechanics of that layer are covered on our OCPI and OICP interoperability page. It has to pass conformance and interoperability testing, the kind CharIN convenes for the Combined Charging System ecosystem and that hubs require before onboarding. And where the platform reaches toward bidirectional charging, it inherits the additional surface of ISO 15118-20 and the capabilities an eMSP platform now has to carry.

That is a genuine engineering and operations commitment. An operator running eighty charge points with no in-house engineering function should rent. Ownership holds where the network is large enough, or the integration roadmap specific enough, that the capability pays for itself.

Layer What it has to do Where it lives on an owned platform What you procure externally
Vehicle-to-charge-point session (ISO 15118-2 / -20) Carry the high-level communication that authenticates the vehicle and negotiates the charging session Charge point firmware, with platform-side handling of the exchange Bought with the hardware; verified during charger selection
Contract certificate validation Check the signature chain, expiry, and revocation status before authorizing the session Owned platform logic Nothing
Certificate provisioning and lifecycle Install contract certificates on vehicles, renew before expiry, revoke on account closure, keep trust stores current Owned platform logic and operations Access to the root and PKI services the chain terminates in
Root of trust / Plug and Charge ecosystem Anchor the trust chain so parties that have never met can validate one another Not run in-house by anyone; shared industry infrastructure by design Membership of a trust ecosystem, such as Hubject’s Plug&Charge Ecosystem
Charger-to-backend transport (OCPP) Carry the ISO 15118 exchange between charge point and platform, natively in 2.0.1 or through 1.6 extensions Owned platform Nothing
Roaming connectivity (OCPI / OICP) Expose your points to other providers’ drivers and reach theirs; exchange tariffs, sessions, and CDRs Owned connector and data model Hub membership or bilateral partner agreements, signed in the operator’s own name
Settlement for roamed sessions Price, reconcile, and invoice sessions that started on somebody else’s contract Owned platform Nothing
Conformance and interoperability testing Prove the implementation behaves against real vehicles, chargers, and partners Owned test regime and release process Industry test programs and hub onboarding certification
Table 1. Ownership of a charging platform has never meant owning every layer beneath it. The trust and roaming layers are shared infrastructure, connected on the operator’s own credentials.

The layers you run yourself, and the layers you buy access to

Ownership of a charging platform has never meant owning every layer beneath it. Root certificate authorities, trust ecosystems, and roaming hubs are shared infrastructure by design, because trust that only one company can vouch for is not trust at all. An owned core connects to that infrastructure on the operator’s own credentials, in the operator’s own name. The engine layer and the network layer are complementary, which is exactly why hub operators have a commercial interest in more operators owning real platforms: each one joins the network in its own name instead of sitting as a sub-tenant behind somebody else’s membership.

Regulation Moved Interoperability From Roadmap Item to Delivery Date

The window in which interoperability could be treated as a roadmap item closed in Europe when the Alternative Fuels Infrastructure Regulation (AFIR), Regulation (EU) 2023/1804, began to apply. AFIR is a regulation rather than a directive, so it binds directly across member states without national transposition, and it writes its obligations to the operator of the recharging point. Public charge points have to accept ad hoc payment without a subscription. Static and dynamic data on those points have to reach national access points so that any service provider can surface them to drivers. Deadlines are fixed in the text, and national programs are layering their own requirements on top, as Portugal did when Decree-Law 93/2025 opened its national charging model to competition.

The standard itself is now inside that framework. Commission Delegated Regulation (EU) 2025/656 amended AFIR’s technical annex so that newly installed or upgraded publicly accessible charge points implement ISO 15118, with the 15118-20 obligation following from January 2027. What the amendment does not settle is how compliance should be demonstrated. CharIN said so directly in an April 2026 position paper: the conformity assessment pathway is undefined, conformance test cases for 15118-20 are still in development, and no certification scheme exists for AC chargers at all. The obligation carries a date. The route to satisfying it does not yet.

The consequence is structural. AFIR’s obligations land on the operator, and they stay there regardless of who supplies the software. If the capability that satisfies an obligation lives inside a product someone else controls, the operator carries the liability while somebody else carries the schedule. That asymmetry is the practical heart of the ownership question.

The same external relationships under two operating models, with only the signatory changing. In Model A the capabilities are bundled inside a subscription: trust ecosystem and PKI membership is held by the vendor with contract certificates provisioned under vendor credentials, roaming hub membership under OCPI or OICP is held by the vendor so network reach arrives as a feature of the subscription, and the operator sits inside that box as a sub-tenant behind somebody else's membership, so cancelling ends the vendor's contract rather than the operator's eligibility. AFIR obligations still land on the operator of the recharging point, so liability sits with the operator while the release queue that satisfies it sits with the vendor. In Model B an owned core connects to the same shared infrastructure: trust ecosystem and PKI membership signed in the operator's name with certificates provisioned under its own credentials, roaming hub or bilateral agreements signed in the operator's name so reach is portable if the software supplier changes, and an owned platform core handling certificate validation, OCPP transport, the roaming connector, and CDR and tariff settlement. AFIR obligations land on the operator and so does the delivery date, because the party carrying the regulatory liability also holds the release queue.
Same protocols, same counterparties, same obligations. The only thing that moves is the name on the contract, and with it the delivery date.

The Release Queue Is the Lock-In Nobody Prices

Here is where the interoperability argument turns. Every change an operator will need over the next two years is, underneath, a scheduling question: an OCPI version migration, a bidirectional pilot that pulls ISO 15118-20 forward, a new national reporting obligation, a hub in a market the network has just entered, a tariff structure the current data model cannot express.

On a shared multi-tenant platform, each of those ships when it reaches the top of a roadmap serving every tenant at once. That is rational product management and no criticism of any provider; a platform that reprioritized for every customer request would serve none of them well. It does, however, locate the decision right somewhere other than with the operator. The release queue is the constraint that never appears in the contract, never shows up in the per-charger fee, and quietly determines whether an operator can meet a regulatory date or open a market on its own timetable.

An owned core relocates that decision. The evidence is in delivery. For OpConnect, Codibly built an implementation of the IEEE 2030.5 Common Smart Inverter Profile (CSIP) covering both the United States requirements and the separate Australian CSIP AUS profile, and led the formal certification testing as a SunSpec Alliance certified test lab. One operator, two regulatory regimes, one stack. For IMP PAN, we built a scalable OCPP 1.6J server with vehicle-to-grid support running across Poland, Denmark, and the Netherlands. For an EV charging hardware manufacturer, we completed an OCPP 1.6 integration into an existing cloud platform inside a month. For Banyon Power, we built the managed charging platform the company owns outright, covering installer commissioning, the homeowner app, charging orchestration and the utility-facing dashboards, on a schedule set by its own commercial launch. None of those schedules were set by a vendor’s backlog.

Interoperability change What it touches Who sets the delivery date on a tenanted platform Who sets it on an owned core
OCPI version migration Roaming connector, tariff and CDR data model, partner conformance retesting The provider’s roadmap, sequenced across every tenant The operator, against its own partner commitments
ISO 15118-20 and bidirectional charging Charge point firmware, session handling, certificate profile, energy-transfer logic The provider, usually once demand across the tenant base justifies it The operator, aligned to its own vehicle-to-grid pilot schedule
New national reporting or access-point obligation Data export, static and dynamic point data, format and cadence The provider, prioritized by how many tenants the market affects The operator, which is the party the regulation names
New hub or bilateral partner in a new market Contracts, connector configuration, onboarding certification, settlement rules The provider, if the relationship sits under its membership The operator, signing in its own name
Table 2. None of these are protocol problems. All four are scheduling problems, and the schedule follows whoever holds the release queue.

Ownership therefore widens the interoperability surface, because the operator decides which protocols, which hubs, and which markets come next. That is the same logic behind our OCPI Accelerator: a pre-built, owned roaming core that removes the protocol work without handing anyone else the calendar. It also sits alongside the contractual question of what an escrow arrangement does and does not convey, because economic ownership and legal ownership are separate tests and an operator needs to pass both.

Owned, and Still on the Network

Standards do not care about balance sheets. A certificate chain validates or it does not, an OCPI session settles or it does not, and neither outcome consults the licensing model of the platform performing the work. The real variable in interoperability is scheduling: whose release queue the next integration sits in, and whether the operator who carries the regulatory liability also holds the delivery date.

Electric vehicles win the mass market on the day charging is easier than stopping for fuel, and Plug and Charge is the closest the industry has come to that. Building it on infrastructure you control, connected to the shared trust and roaming layers everyone depends on, is how an operator delivers that experience without renting it back every month. Codibly’s eMSP Engine and CPMS Engine exist for operators who have reached that point: a customizable core you own outright, with the roaming and Plug and Charge layers wired in from the start.

Own the Charging Software white paper promo - Codibly