AnonymousSign in
Start from a neutral baseline and add what matters to you. Criteria are labeled by source — the platform baseline is architecture-neutral; buyer-contributed criteria are shown separately.
This evaluation is stored in your browser only. We cannot see it, and it is not tied to any account. Save it to a link or create an account to keep it across devices — you can export it at any time either way.
Signing up adds sharing with your team, sending this as an RFP to vendors, and private document sharing. Nothing above is taken away, and nothing here is sent anywhere until you choose to.
Look for named architecture/RTOS coverage and both static + emulated analysis — static-only tools miss runtime behavior, and narrow architecture support quietly excludes much of a real device fleet.
Binary-level SBOM accuracy varies wildly between tools; strong answers cite a measured identification accuracy on reference images, not just 'we generate SBOMs.'
CVE-in-component lists without reachability/configuration context produce overwhelming noise — look for exploitability triage specific to the firmware build.
Hardcoded credentials and leftover debug access are the classic embedded findings — look for concrete detection classes, not generic 'vulnerability scanning.'
No buyer-contributed criteria yet
Verified buyers can suggest criteria (anonymized before pooling).
Update-mechanism weaknesses are how embedded fleets get compromised at scale; strong answers assess the whole update path (signing, transport, rollback protection), not just the image at rest.
Regulatory drivers (CRA especially) are why many buyers are in this category now — look for named-framework report mapping, not generic PDF exports.
Most buyers run devices they didn't build; binary-only analysis of supplier firmware plus fleet version-drift tracking is the practically valuable capability.
Look for a stated turnaround figure and real CI integration — an analysis that takes days or requires manual upload won't be run on every build.
Look for transparent, predictable scaling economics tied to realistic release cadence and product-line growth, not just a per-image price that becomes unpredictable at scale.
Strong answers describe a real forensic-analysis capability for an actual field incident, not just pre-release scanning — this is the highest-stakes use case for a device already suspected compromised.
Fleet-deployment correlation (knowing exactly which field devices need an update) is materially more actionable than firmware-image analysis alone with no connection to what's actually deployed where.
Firmware analysis and hardware-security assessment are genuinely different disciplines — a vendor should be explicit about which they provide rather than implying comprehensive device security coverage.
Trend-over-time reporting is a distinct capability from a per-image analysis report — confirm this exists as a maintained, exportable, fleet-wide report.
Look for genuine integration into a unified risk view; a standalone firmware-security dashboard disconnected from the broader VM picture creates real reconciliation burden for the security team.
A high false-positive rate creates real alert fatigue and erodes trust — ask for a real, customer-validated accuracy figure and a suppression/correction workflow.
A device maker with an acquired or diverse product portfolio needs genuine multi-architecture/multi-RTOS depth, not a tool optimized narrowly for one homogeneous line — ask for a concrete example of heterogeneous-fleet coverage.