Most connected medical devices start life on a vendor board support package: the SoM maker’s Linux image, a kernel from whenever the board launched, and a build that works on one engineer’s machine. That is a reasonable way to get a prototype on the bench. It is a poor foundation for a product that has to be patched, audited, and supported for ten years in a hospital.
Where the vendor BSP stops helping
The SBOM question. FDA premarket cybersecurity guidance expects a software bill of materials and a plan for vulnerabilities across the device’s life. If you can’t say exactly which packages, versions, and patches are in the image, you can’t answer it — and an SBOM you can’t regenerate from source is a guess.
The patch question. A kernel CVE lands. With a vendor image, the fix waits on the vendor, or on someone who remembers which manual steps produced the current build. With a build you control, it’s a version bump, a CI run, and a signed update.
The people question. If one engineer’s laptop is the build system, that engineer is a single point of failure for every unit in the field.
What “a build you control” means
The Yocto Project and its OpenEmbedded build system exist for this problem. Done well, the result looks like this:
- Your own layers. Board support and application recipes live in meta-layers in your repositories, on top of a maintained Yocto release — not as edits scattered through a vendor tree.
- Pinned and reproducible. Every layer revision is locked, and CI builds the same image from a clean checkout. The build is the documentation.
- SBOM as a build output. Yocto can emit SPDX for every image. The SBOM comes from the same build that ships, so it’s never stale.
- Signed, recoverable updates. Secure boot verifies what runs; an A/B update scheme (RAUC, SWUpdate, or similar) installs signed bundles and rolls back if the new image doesn’t come up healthy.
- A read-only root filesystem. Devices boot to a known state every time, and field drift stops being a support category.
How it supports IEC 62304
Every open-source package in your image is SOUP under IEC 62304, and the standard asks you to identify it and track its known anomalies. A Yocto build makes that list a query instead of an archaeology project, and gives you verified, versioned builds to trace releases against. It won’t satisfy the standard on its own — but it turns several of the standard’s asks into byproducts of the build.
Where to start
You don’t need a rewrite. Start from what ships today: move the vendor’s changes into a layer you own, get CI producing that exact image, then rebase onto a maintained kernel and Yocto release once the build is reproducible. Secure boot and signed updates come next, in that order.
If your device is somewhere on that path and stuck, that’s work we do.