Know what's inside.
A component inventory and SBOM for the image, including third-party and open-source software and versions where they can be identified.
00IoT security service
IoT Firmware Security Assessment
What's actually inside the firmware you ship, and what would a regulator, customer, or attacker find in it?
Pilot assessment: $3,500 · One product · One firmware image
Submit your firmware for reviewThe fixed-price pilot is subject to confirming that your firmware fits the agreed scope.
Firmware is where security claims meet reality. Third-party components, leftover debug credentials, and weak update mechanisms are rarely visible from a product datasheet, and they are exactly what the EU Cyber Resilience Act expects manufacturers to know about and manage. We analyze a firmware image and give you documented findings, a software bill of materials, and a prioritized remediation plan mapped to the requirements your market depends on.
01Review outcomes
Know what you ship. Know what it exposes. Know what to fix first.
Understand what's exposed.
Known vulnerabilities, embedded secrets, and insecure configurations, triaged by whether they are reachable and exploitable in your product, not just present.
Get evidence you can use.
Findings mapped to EU CRA Annex I essential requirements and ETSI EN 303 645, ready to feed your risk assessment and technical documentation.
02Who it is for
Firmware assessment for device manufacturers and product teams
- You sell or plan to sell connected products in the EU and need to start building CRA evidence.
- Your firmware includes an SDK, BSP, or open-source stack from a chip vendor or ODM that no one has fully inventoried.
- You don't have a current SBOM, or the one you have was never checked against the shipped binary.
- A customer, retailer, or OEM has sent a security questionnaire you can't fully answer.
- You acquired a product line or switched contract manufacturers and inherited firmware you didn't write.
- You want an independent baseline before a penetration test or certification effort.
You need a firmware image and someone who can answer questions about the product. You don't need a dedicated security team to begin.
03Assessment scope
What we review
Extraction and inventory.
We unpack the image, identify filesystems, bootloader and update components, and inventory the software inside it. Where the image is encrypted or packed in a way we can't unpack within scope, we report that as a finding and agree next steps with you.
Known vulnerabilities and components.
We match identified components and versions to public vulnerability data, then triage the results: which issues affect code that is actually present and reachable, and which are noise from version matching.
Secrets, credentials, and configuration.
We look for hardcoded passwords, private keys, API tokens, cloud credentials, debug services, default accounts, and insecure service configurations left in the image.
Cryptography and update mechanism.
We review how the firmware uses cryptography and how updates are delivered and verified, including signature checks, rollback handling, and whether update integrity can be bypassed.
Static analysis of one image establishes what is present in that build. It does not prove how the device behaves in the field, and it is not a penetration test of the hardware, app, or cloud service.
04Deliverables
What you receive
Software bill of materials
Track the components in the reviewed image in CycloneDX or SPDX format for your vulnerability handling process.
Triaged vulnerability report
See which known vulnerabilities are present, which are reachable, and which can be deprioritized, with the reasoning for each.
Secrets and configuration findings
Locate embedded credentials, keys, and insecure defaults, with the file path and the risk each creates.
CRA Annex I gap map
Connect each finding to the essential requirements it affects, to support your risk assessment and technical documentation.
Prioritized remediation plan
Assign fixes to firmware, supplier, or process owners, with verification steps for the next build.
Findings readout
Walk through the results with your engineering and compliance leads and agree on next steps.
For example, a finding might identify a cloud API key embedded in a configuration file, the services that key can reach, and the requirement it affects. That is recorded separately from a vulnerable library version that is present but not reachable.
05Pilot boundaries
A fixed scope you can plan around
The pilot is a static analysis of a firmware image you provide and are authorized to share. We work from the image and your answers to scoping questions, not from devices deployed with your customers.
The pilot excludes hardware teardown and debug-interface testing, mobile app and cloud API testing, dynamic testing on live devices, exploit development, and fixing the findings. These can be scoped separately as a Connected Device Assessment.
Fixed-price pilot: $3,500
One product, one firmware image (one version), up to 256 MB. Images with multiple separately updated processors or modules are confirmed during scoping.
Included in the pilot
- One scoping call.
- Extraction, component inventory, and SBOM for the image.
- Known-vulnerability triage, secrets and configuration review, and crypto and update-mechanism review.
- A written report, SBOM file, CRA Annex I gap map, and remediation plan.
- One findings readout.
Additional images or versions, hardware and app testing, retesting after fixes, and vulnerability handling process support require separate scope and pricing.
06How it works
How the assessment works
- 01
Confirm scope.
Tell us about the product, the image, and where it's sold. We confirm the pilot fits and agree the handling of your firmware before you send anything.
- 02
Submit the image securely.
Upload through our verified submission portal. Images are stored encrypted, access is limited to the analyst, and we delete them after the engagement unless you ask us to retain them.
- 03
Analyze and triage.
We extract, inventory, and review the image, separating confirmed findings from issues that need your input or further testing.
- 04
Walk through the priorities.
We review the report together and agree who will fix what, and how the fix will be verified.
07Method
Grounded in the requirements your market applies
The assessment maps findings to the essential cybersecurity requirements in Annex I of the EU Cyber Resilience Act and to the provisions of ETSI EN 303 645, the baseline standard for consumer IoT security. Where your product falls under the EU Radio Equipment Directive, findings can also be referenced against EN 18031.
The pilot provides evidence and a starting point for your conformity work. It is not a certification or a conformity assessment, and it does not replace your own risk assessment.
08Questions
Frequently asked questions
Is this a penetration test?
No. The pilot is a static analysis of one firmware image. It shows what is present in the build and where the risks are. Testing the device, its interfaces, its app, and its cloud service is a separate Connected Device Assessment.
What do you need from us?
A firmware image as it ships or as delivered through your update channel, basic product information, and someone who can answer questions about the hardware and update process. Source code is not required.
How do you protect our firmware?
Images are submitted through a verified upload portal, stored encrypted, accessed only by the assigned analyst, and deleted after the engagement unless you request retention. We can sign an NDA before you submit.
What if our image is encrypted?
Tell us during scoping. If we can't extract the image within the pilot's scope, we report what we could determine and discuss options, which may include providing a decrypted build.
Does this make us CRA compliant?
No single assessment does. The CRA requires risk assessment, secure design, vulnerability handling, and documentation across the product's lifecycle. The pilot gives you a component inventory, findings, and an Annex I gap map that feed into that work.
Our firmware comes from a chip vendor or ODM. Is that a problem?
No, that's one of the most common reasons to do this. Inherited SDKs and board support packages are frequent sources of outdated components and leftover credentials, and as the manufacturer you're responsible for what ships.
Does the price include fixing the findings?
The pilot covers the assessment and listed deliverables. Remediation support and retesting a fixed build are scoped separately.
09Start a conversation
Start with the firmware you ship today
Tell us about the product and where it's sold. We'll confirm whether the pilot fits and how to submit the image.
Looking for another service? View all services.