A product and component record
Recognised components remain tied to the image and product where they were identified, supporting a cross-product investigation.
Connected buildings and consumer devices
Track shared firmware components across connected product ranges.
Cameras, locks, sensors, gateways and building controllers often reuse vendor platforms and libraries. FDIE helps teams review those components and the firmware changes that affect them, then retain evidence for the people responsible for the next device release.
A practical scenario
A shared vendor SDK appears in several connected products
A new advisory or update can create questions across the range. Teams need to distinguish the products using the recognised component, inspect credentials and services in the image, and check whether the proposed firmware update changes the relevant evidence.
- Bring to the review
- Authorised images for the relevant products, release identifiers and the supplier context behind the shared platform.
- Work towards
- A component-led investigation across analysed images, product-specific follow-up and a reviewed update record.
The team's working process
Review shared components without losing individual product context
Identify the recoverable software and configuration
Inspect components, credentials, supported services and update-related evidence in each image. Preserve paths and version confidence, particularly where vendor names or static linking make identification less certain.
Assess the product's relevant controls
Review applicable technical mappings such as ETSI EN 303 645, EN 18031 or NIST IR 8259A. Keep radio, privacy, hardware and cloud-backend questions in the wider product assessment rather than assuming firmware checks answer them.
Follow the update through the release pair
Compare candidate and earlier images, inspect changed components and available functions, and revisit the previous triage. Record the current reasoning before sharing VEX or customer-facing assessment material.
The result of the work
Evidence for the next product decision.
An assessed control view
Technical checks, manual review and unassessed scope make the available assurance evidence easier to interpret.
A release decision trail
The update comparison and analyst's reasons help the team explain what changed and what still needs follow-up.
A focused evaluation
Test the workflow with evidence your team already understands.
Choose two products that share a platform and one related firmware update. Verify that the component relationships and coverage match engineering knowledge, then review the output with the product-security and release owners.
Agree the participating team, input scope and expected deliverable before expanding the rollout. The most useful evaluation shows how a real owner investigates and acts on the result.
Practical questions
Planning for connected buildings and consumer devices.
Does FDIE test the device's cloud backend?
Firmware analysis may reveal relevant endpoints or configuration, but it is not an assessment of the backend service, its current configuration or customer accounts.
Does runtime analysis reproduce every peripheral?
No. Execution depends on the supported environment. Hardware interfaces and custom peripherals can prevent or limit the run.
Can we maintain separate product releases?
The firmware library and comparison workflow preserve product and version context. Use related releases and inspect comparable assessment coverage.
FDIE · next step
Start with one authorised firmware assessment.
A component-led investigation across analysed images, product-specific follow-up and a reviewed update record.
Paid at checkout. 14-day money-back guarantee on the first payment if three or fewer new images have been analysed.