A connected-device manufacturer secures its firmware and supply chain before entering the EU
Industrial IoT device manufacturer
A manufacturer of networked environmental sensors was preparing a European launch and needed to meet consumer IoT security requirements it had never been tested against. We assessed the device on the bench, redesigned the boot and update chain around a hardware root of trust, and gave the company a provisioning process that did not require trusting its contract manufacturer with keys.
100%
of fleet on signed, rollback-protected firmware
including devices from the two earlier production runs, via a one-time migration update
0
shared secrets across devices
per-device identity generated and held in the secure element
Pass
retail customer penetration test
no critical or high findings on the re-secured device
Launched
in the EU on schedule
conformant with consumer IoT baseline security requirements
The situation
The device had been designed for a domestic market with no security regulation to speak of. Firmware was unsigned. A UART debug port was live on production units. The Wi-Fi credentials and the API key that let a device talk to the cloud were stored in plain flash, identical across the whole fleet. Updates were fetched over HTTP from a URL hard-coded into the firmware.
The European launch required conformance with baseline consumer IoT security requirements — no universal default credentials, a secure update mechanism, protected storage of secrets — and a large retail customer had added its own penetration-test clause. The hardware had already been through two production runs, and a new board spin was not on the table.
What we did
- 01
Bench assessment first
Firmware extracted and analysed, debug interfaces probed, and the update path intercepted, to produce an honest picture of what an attacker with a device in hand could do. The answer was: everything, to every device, permanently.
- 02
Root of trust on the existing board
The microcontroller already had a secure element the original design had never enabled. We built the key hierarchy on it: per-device identity generated on the chip, never exported, and used to authenticate to the cloud and to verify firmware.
- 03
Signed, measured, rollback-protected boot
A new bootloader verifying every stage against keys in the secure element, with anti-rollback counters so a downgraded image could not be reinstalled. Debug interfaces locked after provisioning, reopenable only with a device-specific signed token.
- 04
Updates the fleet could trust
Over-the-air updates re-engineered as signed, versioned packages over an authenticated channel, with staged rollout and automatic rollback on a failed boot. The hard-coded URL became a signed manifest.
- 05
Provisioning that survives the factory floor
A provisioning station for the contract manufacturer that injected nothing secret. Devices generated their own identity, presented a certificate signing request, and were enrolled against a production allow-list — so a cloned or grey-market unit could not join the fleet.
“We thought we needed a new board. We needed to switch on the chip we already had and stop trusting the factory with our keys.”
— Head of Hardware Engineering, Industrial IoT device manufacturer
Built with
Start with what Hardware Security could do for you.
Tell us about your situation and we will walk you through it against this engagement — what carries over, what is different, and what to expect.