Secure Boot for connected EV chargers, rolled out in the field
How we added a verified boot chain, encrypted storage and a secure flashing tool to a European OEM’s Linux EV chargers, including units already installed, without changing the hardware.
- Industry
- Energy
- Services
- Embedded Software
- Cybersecurity
A European OEM supplies public EV charging stations for parking networks in city centres, shopping malls, airports and office campuses. The chargers run 24/7 and stay connected through OCPP, MQTT and cloud APIs for billing, remote monitoring and energy management.
As deployments grew, firmware updates went out over unstable networks, service engineers reached devices through third-party maintenance ports, and public infrastructure became a growing target for attacks. At the same time, the EU Cyber Resilience Act made secure software design, verified firmware integrity and long-term vulnerability management a legal requirement.
At a glance
- Industry
- Energy
- Services
- Embedded Software
- Cybersecurity
Planning something similar? A senior engineer replies within one business day.
The challenge
Occasional firmware faults and unreliable updates were hurting reliability, and without built-in protection the chargers were open to tampering. Compromised OTA channels could allow unauthorised code or theft of cloud communication certificates, putting the whole charging network at risk.
Adding Secure Boot to new production was only half of it. Chargers already in the field had to be upgraded too, and once Secure Boot was in place, the existing OTA and USB update tools could not pass signature validation and the factory scripts were blocked by the new key and partition rules.
The OEM could replace the main boards in deployed chargers, which is expensive and slow, or update the firmware in the field with a tool that safely applies Secure Boot images. It chose the second path and asked us to design and build it.
Ignoring the CRA can mean loss of certification, product recalls and exclusion from public tenders.
Our approach
Hardware root of trust: boot integrity anchored in the SoC Boot ROM, with the SHA-256 hash of the RSA public key and device-specific salts stored in OTP.
Signed multi-stage boot chain: signature checks for the EEPROM bootloader and RSA-2048 validation of the main boot image on eMMC, so every stage is verified: ROM → bootloader → boot image → kernel.
Secure kernel and initramfs: kernel, device tree and initramfs load only after signature validation; a decryptor in the initramfs uses keys derived from the OTP salt and SoC ID.
Encrypted, verified partitions: dm-crypt for the key and user partitions, integrity checking of a read-only SquashFS root filesystem, and OverlayFS for controlled writable areas.
Secure flashing and migration tool: a custom utility for staged in-field upgrades: a signed transition image first, then safe OTP key burning and bootloader re-signing, with recovery paths so no device is bricked.
Verified OTA pipeline: only signed firmware packages, with rollback-safe update logic that respects the Secure Boot and integrity rules.
Compliance by design: the architecture is designed to meet EU Cyber Resilience Act and IEC 62443-4-2 requirements: authenticated boot, encrypted storage and long-term vulnerability management.
Tech stack: Raspberry Pi bootloader, Armbian, SquashFS + OverlayFS + ext4, systemd, perf and ftrace, OCPP and MQTT, on a Broadcom BCM2712 SoC with 2 GB RAM and 32 GB eMMC.
The challenge
Occasional firmware faults and unreliable updates were hurting reliability, and without built-in protection the chargers were open to tampering. Compromised OTA channels could allow unauthorised code or theft of cloud communication certificates, putting the whole charging network at risk.
Adding Secure Boot to new production was only half of it. Chargers already in the field had to be upgraded too, and once Secure Boot was in place, the existing OTA and USB update tools could not pass signature validation and the factory scripts were blocked by the new key and partition rules.
The OEM could replace the main boards in deployed chargers, which is expensive and slow, or update the firmware in the field with a tool that safely applies Secure Boot images. It chose the second path and asked us to design and build it.
Ignoring the CRA can mean loss of certification, product recalls and exclusion from public tenders.
Our approach
Hardware root of trust: boot integrity anchored in the SoC Boot ROM, with the SHA-256 hash of the RSA public key and device-specific salts stored in OTP.
Signed multi-stage boot chain: signature checks for the EEPROM bootloader and RSA-2048 validation of the main boot image on eMMC, so every stage is verified: ROM → bootloader → boot image → kernel.
Secure kernel and initramfs: kernel, device tree and initramfs load only after signature validation; a decryptor in the initramfs uses keys derived from the OTP salt and SoC ID.
Encrypted, verified partitions: dm-crypt for the key and user partitions, integrity checking of a read-only SquashFS root filesystem, and OverlayFS for controlled writable areas.
Secure flashing and migration tool: a custom utility for staged in-field upgrades: a signed transition image first, then safe OTP key burning and bootloader re-signing, with recovery paths so no device is bricked.
Verified OTA pipeline: only signed firmware packages, with rollback-safe update logic that respects the Secure Boot and integrity rules.
Compliance by design: the architecture is designed to meet EU Cyber Resilience Act and IEC 62443-4-2 requirements: authenticated boot, encrypted storage and long-term vulnerability management.
Tech stack: Raspberry Pi bootloader, Armbian, SquashFS + OverlayFS + ext4, systemd, perf and ftrace, OCPP and MQTT, on a Broadcom BCM2712 SoC with 2 GB RAM and 32 GB eMMC.
Our approach
What it means for you: Secure Boot and CRA readiness can be added to products already in the field, without a hardware redesign or a recall.
Compliance by design: the architecture is designed to meet EU Cyber Resilience Act and IEC 62443-4-2 requirements: authenticated boot, encrypted storage and long-term vulnerability management.
Tech stack: Raspberry Pi bootloader, Armbian, SquashFS + OverlayFS + ext4, systemd, perf and ftrace, OCPP and MQTT, on a Broadcom BCM2712 SoC with 2 GB RAM and 32 GB eMMC.
Audit and plan
A detailed audit confirmed that Secure Boot, signed firmware validation and a new flashing tool could meet CRA requirements and protect deployed chargers, without changing the hardware.
Hardware root of trust
Boot integrity anchored in the SoC Boot ROM, with the SHA-256 hash of the RSA public key and device-specific salts stored in OTP.
Signed multi-stage boot chain
Signature checks for the EEPROM bootloader and RSA-2048 validation of the main boot image on eMMC, so every stage is verified: ROM → bootloader → boot image → kernel.
Secure kernel and initramfs
Kernel, device tree and initramfs load only after signature validation; a decryptor in the initramfs uses keys derived from the OTP salt and SoC ID.
Encrypted, verified partitions
Dm-crypt for the key and user partitions, integrity checking of a read-only SquashFS root filesystem, and OverlayFS for controlled writable areas.
Secure flashing and migration tool
A custom utility for staged in-field upgrades: a signed transition image first, then safe OTP key burning and bootloader re-signing, with recovery paths so no device is bricked.
Verified OTA pipeline
Only signed firmware packages, with rollback-safe update logic that respects the Secure Boot and integrity rules.
Results
- 80% fewer firmware vulnerabilities after the signed boot chain and verified updates
- Chargers start only from trusted, manufacturer-signed images
- Zero device recalls: deployed chargers migrated safely in the field
- Architecture designed to meet EU CRA and IEC 62443-4-2 requirements, with no hardware redesign
Service costs and downtime went down, the deployed chargers got a longer life, and the OEM strengthened its security reputation and its access to public-sector tenders.
Planning something similar?
Tell us where you are. A senior engineer replies within one business day.
Services used
A chain of trust from ROM to application, so devices only run software you signed. Ready for the EU Cyber Resilience Act.
Find out what the EU Cyber Resilience Act means for your connected product: a gap analysis of design, SBOM, vulnerability handling and update obligations, with a practical plan to close the gaps.
Over-the-air updates that never brick a device: A/B partitions, signed images, rollback and staged rollouts.
Give every device a unique, trusted identity from the factory to the cloud: keys, certificates and a PKI that handles provisioning, rotation and revocation across the whole fleet.
Talk to an engineer, not a salesperson
Idea, prototype, production or a fleet in the field: tell us where you are. A senior engineer replies within one business day.
Your benefits:
- Senior embedded engineers
- Hardware, firmware and cloud
- From prototype to fleet
- Clear scope and next steps
- Direct technical answers
- No sales pitch
What happens next?
A free 30-minute call with a senior engineer
A short technical discovery
A proposal with scope, timeline and cost
