Secure Update Readiness Assessment

Who it’s for

Firmware leads, engineering managers and product-security owners at companies whose devices take software updates after they leave the factory. It works well when the person answering knows how updates actually reach your devices today. If no one person knows, it’s a good excuse to get the right two or three people in a room.

What it asks

About a dozen multiple-choice questions, grouped into a few areas:

• Your product. What kind of device it is and how it connects.
• How updates get there. Over the air, by a technician on site, by USB, or not at all.
• Trust. Whether updates are signed, and whether the device checks the signature before it installs.
• Recovery. Whether a failed or bad update can roll back to a known good version.
• Scale and time. Roughly how many devices are in the field, and how long you plan to support them.
• Vulnerabilities and records. How your team hears about and handles security flaws, and whether you keep a software bill of materials (SBOM) for each release.

Most teams finish in a few minutes. You don’t need exact numbers. Ranges are fine.

What you get

A prioritized gap worksheet. Each gap comes with a plain note on why it matters and the kinds of engineering work that usually close it. Items that block everything else rise to the top. You can download the result as an action plan in PDF or CSV to share with your team.

Your results show up on screen right away, and the download is free. No email address is required.

How it works

Each answer maps to common secure-update practices covered in our guide to secure firmware update architecture. The method note at the bottom of this page lists what each question checks, which sources the scoring draws on, and the version and last-updated date of the assessment.

What it can’t tell you

The tool sees only your answers. It can’t inspect your devices or your code, and a short quiz can’t cover every product. Treat the output as a starting list for your engineers, not a final verdict.

This is not a legal or compliance determination. It doesn’t tell you whether a product meets the Cyber Resilience Act or any other law. Confirm your obligations with qualified counsel.

Next steps

Work through the guide on hardware root of trust and secure boot if signing or trust came up short. If the gap list is longer than your team can take on, you can request an introduction to an engineering firm we work with. That’s entirely up to you, and the firm, not us, would do the work. If you’re introduced to a partner firm and hire them, that firm may pay us a referral fee.

Method note

Version 1.0, Last updated Nov 10, 2026. The assessment asks 12 multiple-choice questions in six areas. Two questions (product type and fleet size) set context only. The others each check one practice from our guides, and an answer that misses the practice adds a gap:

• Blocks everything else: no way to update in the field; updates not signed, or not checked on the device. Every other control depends on these.
• High: signing keys on a developer’s machine; no automatic recovery from a failed update; older vulnerable images accepted; offline updates with weaker checks; no process for security flaws; unsure whether updates are signed.
• Medium: keys in CI without a separate approval, or unknown; no offline path for devices that are often offline; support period not written down; informal flaw handling; no per-release SBOM.

The practices come from our guides to secure firmware update architecture, secure boot and hardware root of trust, setting up a PSIRT and SBOM generation for embedded products, which cite their primary sources, including IETF RFC 9019 and RFC 9124 and the Cyber Resilience Act (Regulation (EU) 2024/2847). The priorities are our simplified planning judgment, not a legal ranking.