On this page
Key Takeaways
- The SBOM is a standalone machine-readable attachment in the eSTAR cybersecurity section, not an appendix inside a narrative PDF.
- 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.
The SBOM goes in the cybersecurity section of the 510(k) eSTAR, attached as a machine-readable CycloneDX or SPDX file. It is not pasted into a narrative document and not filed under software documentation. 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. Each of those produces the same outcome: an Additional Information request that costs you a review cycle on an otherwise sound submission. 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, which is why "SBOM provided without vulnerability assessment" recurs so consistently in deficiency letters.
Where each artifact lands in the eSTAR
| Artifact | Where it goes | Format |
|---|---|---|
| SBOM | Cybersecurity section, as an attachment | CycloneDX 1.4+ or SPDX 2.3+, JSON or XML |
| 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 machine-readable file is the deliverable. A human-readable rendering is optional and never a substitute.
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. For any known CVE affecting a listed component, state the status (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. Reviewers want the end-of-support horizon for the components your device depends on and evidence that you have a plan when a component reaches it.
A maintenance description. The cybersecurity management plan describes how the SBOM is regenerated (every build), 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 and ML artifacts where present, including models, referenced datasets, and inference runtimes.
Hyperscaler substrate below your application layer is covered by the shared-responsibility model and does not need component-level enumeration. Your application stack running on it does.
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. Gaps found in an Additional Information letter cost a review cycle.
FAQ
CTA
If you want to know whether your 510(k) cybersecurity section would survive a reviewer's first pass, we will run the package the way they will and tell you what is missing before you file. Talk to a MedTech cybersecurity expert.
