Firmware Development Services: A Buyer's Guide

Illustration

Firmware development services cover the code that runs on a device: architecture, board support and drivers, connectivity, power, the bootloader and over-the-air updates, security, test and production firmware, and maintenance after launch. A good contract gives you the source, the signing keys, a reproducible build, an SBOM per release and written acceptance tests.

Buying firmware development services is different from buying app development. The code runs on hardware you are still changing, it ships inside units you cannot easily recall, and it holds the keys that decide who can update your product. This buyer guide covers what the services include, what to put in the scope and contract, the questions to ask a vendor, and the red flags. It is vendor-neutral.

This is an engineering summary and not legal advice. Have counsel review any contract. All sources were read on November 12, 2026.

What do firmware development services include?

Firmware development covers every piece of code built into the device. For a connected product, the scope usually has eight parts. The right column is what to ask for as proof that each part is done.

Test and production firmware is often left out of early quotes. A factory needs it to test each unit, write serial numbers and load keys. If it is missing, the first production run waits for it. Maintenance is the other gap. Chip SDKs, RTOS kernels and radio stacks publish fixes for years, and someone has to bring them into your product.

For background on the platform choice, see what is an RTOS. For how firmware relates to the app and cloud, see firmware vs software vs hardware.

How do firmware development companies differ?

Vendors fall into a few broad types. Each fits a different need.

• Independent firmware contractors. Good for a defined task: a driver, a port to a new chip, a code review. Continuity depends on one person.
• Embedded software consultancies. Teams that write firmware for hardware you design elsewhere. You coordinate between them and the electronics designer.
• Product development firms. Teams that design electronics, firmware and enclosure together, and often build prototypes and small batches. Fewer handoffs, and more depends on one vendor.
• Chip-vendor design partners. Firms with deep knowledge of one chip family. Strong on that platform, less so if you change chips.

If you are still deciding whether to hire in-house instead, firmware engineer: hire, contract or outsource compares the options.

What should go in the embedded firmware development scope?

A useful scope lists the hardware, the features and the tests. At minimum, write down:

• The chip, radio and board revisions the firmware must support, and who supplies the boards.
• Each feature as a user-visible behavior, with a measurable target where one exists: battery life under a stated use pattern, reconnect time, update time.
• The backend the device talks to, and who owns that side. Firmware tested against a mock server can fail against the real one.
• The update method: over Bluetooth through a phone, over Wi-Fi or cellular, or by cable only.
• The security baseline you need.
• The acceptance tests, on which hardware, with which limits.

For the security baseline, NIST IR 8259A (May 2020) lists six device cybersecurity capabilities: device identification, device configuration, data protection, logical access to interfaces, software update, and cybersecurity state awareness. Its software update capability says the device's software can be updated by authorized entities only, using a secure and configurable mechanism (NIST IR 8259A, as of November 2026). Each capability makes a good scope line. For the US labeling program built on similar ideas, see Cyber Trust Mark requirements.

What should the contract say about source, keys and builds?

Ownership terms are a common source of firmware contract disputes. Write these terms in before work starts:

• Source code, build scripts and documentation are assigned to you, and pushed to a repository you control as work happens.
• Production signing keys are generated under your control. The vendor signs with them only under a written procedure, or not at all.
• A continuous integration build produces the release image from a tagged commit, with pinned compiler and SDK versions.
• Every release ships with an SBOM listing third-party components, versions and licenses.
• Acceptance tests are written into the contract: what is measured, on which hardware, with which pass limits.
• Open source license obligations are listed, and code with licenses you have not approved is not added.
• A support period after launch, with how security fixes are handled and how fast.
• Exit terms: what you receive, in what form, if the engagement ends at any stage.

Published references help you set the bar.

SBOM. The NTIA minimum elements (July 12, 2021) list seven data fields for each component: supplier name, component name, version, other unique identifiers, dependency relationship, author of SBOM data and timestamp. The report names SPDX, CycloneDX and SWID tags as formats, and says a new SBOM must be created when a component gets a new build or release (NTIA report, as of November 2026). The SBOM and source-file handover checklist turns this into a delivery list.

Keys. The MCUboot imgtool documentation supports RSA-2048, RSA-3072, ECDSA P-256 and Ed25519 keys. It says the private key file used to sign images should be protected and not widely distributed, and that a widely distributed sample key should never be used for production (MCUboot imgtool, as of November 2026). Whatever bootloader you use, the same rule applies.

Development process. NIST SP 800-218, the Secure Software Development Framework (February 2022), says software purchasers can use it to communicate with suppliers in acquisition processes (NIST SSDF, as of November 2026). Ask a vendor to say how it meets its practices for code review, dependency tracking and vulnerability response.

How should the bootloader and update path be specified?

An update that fails in the field can turn devices into bricks. Write the expected update behavior into the contract along with the feature.

MCUboot, an open source secure bootloader for 32-bit microcontrollers, is a useful reference for what to ask. Its design documentation describes a primary and a secondary image slot, swap or overwrite upgrades, test images that revert to the old working image at the next reset unless confirmed, signature verification before boot, and an optional security counter for downgrade prevention stored in a non-volatile, trusted part of the device (MCUboot design, as of November 2026).

Ask the vendor to show, on your hardware:

• An update interrupted by power loss at several points, and the device recovering.
• A deliberately broken image being rejected or reverted.
• An image signed with the wrong key being refused.
• An older, vulnerable image being refused if you require downgrade prevention.

Firmware OTA failures that brick devices lists the failure cases in more depth, and secure boot and signed firmware covers the boot chain.

What questions should you ask a firmware vendor?

• Which products have you shipped firmware for, on which chips and radios, and which are still in the field?
• Who on your team will write the code, and who reviews it?
• How do you bring up a new board, and what do you deliver at the end of bring-up?
• How does your update path recover from a power loss or a bad image?
• Where do signing keys live during development and in production, and who can sign a release?
• How do you track security advisories for the RTOS, the chip SDK and the radio stack?
• Can we build the release image ourselves from the repository on day one?
• What does the SBOM look like for a past project, and in which format?

What are the red flags in a firmware development proposal?

• Source code is delivered only at the end, or only as binaries.
• The vendor keeps the signing keys, or the product ships with a sample or development key.
• Builds run on one engineer's laptop and cannot be reproduced.
• No plan for over-the-air updates, or updates with no rollback.
• Acceptance means "it works on our bench" with no written test.
• No answer on how security fixes in third-party code reach shipped devices.
• Licenses of included libraries are unknown.

Any one of these can be fixed in the contract. A vendor that resists fixing them is telling you how the handover will go.

If you want firmware built together with the hardware, with source, keys and SBOM in your hands, tell us about your device.

Sources. All pages accessed November 12, 2026. Standards and tool documentation are revised, so check the current versions.

• NIST, SP 800-218, Secure Software Development Framework Version 1.1 (February 2022) (link)
• NIST, IR 8259A, IoT Device Cybersecurity Capability Core Baseline (May 2020) (page, PDF)
• NTIA, The Minimum Elements for a Software Bill of Materials (July 12, 2021) (link)
• MCUboot, Bootloader design (link)
• MCUboot, imgtool documentation (link)