On this page
Published: · Updated:
Key Takeaways
- Provide a machine-readable SBOM through the applicable eSTAR cybersecurity workflow; follow that template version’s packaging instructions.
- An SBOM submitted without an accompanying vulnerability assessment of its components is an incomplete deliverable.
- The SBOM must correspond to the exact software version being submitted for clearance.
- Your cybersecurity management plan has to reference the SBOM and describe the postmarket maintenance loop.
- Cloud backend and companion app components belong in the submitted SBOM when they participate in the device function.
Where does the SBOM go in a 510(k) submission?
The SBOM goes in the cybersecurity section of the 510(k) eSTAR, provided in machine-readable form through the applicable eSTAR cybersecurity workflow. CycloneDX and SPDX are options, not FDA-mandated formats. Follow the template version’s packaging instructions. Alongside it you attach a vulnerability assessment covering the listed components, a support and end-of-support statement, and a cybersecurity management plan that describes how the SBOM is regenerated and monitored after clearance.
Placement sounds like a clerical detail until a reviewer cannot find the SBOM, or finds it but cannot ingest it, or finds it with no vulnerability analysis attached. These gaps can prompt questions or requests for additional information; no particular review outcome is automatic. This guide covers exactly where the SBOM sits in a 510(k), what has to travel with it, and how it connects to the rest of the cybersecurity package.
Why this matters
Section 524B applies to cyber devices, which for most manufacturers means the 510(k) is the first place the SBOM obligation becomes concrete. The February 3, 2026 final premarket cybersecurity guidance sets the expectation that the SBOM is not a standalone inventory but the input to a vulnerability analysis and to a documented postmarket process.
Reviewers read the SBOM as evidence of two things: that you know what is in your device, and that you have a mechanism to keep knowing after clearance. A file with no analysis attached answers the first question and leaves the second open, so explain the connection between inventory, analysis, and maintenance.
Where each artifact lands in the eSTAR
| Artifact | Where it goes | Format |
|---|---|---|
| SBOM | Cybersecurity section, as an attachment | Machine-readable industry-accepted format; no FDA version floor |
| Vulnerability assessment of SBOM components | Cybersecurity section, referenced from the SBOM discussion | PDF or structured document |
| VEX statements | Cybersecurity section, alongside the vulnerability assessment | CycloneDX VEX, OpenVEX, or CSAF |
| Support and end-of-support statement | Cybersecurity section and device labeling where applicable | Narrative |
| Cybersecurity management plan | Cybersecurity section | Narrative, references the SBOM process |
| Human-readable SBOM rendering (optional) | Cybersecurity section, as a companion only |
The February 3, 2026 FDA guidance, §V.A.4(b), p. 17 recommends machine-readable SBOMs, encourages industry-accepted formats, and specifies no format or version floor. Follow the applicable eSTAR version’s file and packaging instructions rather than assuming only a separate attachment qualifies.
What has to accompany the SBOM
A vulnerability assessment. Every component in the SBOM should be evaluated against current vulnerability data at the time of submission. The output is not a raw CVE dump. It is a triaged analysis: which findings affect the device as configured, which do not and why, and what the plan is for those that do.
VEX statements (recommended practice, not an FDA requirement). Consider recording a status per matched CVE (not affected, affected, fixed, under investigation) and the justification. This is what prevents a large open-source dependency tree from reading as a thousand unresolved risks.
A support statement. Provide component support level and end-of-support date as recommended by the FDA; a separate addendum may carry this information.
A maintenance description. The cybersecurity management plan describes how the SBOM is regenerated (per-build generation is our recommended internal practice, not an FDA cadence), diffed, re-scanned, and triaged, with the cadence and SLAs written down.
Scope: what belongs in the submitted SBOM
- Device firmware, including bootloader, operating system, and application layers.
- All third-party libraries and SOUP, including transitive dependencies, not just direct ones.
- Cloud backend application components that participate in delivering the device function.
- Companion mobile app dependencies for both iOS and Android.
- Container images used for cloud-side components, enumerated by layer and package.
- AI software and inference runtimes where present; model and dataset references are recommended traceability additions, not FDA-required AIBOM fields.
For hyperscaler infrastructure, document shared-responsibility boundaries and justify inventory scope based on device function, supplier information, and risk. Do not assume a categorical exclusion below the application layer.
Version alignment
The submitted SBOM must correspond to the exact software version being submitted for clearance. This sounds obvious and fails often, because SBOM generation is run once during preparation and then the software gets three more release candidates before the submission goes out. Generate the SBOM in CI so the artifact is a byproduct of the release build rather than a manual step someone has to remember to repeat.
If you submit a Traditional 510(k) and then modify software during review, the SBOM has to be refreshed as part of the amendment.
Common placement and packaging errors
- SBOM embedded as a table inside the cybersecurity narrative PDF rather than attached as a file.
- SBOM filed under software documentation instead of the cybersecurity section, where the reviewer looks for it.
- SBOM attached with no vulnerability assessment, so the reviewer has components but no risk analysis.
- SBOM version does not match the submitted software build.
- Cloud backend and companion app omitted entirely.
- Transitive dependencies missing, so only top-level libraries appear.
- No reference to the SBOM anywhere in the cybersecurity management plan, leaving the postmarket loop undocumented.
How Blue Goat approaches this
We treat the SBOM as one node in a connected package rather than a file to attach at the end. The component inventory comes out of your build pipeline, the vulnerability assessment is generated against that exact inventory, the VEX statements carry justifications a reviewer can evaluate, and the cybersecurity management plan references the same process by name. Before submission we run the package the way a reviewer would: open the eSTAR cybersecurity section, locate the SBOM, parse it, resolve every identifier, and check whether the accompanying analysis actually covers what the file lists. Gaps found that way are cheap. Addressing gaps early may reduce follow-up questions but does not guarantee a review outcome.
FAQ
CTA
If you want to know whether your 510(k) cybersecurity section has gaps a reviewer would question, we will review the package for inventory, analysis, and documentation gaps and tell you what is missing before you file. Talk to a MedTech cybersecurity expert.
Related
- FDA SBOM Requirements for Medical Devices (pillar guide)
- What SBOM Format Does the FDA Require
- Who Is Responsible for Supplier SBOMs
- FDA Premarket Cybersecurity Submission Checklist
Free tools for this
- SBOM Readiness Checker - check an SBOM against the FDA's expected fields before you submit it.
- Submission Pathway Selector - work out whether the device fits 510(k), De Novo, or PMA.
Sources & references
Primary sources cited in this article. Links open in a new tab.
- February 3, 2026 FDA guidance- U.S. FDA
