Firmware Development Companies: How to Evaluate an Engineering Partner

If you’re introduced to a partner firm and hire them, that firm may pay us a referral fee.

This is a framework for evaluating firmware development companies, not a list of them. We don’t rank firms and we don’t name any here. What we can give you is a consistent way to compare the firms you’re already talking to: how they engage, what they’ve built on your platforms, how they handle security, and what to check before you sign.

It sits in our engineering partners hub and is written for engineering leaders at US companies that sell connected products in the EU. Use it with the free firmware partner RFP template and scorecard, which turns the questions below into a weighted score you fill in yourself.

Before you talk to anyone

Write down three things first. They decide which firms are even relevant.

• The work. New product, a feature on an existing product, a security retrofit across a product line, or long-term maintenance.
• The platform. Chip family, RTOS or embedded Linux, toolchain, and anything you’re locked into (a BSP from your SoC vendor, a specific radio module, a safety-rated part).
• Who owns it afterwards. Will your team take the code over, or will the firm maintain it for years?

If you’re still deciding whether outside help is right at all, our build vs. buy vs. partner comparison covers that choice. For broader embedded work (BSP bring-up, Yocto maintenance, test rigs), see our guide to embedded systems consulting.

Why security and lifecycle matter more than they used to

If you sell products with digital elements in the EU, the Cyber Resilience Act makes you, the manufacturer, responsible for the product’s cybersecurity whoever writes the code. Its main obligations apply from 11 December 2027 ^[1][2]. A few provisions bear directly on choosing a firmware partner:

• Manufacturers must design, develop and produce products in line with the essential cybersecurity requirements in Annex I, Part I ^[1].
• Manufacturers must exercise due diligence when integrating components from third parties, so those components don’t compromise the product’s cybersecurity ^[1]. How that applies to code a contractor writes for you is a question for counsel. In practice, your partner’s process becomes part of your evidence.
• Vulnerability handling (Annex I, Part II) includes a software bill of materials covering at least top-level dependencies, security updates, and a coordinated vulnerability disclosure policy ^[1].
• Vulnerabilities must be handled for a support period of at least five years, or the expected use time if shorter, set to reflect how long the product will be in use ^[1].

So "can they write firmware?" is only part of the question. You also need to know whether they can produce work you can defend and maintain for the support period. Our guides to secure boot and hardware root of trust and secure firmware update architecture explain the engineering underneath.

Engagement models

Many projects mix models, for example a fixed-scope security retrofit followed by staff augmentation for maintenance. If the job is a retrofit across several product lines, start with how to scope a multi-product firmware security retrofit. The trade-offs above are general observations, not rules; weigh them against your own situation.

Capability checklist by platform

Ask for evidence (shipped products the firm can describe, sample code, design documents with client details removed), not a logo slide. Our original checklist:

Adapt the rows to your platforms; the families named are examples, not a list of what to require.

A note on standards claims: IEC 62443-4-1 sets requirements for a secure product development lifecycle ^[4]. If a firm says it "follows" a standard or "holds a certificate" for it, ask what that means in practice: which scope, which assessor, which date. Check certificates with the issuing body yourself.

Security questions to ask every firm

Ask the same questions of every firm and score the answers in the scorecard.

1. Walk us through the secure boot chain on a product you shipped. Where was the root of trust, and how were keys provisioned in the factory?
2. Where do signing keys live during development and release? Who can sign a production image?
3. What’s your default firmware update design, and how does it recover from a power loss mid-update?
4. How do you produce an SBOM for each release, and what do you do about binary blobs from chip vendors?
5. How do you learn about a new CVE in a component you shipped for us, and what happens next?
6. What would you hand over at the end so that our team, or another firm, could maintain this for the support period?
7. Have you supported a client’s work on EU Cyber Resilience Act requirements? What did you produce, and what did the client’s own team or counsel decide? (Treat claims of "Cyber Resilience Act compliance" as a red flag. Compliance is the manufacturer’s determination, not a vendor’s.)

Red flags

• No written secure development process, or one that exists only as a slide.
• Signing keys on a developer laptop or in the CI system’s plain secrets store.
• "We’ll add security later" or security priced as an optional extra on a connected product.
• No SBOM practice, or "the chip vendor handles that".
• Vague answers about who owns code, tools, test fixtures and keys at the end.
• Promises that their work makes your product "compliant" or guarantees it a certificate.
• References you can’t contact yourself.
• Unwillingness to describe any past work in technical detail, even redacted.

US, EU and nearshore firms: trade-offs to weigh

Location affects how the work runs, not just where it’s done.

• Time zones. EU teams are several hours ahead of US teams, so overlap is often limited to your morning. Plan reviews, on-call and release windows around the hours you actually share.

• Hardware access. Who holds the prototypes, test rigs and production programming fixtures? Shipping hardware across borders adds lead time.

• EU market knowledge. A firm that already works with EU manufacturers may know the vocabulary of the Cyber Resilience Act and harmonised standards. That helps, but it doesn’t replace your own counsel.

• IP and contracts. Ownership of code, background IP, tools and keys; which law governs the contract; how work-for-hire concepts translate across jurisdictions. Raise these with counsel. We don’t draw legal conclusions here.

• Export controls. Sending technical data or source code to engineers outside the US can be an export. Releasing controlled technology or source code to a foreign person inside the US is a "deemed export" under US rules ^[5]. Questions to raise with export-control counsel before any technical data moves:

  • How is our product and its technology classified, and is any of it controlled (for example, encryption functionality)?
  • Do any license requirements or exceptions apply for the countries and people involved?
  • Is any part of the product or data defense-related and subject to different rules?
  • Who screens the partner and its staff, and who records it?

  The answers depend on your product. We don’t give them here. For context, BIS places encryption items under Category 5, Part 2 of the Commerce Control List ^[6].

How to run the evaluation

1. Agree on weights in the firmware partner scorecard before you read any proposals.
2. Send the same RFP to every firm you’re considering.
3. Ask the security questions above in a technical call, with your firmware lead present.
4. Ask for redacted evidence against the checklist.
5. Call references yourself.
6. Run a short pilot project or design review before a long commitment, if the scope allows.
7. Put handover, IP, key custody and vulnerability-handling duties in the contract, and have counsel check it.

Firmware partner scorecard

Firmware & Embedded Partner RFP Template and Scorecard Weighted criteria: security capability, chip/OS experience, process, IP terms, references you collect yourself, communication and time zones. Web version and XLSX download. Start your scorecard →

Full version with the RFP template: Firmware partner RFP template and scorecard.

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