This is the first piece on what we learned about EV charging security in September 2026: this one from icnc26 in Berlin, a second from THE EV:ent and a summary of what the two told us together will follow. We went to both to understand the segment, not to hard-sell into it, and we are still forming our view. What follows is what we heard, what we think it means, and where we are honestly unsure.

At icnc26, a researcher described surveying the powerline communication modules inside public charging stations in Switzerland. Some of the firmware he found was more than a decade old. Nobody had updated it, and in most deployments, nobody had written down a way to.

That story was about one module. This piece is about what stuck with us most: how to manage the component in an EV charger holding the keys. Who updates the security chip? Right now, nobody.

Three domains, one of which is frozen

A modern charging station has three distinct domains that need updating.

1. The application layer: The part that speaks OCPP to the back-end (the charging station management system, or CSMS), drives the display, manages the session. That gets updated routinely; the protocol has a command for it.
2. The metering firmware: The legally relevant code that measures energy and signs the readings the customer is billed on. Under calibration law (Eichrecht in Germany, the Measuring Instruments Directive across the EU) its version is part of the station's approval. With each update of this domain, the station needs re-assessment before it may legally operate again.
3. The security hardware: The TPM or secure element holding the private keys used for transport security, for authentication, and increasingly for ISO 15118 Plug & Charge.

Figure 1 — Three layers of software in a charging station — and which of them can be updated.

That third layer has no standard update path in the field. A manufacturer with a station on the bench can update a TPM's firmware. The tooling exists, but OCPP's firmware-update command addresses the station's main firmware and not the security chip. There is no defined way to target it, no agreed model for who is allowed to authorise the update, and no shared understanding of how it interacts with the metering approval. In conversations at the conference, including with people who sit inside the standards bodies, the consistent answer was that this has simply not been specified.

Who is responsible and why it should be the operator who moves

Here the legal picture and the technical picture point in opposite directions.

The customer’s contract for charging is with the Charge Point Operator (CPO). Under the applicable rules, the obligation to keep a station's hardware and software current sits with whoever operates it, not with whoever built it. Manufacturers have duties of their own for the products they place on the market, but once a station is in the field, keeping it current is the operator's job. A CPO could in theory buy update-as-a-service from a manufacturer, but even so, the liability remains with the operator.

“An operator said to us that curve choice ought to be their decision.”

The CPO is also the party with the least ability to act. A typical operator runs many station types from several vendors. CPOs may hold obligations for the components inside each of their stations, but they cannot see into, verify, or update them. The CPO might not even hold keys that would let them.

That is exactly why individual CPOs should set requirements. They have the most to lose, the broadest fleet to protect, and the clearest interest in a single mechanism that works across vendors. Manufacturers will build to whatever standards say; chip vendors will supply whatever manufacturers ask for. Nobody upstream has a reason to define the operator's update rights unless operators define them first.

Hardware cannot be patched. If a flaw is in physical silicon, no update removes it. Software mitigations can raise the cost of an attack without eliminating it, but the real fix is replacement. That is the strongest possible argument for being able to rotate keys and update the firmware that sits around the silicon, ideally by the CPO. Unless the underlying hardware is fixed, agility in the layer above is the only remaining defence.

Figure 2 — Who holds the obligation, who holds the keys, who has the tools — and why they aren't the same party.

Risks we did not expect

Cryptographic agility is already a live issue. ISO 15118-20 names a primary elliptic curve and a fallback. In practice, almost everything deploys the primary one. A representative of a research institute explained that no chip vendor sees enough demand to implement the fallback, and an operator said to us that curve choice ought to be their decision. A single curve with no practical alternative is not a backup plan in equipment with a field life of a decade or more.

The real attacks are already here — they're just not the ones people picture. The threat picture in this industry is often described in apocalyptic terms. What manufacturers and operators actually reported at the conference was fraud. Attackers used unsophisticated techniques like authentication bypass, copied RFID cards, and even QR codes stuck over legitimate ones on the charger to redirect customers to phishing pages that harvest credit card details. The scarier systemic scenarios, such as a large share of a national fleet taken offline or stations manipulated to damage vehicles, were raised by the security authorities present. They even acknowledged that charging is not yet an attractive enough target to draw that class of attacker, and as a result, resilience has to be built before the day it becomes one.

Meanwhile, the baseline is not universally in place. Secure cryptography, authentication and transport-layer security are not implemented at every interface and by every party in this ecosystem. Several participants made the same point in different words: get the fundamentals right before adding anything clever on top.

What the ISO standard actually asks for

Here is something we heard repeated on the conference floor, and it is worth examining: "the ISO requires a TPM."

It doesn't. ISO 15118-20's requirement is that private keys be protected in hardware. A TPM is named as one way to satisfy that. It is an example and not a mandate. For many manufacturers, TPM has quietly become the specification, because the security chip is one component among hundreds on the board, and the example is the path of least resistance.

That matters, because a TPM is one particular answer to the requirement, with particular trade-offs. Its strength is standardisation: a defined API, a defined command set, a certification story that arrives as a package. Its cost is the same. The command set is fixed by the specification. The internals are closed by design, and, if there is one critical takeaway you should be aware of, neither the TPM model nor OCPP gives an operator a standard way to update it across a fleet.

A secure element meets the same hardware-protection requirement and is not bound to the TPM command set. It can be shaped to what this segment actually needs: an always-encrypted, mutually authenticated channel between the chip and the host that ensures keys are never exposed on the board. It gives ownership designed to be handed on, manufacturer to operator, so the party carrying the legal obligation can hold the keys that matter. Most importantly, where the architecture is published, is gaining the ability for an operator or regulator to verify all of the above rather than take it on trust.

Figure 3 — One requirement, two answers: what ISO 15118-20 asks for, and how a TPM and a secure element each meet it.

The direction of travel in European policy is not ambiguous here. Components in critical infrastructure that cannot be inspected or verified are increasingly treated as a liability rather than a neutral sourcing choice. The word the security authority in Berlin used was “transparency.” A security chip you cannot audit and cannot update is a black box with a long field life.

The chip can be updated. The station can't — yet.

We build TROPIC01, a secure element whose design including RTL, firmware source, and architecture, is published. Its firmware is field-updatable; the image is signed, the chip checks the signature before it runs it, the update lands in a second bank alongside the running version, and the mechanism is inspectable in public source. Keys can be rotated. Ownership can be handed from manufacturer to operator. The verification keys and rollback counters that anchor a station's own firmware updates can live inside it, with access rights the manufacturer sets. None of this is a roadmap item; it is in the datasheet.

So the chip-level half of the problem is solvable today. We cannot update your station. We can make the part we supply updatable and verifiable by design, and we can make sure that when the station's own update runs, it runs against a hardware root that was never exposed.

The fleet-level half is not solved by anyone, us included. But it is not mysterious either. From the conversations in Berlin, a solution would need four things, none of which is a chip:

1. Component-addressable updates in the protocol. OCPP 2.0.1 already has a component-based device model and signed firmware. The extension is to let an update target a named component, the secure element, and report its version back.
2. Images verified where they land. The station acts as courier; the secure element checks the signature itself. The courier never has to be trusted.
3. Operator-held authorisation. The party with the legal obligation triggers the update and holds the keys that permit it, which is what transferable ownership in the chip is for.
4. The security domain kept outside the metering boundary. If the secure element does not sign the billing record, updating it never triggers re-approval. That single architecture decision removes the biggest practical blocker.

Figure 4 — What a fleet-scale secure-element update would need: four pieces, none of them a chip.

That is a process and a standard, not a product. It should be specified in the open by the people who build and operate this infrastructure, and it should work for any vendor's silicon, including our competitors'. We are working on a proposal for how it could fit together end to end, and we intend to bring it to the people who own the protocol. We would rather be one of several voices in that room than the only one.

If you are working on the same problem as an operator carrying the obligation, a manufacturer designing the next platform, or inside the standards process, we would like to hear from you.