Saying “our chargers support OCPP 2.0.1” is one of the most commonly made — and least verified — claims in the EV charging supply chain. A supplier can truthfully state that their hardware is “OCPP 2.0.1 ready” while shipping firmware that fails TLS 1.3 handshakes, drops smart charging profiles silently, or handles OTA updates at a 40% failure rate. By the time those failures surface in production — when the CSMS can’t push a firmware update to 200 units simultaneously, or when a charger rejects every charging limit command — you are already months into a deployment that now requires a hardware recall or a six-figure firmware remediation project.

OCPP 2.0.1 is not a checkbox. It is an implementation that either works correctly at every layer — security, device management, smart charging, transaction granularity — or it doesn’t. This guide gives CPO technical teams the framework to specify, verify, and operationalize OCPP 2.0.1 correctly: from supplier certification verification through CSMS selection and OCPI roaming onboarding, with a practical acceptance test checklist that catches the failures before they reach production.

TL;DR: OCPP 2.0.1 became an IEC international standard (IEC 63584) in 2024 and is now mandated by the US NEVI program (as of the 2023 Final Rule) and multiple EU member states for new commercial installations. The OCA’s full certification program — covering Core, Smart Charging, Advanced Security, ISO 15118, and Device Management profiles — opened in late 2023 and was updated in December 2025. Only 68 charger models worldwide held OCA OCPP 2.0 certification as of September 2025. Verification of supplier claims is not optional. OCPI 2.2.1 is the roaming standard to implement; Hubject’s intercharge network now connects 1 million+ charging points across 70+ countries.

---

Why OCPP 2.0.1 Is Non-Negotiable for CPOs in 2026

The transition from OCPP 1.6 to 2.0.1 is not an incremental upgrade. It is a breaking change — the two versions are not backward compatible — and it carries a weight of regulatory, commercial, and technical consequences that makes deferral increasingly costly.

The Regulatory Mandate: NEVI and EU Requirements

In the United States, the FHWA’s NEVI Standards and Requirements Final Rule (February 2023) explicitly references OCPP 2.0.1 as the standard for charger-to-network communication at federally funded stations. The same rule mandates OCPI 2.2.1 for network-to-network roaming by 2025, and ISO 15118-2 capability for Plug & Charge.

Any hardware deployed with federal NEVI funding — 80% federal cost share — must meet these specifications. Note: the NEVI program has seen significant administrative changes since January 2025, and CPOs should verify current program requirements directly with FHWA’s August 2025 Interim Final Guidance, but the underlying technical standards in the 2023 Final Rule remain the operative framework for hardware compliance.

In the European Union, OCPP 2.0.1 was published by CENELEC as a European standard in 2025, following its adoption as IEC 63584 by the International Electrotechnical Commission in 2024. Several EU member states are requiring OCPP 2.0.1 for new commercial installations from 2025 onward. California’s CALeVIP program required OCPP 2.0 certification for DC fast chargers receiving state incentive funding as of January 1, 2025.

What You Lose Without OCPP 2.0.1

OCPP 1.6 — still the most widely deployed version globally, running on more than 80% of OCPP-connected chargers in Europe as of late 2024 — does not support several capabilities that are becoming operational requirements for competitive CPO networks:

• ISO 15118 Plug & Charge (native): OCPP 1.6 requires a workaround DataTransfer wrapper to carry 15118 messages; 2.0.1 has native message support. The workaround is functional but fragile and not certifiable under OCA profiles.
• Advanced smart charging: OCPP 2.0.1 adds External and Local smart charging on top of 1.6’s Central approach, enabling more granular grid integration and demand response participation.
• Full OTA firmware management: 2.0.1 introduces structured firmware update flows with rollback capability, failure reporting, and component-level verification — not present in 1.6.
• TLS 1.3 mandatory security: OCPP 2.0.1 Security Profile 3 requires TLS 1.3. OCPP 1.6 security profiles use TLS 1.2, which has known vulnerabilities and is being deprecated across regulated industries.
• Per-period transaction data: OCPP 1.6 provides per-session data only. 2.0.1 delivers per-kWh and per-period granularity — essential for accurate billing at multi-tenant sites and for regulatory compliance under metering laws.
• V2G pathway: OCPP 2.1 (released January 2025), which adds native ISO 15118-20 and V2G support, is built on the 2.0.1 message architecture. Hardware that is not 2.0.1-capable cannot be upgraded to 2.1 via firmware.

The Cost of Vendor Lock-In from Non-OCPP Hardware

Proprietary hardware that does not implement OCPP creates a compounding cost problem. The charger can only communicate with the manufacturer’s own CSMS (or a CSMS that has built a proprietary adapter for that hardware). When the CPO wants to switch CSMS platforms — because pricing changes, because the platform doesn’t support roaming, because a better tool exists — they face the choice of replacing the hardware or paying the original vendor whatever they choose to charge. At scale, CSMS switching costs for non-OCPP networks regularly run into six figures before hardware replacement is factored in. This is not a theoretical risk; it is a documented failure mode for early-generation CPO networks built on proprietary hardware.

---

OCPP 2.0.1 vs. 1.6J: What Actually Changed

Understanding the technical scope of the change is important for two reasons: it determines what you need to specify in RFQs, and it identifies where implementation failures are most likely to occur.

Message Architecture

OCPP 1.6J defines approximately 25 core message types organized around basic operations: boot notification, authorize, start/stop transaction, heartbeat, meter values, diagnostics, and configuration. OCPP 2.0.1 expands this to over 100 distinct message types organized into functional blocks — security, device management, provisioning, authorization, transactions, metering, smart charging, ISO 15118, display messages, firmware management, and more. The OCA’s official “What Is New in OCPP 2.0.1” document identifies the key additions:

• Device model: A hierarchical model for representing charging station components (EVSE, connectors, controllers) with individual monitoring and configuration per component — not just per charging point as in 1.6
• Security profiles: Three defined security levels, with Profile 3 requiring TLS 1.3 and certificate-based mutual authentication
• ISO 15118 support: Full Plug & Charge message flows including certificate installation, contract validation, and authorization — native, not wrapped
• Smart charging: Three charging control sources (Central, Local, External) with priority-based conflict resolution
• Display messages: The CSMS can push messages to be displayed on the charger’s screen — important for user communication at unmanned sites

Security Architecture: TLS 1.3 and Certificate Management

OCPP 2.0.1’s Security Profile 3 mandates TLS 1.3 for the WebSocket connection between charger and CSMS, with certificate-based mutual authentication. This means both the charger and the CSMS must present valid certificates in the TLS handshake — not just server-side TLS as in conventional HTTPS. The certificates must be provisioned at the factory or during commissioning, managed throughout the charger’s life, and renewed before expiration without manual intervention at the charger.

This certificate lifecycle is the most common operational blind spot in OCPP 2.0.1 deployments. A charger with an expired certificate goes offline — completely — until the certificate is renewed. At scale, certificate expiration without automated monitoring and renewal creates the risk of synchronized mass-outage events across a network.

Transaction Data Granularity

OCPP 1.6 delivers a single meter reading at session start and session end. OCPP 2.0.1 supports sampled readings at configurable intervals throughout the session — per-kWh, per-period, per-EVSE, per-phase. This granularity is required for:

• MID-compliant metering in the EU (calibrated meter data per interval)
• Accurate multi-tenant billing (charge cost billed per kWh, not per session time)
• Demand charge analysis (identifying peak power draw per 15-minute interval)
• Battery health monitoring (charging curve data per session)

Feature	OCPP 1.6J	OCPP 2.0.1
Message types	~25 core types	100+ types across functional blocks
Transport	JSON over WebSocket (1.6J)	JSON over WebSocket
Security	TLS 1.2 optional (Security Profile)	TLS 1.3 mandatory (Profile 3)
Authentication	Basic Auth or password	Certificate-based mutual TLS
OTA firmware	Basic (no rollback, no verification)	Structured with rollback, status reporting
ISO 15118	Via DataTransfer workaround	Native message support
Smart charging	Central only (ChargingProfile)	Central, Local, and External
Transaction data	Session-level only	Per-kWh, per-period, per-phase
Device model	Flat (single charge point)	Hierarchical (EVSE, connector, component)
Backward compatible	N/A	No — breaking change from 1.6
IEC standard	Not standardized by IEC	IEC 63584 (2024)
V2G pathway	No	Via OCPP 2.1 upgrade (architecture compatible)

---

OCPP 2.0.1 Certification: How to Verify What Suppliers Actually Claim

As of September 2025, Blink Charging announced that its Series 7, 8, and 9 charger models had received OCA OCPP 2.0.1 certification — and noted at the time that only 68 charger models worldwide had achieved OCPP 2.0 certification. In a market with thousands of charger models commercially available globally, that is a very small number. The gap between “OCPP 2.0.1 certified” and “OCPP 2.0.1 ready” or “OCPP 2.0.1 compatible” is the gap between verified conformance and marketing language.

The OCA Certification Program

The Open Charge Alliance’s official OCPP certification program is the authoritative standard for conformance verification. The program is administered by five independent testing laboratories: DEKRA, DNV, Korea Smart Grid Association (KSGA), Korean Testing Certification Institute, and Korea Testing Laboratory. These labs test against defined certification profiles:

• Core (mandatory): Basic charging station functionality — boot, authorization, transactions, remote control, secure firmware updates, and Security Profile 2
• Advanced Security (optional but critical): TLS 1.3, certificate management, Security Profile 3
• Smart Charging (optional): ChargingProfile handling, SetChargingProfile, GetCompositeSchedule
• ISO 15118 Support (optional): Plug & Charge message flows, certificate installation and management
• Advanced Device Management (optional): Component monitoring, configuration management, event notifications
• Local Authorization & List Management (optional)
• Reservations, Advanced User Interface (optional)

In December 2025, the OCA updated the OCPP 2.0.1 certification program to simplify the profile structure while maintaining rigor. The Core profile now includes Security Profile 2 as mandatory. Each certified product receives a certificate that specifies exactly which profiles were tested and passed.

How to Verify a Certification Claim

1. Request the OCA certificate number. Every certified product receives a traceable certificate issued by one of the five approved labs. Ask the supplier for this number.
2. Verify on the OCA certificate verification tool. The OCA Trusted Certificate tool allows independent verification of certificates issued from summer 2024 onward. Cross-check the certificate number, the product name, the firmware version, and which profiles were certified.
3. Check which profiles are covered. A certificate that only covers Core does not confirm Smart Charging behavior or TLS 1.3 compliance. If smart charging or advanced security is in your requirements (and it should be for any commercial network), verify those specific profiles are certified.
4. Confirm the firmware version. Certification applies to a specific firmware version. A supplier who upgrades firmware without re-certifying may have a certified version that differs from what ships on production units. Require that the production firmware version matches the certified version, or that re-certification has been completed.
5. For volume orders, request pilot unit testing. Pre-production prototypes sometimes achieve certification; production units may have supply chain or manufacturing differences that affect software behavior. Include a contractual requirement for pilot batch testing before full order acceptance.

Red Flags in Supplier Claims

• “OCPP 2.0.1 ready” — “Ready” is not certified. Ready means the supplier intends to pursue certification, or that the hardware can theoretically support it pending firmware development.
• “OCPP 2.0.1 compatible” — Compatible means the hardware can connect to a 2.0.1 CSMS, but says nothing about which message types are correctly implemented.
• “Plans to certify by Q[X]” — OCA certification takes time, and suppliers routinely miss projected timelines. A plan to certify is not a certification.
• Certification of only 1.6 with “2.0.1 firmware available” — The 1.6 certificate is irrelevant to 2.0.1 conformance. These are separate certifications.
• Cannot provide a lab name or certificate number — Self-certification claims without independent lab testing are not equivalent to OCA program certification.

---

The OCPP 2.0.1 Acceptance Test Checklist

Certification verifies conformance to the specification in a controlled lab environment. Acceptance testing verifies that the production hardware and firmware function correctly in your deployment environment against your CSMS. These are different things. Certification is necessary but not sufficient. The following five tests should be completed on at least 5–10% of any delivery batch — and on every unit in pilot batches — before final acceptance.

Test 1: TLS 1.3 Handshake and Security Profile Verification

Objective: Confirm the charger enforces TLS 1.3 and rejects downgrade attacks.
Method: Using the OpenSSL command-line tool, attempt a TLS 1.2 connection to the charger’s WebSocket endpoint:

openssl s_client -connect [charger-ip]:9000 -tls1_2

Expected result: Connection should fail with a handshake error. If TLS 1.2 connects successfully, the charger is not enforcing TLS 1.3 and fails OCPP Security Profile 3 requirements.
Also verify: Certificate chain is valid, not expired, and the Common Name matches the charger’s identity. Check certificate expiration date — flag any certificate expiring within 90 days for immediate renewal planning.

Test 2: OTA Firmware Update with Failure Scenario

Objective: Confirm the charger can receive, apply, and verify a firmware update via the CSMS, and rolls back safely on failure.
Method:

1. Initiate a firmware update via the CSMS using the UpdateFirmware message (OCPP 2.0.1)
2. Observe the FirmwareStatusNotification message sequence: Downloading → Downloaded → Installing → Installed
3. Confirm the charger returns to operational state with the new firmware within 15 minutes
4. Optionally: Test with a deliberately malformed firmware package and confirm the charger reports InstallationFailed and reverts to previous firmware

Pass criteria: Update completes within 15 minutes; all status messages received in correct sequence; charger fully operational post-update.
Common failure mode: Charger reports Downloaded then goes silent — indicates insufficient flash memory or a bug in the installation routine.

Test 3: Smart Charging Profile Enforcement

Objective: Confirm the charger respects charging limits pushed from the CSMS.
Method:

1. With a vehicle actively charging at full power, push a SetChargingProfile message from the CSMS with a 5 kW power limit
2. Monitor the charger’s meter value reports to confirm power delivery drops to ≤ 5.5 kW within 30 seconds
3. Record the SetChargingProfile response — it should return Accepted
4. Test with a ClearChargingProfile to confirm power returns to maximum

Pass criteria: Power limit enforced within 30 seconds; response code Accepted; limit removed cleanly on ClearChargingProfile.
Common failure mode: Charger returns Accepted but does not actually limit power — a silent failure that would cause demand charge violations in production.

Test 4: ISO 15118 Plug & Charge (if required by deployment)

Objective: Confirm the charger supports ISO 15118-2 Plug & Charge authentication without user action.
Prerequisites: Charger must hold a valid V2G root certificate; test vehicle or hardware simulator must have a valid contract certificate issued by a compatible root CA (CharIN PKI or equivalent).

1. Connect the test vehicle to the charger without presenting an RFID card or using an app
2. Observe the TLS handshake on the Combined Charging System (CCS) communication line
3. Confirm the charger validates the vehicle’s contract certificate via OCSP against the V2G root CA
4. Confirm the charging session starts automatically on certificate validation

Pass criteria: Session starts within 30 seconds of plug-in with no user action required; CSMS logs show RequestStartTransaction with IdTokenType: eMAID.
If Plug & Charge is not in scope for your current deployment: Still verify the charger holds a valid V2G root certificate and that the certificate management flow via OCPP 2.0.1 InstallCertificate message works correctly.

Test 5: 30-Day Soak Test Before Bulk Acceptance

Objective: Surface intermittent failures — firmware instability, memory leaks, connectivity issues, certificate expiration edge cases — that only appear under sustained operational conditions.
Method: Deploy 3–5 units (representing at least 2–3% of the order quantity) in a live or simulated live environment for 30 days before accepting bulk delivery. Track:

• Session count and success rate (target: ≥98% successful sessions)
• Connectivity uptime (target: ≥98% online time)
• Number of unexpected reboots or firmware crashes (target: 0 critical crashes)
• Firmware version stability (target: firmware version unchanged unless deliberately updated)
• CSMS communication errors (target: all message exchanges within specification)

The 30-day soak test is the single most powerful quality gate available to a CPO before bulk delivery acceptance. It catches systemic manufacturing defects, firmware bugs that only surface under sustained load, and CSMS integration issues that didn’t appear in lab testing. Budget the time — the cost of detecting a failure on 5 units is orders of magnitude lower than discovering it across 500 deployed units.

---

CSMS Selection: What the Feature Checklist Misses

Every CSMS vendor publishes a feature matrix. The matrices all look complete. The real questions — the ones that determine whether a CSMS will still be the right tool in three years, and whether switching costs you a fortune if it isn’t — are not on any vendor feature list.

The Hidden Cost Structure of CSMS Platforms

CSMS pricing models are not standardized, and the per-port monthly fee is only one component of the total cost of ownership. Before signing any contract, model the full cost across all billing dimensions:

• Per-port monthly fee: Typically $6–$15/port/month for mid-market platforms. At 500 ports, that is $3,000–$7,500/month in platform fees alone before any other costs.
• Charger model onboarding fees: Many CSMS platforms charge a one-time fee per charger model for integration and testing — ranges from $500 to $5,000 per model. If you procure hardware from multiple manufacturers, these fees stack.
• API call volume charges: Platforms that bill per API call can generate unexpected overages at high-utilization sites where session data, meter values, and status notifications generate frequent CSMS events.
• OCPI roaming integration fees: Setting up OCPI connections to Hubject, Gireve, or other hubs may carry setup fees — verify whether this is included in the base subscription or billed separately.
• Data export fees: Some platforms charge for exporting transaction data, or limit data export to a rolling window (e.g., 12 months). This creates a de facto data hostage situation at contract renewal.

Data Portability and Vendor Exit Risk

Before signing with any CSMS, answer three questions contractually:

1. Can you export 100% of historical transaction data in a standard format (CSV or JSON) at any time, without additional fees?
2. What happens to your OCPI roaming agreements if you switch CSMS? Roaming agreements are typically between the CPO and the roaming hub — not the CSMS — but verify whether your CSMS has structured the agreements in a way that routes the relationship through them.
3. Is there a minimum contract term, and what are the termination costs? A 3-year contract with a per-port penalty for early exit can make switching effectively impossible even if the platform fails to deliver.

Integration Depth with Adjacent Systems

A CSMS that works perfectly as a standalone platform but cannot integrate with adjacent systems creates operational silos that cost time and accuracy. Priority integration requirements by CPO type:

• Fleet depot CPOs: Fleet management system integration (vehicle SoC, departure scheduling, session attribution per vehicle ID)
• Public network CPOs: Payment processor integration (Stripe, Adyen, direct payment terminal); roaming hub integration (Hubject OCPI/OICP, Gireve OCPI)
• Multi-site commercial CPOs: ERP integration for billing and revenue reconciliation; energy management system (EMS) integration for demand response
• All CPOs: Open REST API with documented endpoints for custom integrations; webhook support for real-time event notification

CSMS Feature Requirements by Network Scale

Network Scale	Minimum Required CSMS Features	Recommended Additional Features
1–50 sites (startup / regional CPO)	Device monitoring, remote reset, basic billing, uptime reporting, OCPP 2.0.1 support	Simple load management, driver app, basic analytics
50–500 sites (growth stage CPO)	OCPI 2.2.1 roaming (Hubject/Gireve), smart load management, site-level revenue analytics, open API	Dynamic pricing, multi-currency billing, predictive maintenance alerts
500+ sites (enterprise CPO)	All above + white-label driver app, multi-tenant support, fleet management integration, enterprise SLA (>99.9% CSMS uptime)	AI-powered dynamic pricing, demand response program integration, custom reporting dashboards

Vendor Stability Questions

CSMS platforms are software companies, and the EV charging software market has seen significant consolidation and failure. Before committing to a platform, investigate:

• How many CPO customers does the platform serve, and can they provide references?
• Is the company venture-backed, profitable, or publicly traded? What is their runway?
• Have they had any significant platform outages in the past 24 months, and how were they communicated?
• What is their published OCPP 2.0.1 roadmap, and which features are currently in production versus “coming soon”?

---

OCPI and Roaming: Making Your Network Discoverable

OCPP governs the communication between a charger and your CSMS. OCPI governs the communication between your CSMS and other operators’ systems — enabling a driver with an eMSP account on another network to charge at your station and be billed correctly. These are completely separate protocols with separate implementation requirements. Both are necessary for a CPO operating public charging infrastructure.

What OCPI Does (And What It Doesn’t)

OCPI 2.2.1 — maintained by the EVRoaming Foundation — handles the information exchange between a CPO and eMSPs or roaming hubs: location data, tariffs, session data, CDRs (charge detail records), and token authorization. It does not control the charger itself (that is OCPP), and it does not handle payment directly (that is settled between the CPO and eMSP separately). Think of OCPI as the interface that makes your charging locations visible and accessible to drivers who have accounts on partner networks.

The Major Roaming Hubs

Hubject (intercharge): The largest global roaming network, now connecting over 1 million charging points across 70+ countries and 2,750+ B2B partners. Hubject historically used its proprietary OICP protocol but announced in September 2025 that it joined the EVRoaming Foundation and is adding native OCPI support, with general availability reached in late 2025. For CPOs targeting North American and European markets, Hubject connectivity is essential.

Gireve: Europe-focused platform founded by EDF, Renault, CNR, and Caisse des Dépôts. As of February 2026, Gireve connects 695,000 charging points across Europe. Already OCPI 2.2.1 compliant. For CPOs operating in France and broader Europe, Gireve is a primary hub.

e-clearing.net: Germany-based hub with strong Central European coverage. Implements OCPI and OCHP.

For CPOs in North America, Hubject’s intercharge network via OCPI is the primary roaming integration priority. For European operations, both Hubject and Gireve connections are expected by eMSP partners.

OCPI Onboarding Process and Timeline

With a pre-built, certified OCPI stack in your CSMS, hub onboarding typically takes four to eight weeks from registration to first live roaming session — covering API endpoint configuration, test session completion, and commercial agreement signing. Building an OCPI stack from scratch adds nine to twelve months. This is why OCPI capability in the CSMS must be a baseline requirement, not an afterthought.

The practical onboarding sequence:

1. Confirm your CSMS supports OCPI 2.2.1 in production (not just “planned”)
2. Register as a CPO on the roaming hub’s partner portal
3. Complete the hub’s technical onboarding: API key exchange, location data push, test session
4. Sign the commercial roaming agreement (typically includes terms for CDR settlement and dispute resolution)
5. Enable your locations in the hub’s discovery layer and verify they appear in partner apps

Roaming economics: Hub fees are typically structured as a small percentage of the transaction value or a per-kWh fee — industry estimates suggest a few cents per kWh or low single-digit percentage of session revenue. At highway corridor sites where non-local drivers represent 40–60% of sessions, roaming revenue from network partners can represent a material share of total site revenue. For depot and destination sites with primarily local or fleet users, roaming contribution is smaller but still valuable for network visibility.

---

ISO 15118 and Plug & Charge: Implementation Roadmap

ISO 15118 defines the communication interface between an EV and a charging station — separate from OCPP (which governs charger-to-CSMS) and OCPI (which governs CSMS-to-CSMS). Its most commercially significant feature is Plug & Charge: a driver plugs in the vehicle, the vehicle and charger exchange certificates automatically, the session is authorized and billed without the driver presenting any card, app, or credential. The driver experience is identical to plugging in a laptop.

ISO 15118-2 vs. ISO 15118-20

• ISO 15118-2: The current deployed standard. Covers AC and DC charging, Plug & Charge authentication via PKI certificates, and basic smart charging via the EIM (External Identification Means) / PnC flow. This is what NEVI mandates must be software-supported on new US public stations.
• ISO 15118-20: The emerging standard, required for V2G (bidirectional charging). Adds support for AC BPT (Bidirectional Power Transfer), DC BPT, wireless power transfer, and advanced scheduling. OCPP 2.1 (January 2025) adds native support for 15118-20 communication.

The Certificate Management Challenge at Scale

Plug & Charge depends on a Public Key Infrastructure (PKI) where each vehicle holds a contract certificate issued by its eMSP and rooted in a V2G root CA managed by a trust anchor consortium (CharIN manages the primary V2G root CA infrastructure). Each charger must hold the root certificates it uses to validate vehicle contract certificates, and those root certificates must be kept current as they are issued, renewed, or revoked.

At scale — 500 chargers across 50 sites — this certificate management is a continuous operational function, not a one-time commissioning task. OCPP 2.0.1 provides the message infrastructure for the CSMS to push certificate updates to chargers via InstallCertificate messages. A CSMS that does not automate this process, or that does not alert when charger certificates approach expiration, will generate Plug & Charge failures at unpredictable times in production.

Rollout Roadmap

• 2026: Specify ISO 15118-2 hardware capability in all new DC fast charger RFQs. Require OCPP 2.0.1 ISO 15118 profile certification from OCA (available since late 2023). Confirm hardware capability for ISO 15118-20 (even if not currently activating V2G).
• 2026–2027: Complete CSMS integration with CharIN PKI or a compatible V2G Root CA. Test Plug & Charge with certified vehicle models (currently a limited set, expanding rapidly as automakers deploy 15118-2 support).
• 2027–2028: Enable Plug & Charge as primary authentication method for premium network positions. Communicate Plug & Charge availability to eMSP roaming partners and direct customers.

---

Cybersecurity for EV Charging Networks

EV charging infrastructure is classified as critical infrastructure in both the US and EU regulatory frameworks. In November 2024, a bad actor exposed 116,000 records of sensitive information — names, locations, payment data, VINs, vehicle make and model — leaked from multiple CPOs. The breach was traced to a white-labeled EV charging app from a single vendor. The incident illustrates how a CPO’s security posture is only as strong as the weakest component in its technology stack.

The Attack Surface

An EV charging network has multiple distinct attack surfaces:

• Charger endpoints: Each charger is a networked device with firmware, an operating system, and an IP connection. A vulnerability in firmware can allow remote code execution, enabling manipulation of charging sessions or power delivery.
• OCPP communication channel: Unencrypted or poorly implemented OCPP channels allow man-in-the-middle attacks that can intercept session data or inject false commands.
• CSMS platform: The CSMS is the central control point for the entire network — a compromised CSMS can simultaneously affect every charger it manages.
• Driver data: Payment credentials, location history, RFID/eMAID identifiers, and vehicle data are all collected during charging sessions and represent valuable targets for data theft.
• Grid interface: At sites with large aggregate charging loads, coordinated manipulation of charging behavior could in principle create grid instability — this is the concern that has attracted government attention to EV charging cybersecurity as critical infrastructure.

IEC 62443: The Applicable Standard

IEC 62443 is the international standard for cybersecurity of industrial automation and control systems — and it applies to EV charging infrastructure as a connected control system. The standard is organized into security levels (SL 1 through SL 4), with SL 2 being the typical minimum for commercial EV charging deployments. The EU is incorporating IEC 62443 requirements into procurement specifications for public charging infrastructure, and it is becoming a procurement requirement in regulated markets.

The NEVI program includes cybersecurity strategy requirements in its state deployment plans — the August 2025 Interim Final Guidance maintains the requirement for states to describe “physical and cybersecurity strategies” in their plans. The Joint Office of Energy and Transportation maintains active cybersecurity guidance for EV charging infrastructure, coordinating with NIST and CISA on threat analysis and mitigation frameworks.

Minimum Security Controls for CPOs

• TLS 1.3 for all OCPP communication: Enforce Security Profile 3 on all OCPP 2.0.1 chargers. Do not accept TLS 1.2 fallback in production.
• Automated OTA firmware updates: Patch firmware vulnerabilities promptly across the network. A charger that cannot receive OTA updates in the field is a charger that cannot be patched when vulnerabilities are discovered.
• Network segmentation: Chargers should be on a dedicated network segment separated from business-critical systems (POS, ERP, corporate LAN). A compromised charger should not provide a pathway to the financial network.
• Certificate lifecycle monitoring: Alert when any charger certificate is within 90 days of expiration. Automate renewal where the PKI infrastructure supports it.
• Vendor vulnerability disclosure policy: Before purchasing any charger or CSMS, ask the supplier: “What is your vulnerability disclosure process? Have you had any reported security incidents in the last 24 months? How were they communicated to customers?” A supplier with no disclosure process has no way to notify you when they discover a vulnerability in production equipment.

Security Questions for Supplier Evaluation

Question	Acceptable Answer	Red Flag Answer
What TLS version does the OCPP connection use?	TLS 1.3, Security Profile 3	“TLS 1.2 or higher”
How are firmware updates delivered?	OTA via OCPP UpdateFirmware, signed packages with verification	“USB or manual on-site” / “via our proprietary tool”
Do you have a CVE / vulnerability disclosure process?	Yes, with public or customer-facing disclosure timeline	“We handle security internally” / “We haven’t had incidents”
Is your CSMS / charger firmware IEC 62443 certified or assessed?	Yes, with certificate or third-party assessment report	“We follow the principles” / “We plan to pursue it”
How is customer data isolated and protected?	Data encrypted at rest and in transit; access controls; audit logging	Vague reference to “industry best practices” without specifics

---

Common OCPP 2.0.1 Implementation Failures and How to Avoid Them

Most OCPP 2.0.1 deployment failures cluster around four specific issues. Knowing them in advance allows a CPO to test for them explicitly before bulk acceptance.

Failure 1: TLS 1.3 Enforcement Not Working

Symptom: Charger connects intermittently, or CSMS logs show TLS version mismatch errors. In some cases, the charger silently falls back to TLS 1.2.
Root cause: Charger firmware implements the TLS library but does not correctly configure the minimum version enforcement, allowing downgrade negotiation.
Prevention: Run the TLS 1.2 connection test from the acceptance checklist before bulk delivery. This takes under five minutes per unit and catches this failure definitively.

Failure 2: OTA Update Failure at Scale

Symptom: OTA firmware updates succeed on 10 test units but fail on 20–40% of production units.
Root cause: Insufficient flash memory on production hardware variants; timeout settings that work on fast-connected lab units but fail on units with slower cellular connections; or a firmware package verification check that only works correctly with specific hardware revisions.
Prevention: Test OTA on pilot units with simulated poor network conditions (throttled connectivity). Require the supplier to provide the OTA failure rate from their own production fleet data — not just lab test results.

Failure 3: Smart Charging Profile Silent Rejection

Symptom: CSMS sends SetChargingProfile, receives Accepted response, but the charger does not reduce power delivery.
Root cause: The charger correctly processes the message acknowledgment but does not implement the power limit in the charging hardware — a bug in the firmware layer between the OCPP stack and the power management controller.
Prevention: The smart charging acceptance test above is designed to catch this exact failure. Do not accept “Accepted” response as confirmation of compliance — verify actual power delivery change.

Failure 4: Certificate Expiration Outage

Symptom: Chargers in a specific cohort (same manufacture date) go offline simultaneously approximately 12 or 24 months after deployment.
Root cause: Factory-provisioned certificates were issued with 1–2 year validity; no automated renewal process was implemented; no monitoring alerted when expiration approached.
Prevention: During commissioning, record the expiration date of every certificate on every deployed unit. Configure CSMS alerts for certificates expiring within 90 days. Implement automated renewal for certificates managed via OCPP InstallCertificate / GetInstalledCertificateIds messages before deploying at scale.

---

OCPP 2.0.1 & CSMS Implementation Checklist

Phase 1: Specification

• ☐ Confirm OCPP 2.0.1 (not “ready” or “compatible”) as RFQ requirement
• ☐ Specify required OCA certification profiles: Core + Advanced Security minimum; Smart Charging and ISO 15118 if applicable
• ☐ Confirm OCPI 2.2.1 support in CSMS (production, not roadmap)
• ☐ Define minimum security requirements: TLS 1.3, IEC 62443 assessment, CVE disclosure process

Phase 2: Supplier Verification

• ☐ Request OCA certificate number and verify on OCA Trusted Certificate tool
• ☐ Confirm which profiles are certified (Core only vs. full profile set)
• ☐ Verify production firmware version matches certified version
• ☐ Request reference contacts at 3+ deployed CPO customers
• ☐ Ask security questions from the table above; flag any red flag answers

Phase 3: Pilot Acceptance Testing

• ☐ Test 1: TLS 1.3 handshake enforcement (OpenSSL TLS 1.2 connection attempt)
• ☐ Test 2: OTA firmware update end-to-end with rollback verification
• ☐ Test 3: Smart charging profile enforcement (measure actual power delivery change)
• ☐ Test 4: ISO 15118 Plug & Charge (if required by deployment profile)
• ☐ Test 5: 30-day soak on pilot units — document uptime, session success rate, firmware stability

Phase 4: CSMS Selection

• ☐ Model full CSMS cost: per-port fee + model onboarding + API overages + roaming integration + data export
• ☐ Confirm contractual data portability: full export of transaction data at any time, no fees
• ☐ Verify open API with documentation and sandbox access
• ☐ Confirm OCPI 2.2.1 in production with Hubject and Gireve references
• ☐ Assess vendor stability: customer count, funding status, security incident history

Phase 5: OCPI Roaming Onboarding

• ☐ Register as CPO on Hubject intercharge (primary for US/global)
• ☐ Register on Gireve if operating in Europe
• ☐ Complete technical API onboarding: location push, test session, CDR verification
• ☐ Sign commercial roaming agreement and verify settlement process
• ☐ Confirm your locations appear in partner network apps (Plugsurfing, IONITY app, etc.)

Phase 6: Security Hardening

• ☐ Enforce TLS 1.3 on all OCPP connections — no fallback to 1.2
• ☐ Segment charger network from business LAN
• ☐ Document all certificate expiration dates; configure 90-day alert in CSMS
• ☐ Establish OTA firmware update cadence and test update delivery at scale
• ☐ Document security incident response process

Phase 7: Go-Live Verification

• ☐ Complete end-to-end test: plug-in → authorization → session → CSMS record → billing → CDR to roaming hub
• ☐ Confirm CSMS uptime SLA and escalation process for CSMS outages
• ☐ Verify fallback authorization (local whitelist) functions when CSMS connection is interrupted
• ☐ Confirm monitoring alerts are live: charger offline, session failures, certificate expiration

---

Frequently Asked Questions About OCPP 2.0.1 and CSMS

What is the difference between OCPP 1.6 and OCPP 2.0.1?

OCPP 2.0.1 is a breaking change from 1.6 — the two versions are not backward compatible. OCPP 2.0.1 introduces approximately 100+ message types (versus ~25 in 1.6), mandatory TLS 1.3 security, native ISO 15118 Plug & Charge support, structured OTA firmware management with rollback, per-period transaction data granularity, and a hierarchical device model. It was adopted as IEC international standard IEC 63584 in 2024.

Is OCPP 2.0.1 backward compatible with OCPP 1.6?

No. OCPP 2.0.1 and 1.6 are not compatible. A charger running OCPP 2.0.1 cannot communicate natively with an OCPP 1.6-only CSMS, and vice versa. Many CSMS platforms support both versions simultaneously — running a dual-version platform — which allows mixed-version fleets to be managed from a single interface. When selecting a CSMS, confirm whether dual-version support is in production or on the roadmap.

How do I verify a supplier’s OCPP 2.0.1 certification?

Request the OCA certificate number from the supplier and verify it using the OCA Trusted Certificate tool at openchargealliance.org. Certificates issued from summer 2024 onward can be independently verified. Also confirm which certification profiles are covered — Core-only certification does not confirm Smart Charging or Advanced Security compliance.

What is the difference between OCPP and OCPI?

OCPP (Open Charge Point Protocol) governs communication between a charging station and the Charging Station Management System (CSMS) — it is the protocol that lets your CSMS monitor, control, and collect session data from individual chargers. OCPI (Open Charge Point Interface) governs communication between your CSMS and other operators’ systems — it enables roaming, where a driver from another network’s customer base can charge at your station and be billed through their home network.

How long does OCPI roaming onboarding take?

With a CSMS that already has a production-ready OCPI 2.2.1 implementation, onboarding to a roaming hub like Hubject or Gireve typically takes four to eight weeks from registration to the first live roaming session. The timeline covers API configuration, test session completion, and commercial agreement signing. Building an OCPI stack from scratch adds nine to twelve months.

What cybersecurity requirements apply to EV charging networks?

In the US, NEVI-funded stations must include cybersecurity strategies in state deployment plans, with guidance coordinated by the Joint Office of Energy and Transportation in alignment with NIST frameworks. In the EU, the NIS2 Directive applies to EV charging networks as critical infrastructure, and IEC 62443 is the applicable technical standard for connected charging system security. At minimum, all OCPP 2.0.1 deployments should enforce TLS 1.3, implement network segmentation, manage certificate lifecycles, and deploy OTA firmware update capability.

What should I do if my supplier claims “OCPP 2.0.1 ready” but cannot provide a certificate number?

“OCPP 2.0.1 ready” without an OCA certificate means the hardware has not been independently tested and verified against the specification. The supplier is asserting compatibility, not conformance. Do not accept this as sufficient for commercial deployment. Either require the supplier to complete OCA certification before delivery acceptance, or budget for extended acceptance testing — the full five-test checklist — to manually verify the behaviors that certification would have confirmed.

---

Key Takeaways

• OCPP 2.0.1 is now an IEC international standard (IEC 63584, 2024), mandated by US NEVI (2023 Final Rule), required by California CALeVIP for DCFCs from January 2025, and mandated by EU member states for new commercial installations. For any CPO deploying in 2026, OCPP 2.0.1 is not optional.
• “OCPP 2.0.1 ready” and “OCPP 2.0.1 certified” are not the same thing. As of September 2025, only 68 charger models globally held OCA 2.0 certification. Verify every claim using the OCA Trusted Certificate tool.
• The OCA certification program’s full profile set — including Smart Charging, Advanced Security (TLS 1.3), ISO 15118, and Advanced Device Management — has been available since late 2023, updated in December 2025. Require the specific profiles relevant to your deployment in supplier specifications.
• TLS 1.3 enforcement failure, OTA update failure at scale, smart charging profile silent rejection, and certificate expiration outages are the four most common OCPP 2.0.1 deployment failures. The five-test acceptance checklist in this article addresses all four.
• CSMS total cost of ownership is determined by per-port fees, model onboarding fees, API volume charges, and roaming integration costs — not just the headline per-port price. Model the full cost before signing.
• OCPI 2.2.1 is the roaming standard to implement. Hubject now supports OCPI in addition to OICP, connecting 1 million+ charging points globally. With a production-ready OCPI stack in your CSMS, hub onboarding takes four to eight weeks.
• The November 2024 data breach affecting 116,000 CPO customer records illustrates that cybersecurity is an operational requirement, not a compliance checkbox. TLS 1.3, network segmentation, certificate monitoring, and OTA patch delivery are the minimum baseline.

JointCharging’s DC fast chargers for USA and Canada and AC EV chargers for North America are designed with OCPP 2.0.1 compatibility for deployment in NEVI-eligible and commercial CPO networks. Contact our technical team to discuss OCPP certification status and CSMS integration support for your specific deployment.

Protocol specifications, certification requirements, and regulatory mandates referenced in this article are subject to change. Verify current NEVI program requirements with FHWA’s most recent guidance, and confirm OCPP certification status for specific hardware via the OCA Trusted Certificate tool. Last reviewed: May 2026.