OCPP 1.6J to 2.0.1 Migration for EV Chargers: Firmware, Security and Hardware
Moving a fleet to OCPP 2.0.1 is a firmware rewrite, not an update, and the units are already on the street. We check whether each charger model can carry it at all, build the firmware, set up certificates and provisioning, and roll it out in waves that can be reversed.
Start with the readiness review. It is the part that tells you which of your models need a board revision rather than a build.
- RIOD builds the Powerpod chargers and Charger360, its own OCPP software
- Both ends of the connection are tested against each other on our own bench
- Around 50 engineers, and over ten years of embedded and cloud engineering
Why networks are moving now
Four things are taking the decision out of operators' hands. In Europe, AFIR requires publicly accessible AC and DC charging points installed or renovated from 1 January 2027 to support ISO 15118-20, and 1.6J has no native way to carry ISO 15118 certificates between the charger and the CMS. Tenders increasingly name IEC 63584:2024, which is what OCPP 2.0.1 was published as. Utility, city and fleet buyers now ask for per-charger certificates, which 1.6J only ever had as a vendor-specific add-on. And charger makers are shipping 2.0.1 firmware whether or not the backend behind them is ready.
Any one of those sets the timeline, and 2027 is closer than a firmware programme makes it look: the readiness review, the build, certification and a phased rollout run in series, not in parallel.
If none of them applies to your network yet, we would rather say so than sell you a migration. Our own article on what 2.0.1 actually gives you is the better read in that case, and it is linked below.
What changes between 1.6J and 2.0.1
2.0.1 is not backward compatible. It is a different protocol, and nearly everything in the firmware that speaks to the CMS has to be rewritten.
| Area | 1.6J | 2.0.1 | What it costs you in firmware |
|---|---|---|---|
| Structure | Charge point and connectors | Station, EVSE, connector | Model shared power and multi-connector EVSEs properly |
| Configuration | Flat keys | Device model of components and variables | Rebuild configuration and map it to real hardware |
| Transactions | Start, Stop, MeterValues; CMS issues the ID | One TransactionEvent; the charger issues the ID | Rewrite the session state machine and the offline queue |
| Authorisation | An idTag string | Typed IdToken, richer offline rules | Rework the cache and local list handling |
| Security | An optional add-on whitepaper | Three profiles built in, with certificates | Add TLS, a certificate store and key handling |
| Firmware update | A download URL | Signed images with status detail | Verify before install, report every step |
| Monitoring | Status notifications | Variable monitoring with thresholds | Report the moment a value crosses a limit |
| Plug and Charge | Not supported | Certificate and contract handling built in | Join the OCPP stack to the vehicle stack |
The three security profiles
Profile 1: a password, unencrypted
HTTP Basic over a plain WebSocket. Defensible on a closed, trusted network. Not on anything public.
Profile 2: TLS with a password
TLS 1.2 or higher, the charger checks the server certificate against a root it holds, and logs in with its own password. This is the baseline the OCA's 2.0.1 core certification covers.
Profile 3: TLS with charger certificates
Both ends prove who they are. No shared password to leak, and a stolen credential cannot impersonate a charger. This is what public networks, utilities and fleets ask for. The CMS can raise a charger's profile remotely; the specification does not permit a remote downgrade.
Certificates on a device that has to last ten years
- Keys are generated on the charger and the private key never leaves it, ideally held in a secure element or the processor's protected storage.
- The charger requests its certificate with SignCertificate and receives it with CertificateSigned.
- Roots are installed and replaced from the CMS, and can be listed or removed.
- Expiry is tracked and renewal requested in time, so no charger drops off because a certificate lapsed.
- Firmware images are signed, and an image whose signature does not verify is refused.
- Failed logins, invalid certificates and unexpected resets are reported and kept in a security log.
- Certificates are only valid between dates, so the charger needs trustworthy time: NTP plus a backed-up real-time clock.
Zero-touch provisioning
An installer mounts the charger, powers it on, scans the code and leaves. No laptop, no shared password, no configuration on site.
- 1At the factory each unit gets a unique identity, a credential and the CMS root certificate.
- 2On first power-up it sends BootNotification with vendor, model, serial and firmware version.
- 3The CMS recognises the serial from the shipped batch, replies Pending, and assigns it to the right operator and site.
- 4It reads the device model and applies the site's configuration template.
- 5The charger generates a key pair and requests its certificate, then reconnects at profile 3.
- 6Firmware is checked and the approved signed image pushed if it is behind.
- 7The charger is accepted and goes live, reporting every connector.
Migrating units already in the field
- Dual-stack firmware: one image carrying both stacks, with only one connection active.
- The 2.0.1-capable image is delivered over the existing 1.6J connection first.
- If the charger cannot reach the 2.0.1 endpoint it falls back to its 1.6J profile, so nothing goes dark.
- A/B partitions, with the previous firmware kept until the new one has proven itself.
- Updates and restarts wait for the charger to be idle, so no session is interrupted.
- Charger IDs do not change, so billing, history and roaming records stay joined up.
- Waves rather than a single push: a pilot group, then larger waves, each watched before the next.
Hardware readiness, before any code
Not every 1.6J charger can carry 2.0.1 well, and finding that out after the firmware is written is expensive. We check each model and say plainly whether it needs a build or a board revision.
| Area | Why 2.0.1 needs it | What we look at |
|---|---|---|
| Processor and RAM | TLS handshakes, JSON parsing, offline queues | Headroom with TLS and charging running together |
| Flash | Two firmware images, certificate store, logs, queues | Space for A/B plus everything else |
| Secure key storage | Private keys for profile 3 and ISO 15118 | Secure element, TPM or protected storage |
| Real-time clock | Certificate validity and timestamps | Backed-up RTC and NTP |
| Connectivity | Stable TLS over 4G, Ethernet or Wi-Fi | Modem TLS limits and reconnection behaviour |
| ISO 15118 | Power line communication on the control pilot | Whether a HomePlug Green PHY modem is on the board at all |
| Metering | Accurate and, in some markets, signed values | Accuracy class and signing support |
The ISO 15118 row is the one that ends projects. Many AC chargers built for 1.6J have no power line modem, and AFIR's 2027 requirement cannot be met with firmware alone on those boards. Better to know in week one.
Testing and certification
Every build is tested with the Open Charge Alliance test tool, against more than one CMS, and in soak tests with real sessions. We prepare the charger for OCA 2.0.1 certification, whose core covers booting, authorisation, configuration, transactions, remote control, secure firmware update and security profile 2, carried out at an independent lab.
How a migration runs
- 1Readiness review: hardware check, firmware audit, and a look at what is actually installed.
- 2Architecture: stack, target security profile, provisioning design, rollout plan.
- 3Build: the 2.0.1 stack, device model, security, update path and any ISO 15118 work.
- 4Test: OCA tool, CMS interoperability, security, soak.
- 5Pilot: a small group in the field against a dual-stack CMS.
- 6Rollout: waves, monitored, with automatic rollback.
- 7Certification and handover: test reports, documentation and source.
What you get
- A readiness report per charger model, including the ones that need a board change.
- OCPP 2.0.1 firmware with 1.6J fallback.
- Security profile 3 with certificate lifecycle handling.
- Zero-touch provisioning for factory and field.
- Signed firmware update with rollback.
- OCA test results and certification preparation.
- A rollout plan and monitoring for the installed base.
- Documentation and source code.
Who it is for
- Charger manufacturers upgrading a model or launching a 2.0.1 one.
- Operators with mixed fleets that have to stay online through the move.
- Fleet and depot operators whose IT will not approve anything below profile 3.
- Anyone bidding where OCPP 2.0.1 or ISO 15118 readiness has to be demonstrated.
Common questions
Can OCPP 1.6J chargers be upgraded to 2.0.1 over the air?
Often, if the processor, memory and flash have headroom for TLS, certificates and two firmware images. ISO 15118 is the exception: it needs a power line communication modem on the board, which firmware cannot add.
Is OCPP 2.0.1 backward compatible with 1.6J?
No. A 2.0.1 charger cannot talk to a 1.6J-only backend. That is why both the firmware and the CMS run dual-stack during a migration.
Can one charger support both?
Yes. Dual-stack firmware carries both, with one connection active by configuration and automatic fallback if the new endpoint cannot be reached.
Do we need 2.0.1 to meet AFIR?
AFIR requires ISO 15118-20 on public AC and DC points installed or renovated from 1 January 2027. OCPP 1.6J has no native ISO 15118 certificate handling, so 2.0.1 is the practical route.
What is security profile 3?
TLS where both charger and CMS identify themselves with certificates. No shared passwords, and each charger has its own identity.
What is zero-touch provisioning?
The charger sets itself up on first power-up: registers, receives its configuration, gets its certificate and moves to the secure connection, with nobody configuring it on site.
What about OCPP 2.1?
2.1 builds on 2.0.1 and adds things like bidirectional charging. Firmware designed for 2.0.1 now makes 2.1 a far smaller step later.
How long does a migration take?
Industry guides put a full network migration at six to twelve months, most of it testing and phased rollout. The readiness review gives you a figure for your models and fleet rather than an average.
Will drivers notice?
They should not. Updates wait for an idle charger, IDs do not change, and a failed switch falls back to 1.6J.
Can you work on EVerest or on our own firmware?
Either, or from a clean base. It depends on your platform and where you want to be in three years.
Related
Find out which of your models can carry it
The readiness review is the honest first step: it tells you which chargers need firmware, which need a board revision, and which should be left on 1.6J.