SBOM for SaMD and Cloud Components: FDA Guide

SBOM guidance was written with embedded devices in mind, where the software is a fixed firmware image. SaMD is different. It runs across phones, browsers, containers and cloud services, and it changes often.

That makes the SBOM harder to scope. Teams ask whether they must list every AWS or Azure service, every container base image and every API they call.

Section 524B(b)(3) of the FD&C Act requires an SBOM that includes commercial, open-source and off-the-shelf software components. The FDA's February 3, 2026 final guidance, "Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions," explains what that means in practice. This post applies it to cloud-based SaMD.

Why This Matters

The SBOM is one of only a few cybersecurity items written directly into law. Section 524B(b)(3) requires cyber device submissions to include "a software bill of materials, including commercial, open-source, and off-the-shelf software components." The FDA's February 3, 2026 guidance, "Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions," adds that the SBOM should be machine-readable and supported by information on each component's support status and known vulnerabilities.

The baseline data fields come from the NTIA's July 2021 "Minimum Elements for a Software Bill of Materials": supplier name, component name, version, other unique identifiers, dependency relationship, author of SBOM data and timestamp. Those seven fields apply to SaMD just as they do to firmware.

What changes for SaMD is scale and pace. A single cloud application can pull in thousands of open-source packages across its services and containers, and it may deploy weekly. The standards behind the supporting evidence are IEC 81001-5-1 for secure development and maintenance, IEC 62304 for software lifecycle, and AAMI TIR57 and ANSI/AAMI SW96 for security risk management.

What must a SaMD SBOM include?

A SaMD SBOM must include every software component that is part of the device as you ship and run it. If you build it, bundle it or deploy it, list it.

Our SBOM for medical devices guide covers format choices and the full field set.

How should cloud services be handled?

Cloud services you consume but do not control, such as managed databases, identity services or storage, are usually documented outside the SBOM. You cannot list their internal components, and the FDA does not expect you to.

What the reviewer does expect is that those services appear in the architecture views and threat model, with trust boundaries, data flows and the security responsibilities you rely on the provider for. Document the shared responsibility split: what the provider secures, what you configure, and how you monitor both.

Where you deploy software into the cloud yourself, such as virtual machines, functions or containers, that software is yours and belongs in the SBOM.

If you are unsure how to scope cloud services for your submission, we can review your architecture and SBOM together. Talk to our team.

How do containers change the SBOM?

Containers make the SBOM much larger, because each base image brings its own operating system packages. Those packages carry vulnerabilities just like your application libraries.

See also: SBOM for Third-Party Chip Firmware, SBOM EOS, EOL & LoS for FDA 524B, and Ransomware and Medical Devices: What the FDA Expects.

Generate a component inventory for each container image you deploy, not only for your application source. Pin base image versions so the SBOM matches what actually runs. Choose minimal base images to reduce the number of components and the number of vulnerabilities you have to assess. Record which image each service uses so the architecture views and SBOM line up.

How do you keep a SaMD SBOM current?

Keep a SaMD SBOM current by generating it automatically in the build pipeline for every release. A hand-built SBOM will be out of date within weeks.

Pair each SBOM with VEX statements that explain whether known vulnerabilities actually affect the device. That keeps reviewers and customers from chasing vulnerabilities in code paths you never use. Monitor the SBOM continuously against vulnerability sources so new issues are triaged quickly. See SBOM vs VEX and our postmarket SBOM and VEX monitoring service.

How Blue Goat Cyber Approaches This

We scope SaMD SBOMs from the architecture outward. First we map every service, container, mobile app and third-party dependency, then we decide what belongs in the SBOM and what belongs in the architecture views and risk assessment. That keeps the submission consistent, which is what reviewers look for.

Our US-based engineers generate machine-readable SBOMs, add support status and vulnerability assessments, and write VEX statements for known vulnerabilities. After clearance, GoatWatch matches your SBOM against new CVEs daily and a named engineer triages what matters.

We have supported more than 275 device submissions, including cloud-based SaMD. See our FDA-compliant SBOM services. If the FDA raises cybersecurity deficiencies after our submission, we resolve them at no additional cost.

Frequently Asked Questions

What should an SBOM for SaMD include?

An SBOM for SaMD should include every software component you ship or run as part of the device: your application modules, open-source libraries and their dependencies, commercial SDKs, container base images and operating system packages, and mobile app frameworks. It should be machine-readable, include the NTIA minimum data fields, and be supported by support status and vulnerability information.

Do I need to list AWS or Azure services in my SBOM?

Usually not as SBOM components, because you do not control or ship their internal software. Instead, document the managed cloud services you depend on in your architecture views and threat model, including data flows, trust boundaries and the security responsibilities you rely on the provider for. Software you deploy into the cloud yourself does belong in the SBOM.

Is a SaMD SBOM a one-time submission document?

No, and this is a common misconception. The SBOM describes the device as released, and SaMD changes often. Section 524B expects you to maintain it as part of postmarket cybersecurity. Generate it automatically for each release and monitor it for new vulnerabilities so your records stay accurate.

Which SBOM format does the FDA accept for SaMD?

The FDA expects a machine-readable SBOM and commonly sees SPDX and CycloneDX. Either works for SaMD. CycloneDX is popular in cloud pipelines because many tools generate it natively, while SPDX is widely used for licensing data. Choose one, use it consistently, and make sure it carries the minimum data fields.

How do VEX statements help with a SaMD SBOM?

VEX statements explain whether each known vulnerability actually affects your device. Large SaMD SBOMs can list hundreds of vulnerabilities, many in code you never call. A VEX statement marks each one as affected, not affected, fixed or under investigation, with a reason. That saves reviewers and customers time and shows your vulnerability management works.

CTA

If you are building SaMD and are not sure how to scope your SBOM for cloud services and containers, we can review it. You will get a clear list of what belongs in the SBOM, what belongs in the architecture views, and what to fix before submission. Book an SBOM review.

---

About the author. Christian Espinosa, MBA, is the founder and CEO of Blue Goat Cyber and a graduate of the US Air Force Academy. He leads a team focused only on medical device cybersecurity, including SBOM and vulnerability management for cloud-based SaMD. Read more about Christian.