> [...] we did find what appears to be Zaptec’s means of remotely debugging their devices. The first is a function called RunRemoteCommand. This passes the contents of a message received from the cloud directly to Process.Start. [...] A second interesting function called StartRemoteTunnel appears to allow Zaptec to create a reverse shell back to an SSH listener on the internet. [...]

I don't know if things have changed, but back in the day this sort of thing would be called a "backdoor". Yeah, only the manufacturer can use it, for now, but that lasts only until the manufacturer gets compromised, and either the relevant keys get leaked, or the manufacturer systems themselves get used as a jumping point.

This isn't a charger. It is a fancy electrical junction box. The voltage into the box and the voltage out is the same. The only function of the box is to switch the power on and off. And the car already has a switch in to switch stuff on and off anyway. So this box of expensive electronics is entirely redundant.

And they don't even provide much power - typically 32 Amps at 230 volts. Ie. about the same as a caravan hookup. But a caravan hookup doesn't need to run Linux...

This always gets me: "secure" meaning "the manufacturer remains the owner even after selling the device".

What does getting root access have to do with security? Does the threat model include the buyer of the device? If the box is physically opened by a random person, the damage has already been done - they can mess with the electrical installation already. What's the benefit of hiding the software in that situation?

Exercise your rights as the owner and ask for the sources instead. Linux is covered by the GPL.

Having it signed would provide no value for residential customers, where the chargers ostensibly would be physically secured, and should in that case actually be considered an anti-feature.

It seems to me they just included that "recommendation" because they couldn't find anything else to write.

Such a charger needs to be presented some kind of authorization, but the amount of energy transferred (and thus the amount charged) is only determined later.

Is the logic for that server-side, or is it triggered from within the charger? If the latter, could you avoid being charged by power-cycling the computer inside the charger before finishing the charge?

Probably the safer option would be for the charger to send a message like "for authorization XYZ, I've, until now, supplied 5.003kWh" every 5 seconds, then a server-side stream processor can detect the end of the charge and initiate billing.

There are many different implementations, and different charging vendors tend to have varying degrees of functionality, so I would expect a pretty wide assortment of vulnerable chargers (and backend servers). A lot of them also seem to only communicate via static IPs.