IN Brief:
- EZ BSP combines Linux hardware enablement with secure boot, signed images, encrypted storage, and manufacturing provisioning.
- The software spans Ezurio SOMs using NXP, Texas Instruments, and MediaTek processors.
- LTS releases, SBOM generation, and open-source OTA tooling target long embedded-product service lives.
Ezurio has made its EZ BSP software platform generally available across its system-on-module range, combining Linux hardware enablement with secure boot, signed software, manufacturing provisioning, and longer-term security maintenance.
The board support package uses established open-source components including the Linux kernel, U-Boot, Yocto, and Buildroot. Ezurio has extended the usual BSP role beyond initialising hardware and exposing peripherals, adding device identity, image signing, update management, and production provisioning to the baseline module platform.
That addresses a distinction embedded developers increasingly have to manage over the life of a product. A conventional BSP can provide everything required to bring up the processor, memory, interfaces, and operating system, while the mechanisms needed to authenticate software, provision production units, track vulnerable packages, and maintain deployed equipment may still be assembled separately.
EZ BSP incorporates a hardware-rooted chain of trust, signed bootloader and kernel images, secure boot, encrypted storage, and production-grade image signing. The latter can use AWS Key Management Service, allowing private signing keys to remain inside managed key infrastructure rather than being distributed across development and manufacturing systems.
Protecting those credentials is as important as the cryptographic algorithm used to verify firmware. A secure-boot implementation depends on trustworthy keys, controlled provisioning, and a production process that prevents unauthorised software or credentials being introduced before the finished device leaves the factory.
Manufacturing therefore forms a substantial part of the platform. Prototype devices can be programmed manually, but volume production requires repeatable procedures for loading software, assigning identities, installing credentials, locking security configuration, recording traceability information, and confirming that the intended image has been programmed.
Ezurio says its provisioning system is already being used by customers shipping hundreds of thousands of securely programmed modules each year. At those volumes, manufacturing tooling becomes part of the product-security architecture rather than an administrative step at the end of development.
The software-maintenance side is built around long-term-support releases and software bills of materials. An SBOM provides a structured inventory of software components used in a device, allowing manufacturers to determine whether a newly disclosed vulnerability affects deployed products and which package or library requires attention.
That becomes harder as equipment remains in operation longer than the original development environment. Industrial controllers, gateways, medical equipment, and building systems may stay deployed for many years, while Linux packages, bootloaders, networking services, and cryptographic libraries continue to receive security updates during that period.
Ezurio also points to the EU Cyber Resilience Act as one factor increasing attention on updateability and vulnerability handling. Individual compliance obligations will depend on the finished product, but the engineering requirement is already familiar: equipment expected to remain connected for years needs a controlled way to identify affected software and distribute authenticated corrections.
Over-the-air updating uses the open-source SWUpdate framework. Ezurio says the device-side software can work with services including hawkBit, AWS IoT, and Azure Device Update, allowing an equipment manufacturer to retain its preferred fleet-management infrastructure rather than being tied to a single mandatory cloud service.
The embedded target still needs to receive, authenticate, install, and recover safely from updates regardless of which service controls deployment. Separating those functions gives developers some freedom at system level while keeping the update mechanism on the module consistent.
Ezurio is also using EZ BSP to reduce software fragmentation across processor families. The platform is intended to span SMARC and OSM modules using silicon from NXP, Texas Instruments, and MediaTek, allowing common release methods, lifecycle tooling, and security processes to be reused across products with different compute requirements.
Support is being phased by module family. The BSP is available for Nitrogen products based on NXP i.MX processors and Carbon OSM modules using TI AM Sitara devices, while support for Tungsten SMARC modules based on MediaTek silicon is scheduled for the second half of 2026.
A common BSP does not eliminate the differences between those processors. Boot ROMs, security engines, peripheral sets, memory architectures, and carrier-board designs still affect how a secure system is implemented, while application software, network services, cloud interfaces, debug access, and product credentials remain responsibilities of the equipment developer.
The change is at lifecycle level. Bringing provisioning, authenticated software, vulnerability tracking, and update support into the module platform gives embedded teams a common foundation for products whose useful lives extend well beyond the point at which the original board first booted successfully.
