OCPP protocol for businesses: a technical guide
- Swift Charging
- Aug 17
- 14 min read
The OCPP protocol is the open application protocol that lets charge points and central management systems talk to each other, so hardware from one manufacturer works with software from another. It stands for Open Charge Point Protocol, and it is stewarded by the Open Charge Alliance (OCA), the non-profit body that maintains the specification, runs certification testing and publishes the schemas developers build against.
Three versions are in active use: OCPP 1.6, OCPP 2.0.1, and OCPP 2.1. The newest edition of 2.0.1 has been formalised as the international standard IEC 63584, which matters if you sit on a procurement board that needs a recognised standards body behind a purchasing decision rather than a vendor’s word for it.
Our recommendation for most commercial buyers: specify OCPP 2.0.1 or 2.1 for new installations where device management, stronger security and future smart-charging features matter, and keep OCPP 1.6 in the conversation only where you are extending an existing fleet of 1.6 hardware and full compatibility with that estate is the priority. Before you sign anything, run through this shortlist with your vendor:
Ask exactly which OCPP version and sub-profile the hardware and charging station management system (CSMS) support, in writing.
Request evidence of OCA certification or an independent test report, not just a claim of “OCPP compliant.”
Confirm how the charger handles TLS and certificate-based authentication, and who manages certificate renewal.
Check whether the charger can maintain simultaneous connections to a CSMS and a separate energy management system (EMS) without dropping one.
Key Takeaways
Choosing OCPP-compliant, properly certified charging hardware and a matching CSMS protects your infrastructure investment by keeping vendor switching genuinely possible.
Point | Details |
OCPP prevents lock-in | The open protocol lets charge points and CSMS platforms from different vendors interoperate, so you are never stuck with one supplier. |
Match version to need | Favour OCPP 2.0.1 or 2.1 for new purchases needing ISO 15118, DER or stronger security; keep 1.6 only for existing estate compatibility. |
Certification is not optional | Request independent lab certification evidence and plugfest participation history before signing any vendor contract. |
Secondary connections need testing | Confirm how hardware handles simultaneous CSMS and EMS connections before go-live, especially on smart charging or renewable sites. |
Swift Charging supports full delivery | Swift Charging handles site surveys, OCPP-compliant charger supply, CSMS integration, commissioning and ongoing maintenance across UK projects. |
Table of Contents
What are the differences between OCPP 1.6, 2.0.1, and 2.1?
OCPP 1.6 remains the most widely deployed version in the field. It introduced smart charging support and local authorisation list management, and it works over two transport flavours: SOAP and JSON, though JSON over WebSocket has become the practical default almost everywhere. Its feature set is organised into optional profiles, which means two “OCPP 1.6” chargers can support quite different capabilities depending on which profiles the manufacturer implemented.
OCPP 2.0.1 arrived as a substantial rewrite rather than an incremental update. It adds proper device management, more granular transaction handling, and built-in support for ISO 15118, the standard that enables plug-and-charge authentication between vehicle and charger. Edition 3 of the 2.0.1 specification was approved as IEC 63584, giving it formal international standard status that 1.6 never received.
OCPP 2.1 builds on 2.0.1 rather than replacing it. It extends the protocol with functionality for controlling distributed energy resources (DER), which matters for sites running solar, battery storage or vehicle-to-grid pilots. Crucially, application logic written for 2.0.1 is largely compatible with 2.1, so an upgrade path exists that does not require rebuilding integration from scratch.
Before committing to an upgrade, run through this checklist: confirm the charger’s firmware actually supports the target version rather than merely listing it on a spec sheet, verify your CSMS vendor supports the same version on their side, budget time for interoperability testing rather than assuming a version match guarantees a working connection, and check whether certification evidence exists for the specific version and profile combination you are buying.
How does the OCPP protocol actually work?
Three actors typically sit in an OCPP deployment: the charge point (the physical charger), the central system or CSMS (the software platform managing it remotely), and, increasingly, a secondary system such as an energy management system (EMS) or a certificate authority handling security credentials. The charge point always initiates the connection to the CSMS, never the other way round, which simplifies firewall configuration considerably on the operator’s side.
Transport has evolved. Early deployments used SOAP over HTTP, a heavier, XML-based messaging style. Almost all modern implementations now use OCPP-J: JSON messages carried over a persistent WebSocket connection. That persistence matters: the charger holds one long-lived, full-duplex connection open to the CSMS, so either side can push a message the moment something happens rather than waiting for a polling cycle.
A typical charging session follows a predictable rhythm. The charger sends a BootNotification when it powers up, and once accepted, it starts sending periodic Heartbeat messages to confirm the connection is alive. When a driver presents an RFID card or app token, the charger sends an Authorize request to check permission before power flows. Once authorised, StartTransaction begins the session, MeterValues reports energy delivered at intervals throughout, and StopTransaction closes it out with a final reading. Firmware updates and diagnostics requests can happen independently of any active session.
Two networking details trip up integrators more often than anything else. First, keepalive and heartbeat timing needs tuning against your network’s NAT and firewall behaviour, since an idle WebSocket can be silently dropped by intermediate equipment if heartbeats are too infrequent. Second, the Sec-WebSocket-Protocol header during the initial handshake is what tells the CSMS which OCPP version the charger is speaking, so a mismatch here fails the connection before a single message is exchanged.
What are the core OCPP messages developers need to support?
Every implementer, whether building charger firmware or a CSMS integration, ends up working with a recurring set of request and response pairs. The official OCPP 2.0.1 JSON schemas define the exact structure for each, but the practical shortlist looks like this:
BootNotification, sent when a charger connects or restarts, carrying model, vendor and firmware version data the CSMS uses to identify the device.
Heartbeat, a lightweight keepalive that confirms the connection remains active between other messages.
Authorize, checked against a driver’s ID token before a charging session is permitted to start.
StartTransaction and StopTransaction, marking the beginning and end of a charging session along with meter readings.
MeterValues, reporting energy, voltage, current and other measurements at configurable intervals during a session.
StatusNotification, telling the CSMS when a connector’s state changes, such as moving from available to charging or to faulted.
RemoteStartTransaction and RemoteStopTransaction, letting the CSMS trigger or halt a session remotely, useful for app-based start commands.
SetChargingProfile, the mechanism behind smart charging, allowing the CSMS to constrain or shape a charger’s power delivery over time.
GetCompositeSchedule, which returns the combined effect of all active charging profiles on a connector, useful for diagnosing why a charger is delivering less power than expected.
Firmware update messages (UpdateFirmware, FirmwareStatusNotification), managing over-the-air updates and reporting progress back to the CSMS.
DataTransfer, a deliberately generic message type used to carry vendor-specific or extension data that does not fit the standard schema.
A few implementation details are easy to miss on a first read of the spec. In OCPP 1.6, features are grouped into optional profiles, so Core, Firmware Management, Local Auth List Management, Reservation, Smart Charging and Remote Trigger can each be present or absent depending on what the manufacturer chose to build; never assume a “1.6-compliant” charger supports smart charging just because the version number matches. Watch for mandatory versus optional fields in each schema, particularly timestamp formats and identifier types, since a subtle mismatch there is a common cause of messages that parse but get silently rejected. Message correlation runs on a unique ID attached to every request, which the response must echo back, and building solid error handling around unmatched or timed-out correlation IDs will save considerable debugging time later.
How secure is the OCPP protocol, and what changed in 2.x?
TLS is the baseline for any production OCPP deployment, encrypting the WebSocket connection between charger and CSMS so meter data, authorisation tokens and remote commands cannot be intercepted or spoofed in transit. OCPP 1.6 supports TLS but leaves a good deal of the certificate handling to implementation choice, which is part of why security posture varies so much between vendors claiming the same version number.
OCPP 2.0.1 and 2.1 tighten this considerably. They formalise certificate-based authentication patterns, including provisions for the charger and CSMS to exchange and validate certificates as part of connection setup, and they extend security into firmware updates by supporting signed firmware packages, so a charger can verify an update genuinely came from an authorised source before installing it. This closes a real gap that existed in many 1.6 deployments, where firmware integrity checking was left almost entirely to the manufacturer’s own tooling.
For anyone running or specifying a fleet of chargers, a short operational checklist matters more than any spec clause:
Track certificate expiry dates centrally rather than per-charger, since certificate lapses are one of the most common causes of chargers silently dropping offline.
Confirm your CSMS supports certificate revocation, not just issuance, so a compromised device can be locked out quickly.
Verify chargers maintain accurate time synchronisation, since expired or not-yet-valid certificates are frequently a clock problem in disguise rather than a certificate problem.
Ask vendors directly what monitoring exists for anomalous message patterns on the CSMS side, such as repeated failed authorisation attempts, which can indicate a compromised RFID token or a probing attack.
Pro Tip: Ask your CSMS provider to show you a real certificate renewal event in a test environment before go-live. A surprising number of “automated” renewal processes still require a manual trigger somewhere in the chain, and you want to find that out before a certificate actually lapses in production.
How does OCPP certification and testing work?
The OCA runs a formal certification programme covering specific OCPP versions, and passing it means a charger or CSMS has been run through independent testing labs against a defined conformance suite rather than simply asserting compliance. Certification confirms a device correctly implements the messages and behaviours the specification requires for that version. It does not guarantee that two certified products will behave identically in every edge case, particularly around vendor-specific extensions layered on top of the core protocol.
That gap is exactly what plugfests exist to close. These are practical interoperability events where multiple vendors connect their hardware and software to each other’s systems in the same room, surfacing the mismatches that pass individual certification but fail in combination, timing quirks, unusual message ordering, or ambiguous handling of an optional field. If a vendor has participated in recent plugfests, that is a genuinely useful signal during procurement, arguably more useful day to day than the certification certificate itself.
Before accepting any installation, build acceptance testing around a concrete checklist rather than a vendor’s assurance:
Confirm core message flow end to end: boot, heartbeat, authorise, start, meter values, stop, all logged and reviewed.
Test the firmware update flow at least once in a controlled window, watching for a clean status notification sequence.
Verify meter value accuracy against a calibrated reference meter, not just that values arrive.
Deliberately interrupt the network connection mid-session and confirm the charger and CSMS recover state correctly rather than losing the transaction.
Request the vendor’s certified lab report for the exact hardware and firmware version being installed, not a generic model-line certificate.
What should businesses check before procuring OCPP-based systems?
Vendor lock-in is the risk OCPP was built to prevent, but only if buyers actually exercise the leverage the open standard gives them. A supplier claiming “OCPP compliant” without naming the specific version, profile support and certification evidence has told you almost nothing useful; press for the detail before signing.
A solid procurement checklist covers which OCPP versions and sub-profiles are supported (in writing, not verbally), whether independent certification test reports exist for the exact hardware and firmware combination on offer, how the charger behaves when it loses connection to the CSMS (does it fail open, fail closed, or queue transactions locally), what the vendor’s over-the-air firmware update process looks like and whether it is signed, and what commercial support SLA backs the installation once it is live.
Acceptance criteria should be written into the contract itself, not left as a handshake agreement. Useful metrics include message conformance against the published schema, a demonstrated successful firmware update cycle, verified meter value integrity against a calibrated reference, and confirmed resilience when the network connection drops mid-session. The most common risks in the field are partial OCPP implementations that technically claim version support while quietly omitting whole profiles, undocumented vendor-specific behaviour hidden inside DataTransfer messages, and CSMS platforms that handle only one OCPP version cleanly despite marketing claims of broader support. Staged rollouts, detailed system and user acceptance test scripts, and a genuine commercial support SLA all mitigate these risks far more reliably than trusting a spec sheet.
Integration with wider site energy systems adds another layer. Smart charging and site-level load balancing depend on the CSMS correctly issuing and managing SetChargingProfile limits across every connected charger, and sites layering in ISO 15118 plug-and-charge need to confirm their OCPP version actually supports it, which effectively means OCPP 2.0.1 or later rather than 1.6.
A practical installation checklist from the field
Getting an OCPP deployment right on paper and getting it right on a live site are two different exercises. A dependable sequence runs from site survey through to commissioning, and skipping steps here is where most avoidable problems originate.
Assess site power capacity and comms topology before ordering hardware, since a charger’s OCPP version is irrelevant if the site cannot support its connection method.
Confirm the exact OCPP version and profile set the chosen hardware supports, cross-checked against the CSMS platform it will connect to.
Provision and test certificates before go-live, including a dry run of the renewal process described earlier.
Run baseline acceptance tests on site, covering the full session lifecycle and at least one deliberate network interruption.
Document the final configuration, firmware version and certification evidence for every unit installed, not just a sample.
The pitfalls that recur most often across installations are rarely about the protocol itself. Misconfigured timekeeping causes certificate and TLS handshake failures far more frequently than any actual security flaw. NAT and firewall misconfiguration on the site network can silently drop the persistent WebSocket connection, particularly where heartbeat intervals were left at manufacturer defaults without checking against the site’s own network equipment. Partial feature implementations, a charger claiming smart charging support but implementing only a subset of the SetChargingProfile schema, tend to surface only once real load management is attempted, not during a simple connectivity test. Poor firmware management, specifically a lack of any tested rollback path, turns a routine update into a site-wide outage.
Sites running renewable generation, battery storage or fleet depot charging need particular care around secondary connections. Field research on flexible charging deployments highlights that many smart-charging scenarios require a charger to hold simultaneous connections, one to the CSMS for billing and session management, another to a local EMS for real-time load constraints, and the two systems do not always agree on which one has authority over power limits at any given moment.
Pro Tip: Before any go-live, deliberately test what happens if the EMS connection drops while the CSMS connection stays up, and vice versa. Ask the vendor directly which connection wins if the two ever issue conflicting instructions. Getting a clear answer to that question before commissioning, rather than after a load-shedding incident, is the difference between a smooth rollout and an urgent site visit.
Why OCPP compliance should shape your charging strategy, not just your spec sheet
Treat OCPP compliance as a spec sheet checkbox and you will miss what actually matters about it: the protocol is what lets you replace a failing charger, switch CSMS providers, or bring in a second hardware vendor without tearing your whole network apart. Businesses that specify open, well-certified hardware from day one are the ones who can renegotiate a software contract three years later from a position of choice rather than dependency. That is the real commercial value of the standard, and it rarely gets stated plainly enough during procurement conversations dominated by unit price.
For fleet and workplace operators managing a mixed estate, the sensible approach is staged rather than wholesale. Keep OCPP 1.6 hardware running where it works and where full compatibility with existing infrastructure justifies the cost of not upgrading, but specify 2.0.1 or 2.1 for every new purchase from this point forward. Migrating a functioning 1.6 estate purely for the sake of version currency rarely pays for itself; migrating because you need ISO 15118 plug-and-charge, tighter certificate-based security, or DER control genuinely does.
That DER and vehicle-to-grid capability in OCPP 2.1 deserves more attention than it currently gets in most procurement conversations. Sites planning to add solar generation, battery storage or bidirectional charging in the next few years are making a mistake if they buy 1.6 hardware today purely because it is cheaper at the point of purchase. The protocol version you choose now sets the ceiling on what your energy strategy can do later, and that ceiling is far harder to raise after installation than before it.
How Swift Charging helps you get OCPP implementation right
Getting OCPP compliance right on paper is one thing; getting a live multi-charger site to actually behave that way is another, and that gap is where most of the problems in this guide originate. Swift Charging works with UK businesses from initial site survey through to charger supply, CSMS integration, commissioning and ongoing maintenance, so the checklists above are not theoretical for us: they are the acceptance criteria we build into every project.
Our support on OCPP-related projects typically covers project design and vendor selection with certification evidence in hand, firmware and certificate lifecycle management once a site is live, and long-term maintenance contracts that catch the kind of drift, expired certificates, outdated firmware, that quietly erodes reliability over time. We also help businesses identify available government EV charging grants to offset installation costs where eligibility applies.
If you are planning a new installation or want to migrate an existing site onto OCPP-compliant infrastructure, get in touch through our Chichester commercial installation page for a feasibility conversation, or ask us directly for the acceptance-test templates we use on site commissioning. It is a faster way to start than drafting your own from scratch.
Where to find authoritative OCPP resources
Developers building against the protocol and procurement teams verifying vendor claims need different starting points, so it helps to know which resource answers which question.
For the protocol overview, version history and OCA’s role, start with the Open Charge Alliance’s protocol pages.
For implementation-level detail on OCPP 1.6 specifically, including its transport flavours and profiles, see the OCPP 1.6 specification page.
For the exact JSON schemas your firmware or CSMS integration needs to validate against, use the OCPP 2.0.1 JSON schema repository.
For normative transport and connection guidance, including WebSocket handshake behaviour, consult the OCPP specification’s introduction section.
For procurement teams specifically, verifying a vendor’s OCA certification status is the single most useful check before signing a contract, and it is worth requesting the certificate reference number directly rather than accepting a general compliance claim.
Frequently asked questions about the OCPP protocol
Is OCPP free to use, or does it require a licence? OCPP specifications are published under a Creative Commons licence and are freely available for unrestricted use, with no licence fees or registration required to implement the standard.
Can OCPP 1.6 and OCPP 2.x devices communicate with each other? No. OCPP 1.6 and the 2.x versions are not compatible at the protocol level, so a CSMS platform needs to support both versions explicitly if it is managing a mixed fleet of older and newer hardware.
What is the difference between OCPP and ISO 15118? OCPP governs communication between the charge point and the central management system; ISO 15118 governs communication between the vehicle and the charger, enabling features like plug-and-charge authentication. The two protocols work alongside each other, and OCPP 2.0.1 and 2.1 both include support for coordinating with ISO 15118 sessions.
Do I need OCA certification, or is vendor self-declaration enough? Self-declared compliance is not the same as independent certification. OCA certification means a device has passed conformance testing at an accredited lab, which is a materially stronger guarantee than a vendor simply stating it supports a given OCPP version.
Which OCPP version should a new commercial installation use in 2026? For most new commercial deployments, OCPP 2.0.1 or 2.1 is the sensible default, given the IEC 63584 standard status, stronger security model and ISO 15118 support. OCPP 1.6 still makes sense where you are extending an existing fleet and full compatibility with that hardware is the priority.
Sources
Recommended