What should be in the SBOM and source-file handover for a connected device?

A complete handover gives you everything needed to build, test, certify and update the device without the original team: native schematic and layout files, Gerbers, a BOM with alternates, mechanical CAD, firmware source with build instructions, a CycloneDX or SPDX SBOM per release, test procedures, fixture designs, certification records and control of signing keys.

"You own the IP" is only useful if you hold files another team can work from. A PDF schematic and a binary firmware image are evidence that a design exists. They are not enough to change it, build it elsewhere or patch a vulnerability. This checklist lists what a connected device handover should contain, the format to ask for, and how to check each item yourself. We deliver this package at every paid gate, for the design as it stands at that gate.

What files should be in the handover?

Each table lists the item, the format to ask for, and a check your team can run without the original engineers.

Electrical

Mechanical

Firmware and software

Manufacturing, test and compliance

Two items are easy to forget. First, the native CAD files: Gerbers let a factory build the board, but they cannot be edited in any practical way. Second, the production test software: without it, a new factory cannot tell a good unit from a bad one.

What is an SBOM, and what must it contain?

A software bill of materials lists every software component in a firmware release, with versions and relationships. For a connected device that means the RTOS or Linux distribution, the network and TLS stack, the vendor SDK, the codecs, the AI runtime, and every open-source library pulled in by the build.

The baseline in the US is the NTIA's minimum elements for an SBOM (2021). It requires seven data fields, automation support in a machine-readable format, and defined practices.

The practices matter as much as the fields. A new SBOM should be produced with every release. At minimum it should list every top-level component, with enough detail to trace each one's dependencies. Anything the generator could not resolve should be listed as an explicit unknown. Ask for license identifiers and component hashes too. The NTIA baseline does not require them, but they make license review and binary matching far easier.

CycloneDX or SPDX?

Both are machine-readable formats that satisfy the NTIA automation requirement. Pick the one your tools read.

For devices sold to enterprise or public-sector buyers, expect questions about hardware origin too. As of October 2026, the FCC's Covered List rules reach modules and, since October 13, 2026, certain logic-bearing components. A hardware bill of materials that names the maker of each module and main chip answers that question quickly. CycloneDX can carry both in one document.

How do you check that the SBOM is real?

An SBOM written by hand at the end of a project is a guess. One generated by the build is evidence. Check it this way:

1. Validate the file. Run it through the format's schema validator, such as the CycloneDX CLI or the SPDX online tools. A file that does not validate will not load into your security tooling.
2. Regenerate it. Build the firmware from the tagged commit and generate the SBOM again. The component list should match.
3. Compare with the binary. Run a binary analysis tool over the release image. Libraries that show up in the binary but not the SBOM point to vendored code or a prebuilt blob.
4. Scan it. Load it into your vulnerability scanner. A firmware release on a current SDK should have few critical findings, and each should have a note: fixed, not reachable, or planned.
5. Check vendor blobs. Radio firmware, DSP binaries and AI accelerators often ship as closed blobs. Each should appear as a component with a supplier and version.

Who should hold the keys and accounts?

Files are half the handover. The other half is control. Without these, you own a design you cannot update.

• Firmware signing keys. Generated in your key management system. The build team gets a signing process, not the private key.
• Secure boot and debug lock settings. Documented, with the procedure to unlock a returned unit for failure analysis.
• OTA service. Running in your cloud account, with update rollout under your control. The same applies to any app backend we build for you; see app and cloud options.
• Device identity. Certificates or keys provisioned per device, with the provisioning records sent to you.
• Certification grants. The FCC grant and any carrier or PTCRB approvals in your company's name, under your FCC Registration Number.
• Supplier accounts. Module, cellular connectivity and cloud accounts opened by your company, not by the build team.

We set this up in Gate 0. See data sovereignty for where device data goes, and how to keep audio out of a China-hosted cloud.

When should the handover happen?

At every paid gate, for the design as it stands. A single handover at the end means your leverage disappears exactly when you need it. Tie each payment to delivery of that gate's files, and run the checks above before you approve the next gate. Our gate deliverable list shows what arrives when, and who owns the source files covers the contract side. Our contract is with Aximora Labs Inc., under US law.

Want to see what a handover package looks like for your device? Tell us about the project and we will walk through the deliverable list on the scoping call.