Medical devices are staying in the field longer — and security expectations are rising. Learn how a software bill of materials (SBOM) helps OEMs reduce risk and support long-term compliance in regulated environments.
Medical devices are becoming more connected while remaining in the field longer, increasing the need for a clear, repeatable approach to security and compliance. In this recorded webinar, Digi and Bytesnap share a real-world medical device use case and explain how a software bill of materials (SBOM) helps OEMs identify risk, manage vulnerabilities and support regulatory requirements over time. The session also highlights how Digi ConnectCore® Security Services and Bytesnap’s software support simplify security reviews and reduce long-term support effort in regulated environments.
To learn more, visit the Digi ConnectCore product page, check out our medical solutions page, or review our comprehensive offering of embedded connectivity solutions for a variety of applications and industries.
Connect with Digi
Want to learn more about how Digi can help you? Here are some next steps:
Follow-up Q&A: Long-Term Security for Medical Devices: Leveraging SBOM to Reduce Risk and Improve Compliance
This webinar explored the growing role of software bills of materials (SBOMs) in strengthening medical device security and meeting evolving regulatory requirements. The following Q&A captures key audience questions and expert responses, offering practical insight into how OEMs can approach long-term security, compliance and lifecycle management.
Presenters:
- Graeme Wintle, Director, Bytesnap
- Andreas Burghart, Senior Product Manager, Digi International
Moderator: Keith Kreischer, Executive Director, IoT M2M Council
Which SBOM formats does the security service support?
Andreas Burghart (Digi International):
The service supports the standard SBOM formats, including SPDX and CycloneDX. SBOMs are typically generated as part of the build process, for example through a Yocto build, using recipes that output the required formats for use with the service.
What happens if an organization is not currently using a Digi solution? Can it still use these services?
Graeme Wintle (Bytesnap):
Yes. Previously, customers needed to be on a Digi platform, but the service is now available to organizations running on a compatible Linux kernel. The typical process involves migrating to a supported long-term support (LTS) kernel and then applying the Digi meta layer on top of that. In many cases, organizations are already close to a supported configuration, so the effort is manageable. Currently, the focus is on NXP and ST platforms, such as i.MX8, i.MX9 and STM MP1 or MP2.
Andreas Burghart (Digi International):
This expansion was driven by customer demand, especially where newer products use Digi hardware but legacy products do not. By working with partners like Bytesnap, Digi can extend the same security services and tooling across both Digi and non-Digi hardware, reducing fragmentation. There are some constraints, primarily around supported STM and NXP platforms, but this approach delivers significant value for mixed hardware environments.
What happens if a device is not running a compatible Linux kernel? Can Bytesnap help?
Graeme Wintle (Bytesnap):
Yes. Bytesnap can help migrate systems to a supported kernel. On older processors, such as i.MX6, some kernel features or drivers may have changed or been removed, which can introduce challenges, particularly around drivers or Wi-Fi compatibility. However, maintaining security requires moving to a supported LTS kernel, so migration is often a necessary step.
Does the security service support any Linux kernel?
Andreas Burghart (Digi International):
No. The service supports a defined set of LTS kernels rather than every possible kernel. OEMs need to plan for ongoing software and kernel updates to remain secure. Maintaining security over the product lifetime requires regular updates, including kernel updates.
How often are CVE reports updated?
Andreas Burghart (Digi International):
CVE reporting can be provided on an as-needed basis, but the service is typically set up to deliver automated monthly reports. A key differentiator is the curation and analysis performed by Digi security engineers. Instead of overwhelming customers with hundreds or thousands of raw CVEs, the reports focus on what is relevant, what is already patched and what applies to a specific configuration. This saves OEMs significant time and reduces the need for in-house security expertise.
How do ongoing updates and reporting support awareness and regulatory requirements?
Graeme Wintle (Bytesnap):
Regular reporting provides visibility into what has changed month over month, helping organizations decide whether to schedule routine updates or issue emergency patches. The service highlights issues but leaves decisions with the customer, preserving technical ownership. Compared to using open source tools alone, this approach significantly reduces the time and cost required to understand, prioritize and remediate security issues. It also supports growing regulatory requirements across industries, including medical devices.
Do the services support the Zephyr RTOS?
Andreas Burghart (Digi International):
Zephyr is a well-known and widely used RTOS, but Digi System-on-Module solutions and the associated security services are currently Linux-based. Zephyr is not yet integrated into the service.
How does the security service help with Cyber Resilience Act (CRA) compliance?
Andreas Burghart (Digi International):
The security services and the Digi TrustFence® framework directly support CRA requirements. Digi has published a white paper that maps specific CRA requirements to the relevant services and TrustFence features. This resource also explains reporting obligations and compliance responsibilities. While CRA applies to medical devices, it also affects many other connected products across industries.
Are there any final points to highlight?
Graeme Wintle (Bytesnap):
The service provides peace of mind, particularly for organizations transitioning from environments where security updates were handled automatically. In open source Linux environments, OEMs are responsible for ongoing security maintenance. This service helps fill gaps for teams without dedicated security staff and reduces the operational burden of maintaining long-term security.
Andreas Burghart (Digi International):
Organizations are encouraged to engage with Digi to discuss how to secure their products across the entire product lifecycle.