Firmware signing is the process of applying a cryptographic digital signature to a firmware image so an EV charger can verify that the firmware is authentic, untampered, and approved before installing or running it. It is a core control in secure device design and is foundational for preventing unauthorized firmware and supply-chain tampering.
What Is Firmware Signing?
Firmware signing works like a seal of authenticity for software.
– The manufacturer (or authorized operator) signs the firmware using a private key
– The charger verifies the signature using the corresponding public key stored securely on the device
– If verification fails, the charger rejects the firmware and does not run it
Firmware signing proves both:
– Integrity: firmware has not been modified
– Authenticity: firmware came from a trusted signing authority
Why Firmware Signing Matters for EV Charging
– Prevents malicious firmware that could bypass safety logic or disrupt charging
– Protects credentials and sensitive data stored on the charger (certificates, tokens)
– Reduces risk of charger fleets becoming an entry point into operator networks
– Enables controlled OTA updates and auditable release governance
– Supports cybersecurity requirements in tenders, audits, and critical infrastructure environments
– Improves reliability by reducing corrupted update incidents and inconsistent builds
Where Firmware Signing Is Used
– During manufacturing (factory provisioning) to install a trusted baseline firmware
– During commissioning (field provisioning) to confirm approved firmware on site
– During OTA updates from a CPMS or secure update service
– During boot if the device uses secure boot (signature verified before execution)
– During incident response to confirm whether a device is running an approved build
How Firmware Signing Works
Signing (Manufacturer Side)
– Build firmware image
– Compute cryptographic hash of the image
– Create a signature using the private signing key
– Package firmware + signature (+ metadata like version, hardware target)
Verification (Charger Side)
– Compute hash of received firmware
– Verify signature using the stored public key
– Confirm metadata compatibility (model, hardware revision, minimum version)
– If valid → accept install/boot
– If invalid → reject, log, and remain on last-known-good firmware
Firmware Signing and Secure Boot
Firmware signing is most effective when combined with secure boot.
– Secure boot verifies the signature at startup before firmware runs
– Prevents execution of modified firmware even if storage is compromised
– Creates a hardware-rooted chain of trust (bootloader → OS → application)
Firmware Signing and Anti-Rollback
To prevent downgrades to vulnerable firmware, some systems add:
– Minimum allowed version enforcement
– Anti-rollback counters stored in secure hardware
– “Last known good” fallback rules
This makes signed firmware safer by preventing attackers from loading an older signed but vulnerable build.
Key Management Considerations
Firmware signing is only as strong as signing key protection.
– Keep private keys in a secure environment (often HSM-backed)
– Restrict signing access and require approvals for production releases
– Separate keys for development, staging, and production
– Plan key rotation and revocation procedures
– Maintain audit logs for every signed release (who, when, which version)
Best Practices for EV Charger OEMs and Operators
– Sign all production firmware; block unsigned firmware on devices
– Use staged rollout with signed releases and strong integrity reporting
– Report signature verification status and firmware version to CPMS
– Maintain a compatibility matrix by hardware revision and market requirements
– Include firmware signing checks in FAT/SAT and update pipeline validation
– Protect signing keys and ensure a documented emergency hotfix signing process
Common Mistakes to Avoid
– Using the same signing key for dev and production environments
– Allowing “engineering mode” installs of unsigned firmware in production devices
– No anti-rollback policy, enabling downgrade attacks to older signed versions
– Poor audit trails: not tracking which firmware was signed and deployed where
– Blocking update endpoints via firewall rules, leading to mixed versions across fleets
– Not including third-party module firmware (modems, payment terminals) in the overall security plan
Limitations to Consider
– Firmware signing does not remove vulnerabilities; it ensures only trusted code runs
– Key compromise is catastrophic without a recovery plan (revocation, re-keying, secure boot updates)
– Legacy devices may have limited secure storage for public keys or anti-rollback counters
– Operational complexity increases with multiple hardware variants and regional constraints
– Some update failures still require robust rollback and recovery mechanisms
Related Glossary Terms
Firmware Integrity Validation
Secure Update Pipeline
Secure Boot
Encrypted Firmware
Certificate Management
Device Certificate Enrollment
Charger Cybersecurity
Factory Provisioning