Industrial and Embedded Systems
IoT, Embedded System and Hardware Security
Anyone who buys your device can examine it for months. We do this analysis before your product ships. We extract the firmware and test the update mechanism and cloud connection. The key question is whether a key from one device can access all devices and your cloud service.
IoT, Embedded and Hardware Security
A hardware flaw in a deployed device may not be fixable by an update. At the design stage, a board revision can address it. From December 2027, the EU Cyber Resilience Act requires products to be placed on the EU market without known exploitable vulnerabilities.
The need
When organizations need it
- Before the final hardware revision is approved for mass production.
- When you need to demonstrate your product meets the Cyber Resilience Act for the EU market.
- Before adding over-the-air updates to your devices.
- Before connecting a device purchased in large quantities to your corporate network.
Questions
What this work answers
- Is a key or password extracted from one device valid on others?
- Will the device boot with modified firmware?
- Does the device verify the source and integrity of the update package?
- Are maintenance and debug interfaces disabled after manufacturing?
IoT, Embedded and Hardware Security
What we do
-
IoT Product Security Assessment
We examine the device, mobile app and cloud service together. We show how a weakness in one can affect the others.
-
Firmware Security Analysis
We unpack the firmware and search for embedded passwords and keys. We also review third-party components.
-
Embedded Communication Security
We test authentication and encryption in device communication with the cloud and mobile app. We also check if messages can be altered.
-
Update and OTA Security
We test if the device verifies the update signature. We also check rollback protection and the update server's permissions.
-
Device Identity and Key Storage
We review how device-unique keys are loaded during production. We check if the device stores them in secure hardware.
-
Hardware and Debug Interface Analysis
We test whether maintenance interfaces like JTAG and UART are disabled after manufacturing. We also check if data can be read from memory chips.
-
Secure Boot and Chain of Trust
We test whether each stage, from bootloader to application, verifies the next. We check if the device boots with modified firmware.
-
Physical Access Risk Analysis
We assess which data and systems can be accessed from the board by someone opening the device.
-
Vehicle and CAN Bus Communication Security
We check if messages are authenticated on in-vehicle networks. We test whether critical control units are accessible from the telematics unit.
-
RF and Wireless Protocol Analysis
We test authentication and encryption in proprietary radio protocols. We check if a replayed recorded signal is accepted.
Scope
The scope includes the product as sold, and its associated mobile app and cloud service. At least two devices are needed for testing. If possible, we also request a development board and technical documentation.
How we work
First, we approach the device like an attacker, without documentation. We examine the board, identify interfaces and extract the firmware. Then we work with your engineering team. We determine the root cause of each finding and which models are affected.
Deliverables
What you receive
For each finding: whether it affects a single device or the whole model, and whether the fix requires a software update or hardware revision. If targeting the EU market, a table mapping findings to the Cyber Resilience Act's essential requirements.
NoteTests that could damage the device, such as removing a memory chip, are planned separately. The number of devices to be used is agreed in advance.
Related services
Schedule Product Security Meeting
Tell us your objective and critical systems. We will settle the right scope in the first meeting.
Schedule a Meeting