Embedded Security Testing for Firmware & Devices

Why embedded security is harder to investigate

Embedded security problems rarely depend on code alone. Firmware version, device state, interfaces, network conditions and hardware behavior can change how the same issue appears.

That makes reproducibility especially important: the device and environment behind a security-sensitive result need to stay attached to the run.

Security areas that may depend on the device context

•

Firmware behavior

Code-level issues, firmware version and update-related behavior.

•

Communication interfaces

Behavior across device-to-device, device-to-server and other communication boundaries.

•

Abnormal inputs and device states

Scenarios that appear only under particular input, state or configuration conditions.

•

Hardware-dependent behavior

Security-sensitive behavior affected by peripherals, drivers or interaction with the target device.

•

Configuration-dependent behavior

Cases where the same software behaves differently under another device or network configuration.

Midair

How Midair investigates embedded security

On a device, the scenario that reproduces the behavior matters as much as the finding that points to it.

1

Analyze the code

Visao

Find code-level issues before execution, including confirmed examples such as unsafe memory use, integer overflow and violations of project-specific rules.

2

Reproduce the device scenario

TS Factory

Run the relevant scenario against the device, firmware version and configuration that produced the security-sensitive behavior.

3

Capture runtime evidence

Delta

Collect logs, system events and resource data while the scenario runs.

4

Keep the context

Midair

Connect the code finding, firmware version, device configuration, test conditions and runtime evidence, then rerun the same setup after a change.

Reproduce the same security-sensitive behavior

Device A + Firmware 2.4.1 + Interface / network state X + Configuration Y + Input Z → security-sensitive result

After a change

Same setup → Rerun → Compare evidence

Where this workflow fits

•

Connected devices and IoT products

Firmware and software exposed through network or device interfaces.

•

Routers, gateways and network hardware

Devices whose behavior depends on traffic, firmware and communication state.

•

Firmware-heavy embedded systems

Where a security-sensitive result can depend on the exact firmware build and target hardware.

•

Multi-device environments

Where behavior changes depending on other devices, nodes or configuration.

•

Security-sensitive embedded software

Where a code finding needs to be checked against behavior on the actual device.

Related capabilities

Cybersecurity testing

Connect security-relevant code findings, tests and runtime evidence

Firmware testing

Reproduce firmware behavior with its device and test configuration

Network hardware testing

Test connected devices under real traffic and network conditions

Hardware-software integration testing

Investigate behavior where software, firmware and hardware meet

Static analysis for embedded systems

Find code-level issues before hardware integration

From our engineering work

Embedded testing diary

Embedded testing diary #2: Reproducible tests

Resets, device state, network isolation and run fingerprints: what it takes for two runs on a device to be comparable.

Start your pilot

Start with one device, firmware version and security-sensitive scenario, and keep the code findings, test conditions and runtime evidence connected in Midair.

To get started

Community

€0

Run Visao and TS Factory on a shared instance and review the findings.

Embedded security testing for firmware and connected devices