The promise of Plug & Charge (coming soon) is simple: plug in, charge starts, billing happens, no card or app interaction. The reality behind that simple experience is one of the most complex public-key infrastructure (PKI) deployments in the consumer infrastructure space.
This article explains the certificate world of EV charging: the certificates involved, who issues what, how the PKI is structured, and the operational realities that make this harder than it sounds.
The cast of certificates
A Plug & Charge session involves several certificates.
OEM Provisioning Certificate
Installed on the vehicle at the factory by the OEM. Identifies the vehicle as a genuine vehicle of that brand.
Used to bootstrap trust — when the vehicle later wants a contract certificate installed, the OEM’s provisioning certificate proves the vehicle is legitimate. This is part of the broader mutual-authentication model introduced in ISO 15118 (coming soon).
Long-lived (often 10+ years).
Contract Certificate
Represents the user’s charging contract with their eMSP. Installed on the vehicle after a contract is established.
Multiple contract certificates can coexist on a vehicle — one per eMSP relationship.
Used during Plug & Charge — the vehicle presents this to the charger to identify the user.
Typically valid 1-3 years before renewal needed.
EVSE Certificate
Each charger has its own certificate. Identifies the charger to vehicles and back-ends.
Used in mutual authentication — the vehicle verifies the charger is legitimate before sharing its contract certificate.
Typically valid 1-3 years.
CPS / V2G Root Certificate Authority
The trust anchors. Specific root CAs that the EV charging ecosystem trusts.
Examples:
- Hubject’s V2G Root (widely used in Europe).
- Various national or regional V2G roots.
- OEM-operated roots for OEM-specific PnC implementations.
A certificate is trusted if it chains back to a recognized root.
Intermediate CAs
Between the root and the end-entity certificates. Issued by the root, used to issue contract or EVSE certificates.
Provides flexibility — the eMSP doesn’t directly hold the root key; they have an intermediate.
The certificate chain in action
When a vehicle presents a contract certificate to a charger, the charger validates:
- Does the contract certificate’s signature verify against the issuer’s public key?
- Does the issuer’s certificate chain back through intermediates to a trusted root?
- Are all certificates in the chain valid (not expired, not revoked)?
- Is the contract certificate’s EMAID (eMobility Account ID) consistent with the issuer?
Only if all pass does the charger consider the certificate trustworthy.
flowchart TD
A[Contract Cert] --> B[Intermediate CA]
B --> C[V2G Root]
C --> D{Root trusted<br/>by charger?}
D -->|Yes| E[Check expiry<br/>and revocation]
D -->|No| F[PnC fails<br/>fallback auth]
E -->|Valid| G[Authorize session]
E -->|Invalid| F
style G fill:#0c590c,stroke:#0c590c,color:#fff
style F fill:#7a1f1f,stroke:#7a1f1f,color:#fffThe chain validation is the same as any PKI — TLS certificates, code signing certificates, etc. The specifics for V2G PKI are about which roots are trusted and how the EMAID is encoded in the certificate.
Who runs the PKI?
The EV charging PKI is not centrally operated by one entity globally. Several PKIs coexist, with varying trust between them.
Hubject’s V2G Root (Europe)
One of the larger and oldest PKIs in EV charging. Operated by Hubject. Many European charging networks trust this root. Many eMSPs issue contracts under this root (often via intermediate CAs).
V2G Root operated by various entities
Other operators run V2G roots — some national (one per country), some operator-specific, some shared.
OEM PKIs
Some OEMs operate their own roots specifically for their vehicles. The OEM provisioning certificates chain through these.
Cross-trust
A given charger may trust multiple roots. A given vehicle may have certificates from multiple roots. Cross-trust agreements between PKI operators determine whether a vehicle’s contract from PKI A works on a charger that trusts PKI B.
This is the source of “PnC works on some networks but not others” — the certificate roots don’t always overlap cleanly.
Provisioning a contract certificate
The process by which a user gets a contract certificate onto their vehicle:
- User signs up with an eMSP. Provides identification, payment method, account info.
- eMSP creates a contract in its back-end.
- eMSP requests a contract certificate from its CA (or issues one directly if it operates its own intermediate).
- Certificate is installed on the vehicle. Several mechanisms:
- At an enabled charger: during the next session, the vehicle and charger negotiate an install via ISO 15118 contract management messages. The certificate flows from the eMSP through OCPI to the CPO to OCPP to the charger to the vehicle.
- Via the vehicle’s own connected services: some OEMs install certificates OTA without requiring a physical charger interaction.
- At the OEM factory: less common; provisioned at vehicle delivery if the eMSP relationship was set up that early.
The first mechanism is most common. The user signs up online, then their next visit to a PnC-capable charger triggers the install automatically.
Renewal
Contract certificates expire. Renewal is usually transparent to the user.
When the eMSP detects an expiring certificate (typically 30-90 days before expiration), it triggers a renewal:
- A new certificate is issued by the CA.
- The new certificate is pushed to the vehicle (similar mechanisms to initial install).
- The old certificate is replaced or remains alongside until expiration.
If renewal fails (vehicle didn’t reach a PnC-capable charger during the renewal window, network issues, etc.), the certificate eventually expires and PnC stops working. Fallback to other authentication kicks in.
Revocation
Sometimes a certificate needs to be revoked — user cancels their contract, vehicle is stolen, certificate compromised.
Revocation mechanisms in EV charging PKI:
CRL (Certificate Revocation List). The CA publishes a list of revoked certificate serial numbers. Chargers periodically download and cache this list.
OCSP (Online Certificate Status Protocol). The charger queries the CA in real time for the certificate’s status.
Out-of-band signals. The eMSP can mark a Token as Invalid in the OCPI Tokens module (coming soon), which causes the CPO to reject sessions even if the certificate would otherwise validate.
In practice, the EV charging PKI relies more on out-of-band signaling than on traditional CRL/OCSP. Chargers don’t always have reliable internet, and CRL downloads are bandwidth-heavy. The OCPI Token validation flow gives a real-time backstop.
The cross-network problem
A vehicle has a contract certificate from eMSP A, issued under PKI X. The user drives to a charger operated by CPO B, which only trusts PKI Y.
What happens:
- The vehicle presents its certificate.
- The charger checks — doesn’t recognize the root.
- PnC fails.
- Fallback to other authentication (if available).
This is a real coverage gap. Solving it requires either:
- The vehicle holds multiple contract certificates under different roots. Some EVs support 4-8 contract slots; the right certificate is presented based on the charger’s trust.
- Cross-trust between PKIs. PKI X and PKI Y agree to trust each other’s certificates. Some cross-trust exists; not universal.
- Bridge eMSPs that have relationships across PKIs.
- Roaming via OCPI at the back-end — the eMSP authorizes the user even though the PKI didn’t match. Slower but works.
The cross-network problem is one of the bigger operational challenges in PnC’s mainstream rollout, and the certificate handling differs between the two spec generations covered in ISO 15118-2 vs ISO 15118-20 (coming soon).
Common operational issues
A list of PKI-related problems that come up in PnC deployments.
Certificate expired. Most common cause of “PnC suddenly stopped working.” Renewal didn’t happen in time.
Trust root mismatch. Vehicle’s contract is under PKI X; charger only trusts PKI Y. PnC fails.
Vehicle’s OEM provisioning certificate untrusted. The charger requires that the vehicle prove genuineness via its OEM cert; the charger doesn’t trust the OEM’s root. Edge case but happens.
Certificate revoked. User canceled contract; vehicle’s certificate is invalidated.
Vehicle’s HSM (Hardware Security Module) failure. Vehicle can’t sign challenges; PnC fails. Rare but happens.
Charger HSM failure. Same on the other side.
Time skew. Vehicle or charger clock is wrong; certificate validity check fails.
Slow OCSP. Charger checks OCSP, OCSP server is slow, session start times out.
Operational best practices
For PKI operators:
Plan for long-tail certificate lifecycle. Provisioning, renewal, revocation — all need clean operational flows.
Cross-trust agreements. Negotiate with other PKI operators to maximize coverage for your users.
HSM-protected keys. Don’t let signing keys touch general-purpose servers.
Audit everything. Certificate issuance is a security-critical operation; full audit trail.
Revocation responsiveness. Be able to revoke quickly when needed.
For charging network operators:
Trust multiple roots. The more roots you trust, the broader your PnC coverage.
Robust revocation checking. Don’t fail open on OCSP timeout; have a defensible policy.
Clear fallback. When PnC fails, the user experience shouldn’t be a black hole — fall back to RFID/app gracefully.
Observability. Track PnC success rate per partner, per PKI. Spot certificate problems early.
The honest summary
The PKI behind Plug & Charge is more complex than most observers realize. Multiple roots, intermediate CAs, contract certificates, OEM certificates, revocation infrastructure — all coordinating to deliver the simple “plug in and charge” user experience. The complexity is part of why PnC adoption has been slower than the spec writers hoped. As cross-trust matures, as more vehicles support multiple contract certificates, and as operational practices solidify, PnC’s coverage and reliability will improve. Understanding the certificate world is essential for anyone building PnC infrastructure or operating EV charging at scale.