OCPP Backend Software: How To Verify A Vendor’s Compliance Claim

OCPP Backend Software: Verifying The Compliance Claim

Every charging platform RFP response says the same three words: OCPP compliant. It is the least informative claim a vendor can make, because the standard behind it is large, modular and optional across most of its surface. If you are a CPO CTO, a head of engineering, or the operations lead who inherits whatever gets signed, the useful question is not whether a piece of OCPP backend software is compliant — it is which parts of OCPP it implements, who tested that, against which charger models, and what happens when one of those models ships firmware that breaks the assumption.

This is a due-diligence guide, not a protocol explainer: what certification does and does not cover, how to read feature profiles as a capability checklist, how to interrogate charger-model coverage, what a mixed-version estate demands, and the security floor worth insisting on — closing with a 12-point checklist for your vendor questionnaire.

Why “OCPP Compliant” Is Close To Meaningless On Its Own

OCPP 1.6, published in 2015 and still the workhorse of most estates, organises its messages into six feature profiles — Core, Firmware Management, Local Auth List Management, Reservation, Smart Charging and Remote Trigger. Only Core is required. OCPP 2.0.1, released in 2020 and since adopted as IEC 63584, keeps the same logic: a mandatory Core plus seven optional certification profiles.

Two systems can therefore both be honestly described as OCPP compliant and share nothing beyond booting, authorising and reporting a transaction. One may be unable to push firmware remotely; the other unable to hold a charging profile. Neither is lying. And because the Open Charge Alliance states that OCPP 1.6 and OCPP 2.0.1 are not compatible, the word does not even pin down which protocol the two ends will speak.

So separate three claims vendors blur into one. Self-declared — the vendor says it works; the OCA formalised this weakest tier in March 2025 as a Vendor Declaration of Conformance. Tested — the vendor ran the OCA test tool internally and liked the result. Certified — an independent laboratory tested a named product at a named software version. Only the third is verifiable from outside.

What OCPP Certification Actually Certifies

is run by the Open Charge Alliance with independent laboratories — Dekra, DNV and three Korean testing bodies among them. Separately the OCA publishes the OCPP Compliance Test Tool (OCTT), which any implementer can subscribe to and run against a charging station, a CSMS or a software stack. Running OCTT internally is preparation for certification, not certification; only the latter produces a document with a number on it.

A certificate is scoped four ways

Every OCA certificate names a role (charging station or CSMS), a version (1.6 or 2.0.1), a set of profiles and a software version — and, since the March 2025 renewal, the product family, the firmware image hash and any additional communication ports. That granularity is the point, and it is exactly what a datasheet bullet destroys.

The most expensive misreading treats the two roles as one. A certified charger tells you nothing about the backend, and a certified backend nothing about the charger — separate certifications of separate implementations. A certified device at each end is a good starting position, not proof the pair will interoperate in your estate.

Ask for the certificate’s date — the goalposts moved in October 2025

On 3 October 2025 the OCA restructured the OCPP 1.6 certification programme to align it with the 2.x programme. Firmware Management and Security Profile 2 became mandatory parts of Core; Reservation, Local Authorization List Management and Remote Trigger became optional elements within it. The old “Fully Certified”, “Subset Certified” and “Security Certified” marks gave way to one badge.

So a 1.6 certificate from 2022 and one from 2026 carry the same name and prove materially different things — the later implies remote firmware management and TLS. Ask for the issue date and the profile list, not the badge. Note too the role asymmetry inside the same programme: for a CSMS, Core and Smart Charging are both mandatory, so a certified 1.6 backend has been tested on every smart-charging profile type including stacking. On a charging station, Smart Charging is optional.

One boundary to know before a vendor quotes it at you: the programme covers 2.0.1 and 1.6 only. OCPP 2.1 was released in 2025 and no certification programme for it has opened, so nobody holds a certified 2.1 product today — 2.1 support is a claim you test yourself. Our OCPP 2.1 vs OCPP 2.0.1 upgrade guide covers whether it is worth chasing yet.

Feature Profiles: The Checklist That Actually Discriminates

Profiles are the most useful instrument a CPO has for sizing up OCPP backend software, because each one either unlocks something your team needs at 2am or it does not. Below is the OCPP 1.6 profile set — the version most estates still run — read operationally rather than as a message list.

Two entries decide whether a network is operable at scale. Firmware Management turns a fleet-wide patch from a truck roll into an overnight job; at fifty sites that is the field-service budget. Smart Charging is most often waved through in evaluation and most painfully missed later — add a second DC charger to a sanctioned connection and a stackable power limit is all that stands between you and a demand-charge surprise. Reservation and Remote Trigger are genuinely optional.

On OCPP 2.0.1 the same reasoning covers a wider set: Core plus advanced security, local authorisation list management, smart charging, advanced device management, reservation, advanced user interface and ISO 15118 support. Have the vendor mark its own row against each — then ask which marks a laboratory has seen.

Charger-Model Coverage: The Honest Answer To “Does It Support My Hardware?”

Certification establishes that two implementations follow the specification — not that they follow it identically, because the spec deliberately leaves room to extend. The OCA’s guidance on customising OCPP describes four sanctioned mechanisms — device-model customisation, a CustomData property, the DataTransfer message, and using the firmware-update mechanism to move data — with a blunt warning to “use with extreme caution, since it may impact your compatibility with other systems that do not make use of these options.”

OEMs use that room for good reasons: a parking sensor, a payment terminal status, an advertising screen, a cabinet reporting two connectors as one. They also use it accidentally — non-standard configuration keys, vendor-specific error codes inside StatusNotification, meter values at odd intervals or units, reconnection behaviour that hammers the backend after an outage. None of it makes a charger non-compliant. All of it means the backend absorbs the deviation somewhere.

Where it absorbs them is what to interrogate. A mature platform holds a per-model adaptation layer that normalises each model’s quirks into one internal session and meter model, so adding model 41 does not destabilise models 1 to 40. A thin integration holds them as per-customer forks in shared code — which is why its fix for your problem arrives with someone else’s regression attached. Same logic as running a mixed hardware fleet under one software layer.

1.6J, 2.0.1 And 2.1 In The Same Estate

No operator of any size runs one protocol version, which is why version handling is where OCPP backend software either earns its keep or quietly fails. The network built in 2022 is 1.6J over WebSocket, last year’s DC units are 2.0.1, and the roadmap says 2.1 for bidirectional and DER control. Since 1.6 and 2.0.1 are not wire-compatible, the backend must terminate every version concurrently and normalise them into one internal model of a session, a meter reading and a fault.

The verification question is not “do you support 2.0.1?” — everyone says yes. It is: does a charge detail record from a 1.6J unit and one from a 2.0.1 unit reach billing with the same shape? If the answer involves version-specific reports or a tenant per protocol, the normalisation was never done, and finance finds out at month end. Ask to see one mixed-version site on one dashboard.

In India this plurality is effectively policy: the Ministry of Power’s 2024 guidelines push CPOs toward open protocols — OCPP and OCPI alongside the Unified Energy Interface and OpenADR — without freezing a version. In a market adding hardware faster than it retires it, that puts the burden of version plurality squarely on the backend.

Security: What To Insist On From OCPP Backend Software

OCPP defines three security profiles, and the gap between them is the gap between a reasonable network and an indefensible one.

The three profiles, in plain terms

Profile 1 is an unencrypted WebSocket with HTTP Basic authentication: the charger proves itself with a password, the backend proves nothing, and everything between travels in the clear. Profile 2 puts that exchange inside TLS 1.2 or higher with the charger validating the backend’s certificate — the realistic baseline. Profile 3 replaces the password with client-side certificates so both ends authenticate cryptographically.

Since the October 2025 revision, Security Profile 2 sits inside the mandatory Core profile for OCPP 1.6 certification — a recent 1.6 certificate now implies TLS where an older one did not. That change alone is the argument for asking a vendor for the certificate date rather than the badge.

Three questions worth more than a security datasheet

First: can a charger still connect over Profile 1, and can I switch that off per tenant? Most platforms accept plaintext for legacy hardware; the acceptable answer is possible, off by default, revocable by you. Second: who issues, installs and rotates charger certificates, and what happens the day one expires? An expired certificate silently drops a charger off the network, and lifecycle is the commonest gap between a security page and operations. Third: are credentials per-charger? A shared password turns one compromised unit into all of them — see our guide to security and compliance for EV charging APIs.

How Do I Verify A Charging Platform’s OCPP Support?

Verify an OCPP backend in three moves. Get the evidence: ask for the OCA certificate number, issue date, role, profiles and the software version it was issued against — then check it in the OCA’s certified-products register rather than accepting a PDF. Get the coverage: ask for the charger models running in production on the platform, with firmware versions, and the process for a model that breaks after an OEM update. Get the proof: connect one of your own chargers to a trial tenant and run the real operations — a remote firmware update, a charging-profile limit, an offline authorisation, a deliberate disconnection.

The twelve points below turn that into a questionnaire. Send it before the demo, not after.

Points 1 to 5 are answerable from documents in a day. Points 6 to 8 separate platforms with a real hardware estate behind them from platforms with a certificate and a slide. Points 9 to 12 are what your operations team lives with for a decade. A platform built for multi-vendor estates should answer all twelve without a follow-up call — the bar we hold OCPP-compliant charging software and hardware-agnostic charger support to, and worth applying to whoever you are evaluating, us included.

None of this is exotic diligence. It is the difference between buying a protocol claim and buying an integration — and on a ten-year asset only the second is worth anything. Thin answers show up not in the contract but as truck rolls, a reconciliation nobody budgeted, and a charger model you cannot add without a change request. Whatever charging management platform you land on, make it answer these twelve questions first.

Frequently Asked Questions

What CPO engineering and operations teams ask when they are checking an OCPP claim.

Sources: Open Charge Alliance — OCPP Certification Program | Open Charge Alliance — Certification OCPP 1.6 profiles | Open Charge Alliance — New OCPP 1.6 Certification Program, 3 October 2025 | Open Charge Alliance — Customizing OCPP Implementations (whitepaper) | Open Charge Alliance — OCPP versions and releases | Ministry of Power — Guidelines for Installation and Operation of EV Charging Infrastructure, 2024