Why an embedded firmware security review is often required before launch
A firmware security review analyzes the device image and everything inside it, following the OWASP Firmware Security Testing Methodology (FSTM), and it does not need the device on a production network. The work starts from the firmware file, an update package or a copy of the filesystem, so it can run in a lab while the product is still in development. Teams usually commission it when a product launch is approaching, when a customer security questionnaire asks for evidence about firmware, when a Cyber Resilience Act readiness program needs technical input, or when an insurer or acquirer asks how the device is secured. The review answers a narrower question than a full device test: what does the image itself reveal about the product's security before it reaches the field?
The review targets four risk categories that appear repeatedly in connected products. The first is credentials and keys left in the image, such as default accounts, hardcoded passwords, certificates with private keys and API tokens embedded in scripts or configuration files. The second is vulnerable third-party components, where the review identifies libraries, operating system packages and web servers in the filesystem and checks them against known vulnerabilities, which is why an accurate software bill of materials helps. The third is update integrity, meaning whether the device verifies that an update is signed by the manufacturer before installing it, and whether the update mechanism can be abused to load altered code. The fourth is exposed services, such as debug interfaces, network daemons listening by default and management ports that were meant for manufacturing only. Each of these maps to provisions in ETSI EN 303 645 V3.1.3, including no universal default passwords, keeping software updated, and minimizing exposed attack surfaces.
Regulators and buyers now expect this evidence as a matter of course. The EU Cyber Resilience Act applies from 11 December 2027, and its manufacturer reporting obligations under Article 14 apply from 11 September 2026. The Commission's CRA FAQ lists firmware analysis among the possible additional security tests when components are integrated, so a firmware review is a natural part of building the technical file. Before scoping, confirm with your compliance lead which obligations apply to your product category and which evidence your customers will ask for, then ask the testing provider to map each finding to the relevant provision so the results can be reused in both launch and regulatory work.
What can be in scope for a firmware security review
A firmware review is only as useful as its boundaries. The artifacts under review, the product variants they cover and the access the tester receives all shape the depth of the work and the evidence it produces. Agree each of these decisions in writing before testing starts.
Firmware images and update packages
A full firmware image is the primary artifact: the packed bundle a device flashes, including its partition layout and signature blocks. Update packages are reviewed separately because they carry the delivery path, version checks and any rollback logic. Ask the client which images come from vendor downloads, which come from their own build pipeline, and whether the same release is shipped to every product variant.
Bootloaders and boot chain
The bootloader decides what code runs first, so weaknesses here undermine every later control. Reviewers check whether each stage verifies the next, whether debug and recovery interfaces remain enabled in the shipped build, and whether the boot configuration can be changed from the file system. Confirm early whether the bootloader source is available or only the compiled binary.
Extracted filesystems and configuration files
Once a filesystem is extracted, the review covers init scripts, web interface assets, service definitions, certificates and configuration files. These files often hold default accounts, debug settings and exposed services that the device never documents to its owner. Ask whether the client can supply a known-good configuration for comparison, since it speeds up separating intended settings from defects.
Companion components in the image
Many images bundle third-party binaries, libraries, web servers and proprietary agents that run alongside the main application. Each one inherits its own patch history and default settings. Ask the client for the component list or a software bill of materials, and confirm which packages the vendor modified, because modified upstream code needs closer reading than stock packages.
Product variants and firmware versions
The review must name the exact firmware versions and hardware or product variants it covers. Variants often share a base image but differ in radios, enabled services or keys, so a finding on one may not apply to another. Agree whether testing covers the current release only, supported older releases or a defined version range, and record what is excluded.
Source access, lab devices and excluded functions
Source code or build artifacts make the review faster and more precise, while a lab device allows dynamic analysis and emulation without touching production units. Decide whether the client provides a device, a development board or only images, and whether any functions such as cryptographic hardware, radio stacks or physical interfaces sit outside the agreed scope. Document each exclusion in the statement of work.
How a firmware security review moves from image to written report
The sequence turns a firmware image obtained within agreed rules into a documented set of findings, each traced to a stage of the OWASP FSTM and a test case from the OWASP ISTG, with a retest path for the fixes. Each phase closes with a defined output so the client can see what was examined and what remains open.
Agree scope and rules of engagement
DeployOpen and the client agree in writing which firmware images, device variants and components are in scope, which stages of the OWASP FSTM apply, and which activities are excluded. The rules of engagement cover whether testing uses only images supplied by the client or also images obtained from the vendor, whether a physical device is available, and whether runtime analysis or binary exploitation is permitted at all. Safety and uptime constraints are recorded here, because a firmware review on a bench copy carries different risk from any test touching a live controller. The step closes when both parties sign the scope and the rules, and the client confirms who approves any change to them.
Gather information and obtain firmware
The first two FSTM stages establish what the device is and where its firmware came from. The reviewer collects vendor documentation, release notes, model and hardware revision data, and public advisories, then obtains the image through the route agreed in scope, such as a client-supplied file, a vendor download or an update package from the client's own asset inventory. Each image is recorded with its source, version identifier and cryptographic hash so later findings can be tied to an exact build. The step closes with an inventory entry for every image in scope, and any image that cannot be sourced is logged as a limitation for the report.
Analyze the image and extract the filesystem
The reviewer examines the image structure, identifies the packaging, compression and any encryption, and separates the bootloader, kernel and root filesystem where the format allows. Where the image can be unpacked without bypassing protections the scope does not allow, the filesystem contents are extracted for analysis. The output is a map of partitions and a record of anything that could not be extracted, with the reason stated. The step closes when every in-scope partition is either extracted or documented as opaque, so the client knows the coverage of the review before any findings are drawn.
Review static content for credentials and keys
Working from the extracted filesystem, the reviewer checks configuration files, startup scripts, certificates, private keys, default accounts and embedded secrets against the test cases in the OWASP ISTG. Findings are grouped by weakness category, such as hardcoded credentials, shared keys across units, weak certificate handling and default settings that conflict with ETSI EN 303 645 provisions on universal default passwords and secure storage of security parameters. Each candidate is verified and rated for exposure. The step closes with a verified list of secret and configuration findings, with false positives removed and the basis for each finding recorded.
Assess outdated components and update integrity
The reviewer identifies the software components in the filesystem and their versions, then matches them against public vulnerability records and the vendor's own advisories. The same stage examines how the device validates updates, including whether the image signature is checked, which key anchors trust and whether rollback protection exists. These checks map to ETSI EN 303 645 provisions on keeping software updated and ensuring software integrity. Where the client has an SBOM, the reviewer compares it with the observed components. The step closes with a component inventory, a list of known-vulnerable versions with their advisory references, and a documented view of the update chain.
Emulate the firmware where scope allows
Where the scope permits and the filesystem supports it, the reviewer runs the firmware in an isolated emulated environment that is not connected to any production network. Emulation lets the reviewer observe service startup, listening ports and default configuration without the physical device. Limitations are expected, because peripheral hardware and some hardware-dependent behavior often cannot be reproduced, and these limitations are written into the report. The step closes with an emulation record stating what started, what did not, and which findings can or cannot be confirmed in emulation.
Run dynamic and runtime tests within agreed limits
Dynamic analysis exercises the emulated or bench device through its exposed services, such as network interfaces, management endpoints and update mechanisms, using the test cases in the OWASP ISTG. Runtime analysis and binary exploitation stages from the OWASP FSTM are included only where the agreed scope and rules permit them, and any such work is limited to isolated lab targets with a rollback plan. Safety and uptime constraints from the first step apply throughout. The step closes with dynamic findings linked to observed behavior, and a list of any test that was declined or stopped because it fell outside the rules.
Deliver the written report and support retest
The report presents each finding with its FSTM stage, ISTG test case reference, affected image version, evidence, severity rationale and recommended remediation, and it states the coverage, limitations and rules under which testing ran. The client reviews the draft for factual accuracy, then receives the final report. After the vendor or client ships fixes, DeployOpen retests the affected images under the same scope and records each finding as resolved, partially resolved or open. The report does not constitute a certification, and any use in a Cyber Resilience Act or other compliance file is for the client's assessor to determine. The step closes with the signed final report and a retest record.
Which firmware weaknesses the review looks for and why they matter
This table compares six weakness categories the firmware review looks for, showing what each one looks like inside an extracted image and why it matters to the device and its owner. Read each row as a question to ask of the device: where the weakness would sit, and which ETSI EN 303 645 provision it touches.
| Weakness category | What it looks like in a firmware image | Why it matters for the device and owner |
|---|---|---|
| Hardcoded credentials and cryptographic keys | Passwords, API tokens, private keys or certificates stored as readable strings or binary blobs in the filesystem, configuration files or bootloader. | Anyone who obtains a single firmware file can reuse the secret across every unit of the same model. Relates to provision 5.1 No universal default passwords and secure storage of sensitive security parameters. |
| Default or shared accounts | Built-in administrative or service accounts with the same credentials on all units, or login logic in the init scripts and web server configuration. | Owners cannot change what they never knew existed, so fleet-wide access becomes possible. Relates to provision 5.1 No universal default passwords. |
| Outdated or vulnerable third-party components | Bundled libraries, daemons or operating system packages with version strings that predate current vendor fixes, or no version information at all. | Known flaws in embedded components remain exploitable until the vendor ships a fixed build. Relates to provision 5.3 Keep software updated and to the need for a usable software bill of materials. |
| Weak update integrity and signature checks | Update routines that accept packages without verifying a signature, verify only a checksum that the attacker can recompute, or fall back to unsigned images. | A device that installs unverified code can be given malicious firmware by anyone able to reach its update channel. Relates to provision 5.7 Ensure software integrity. |
| Insecure filesystem permissions and leftover debug interfaces | World-writable configuration or binaries, setuid programs with unnecessary privileges, or serial console, JTAG or debug services left enabled in the image. | Local or network users gain elevated control over the device, and debug access bypasses other controls. Relates to provision 5.6 Minimize exposed attack surfaces. |
| Sensitive data stored unencrypted | Session tokens, user records, Wi-Fi keys, telemetry credentials or personal data kept in plain files, logs or unprotected flash partitions. | Data extracted from one device exposes its owner, and any connected cloud or companion app that trusts the stored value. Relates to provision 5.4 Keep personal data secure and secure storage of sensitive security parameters. |
How firmware is tested without the device on a production network
Most of the work in an embedded firmware review happens offline, on a copy of the firmware image. The tester obtains the image through the vendor, a published update package or, where the client owns the device, a dump taken in a lab. Extraction, filesystem analysis, credential and key searches and component version checks all run against that copy. Nothing in this path touches a live device, a production network or a process that a plant or building depends on. That separation is the first control the client should expect: the test scope should state where the image came from, where it is stored, who can access it and when it is destroyed.
Emulated testing runs the extracted filesystem in a controlled lab so that network services, web interfaces and update handlers can be exercised without hardware. It is useful for finding exposed services, default configuration problems and authentication weaknesses that appear in software. Its limits matter to the decision. Emulation may not reproduce hardware peripherals, bus behavior, timing, radio interfaces or the way a device boots from its own storage. Findings that depend on those behaviors need a lab unit, and some findings only become confirmed after a check on the physical device. The report should label each finding as emulated or hardware-confirmed so the client knows which ones need a retest on a bench.
To make this work, the client must choose one of three inputs: a lab unit the tester can keep on an isolated bench, an agreed test environment such as a segregated lab network, or a vendor-supplied image with permission to analyze it. Each input needs written permission from the device owner, and the vendor's terms should be checked where firmware is licensed. For operational technology, the reason for this offline approach comes from NIST SP 800-82 Rev. 3, which recommends security countermeasures that keep performance, reliability and safety requirements intact. Any active test against a controller, sensor or building system therefore belongs in a planned window with an operator present, and the offline work should absorb as much of the analysis as possible.
What drives the cost and duration of a firmware review
This table compares the factors that change the effort of an embedded firmware review, who carries the work for each one, and whether it is paid once or recurs. Read each row alongside the artifacts you can provide, because most of the effort reduction comes from what the client hands over before testing starts. DeployOpen does not publish a price list, and a quote follows from the written scope.
| Cost driver | Who does the work and what is one-time or recurring | What the client can do to reduce effort |
|---|---|---|
| Number of firmware images and product variants | DeployOpen triages each image and variant against the same FSTM stages. Each additional image or hardware variant is a separate analysis, usually one-time per release line. | List every model, hardware revision and regional variant in scope, and state which ones share a codebase so overlap can be tested once. |
| Image complexity (filesystem size, binaries, custom versus open-source components) | DeployOpen extracts and analyzes the filesystem and binaries. Large filesystems and many custom binaries add analysis time, one-time per image. | Provide the unpacked filesystem or an accurate build output, and flag which binaries are proprietary and which are upstream open-source packages. |
| Availability of source code and build artifacts | Access to source and build scripts lets DeployOpen compare compiled output with its origin and reduce guesswork. The client provides this, and it is typically one-time setup. | Supply source for the scoped firmware, build configuration, toolchain versions and a signing key inventory without sharing private keys. |
| Need for emulation versus a lab device | Emulation requires work to reproduce the target environment, which can be substantial for some architectures. A physical lab device is used when emulation does not reproduce hardware behavior. Both are one-time setup per platform. | Provide a development board, debug access permitted by policy, or a test unit, and confirm whether the device can be reset or reflashed during testing. |
| Dynamic and runtime analysis depth | Dynamic and runtime work covers services, network interfaces and update behavior while the firmware runs. Depth is set in the written scope and is the largest variable in effort. | Agree a bounded list of services, interfaces and update paths to test, and provide a running test setup with logs and documentation of expected behavior. |
| Reporting depth and audience | Report depth ranges from a technical findings list to evidence formatted for an auditor or a customer's security review. Drafting and review time is paid once per engagement. | State up front who receives the report and what evidence format they require, such as mapping to ETSI EN 303 645 provisions. |
| Retesting after new firmware releases | Retesting a fixed finding is smaller than a full review, but each new release that changes the image is a repeat of the affected stages. This is recurring if the product keeps shipping updates. | Keep a clean image history with release notes, an SBOM for each version, and a change log so only affected components need retesting. |
Which frameworks expect firmware testing and what each one asks for
Several frameworks reach firmware directly, either as baseline requirements for connected products or as component and environment requirements for industrial systems. Each one asks for different evidence, so the firmware review scope should start from the framework your assessor or customer will apply.
ETSI EN 303 645 baseline provisions
ETSI EN 303 645 V3.1.3 sets baseline requirements for consumer IoT, and several provisions map directly to firmware: no universal default passwords, software kept updated, and secure storage of sensitive security parameters. A firmware review checks whether credentials and keys are absent from the image and the filesystem, whether the update mechanism is authenticated, and whether secrets are protected at rest. Confirm with your assessor which provisions apply to your product category.
EU Cyber Resilience Act obligations
Regulation (EU) 2024/2847 requires manufacturers of products with digital elements to meet essential cybersecurity requirements, and reporting obligations under Article 14 apply from 11 September 2026 under Article 71(2). The Commission's FAQ lists firmware analysis among possible additional tests when integrating components. Firmware review produces evidence of update integrity, component currency and vulnerability handling, which supports the technical file. Confirm the exact requirement and timing with your notified body or legal counsel.
ISA/IEC 62443 component requirements
ISA-62443-4-2 defines technical security requirements for industrial automation and control system components, so a firmware review of an IACS device tests against those component requirements. Reviewers look at authentication, secure update paths, hardcoded credentials, and whether the firmware exposes unnecessary services. The output maps findings to the requirement areas the component supplier or integrator must demonstrate. Confirm with your certification body which component security level and requirements apply.
NIST SP 800-82 Rev. 3 for OT
NIST SP 800-82 Rev. 3, published in September 2023, guides OT security across industrial control systems, building automation, transportation and physical access control. It recommends countermeasures that keep performance, reliability and safety intact, so firmware findings are judged against operational impact. A firmware review in an OT setting documents how a device's firmware affects its place in the control architecture, and recommends fixes that can be scheduled within maintenance windows. Confirm how your asset owner and operators want findings prioritized.
What the client prepares before a firmware review starts
The most useful preparation is a complete set of firmware images with its release history, so the reviewer can compare versions, trace when a vulnerable component entered the build and confirm which images are still in the field. Provide every product variant that shares the codebase, with its hardware revision and bootloader notes, because a flaw that looks fixed on one variant is often present on another. Where the vendor or open-source component inventory exists, share it or a software bill of materials. If no SBOM exists, say so early: the reviewer will need to identify components from the filesystem itself, which takes longer and produces less certain version data. Name a point of contact who understands the build pipeline and can answer questions about how images are signed, where keys live and which configuration differs between releases.
Agree on the test hardware before the work begins. Confirm whether a lab device is available, whether it can be reflashed and whether the reviewer may attach debug interfaces to it. If emulation is part of the plan, confirm which parts of the firmware the client expects to run without physical hardware, since some peripherals will not behave the same way in an emulator. Put handling rules for proprietary code and cryptographic material in writing: where files may be stored, who may receive them, whether the reviewer may keep extracted filesystems after the engagement, and how they are destroyed. Name one owner on the client side who triages findings, decides severity acceptance and assigns fixes. Without that owner, reports tend to stall at the first finding that needs a product decision.
Plan for credentials and keys the review will find. Hardcoded passwords, private keys and API tokens in a firmware image should be treated as compromised from the moment they are extracted, so the client should decide in advance who rotates them, in which systems and on what timeline. Rotation must cover the device population already deployed, not only the next build, and it may require an update channel that can reach those devices. Scope changes, such as adding a variant, a debug interface or a companion cloud service, should be recorded as written amendments to the agreed scope before the work changes, with any effect on timing or deliverables noted. Ask the provider to confirm how it records these amendments and how it handles credentials found outside the agreed scope.
What a firmware review report contains and whether it satisfies an auditor or customer
A firmware review report is evidence that your assessor or customer weighs against their own requirements. Each section below answers a question that party will ask, and the scope statement determines how far the findings can be relied on.
Executive summary for leadership
A short section for executives and product owners that states what was reviewed, the overall risk picture, the most significant findings and the decisions that need an owner. It avoids technical detail so a board member can read it in one sitting. Check that it names the firmware versions covered and the date of testing, since a summary without those details cannot be tied back to a release.
Technical findings for engineers
Each finding describes the weakness category, the affected component or stage, the conditions under which it was observed and the evidence that supports it. Reproduction context explains what an engineer needs to verify the issue, without exploit code or step-by-step attack instructions. Ask whether the report includes enough detail for your firmware team to confirm each finding in their own build.
Severity ratings and their basis
Every rating should show how it was assigned. Look for the criteria used, such as exposure of the device, the preconditions an attacker would need and the impact on safety, availability or data. A rating without a stated method cannot be compared across findings or defended to an assessor. Confirm whether your assessor expects a specific scoring system before testing begins.
Mapping to test cases and stages
Findings should be traceable to the OWASP FSTM stages or OWASP ISTG test cases that produced them, and to the ETSI EN 303 645 provisions they relate to where those apply. This mapping shows the assessor what was covered, including areas where no issue was found. Ask for a coverage table that lists stages tested, stages not applicable and the reason for each exclusion.
Remediation guidance and retest results
Remediation guidance explains the expected fix for each finding, such as replacing a component, rotating a key or correcting update verification, and notes any dependency on the vendor. The retest section records which findings were closed, which remain open and the firmware version that was retested. Ask whether retest results are issued as a separate, dated record so the original report stays unchanged.
Scope, limitations and tested versions
The scope statement lists the firmware images, hardware revisions, emulation setup and tools used, and it states what was excluded. Limitations matter because emulated testing cannot reproduce every peripheral or timing condition of the physical device. Acceptance is decided by your assessor or customer, so confirm the report format they expect before the scope is signed.
What buyers ask before commissioning a firmware security review
Does the device have to be on our production network for a firmware review?
No. A firmware review works from the firmware image itself, so the analysis runs offline in a DeployOpen lab or in a controlled environment you provide. The work covers obtaining and unpacking the image, reviewing the filesystem, checking for hardcoded credentials and keys, identifying outdated components and examining how updates are signed and verified. Where dynamic testing needs a physical unit or a running instance, the lab setup is agreed in the written scope, and any connection to a live network is planned with your operations team before testing starts. Production systems stay out of the critical path for the static work.
Can our own engineers run a firmware security review in-house?
Yes, if your team has the skills, tooling and time to cover the same ground. The OWASP Firmware Security Testing Methodology (FSTM) has nine stages, from information gathering through runtime analysis and binary exploitation, and an in-house team should be able to show coverage of each one that applies to your device. Consider two questions before deciding. First, whether the team has the depth to judge findings on hardware-specific components. Second, whether an internal reviewer can give an independent view of the product they built, which some auditors and customers will ask about. Many organizations use internal teams for routine checks and bring in an outside reviewer for release gates or assessments.
What do we need to provide before a firmware review starts?
The main inputs are the firmware images under review, including every version you want covered, and documentation of the device's architecture, components and update process. You should also provide the names of any third-party or open-source components you know of, the current bill of materials or software list if one exists, and details of how updates are distributed and signed. For dynamic testing, you need access to a test unit or a lab-safe image, a list of interfaces in scope and written permission from the owner of any connected cloud or companion service. Confirm in the quote exactly which of these items your team must supply and by when, because gaps in these inputs are a common cause of delay.
How is the cost of a firmware security review set?
The cost is set from the written scope, and DeployOpen does not publish a price list. The main drivers are the number of firmware images and versions, the complexity of the filesystem and the number of components, whether dynamic or emulated testing is included, the hardware and lab setup needed, and the depth of reporting your auditor or customer expects. Engagements are typically fixed-scope, so the quote should state the deliverables, the images covered and any items excluded. Ask whether the price covers a single review or ongoing work, and whether retesting is included. Cost is one-time for a defined review and recurs only if you buy a retainer for continuous testing.
How long does a firmware security review take?
The duration depends on the number of firmware images, how deep the review goes and whether emulation or dynamic work is needed, so it is confirmed in the written quote rather than fixed in advance. Static review of a single image moves faster than a product line with many versions and hardware variants. Dynamic and emulated testing add setup time, and any work that needs a physical unit depends on when that unit is available. To plan well, ask for a timeline that separates intake, analysis, testing, reporting and any agreed review of findings, and check which steps depend on your team's input.
Is retesting included after a firmware review?
Retesting is usually priced separately, but this depends on the written scope, so confirm it before signing. A typical approach is to agree in the quote whether one verification round covers findings that have been fixed, which firmware versions the retest will examine and how fixes are verified. Retesting a new firmware build is a fresh review of changed components, so it may need its own scope. Ask whether retesting is priced as a fixed item or as part of a retainer, and whether it includes checking the update integrity and key handling changes that often follow a finding.
Will a firmware review report satisfy CRA or ETSI evidence requirements?
A firmware review produces technical evidence that supports conformity work under the EU Cyber Resilience Act, Regulation (EU) 2024/2847, and checks against the baseline provisions of ETSI EN 303 645 V3.1.3, such as default passwords, secure storage of security parameters and software integrity. Whether that evidence is sufficient is decided by the independent assessor, auditor or certification body you work with, not by DeployOpen. The Commission's CRA FAQ lists firmware analysis and penetration testing among possible additional tests when components are integrated, so confirm with your assessor which tests they expect. DeployOpen does not issue audit reports, attestations or certifications.
What to check in a firmware testing provider before you sign
Firmware review results are only as useful as the method, scope and handling behind them. The cards below cover the checks that separate a comparable, defensible firmware review from an unscoped one, and the questions to put to any provider before a statement of work is signed.
Documented methodology and OWASP references
Ask for the provider's written firmware methodology and whether it maps each phase to the OWASP Firmware Security Testing Methodology (FSTM) and the OWASP IoT Security Testing Guide (ISTG). A named methodology makes results comparable across vendors and lets your team check coverage stage by stage. Ask which FSTM stages are in scope and which are excluded, and why. A provider that cannot describe its method at this level is not ready to quote.
Embedded and IoT experience
Ask for anonymized examples of firmware work on device classes similar to yours, such as small microcontroller boards, gateways or industrial controllers. Confirm which architectures, operating systems and update mechanisms the team has handled. Do not accept invented or vague case studies. A credible answer names the kinds of findings reported and the stages covered, without naming clients.
Emulation limits and hardware testing
Firmware often cannot run fully outside its device, so emulated testing has limits. Ask how the provider decides when emulation is sufficient, which findings require bench or hardware testing, and what they will report as not verified. Ask whether they need physical access to a test unit, and who supplies it. A clear statement of what emulation cannot show protects you from false assurance.
Protection of firmware and secrets
Extracted firmware often contains proprietary code, keys and credentials. Ask where images are stored, who can access them, how long they are kept, and how they are destroyed at close. Ask how any recovered secrets are reported, whether values are redacted in deliverables, and whether data stays in your environment or the provider's systems. Agree these terms in the contract before any firmware is shared.
Written scope with tested versions
Firmware changes with every build, so a finding is only meaningful for the image it came from. The written scope should name the exact firmware versions, hardware revisions and interfaces tested, along with explicit exclusions such as cloud back ends, companion apps or radio interfaces. Ask how the provider will handle a new build received during the engagement. Ambiguous scope is the most common source of disputes over results.
Retest priced and scheduled up front
Most firmware findings need a fix and a verification pass. Ask whether one retest round is included, how much it costs, and when it must happen relative to your release or certification dates. Confirm the retest will use a named firmware build and that the report will state which findings were closed. Agreeing this at signing avoids delays when your release schedule is fixed.
How DeployOpen scopes, tests, reports and retests firmware
DeployOpen runs firmware reviews as fixed-scope engagements, with scope, deliverables and timelines agreed in writing before work starts. The work follows the nine OWASP FSTM stages and can proceed without the physical device on a production network.
How we scope
- Agree in writing which firmware images, versions and hardware revisions fall inside the review before any analysis begins.
- Confirm whether the review includes static analysis only, emulated dynamic testing, or both, and record that choice in the scope.
- Identify the vendor update package, signing method and any companion components the client has the right to test.
How we build
- Obtain and analyze firmware images, extract filesystems and review contents for hardcoded credentials, keys and certificates.
- Map identified software components and versions against public vulnerability records, then flag outdated or unsupported packages.
- Assess update integrity, including how images are verified, and attempt emulated testing only where the scope and the client's rights allow it.
How we hand over
- Deliver a written report that maps each finding to the affected firmware version, component and the OWASP FSTM stage where it was found.
- Include reproducible evidence and remediation guidance for the vendor or engineering team, written so it can be passed to a product security owner.
- Show how findings relate to ETSI EN 303 645 provisions or CRA-related evidence when the client needs them for an assessor or customer.
How we support
- Retest agreed findings against a new firmware build, and record which issues are closed, open or accepted as risk.
- Offer ongoing support and continuous testing as a retainer for clients who ship firmware updates on a regular cycle.
- Confirm the retest window, the number of retest rounds and any follow-up work in the written scope before engagement starts.
