Before You Sign: OCPP Explained for Procurement and Engineering
OCPP (the Open Charge Point Protocol) is the open messaging standard that lets a charge point talk to a central management system, regardless of who built either one. Three production versions matter today: 1.6, 2.0.1 and 2.1. Before you sign a contract, demand the vendor’s explicit version support, a Vendor Declaration of Conformance or OCA certification, and a written list of which functional blocks are actually switched on.
TL;DR:
Support for OCPP 2.0.1 or 2.1 is essential for improved security, V2G, and DER features, especially in new installations needing Plug & Charge and grid management.
Verify vendor claims with up-to-date conformance declarations that specify the exact software version, functional blocks supported, and check certification status regularly after firmware updates.
Connection stability relies on persistent WebSocket links; poor implementation or dropped connections can lead to data loss and should be stress-tested during commissioning.
Compatibility with legacy hardware favors requiring support for both 1.6 and newer versions during transitions, with careful planning for phased upgrades and rollback strategies.
Publicly accessible chargers should meet at least Security Profile 2 or 3 (TLS with client certificates) to ensure encryption, authentication, and support for ISO 15118 Plug & Charge.
Table of Contents
How does OCPP work? Architecture and message flow
Every OCPP deployment follows the same client/server pattern: the charge point is the client, and your charging station management system (CSMS) is the server. That matters because the charger initiates the connection, not the other way round, and it keeps that connection open as a persistent WebSocket rather than repeatedly polling. A dropped WebSocket is a dropped charger, so connection stability is the first thing engineers should stress-test during commissioning.
A typical session runs through a predictable sequence:
DNS resolution and TCP connection to the CSMS endpoint.
TLS negotiation over wss://, ideally with certificate-based authentication rather than a shared password.
WebSocket upgrade and OCPP sub-protocol identification, confirming both sides agree on the version in use.
BootNotification sent by the charger, met with an Accepted response and a Heartbeat interval.
StartTransaction when a driver plugs in and authorises, followed by periodic MeterValues.
StopTransaction when charging ends, closing out the billing record.
Offline behaviour deserves separate attention. A well-implemented charger keeps a local authorisation list so it can still start a session without a live connection, then queues meter values and transaction records for transmission once the link returns, a resilience feature OCPPLab documents in detail. For integration testing, don’t just check the happy path. Force a mid-session disconnection and confirm the queued data arrives intact when the connection restores.
OCPP versions compared: which one should you specify?
Version choice shapes almost everything downstream, from security posture to smart charging capability. OCPP 1.6 launched in 2015 and remains the most widely deployed version in the field; OCPP 2.0.1 arrived in 2020 with a stronger security model; OCPP 2.1 followed in 2025, adding distributed energy resource and vehicle-to-grid features while aiming for backward compatibility with 2.0.1 deployments.
OCPP 1.6: proven, broadly supported, but TLS and authentication are optional extras rather than defaults.
OCPP 2.0.1: introduces a structured device model, mandatory security profiles and materially better transaction handling.
OCPP 2.1: builds on 2.0.1 with V2G and DER controls for sites planning bidirectional charging or grid services.
Message richness: 2.x versions expose far more granular device state, useful for fault diagnosis and remote configuration.
Compatibility strategy: on brownfield sites with existing 1.6 hardware, require the CSMS to support both versions rather than forcing a wholesale swap.
For most retrofit projects, 1.6 remains the pragmatic baseline for compatibility, while 2.0.1 or 2.1 suit new installs that need Plug & Charge or tighter security from day one. Read more in Swiftcharging’s technical guide to the OCPP protocol for a deeper walk-through of feature sets.
What security changes come with OCPP 2.x and ISO 15118?
OCPP 1.6 treats TLS as optional, which means a poorly configured deployment can run entirely unencrypted. OCPP 2.0.1 and 2.1 close that gap by making security profiles mandatory, covering certificate-based authentication, signed firmware updates and encrypted transport as standard requirements, not add-ons.
For any publicly accessible charger, Security Profile 2 or 3 (TLS with client certificates) should be the contractual minimum. This also unlocks ISO 15118 Plug & Charge, which lets a vehicle authenticate and start a session automatically over the same cable, with OCPP carrying the certificate exchange between charger and CSMS.
Public funding schemes in several markets already favour or require OCPP-compliant infrastructure precisely to avoid vendor lock-in and keep security auditable.
Pro Tip: Ask every vendor how firmware updates are signed and delivered. An unsigned update path is a bigger long-term risk than a missing feature.
Does OCPP support smart charging and V2G?
OCPP handles smart charging through charging profiles, instructions that cap or shape power delivery over time. OCPP 1.6 offers basic profile support; OCPP 2.0.1 and 2.1 extend this considerably, adding composite schedules and, in 2.1, direct hooks for distributed energy resources and vehicle-to-grid discharge.
None of this is automatic, though. Several functional blocks sit in the “optional” category of the spec, so support varies by vendor:
Smart charging profiles (present in both 1.6 and 2.x, but depth varies).
V2G and DER management (2.1 territory, rarely backported).
Local load management across multiple connectors.
Dynamic tariff updates pushed from the CSMS.
If load management or tariff-linked charging matters to your site, get written confirmation of which blocks are live, not just theoretically supported by the spec version.
How do you verify a vendor’s OCPP claims?
“OCPP compliant” is marketing language; it isn’t a guarantee. Formal OCA certification is tied to a specific product and a specific software version, which means a certificate for last year’s firmware tells you nothing about the build shipping today.
Request the Vendor Declaration of Conformance and check it names the exact software version, the OCPP version, and the specific functional blocks supported.
Cross-check any certification claim against the OCA’s certified products list rather than taking a sales sheet at face value.
Ask directly whether the charger uses any secondary communication channel back to the manufacturer, since undisclosed side channels for firmware or telemetry can quietly block migration later.
Write firmware access, data export and migration rights into the contract, not just into a sales conversation.
Pro Tip: Re-check the certificate reference every time firmware updates, because a certified build can lose conformance after an update that changes its OCPP behaviour.
What should implementation and migration planning cover?
Migrating from 1.6 to 2.0.1 or 2.1 rarely happens overnight, so a CSMS that runs dual-version support during the transition avoids stranding older hardware while newer sites move ahead.
Build an integration test plan covering BootNotification handling, reconnection after signal loss, and load behaviour under peak demand.
Regression-test after every firmware update, since certificates and VDoCs apply to specific builds and an update can reintroduce defects.
Keep local authorisation lists current so chargers can authenticate drivers even during connectivity drops.
Stage rollouts site by site, confirm meter data continuity, and keep a documented rollback plan before touching production chargers.
For fleet and depot sites specifically, pairing this with sound logistics fleet management practice helps align charger scheduling with vehicle turnaround, an operational layer OCPP alone doesn’t solve. Swiftcharging’s guide to fleet depot charging covers the load management side in more depth.
What we’ve learned installing OCPP-compliant chargers
Two patterns keep repeating across our projects. On depot sites, operators who insisted on explicit OCPP 2.0.1 security profiles from the outset avoided a costly retrofit later, once their funding body started asking for certificate evidence. On a destination site like Edinburgh Leisure, the priority sat elsewhere: dual-version CSMS support so ageing 1.6 hardware kept working alongside newer chargers added in later phases.
We design, install and manage both AC and DC infrastructure across workplace, fleet and destination sites, and treat conformance evidence as a procurement gate, not paperwork to chase afterwards. If you want a second opinion on a vendor’s OCPP claims before you sign, that’s a conversation worth having early.
— Swift Charging
Where to check the OCPP standard yourself
The Open Charge Alliance’s protocol page is the primary reference for OCPP versioning and scope. Its OCPP Chronicles whitepaper traces how the standard has evolved since 2009, and the certified products listing lets you check a vendor’s claim directly. For a plainer technical walk-through aimed at implementers, OCPPLab’s explainer covers security profiles and the device model in practical terms.
Ready to specify or audit an OCPP-compliant installation? We support UK businesses from feasibility through to long-term management, including sites in Chichester, Eastbourne, Farnborough, Farnham and Portsmouth. Get in touch for a conformance review before you commit to hardware.
Sources
FAQ
What is the 80/20 rule for EV charging?
There’s no OCPP specification called an “80/20 rule”.
Which EV chargers are OCPP compatible?
Compatibility depends on the specific hardware and firmware build, not the brand generally, since OCPP support is implemented per product and per software version. Always ask for a current Vendor Declaration of Conformance or check the OCA’s certified products list rather than relying on a general “OCPP compatible” label.
What is the difference between OCPP and OCPI?
OCPP governs communication between a charge point and its management system, while the Open Charge Point Interface (OCPI) governs communication between different charging networks and roaming platforms, so operators can share access across providers. The two protocols solve different layers of the same ecosystem and often run alongside each other.
Which EV chargers support OCPP?
Most commercial charge points sold today support OCPP 1.6 at minimum, with a growing number of newer models supporting OCPP 2.0.1 or 2.1. Confirm the exact version and functional blocks in writing rather than assuming from the product name alone.
Recommended