Embedded Systems Consulting: Project Scopes, Questions and Red Flags

Embedded systems consulting covers a wide range of work, from a two-week board bring-up to years of Linux maintenance on a product line. This guide sets out the work US product companies typically bring in outside help for, how to write a scope a consultant can quote against, what to ask at each project phase, and the warning signs.

It’s part of our engineering partners hub. If you’re comparing firms for a firmware build, read it with our guide to evaluating firmware development companies. We don’t rank or name consultancies.

What work is typically outsourced

These are common categories of outsourced work. We have no survey data on how common each one is.

• BSP bring-up. Getting a new board running: bootloader, kernel, device tree, drivers, and a minimal root filesystem. Often time-boxed and well suited to fixed scope.
• Yocto and embedded Linux maintenance. Keeping layers, the kernel and packages patched across releases, often for several product lines at once.
• Security retrofits. Adding secure boot, signed updates, SBOM generation and vulnerability handling to products already shipping.
• Test rigs and automation. Hardware-in-the-loop benches, CI for firmware, flashing and provisioning stations.
• Driver and middleware work. A new sensor, radio or fieldbus stack.
• Architecture reviews. An outside look at a design before you commit, for example the update architecture or the chain of trust.

Why long-term maintenance is the hard part

Most connected products outlive the software they ship with. Two public examples show the gap:

• The Linux kernel’s longterm releases have projected end-of-life dates. Today kernel.org lists 6.1 and 6.6 with projected EOL in December 2027, and 6.12 and 6.18 in December 2028 ^[1].
• The Yocto Project’s long-term support releases have fixed support windows. Scarthgap (5.0) is listed with LTS until April 2028, and Wrynose (6.0) until April 2030 ^[2].

Under the EU Cyber Resilience Act, manufacturers must handle vulnerabilities for a support period of at least five years, unless the product is expected to be used for less time ^[3]. The CRA’s recitals note that industrial products, such as industrial control systems, are often in use for much longer ^[3]. Its main obligations apply from 11 December 2027 ^[3][4].

Worked example (illustrative, not advice). A product that starts shipping in 2027 on a kernel with a projected December 2028 EOL, with a support period of 10 years, has to cross several kernel and Yocto LTS generations. Someone has to backport fixes, move to a newer LTS, or both, many times over. That work is easy to underestimate, and it belongs in the scope from day one.

For the hardening and patching side, see our embedded Linux and Yocto security hardening guide.

Illustrative scope statements

These are illustrative examples we wrote for this guide, not real projects. Adapt them to your product. Each gives a consultant enough to estimate effort and lists what you’ll accept as done.

1. BSP bring-up (fixed scope)

Bring up [board rev] based on [SoC] to boot a Yocto-based image from eMMC with secure boot enabled in development mode. Deliverables: Yocto layer in our repository, bootloader and kernel configuration, device-tree sources, a build that reproduces from a clean checkout, and a bring-up report listing known issues. Done when the image boots on 3 boards, passes our smoke tests, and our engineer has rebuilt it without their help.

2. Yocto maintenance (ongoing)

Maintain [product lines] on Yocto [LTS release]. Monitor CVEs in the shipped image, triage them against our SBOM, and deliver patched builds on an agreed cadence, plus out-of-cycle fixes for vulnerabilities we rate critical. Plan and execute the move to the next LTS before the current one’s end of support. Monthly report: CVEs triaged, fixed, deferred (with reasons).

3. Security retrofit (phased)

Phase 1: assess [product] for root of trust, signing, update path and SBOM gaps, and propose a design. Phase 2: implement signed updates with A/B rollback and per-release SBOM generation. Phase 3: hand over runbooks and train our team. Each phase ends with a written report and our go/no-go decision.

4. Test rig (fixed scope)

Build a hardware-in-the-loop bench for [product] that flashes a build from CI, runs our functional tests and an update/rollback test (including power loss mid-update), and reports to our CI system. Deliverables: bill of materials, wiring diagram, scripts, and documentation good enough for our team to build a second bench.

The acceptance criteria are starting points; add your own tests and thresholds.

Security retrofits

A retrofit across several products is a planning problem before it’s an engineering one: inventory, triage by product line, then sequencing. See how to scope a multi-product firmware security retrofit, and our guides to hardware root of trust and secure boot and secure firmware update architecture.

Questions by project phase

Our original question set. Use it with the firmware partner scorecard to score answers the same way across firms.

The "good answer" column describes what to look for, not a guarantee of quality.

The SBOM questions matter for the EU: the CRA’s vulnerability-handling requirements include an SBOM covering at least top-level dependencies ^[3]. Manufacturers must also exercise due diligence when integrating third-party components ^[3]. How that applies to consultant-written code is a question for your counsel.

Red flags

• No security process. No secure development practice they can describe, or security treated as optional on a connected product. A public reference point is NIST’s Secure Software Development Framework ^[5].
• No SBOM practice. They can’t produce a component list per build, or say the chip vendor handles it.
• Unclear IP terms. Vague answers on who owns code, layers, scripts, test fixtures and keys at the end. Have counsel review the contract.
• Work kept outside your repository until the end of the project.
• Builds only they can reproduce.
• No plan for LTS end of life on a long-term engagement.
• Claims that their work makes your product "compliant". Compliance is the manufacturer’s determination.

Where to start

1. Pick the category of work above that matches your problem.
2. Adapt the matching illustrative scope.
3. Weight the criteria in the firmware partner scorecard before you talk to firms.
4. Use the phase questions in technical calls, with your engineer present.
5. Have counsel review IP, confidentiality and export-control terms before any technical data changes hands.

Spotted an error? Report it to our corrections log. Read our editorial methodology.