EV Charger Certificate Rotation
Certificates expire on a date, and the date arrives whether or not anyone diarised it. On a charging fleet the consequence is not degraded service, it is chargers that cannot connect, and a charger that cannot connect usually cannot be told to renew. That circularity is why this has to be designed before the first unit ships.
Rotating certificates across deployed chargers: what has to rotate and on what clock, how renewal is done without interrupting service, the lockout problem, why a wrong clock breaks validation, and what to require at acceptance so this never becomes an emergency.
Check your certificate expiryFor A network operator with a deployed fleet and a renewal date approaching, or a manufacturer who has just realised the units they shipped will expire.
What has to rotate, and on what clock
Swipe to compare
| Item | Typical life | What happens when it expires |
|---|---|---|
| Charger client certificate | One to three years | The charger cannot authenticate. It is offline until renewed |
| Backend server certificate | Months to a year | Chargers refuse to connect to their own backend |
| Certificate authority root | Many years | Everything fails at once, and this is the one least often planned for |
| Firmware signing certificate | Varies | Updates are rejected, including the update that would fix it |
The root is the dangerous one. It has the longest life, so it is the one furthest from anyone's memory, and its expiry takes every unit simultaneously.
The lockout problem
This is the core difficulty and it deserves stating plainly. A charger renews its certificate over its connection to the backend. Once the certificate has expired, that connection is refused. The mechanism for renewal requires the thing that renewal was supposed to preserve.
Every workable design breaks the circle somewhere: renewing well before expiry rather than at it, keeping a fallback path that does not depend on the expiring credential, or allowing a bounded recovery mode. What does not work is discovering the problem on the expiry date, because at that point the fleet is unreachable and the remaining option is a site visit per unit.
Rotating without an interruption
- 1
Start early
Renewal begins at a fraction of the certificate's life rather than near its end. This leaves room for units that are offline, on sites that are closed, or simply missed.
- 2
Overlap validity
The new certificate is issued and installed while the old one is still valid, so a failed installation is recoverable rather than terminal.
- 3
Stage it
A pilot group first, then progressively wider. A rotation pushed to a whole fleet at once is a fleet-wide outage if anything is wrong with it.
- 4
Verify before switching
The unit proves it can authenticate with the new credential before the old one is retired.
- 5
Track completion per unit
The units that matter are the ones that did not renew. A rotation reported as ninety-eight percent complete has left units that will fail silently on a date.
Clock drift, and why the date matters
Certificate validation is a comparison against the current time. A charger whose clock is wrong will reject a perfectly valid certificate, or accept an expired one.
- A unit that loses power and has no backed-up clock may restart in the past, and then refuse a certificate that is not yet valid according to it
- Time is usually obtained from the network, which requires a connection, which requires validation, which requires the time. The same circularity again
- Drift over years is enough to matter on cheap oscillators, particularly at temperature
- A maintained real time clock with a backup source is therefore a security requirement, not a convenience
This is why the clock appears in the control card baseline. It looks like housekeeping until certificates are introduced, at which point it becomes load bearing.
Designing it in before the first unit ships
Everything above is straightforward if it was planned and expensive if it was not. These are the requirements worth putting in a specification and testing at acceptance.
- Demonstrated remote certificate renewal, executed on a real unit, before acceptance rather than described in a document
- A recovery path for a unit whose certificate has already expired, that does not require opening the enclosure
- A maintained clock with a backup source and a defined behaviour when time is unknown
- Visibility of expiry dates across the fleet, so the question when do these expire has an answer that is not a spreadsheet
- Alerting well ahead of expiry, at a horizon long enough to actually act on
Want this applied to your own site?
Check your certificate expiryRelated
Technically reviewed by Deepu Joy, Director of Products and Delivery. Last reviewed 2026-09-10.
Frequently asked questions
What happens if a certificate expires before we renew it?
The charger cannot authenticate, so it cannot connect, so it cannot be told to renew. Recovery usually means a site visit per unit unless a fallback path was designed in.
How far ahead should we renew?
Early enough to catch units that are offline, on closed sites, or simply missed. Renewing near expiry leaves no room for the units that do not respond first time.
Can we rotate the whole fleet at once?
You can, and it is how a fleet-wide outage happens. Stage it: a pilot group, verified, then progressively wider.
Why does the clock matter?
Validation compares against current time. A unit that restarts with a wrong clock will reject a valid certificate. Time usually comes from the network, which needs a valid connection, which needs the time.
What should we require at acceptance?
A demonstrated remote renewal on a real unit, a recovery path for an already-expired unit that does not need the enclosure opened, and fleet-wide visibility of expiry dates.
Do you know when your fleet's certificates expire?
If the answer is a spreadsheet, or no one at all, that is worth resolving before the date rather than on it.
Check your certificate expiry