--- title: "SBOM Hygiene for Medical Devices: A Practical 2026 Playbook" description: "A working SBOM is not a file you generate once and ship. Here is how MedTech teams produce, maintain, and defend a Software Bill of Materials that survives…" lang: en json-ld: | [ { "@context": "https://schema.org", "@type": "Person", "@id": "https://christianespinosa.com/#person", "name": "Christian Espinosa", "url": "https://christianespinosa.com/", "image": "https://christianespinosa.com/__l5e/assets-v1/de07e44b-a8e0-4bcc-bcb0-13aec15421f1/headshot-front.jpg", "sameAs": [ "https://www.facebook.com/christian.espinosa.official", "https://x.com/Ironracer", "https://www.instagram.com/christian.espinosa.official/", "https://www.youtube.com/@ChristianEspinosaOfficial", "https://www.linkedin.com/in/christianespinosa/" ], "jobTitle": "Bestselling Author, Keynote Speaker, Entrepreneur", "worksFor": { "@type": "Organization", "name": "Blue Goat Cyber", "url": "https://bluegoatcyber.com/" } }, { "@context": "https://schema.org", "@type": "WebSite", "@id": "https://christianespinosa.com/#website", "name": "Christian Espinosa", "url": "https://christianespinosa.com/", "publisher": { "@id": "https://christianespinosa.com/#organization" }, "inLanguage": "en-US" }, { "@context": "https://schema.org", "@type": "Organization", "@id": "https://christianespinosa.com/#organization", "name": "Christian Espinosa", "url": "https://christianespinosa.com/", "logo": { "@type": "ImageObject", "url": "https://christianespinosa.com/logo.svg" }, "founder": { "@id": "https://christianespinosa.com/#person" }, "sameAs": [ "https://www.facebook.com/christian.espinosa.official", "https://x.com/Ironracer", "https://www.instagram.com/christian.espinosa.official/", "https://www.youtube.com/@ChristianEspinosaOfficial", "https://www.linkedin.com/in/christianespinosa/" ] }, { "@context": "https://schema.org", "@type": "Article", "headline": "SBOM Hygiene for Medical Devices: A Practical 2026 Playbook | Christian Espinosa", "description": "A working SBOM is not a file you generate once and ship. Here is how MedTech teams produce, maintain, and defend a Software Bill of Materials that survives FDA review and postmarket reality.", "image": "https://christianespinosa.com/assets/og-default-vx4o85jG.jpg", "datePublished": "2026-06-21T13:00:00Z", "dateModified": "2026-06-21T13:00:00Z", "mainEntityOfPage": { "@type": "WebPage", "@id": "https://christianespinosa.com/guides/sbom-hygiene-for-medical-devices-a-practical-2026-playbook" }, "author": { "@type": "Person", "name": "Christian Espinosa", "url": "https://christianespinosa.com/about" }, "publisher": { "@type": "Organization", "name": "Christian Espinosa", "logo": { "@type": "ImageObject", "url": "https://christianespinosa.com/logo.svg" } } }, { "@context": "https://schema.org", "@type": "FAQPage", "mainEntity": [ { "@type": "Question", "name": "Do I need a separate SBOM for the device firmware and the companion mobile app?", "acceptedAnswer": { "@type": "Answer", "text": "Yes. Each independently distributed software artifact gets its own SBOM. The submission package can bundle them, but they must be individually generated, scanned, and maintained." } }, { "@type": "Question", "name": "Does FDA accept a PDF of the SBOM?", "acceptedAnswer": { "@type": "Answer", "text": "No. The SBOM must be machine-readable (SPDX or CycloneDX). A PDF rendering can accompany the submission for human reviewers, but the authoritative artifact is the structured file." } }, { "@type": "Question", "name": "How often does the SBOM need to be regenerated postmarket?", "acceptedAnswer": { "@type": "Answer", "text": "Whenever the software changes, and on a recurring vulnerability-scan cadence regardless of whether the software changed. Monthly is the minimum credible cadence; high-risk surface warrants weekly." } }, { "@type": "Question", "name": "What if a third-party supplier refuses to disclose their components?", "acceptedAnswer": { "@type": "Answer", "text": "Document the gap, treat the entire opaque component as SOUP at the highest risk tier, apply compensating controls (network isolation, monitoring, restricted privileges), and disclose the limitation in your risk file. Reviewers accept honesty about a gap; they reject pretending it does not exist." } }, { "@type": "Question", "name": "Are AI/ML model weights part of the SBOM?", "acceptedAnswer": { "@type": "Answer", "text": "Treat them as software components. Capture model name, version, supplier, training data provenance where available, and known model-level vulnerabilities (data poisoning history, prompt-injection susceptibility for LLMs). FDA is converging on this expectation for SaMD with AI/ML components." } } ] } ] --- [Skip to content](#main) [](/) [About](/about)[Speaking](/speaking)[Cybersecurity](/cybersecurity)[Programs](/programs)[Books](/books)[Media](/media) Writing Search Ctrl K[Connect](/connect) Article # SBOM Hygiene for Medical Devices: A Practical 2026 Playbook Direct answer A defensible medical device SBOM is generated automatically from the build pipeline in SPDX or CycloneDX, captures every first-party, third-party, and SOUP component with version and supplier, links each entry to a live vulnerability feed, and is regenerated on every release and on a recurring postmarket cadence. The deliverable to FDA is not the file; it is the process that keeps the file true. ## Key takeaways - An SBOM produced by hand or only at submission time is the single most common cause of postmarket cybersecurity surprises. - SPDX and CycloneDX are both acceptable to FDA; pick one, generate it from the build, and stop debating format. - SOUP analysis is where most submissions fail review, not SBOM generation itself. - Reviewers cross-check submitted SBOMs against the CISA KEV catalog and the NVD; unaddressed criticals draw deficiencies. - Your postmarket monitoring is only as good as the SBOM it queries against, so the same artifact has to live past clearance. On this page 1. [What does FDA actually expect in a medical device SBOM?](#what-does-fda-actually-expect-in-a-medical-device-sbom) 2. [Where should the SBOM actually be generated?](#where-should-the-sbom-actually-be-generated) 3. [How do you handle SOUP and third-party components properly?](#how-do-you-handle-soup-and-third-party-components-properly) 4. [How do you keep the SBOM current after release?](#how-do-you-keep-the-sbom-current-after-release) 5. [What format should you pick: SPDX or CycloneDX?](#what-format-should-you-pick-spdx-or-cyclonedx) 6. [How does the SBOM connect to international submissions?](#how-does-the-sbom-connect-to-international-submissions) ## Why this matters Since FDA gained Refuse-to-Accept authority under Section 524B of the FD&C Act, the SBOM has moved from a nice-to-have appendix to a load-bearing artifact in every premarket submission. In 2025, across the 250+ submissions my team at [Blue Goat Cyber](https://bluegoatcyber.com/) cleared, weak SBOMs and thin SOUP analyses were the most common single reason a package came back with deficiencies. The deeper problem is that the SBOM is also the foundation of postmarket cybersecurity. When a new critical CVE lands against a library you embedded eighteen months ago, the speed of your response is gated entirely by whether your SBOM is accurate, current, and queryable. Teams that treat the SBOM as a submission artifact discover this the hard way; teams that treat it as a living engineering asset respond in hours, not weeks. ## What does FDA actually expect in a medical device SBOM? FDA expects a machine-readable SBOM (SPDX or CycloneDX) that lists every software component shipped on the device or in companion software, including operating system, drivers, libraries, embedded RTOS, third-party SDKs, open-source dependencies, and any binary blobs from chipset vendors. Each entry should carry name, version, supplier, and a unique identifier (PURL or CPE) sufficient to map against vulnerability databases. The FDA [premarket cybersecurity guidance](https://www.fda.gov/regulatory-information/search-fda-guidance-documents/cybersecurity-medical-devices-quality-system-considerations-and-content-premarket-submissions) is explicit that the SBOM must be accompanied by a vulnerability assessment and a plan for ongoing monitoring. A list of components without that wrapper is not an SBOM in the regulatory sense; it is a parts manifest. ## Where should the SBOM actually be generated? In the build pipeline, not in a spreadsheet, and not at submission time. Tools like Syft, CycloneDX Maven/Gradle/npm/PyPI plugins, and SPDX generators integrate into CI in an afternoon. The output should be versioned alongside the build artifact so every released firmware image has a corresponding SBOM hash bound to it. When reviewers ask, 'Does this SBOM represent the device under review?' you want to answer with build provenance, not a story. Sign the SBOM with the same key chain you use for firmware signing whenever the device threat model allows it. ## How do you handle SOUP and third-party components properly? Software of Unknown Provenance is the category most teams underestimate. Any component you did not author and cannot fully audit is SOUP: open-source libraries, vendor SDKs, embedded RTOS kernels, chipset firmware, machine learning model weights. AAMI TIR57 expects you to document the rationale for using each SOUP component, its known vulnerabilities, the residual risk it introduces, and the mitigations you applied. A defensible SOUP analysis ties every component to (1) a supplier of record, (2) a current vulnerability scan, (3) a justification for inclusion, and (4) a fallback plan if the supplier goes away or the component becomes unsupported. The fallback plan is the part teams skip; reviewers notice. ## How do you keep the SBOM current after release? The SBOM has to be regenerated whenever the codebase changes (every release, every hotfix) and re-scanned against vulnerability feeds on a defined cadence. Monthly is the minimum credible cadence for active products; weekly is better for high-risk surface (network-connected, wireless, exposed services). The operational pattern that works: a scheduled job pulls the current SBOM for every supported firmware version, queries the [NVD](https://nvd.nist.gov/) and the [CISA Known Exploited Vulnerabilities Catalog](https://www.cisa.gov/known-exploited-vulnerabilities-catalog), and opens a triage ticket the moment a new CVE matches a component in the bill of materials. The triage decision (patch now, patch in next release, accept with compensating control, retire) is logged against the device record, not the engineer's inbox. ## What format should you pick: SPDX or CycloneDX? Either. Both are accepted by FDA, both are machine-readable, and both have mature tooling. CycloneDX has slightly richer vulnerability and pedigree extensions; SPDX has slightly broader legal and license tooling. Pick the one your toolchain produces natively and stop holding meetings about it. What matters is consistency across the product portfolio. If you have three product lines each producing a different format, your postmarket monitoring has to speak three dialects, and that is where errors creep in. ## How does the SBOM connect to international submissions? The same SBOM, with minor metadata additions, satisfies EU MDR, the EU Cyber Resilience Act, MDCG 2019-16, IMDRF principles, TGA expectations, and the maturing NMPA and PMDA cybersecurity requirements. The cost of producing a high-quality SBOM is amortized across every jurisdiction you launch into, which is why the math favors investing in the pipeline once. Map your SBOM and SOUP analysis to the strictest jurisdiction in your roadmap. Back-mapping documentation later is almost always more expensive than over-engineering it once at the start. KEY MISTAKE Generating the SBOM the week before submission, by hand, from a developer's recollection. Reviewers can tell. Build pipelines do not forget components; humans do. REVIEWER LANGUAGE When a deficiency letter cites 'incomplete characterization of third-party software,' it almost always means your SOUP analysis stopped at naming components and did not justify their inclusion or address known vulnerabilities. ## How Christian approaches this At [Blue Goat Cyber](https://bluegoatcyber.com/) we build the SBOM into the client's CI pipeline before we write a single line of the premarket package. The SBOM becomes the source of truth for the threat model, the vulnerability report, the postmarket plan, and the labeling. Every artifact in the submission references the same component manifest, with the same version pins, signed by the same build. The approach is documented in my 2026 book, _[Medical Device Cybersecurity: An In-Depth Guide](https://medicaldevicecybersecuritybook.com)_ (see the [chapter overview](/books/medical-device-cybersecurity)). The chapter on SBOM and SOUP is the one I get the most questions about from product teams, because it is the one that changes day-to-day engineering practice the most. Related guides: [Threat modeling connected medical devices](/guides/threat-modeling-connected-medical-devices-a-practitioner-guide), [Postmarket vulnerability management](/guides/postmarket-vulnerability-management-for-connected-medical-devices), and [What the FDA actually wants in a 2026 premarket submission](/guides/what-the-fda-actually-wants-in-a-2026-premarket-cybersecurity-submission). ### Get the full playbook in book form This guide is one slice of \*Medical Device Cybersecurity: An In-Depth Guide\*, shipping in 2026. Get launch notification, the full chapter list, and a sample on the book site. [Visit the book site](https://medicaldevicecybersecuritybook.com) Prefer the on-site overview? See the chapter list at /books/medical-device-cybersecurity. ## Frequently asked questions ### Do I need a separate SBOM for the device firmware and the companion mobile app? Yes. Each independently distributed software artifact gets its own SBOM. The submission package can bundle them, but they must be individually generated, scanned, and maintained. ### Does FDA accept a PDF of the SBOM? ### How often does the SBOM need to be regenerated postmarket? ### What if a third-party supplier refuses to disclose their components? ### Are AI/ML model weights part of the SBOM? ### Get the full playbook in book form This guide is one slice of \*Medical Device Cybersecurity: An In-Depth Guide\*, shipping in 2026. Get launch notification, the full chapter list, and a sample on the book site. [Visit the book site](https://medicaldevicecybersecuritybook.com) Prefer the on-site overview? See the chapter list at /books/medical-device-cybersecurity. About the author [Christian Espinosa](/about), MBA, CISSP, PMP · Founder, Blue Goat Cyber · Author, Medical Device Cybersecurity: An In-Depth Guide (2026) I'm the founder and CEO of Blue Goat Cyber, a medical device cybersecurity firm where my team has supported 250+ FDA submissions with zero failing to clear on cybersecurity. I previously founded and sold Alpine Security. I host The Med Device Cyber Podcast and wrote The Smartest Person in the Room and The In-Between: Life in the Micro, with Medical Device Cybersecurity: An In-Depth Guide out in 2026. Air Force Academy grad, 24x Ironman, climber of two of the Seven Summits. Christian Espinosa Bestselling author, keynote speaker, and Founding CEO of [Blue Goat Cyber](https://bluegoatcyber.com/). Helping technical leaders develop the soft skills that turn brilliance into impact. [](https://www.linkedin.com/in/christianespinosa/)[](https://x.com/Ironracer)[](https://www.instagram.com/christian.espinosa.official/)[](https://www.youtube.com/@ChristianEspinosaOfficial)[](https://www.facebook.com/christian.espinosa.official) Explore - [About](/about) - [Timeline](/timeline) - [Speaking](/speaking) - [Cybersecurity](/cybersecurity) - [Programs](/programs) Read - [Books](/books) - [Guides](/guides) - [Blog](/blog) - [Media](/media) - [Podcast Interviews](/podcasts) - [Success Stories](/success-stories) Connect - [Contact Christian](/connect) - [LinkedIn ↗](https://www.linkedin.com/in/christianespinosa/) - [Blue Goat Cyber ↗](https://bluegoatcyber.com/) - [Resources](/resources) © 2026 Christian Espinosa. All rights reserved. [Privacy](/privacy-policy)[Terms](/terms-of-use)