Why Your BSP Should Be Your First Security Decision

Security isn't a layer you add on last. It's structural and the place that structure starts is your board support package.

Published on July 1, 2026

Why Your BSP Should Be Your First Security Decision

Most embedded projects treat security the same way as something you'll handle later. You pick your SOM, get the hardware working, create a basic BSP, and tell yourself you'll fine tune everything before release. It's a good plan, but it almost never works. Security isn't a layer you add on top of a working system. It's structural and the place that structure starts is your board support package.

What a BSP actually gives you

Every SOM ships with a BSP, that's not a differentiator. The vendor BSP gets your hardware talking to your OS: drivers, bootloader, kernel config, and some peripheral support. It's the thing that makes the board boot. What it doesn't do is give you a security architecture. After you have a working BSP, you still need to figure out:

  • How to establish a hardware root of trust
  • How to sign firmware images and verified boot
  • How to provision cryptographic keys at manufacturing without building your own key management infrastructure
  • How to push OTA updates with integrity protection
  • How to respond when CVE hits your kernel version two years into field deployment

For a SOM, the BSP generates the operating system that boots and runs on the SOM and its carrier board.

2

Linux BSP

Two Flavors
  • Yocto OR Buildroot build system
  • Configure during integration — expected and fully supported
3

Linux OS

Built for the SOM + Carrier
  • Boots and runs on the SOM and its carrier board
  • Tailored to your hardware, production-ready
1

SDK

Tools for app developers
  • Output of the EZ BSP build
  • Qt, C++, .NET, Python supported
  • Hands off cleanly to app teams

The Real Cost of Building It Yourself

Secure key provisioning at manufacturing requires a controlled environment, auditable processes, and people who know what they're doing. Getting that wrong doesn't just create a weak product, but one with the appearance of security that fails under inspection. 

Maintaining a secure BSP over a product's lifetime means tracking CVEs, backporting patches to a stable kernel, and doing that continuously for however long your device is in the field. Industrial and medical products routinely have 10+ year lifecycles. That's a decade of security maintenance for something most teams built once and hoped would hold. Most teams don't budget for that so it usually doesn't happen, and the device gets left behind. exposed.

Why The BSP Is Where Security Has to Start

Retrofitting trust into a hardware platform is extremely hard. Not difficult in the sense of requiring clever engineering, but that some things simply cannot be added after the fact. 

Hardware root of trust requires unique cryptographic keys provisioned per device at manufacturing. Secure boot means the bootloader verifies every signed image before it runs, but that signing process has to be part of your build pipeline from the beginning. The chain of trust is exactly that: a chain. Every link depends on the one before it. If the manufacturing step doesn't establish the hardware root, nothing downstream can happen.

The Chain of Trust in Practice

A complete chain of trust runs from the hardware layer through to your application environment:

  1. Unique cryptographic keys provisioned per device at manufacturing — the hardware root of trust
  2. Signed bootloader verified against the hardware root before anything else runs
  3. Signed Linux kernel and application images. Only your software, on a verified filesystem
  4. Secure enclave for private key and credential storage
  5. OTA updates that verify signatures before applying, so no unsigned firmware gets onto the device

Nothing in that chain is assumed secure. Every layer is authorized by the one before it. Remove any link and the chain is broken.

COT-Icon-White-Outline1.png

What We Build EZ BSP To Do

EZ BSP exists because we kept seeing the same problem. Customers would come to us with a working SOM design and a security gap they needed to close, usually under deadline pressure after a customer or regulatory requirement forced the issue. 

We built the security architecture into the BSP itself. EZ BSP gives you hardware root of trust provisioning done at manufacturing, signed image compilation as part of your build pipeline, verified and secure boot, OTA updates with integrity protection, and an LTS kernel with ongoing CVE response. The chain of trust runs from the hardware layer through firmware through your application environment. 

It's built on Yocto and Buildroot, tools your team already knows, with no proprietary platform lock-in. If you ever need to move, you can. We're not trying to trap you. 

The manufacturing piece matters more than people realize. Secure key injection at the factory means devices arrive at your customer with trust anchors already in place. You don't need to build a key management infrastructure. You don't need a secure provisioning step in your own facility.


Capability Ezurio EZ BSP Competitor 1 Competitor 2 Competitor 3
Secure Boot ✔ Full support Limited scope Proprietary ✔ Yes
Secure OTA Update ✔ Full support No Proprietary No
Secure Signing ✔ Full support No Proprietary No
Custom Secure Programming ✔ Yes Not offered Proprietary Not offered
Platform Lock-in Required ✔ No lock-in N/A Proprietary Platform Proprietary
In-House Wireless ✔ Multi-type Partners only Partners only Partners only
BSP Build System Yocto + Buildroot Yocto Yocto + Proprietary Yocto

The Honest Case For Getting This Right Early

If your device ships to a regulated market, like medical, industrial, defense, security is a product requirement. Regulators are moving fast, and “we'll add it later” is not an acceptable answer in a certification audit. The EU Cyber Resilience Act, FDA guidance on connected medical devices are raising the baseline across the board. 

But even outside regulated markets, things have shifted. Connected devices are attacked more than they used to be. Field failures from security vulnerabilities are expensive in cost, in customer trust, in the engineering time pulled away from your actual product roadmap to fight fires that could have been prevented. 

Your BSP is where that planning starts. To learn more about Ezurio’s EZ BSP, visit ezurio.com/ez-bsp