Device firmware security: find the problems, then fix them

Last updated: 2026-10-19

Softwsp closes the loop: scan, AI-assisted fix, re-scan as proof, then monitoring of every version you ship. AI-written findings cite their evidence and an engineer reviews them. MCP access, so your own AI agents can query findings and alerts, is coming. If you sell connected products, your firmware is a product in its own right. It contains open-source components that age, settings that were convenient in development, and update mechanisms that must be right the first time. We analyse it, explain what we find, and help you fix it.

The problem

Many device makers cannot easily keep firmware up to date, and the reasons are practical rather than careless.

• Economics. Margins are thin, a model sells for a year or two, and updates add cost but no revenue.
• No source code. Branded products often come from an ODM, and the brand holds only a binary file.
• Frozen SDKs. The chip vendor stops supporting an SDK, and the kernel is stuck on an old version.
• No way to rebuild. The engineer who built the release has left, and nobody can reproduce what is on the market.
• Fear of a bad update. Without rollback, one faulty update can mean thousands of returned devices.

At the same time, rules now ask for more. The EU Cyber Resilience Act brings vulnerability handling and an SBOM. Radio equipment in the EU falls under the RED delegated act and the EN 18031 standards. The UK product security rules have applied since April 2024. Buyers, retailers and importers are starting to ask for proof.

What we do

• Firmware scan. We unpack the image, identify the components and versions inside, and list the published vulnerabilities that affect them.
• Configuration checks. We look for hard-coded passwords, embedded keys, debug services left on, open network services and update mechanisms that are not signed.
• AI-BOM and secrets checks. We look for AI models, inference runtimes and API keys or tokens embedded in the image, and list them in an AI bill of materials alongside the software SBOM.
• Compliance mapping. We map findings to the relevant requirements, such as EN 303 645, EN 18031 and the UK rules, as an indicative view.
• Remediation. Where you hold the source code and can build it, we update vulnerable components, harden the configuration, write the patches and rebuild.
• Maintenance. We can look after older models for the support period you have promised, so your own R&D team can focus on the next product.
• Monitoring. When a new vulnerability affects a component in firmware you have already sold, we alert you, ranked by how likely it is to be exploited.

What you receive

• A summary report for management and a detailed report for engineers, with evidence for each finding.
• A software bill of materials in a standard format, which you can reuse for customers and regulators.
• A prioritised fix list with the official fix or a mitigation for each item.
• For remediation jobs: patches, a rebuilt image, a changelog, and a before-and-after scan, plus a rollout and rollback guide.

How it works

1. You upload the firmware under a confidentiality agreement.
2. Our engine analyses it automatically and an engineer reviews the output.
3. You receive the report and a short walkthrough call.
4. If you choose remediation, we agree the scope in writing, then patch, build, test in an emulated environment and scan again.
5. When real hardware testing is needed, you set up a small lab and we work through it remotely.
6. We hand over the result. You sign and release the firmware with your own keys.

What you prepare

• The firmware image of the version you actually sell.
• For remediation: the source code or SDK, and the build instructions if they exist.
• For hardware testing: two or three sample devices, a computer that stays on during the job, a network connection, and one engineer who can attend the test sessions. We send a checklist.

Scope and responsibilities

We are responsible for the analysis, the reports and the agreed fixes. You are responsible for the right to share the code with us, for signing and releasing the firmware, for rollout, for any re-testing needed for radio approvals, and for regulatory filings. Emulated tests are not a substitute for tests on real devices, and a report reflects the known vulnerabilities on the day of analysis. See our disclaimer.

Next step

If you would like to see what a report looks like on your own product, the Design Partner programme is the easiest way to start.

Join the Design Partner programme