If your medical device is a cyber device in 2026, your FDA submission needs an SBOM or it can be refused before review starts. Since February 2, 2026, SBOM work also needs to sit inside your quality system, with records tied to design, risk, change control, and CAPA.
Here’s the short version of what I’d want to know first:
- First, confirm scope. If the device has software or firmware, connects to a network, and can face cybersecurity threats, treat it as in scope.
- Next, assign owners. Engineering, security, QA/RA, regulatory, and leadership each need named duties.
- Then, build the SBOM from the as-shipped product. Use SPDX or CycloneDX, and include first-party code, third-party software, firmware, COTS, and transitive dependencies.
- After that, validate it. The SBOM should match the risk file, software records, device configuration, and submission package.
- Last, keep it current. Update it for every release or patch, track CVEs, KEV entries, and EOS/EOL dates, and notify customers fast when risk is high.
A few points stand out. The FDA now expects a machine-readable SBOM, not just a PDF or spreadsheet. The article also points to a customer notice window of about 30 days for serious vulnerabilities, which puts more pressure on postmarket tracking and vendor communication.
What this means in plain English: SBOM compliance is no longer a one-time submission task. It is a repeatable process that starts before filing and continues after the device ships.
FDA SBOM Compliance Checklist: 5 Steps for Medical Device Makers in 2026
Webinar: FDA Expectations for SBOMs - A Deep Dive with Blue Goat Cyber
sbb-itb-535baee
Checklist Step 1: Establish Scope, Ownership, and Governance
Before you document components, set the boundaries first: scope, ownership, and where evidence will live. Do that early, and the submission package is much easier to keep organized and audit-ready.
Identify In-Scope Devices and Submission Pathways
After you confirm cyber-device status, map each product to its submission pathway: 510(k), De Novo, or PMA. Then place the SBOM in Section 5 of eSTAR. If scope is fuzzy, submissions can stall, and that can turn into a business problem fast.
Once scope is set, assign clear owners for generation, validation, and submission.
Assign SBOM Responsibilities Across Teams
SBOM compliance doesn't sit with one team. It cuts across engineering, product security, QA/RA, regulatory affairs, and management. Each group has a separate job, and that split should be clear from day one.
| Role | Primary Responsibility | Key Deliverable |
|---|---|---|
| Engineering | SBOM generation and CI/CD integration | Machine-readable SBOM in SPDX or CycloneDX format |
| Product Security | Vulnerability analysis and VEX documentation | VEX files / risk mitigation records |
| QA/RA | Configuration management and compliance | DHF/DMR integration |
| Regulatory Affairs | Submission package assembly | eSTAR cybersecurity section |
| Management | Risk oversight via management review | Management review minutes |
Put these roles in writing before development starts. Name specific owners for generation, validation, version control, and submission readiness. It also helps to set a clear escalation path. Management reviews are the right place to surface SBOM-related cybersecurity risks that could affect patient safety or clinical performance [2].
Those owners should all work from one shared evidence repository used during validation and submission.
Centralize Evidence and Risk Workflows
Scattered records create submission risk. The SBOM, threat model, risk assessment, and testing records should all trace back to one another, and the FDA's 2025 guidance directly calls for that traceability [2].
Censinet RiskOps™ can bring SBOM evidence, device risk workflows, and submission records into one place. That same repository also supports SBOM generation and validation in Step 2.
Checklist Step 2: Build a Complete, Machine-Readable SBOM
With scope and ownership locked in, the next task is the SBOM itself. Build it from the as-shipped configuration, not the development view. That difference matters. Manual SBOMs often leave out components that end up in the shipped product.
Use SPDX or CycloneDX and Meet NTIA Minimum Elements
The FDA expects SBOMs to be machine-readable and based on a standard format. SPDX and CycloneDX are both accepted. Whichever one you pick, each component entry should include the seven NTIA minimum elements [2]:
| NTIA Element | What It Means |
|---|---|
| Supplier Name | Entity that creates or identifies the component |
| Component Name | Common name of the software part |
| Version String | Specific version identifier |
| Unique Identifier | PURL or CPE string for automated vulnerability matching |
| Dependency Relationship | How the component relates to others, such as depends on |
| SBOM Author | Entity that generated the SBOM |
| Timestamp | Date and time the SBOM was created |
Once the format is set, the goal is simple: capture every shipped component and dependency.
Include First-Party Code, Third-Party Software, and Transitive Dependencies
A complete SBOM should show every shipped layer, including first-party code, third-party software, open-source libraries, firmware, bootloaders, drivers, and the OS.
The tricky part is usually transitive dependencies - the dependencies of your dependencies. These are easy to miss if you're building the SBOM by hand. Use software composition analysis (SCA) tools during the build process to identify the full dependency tree and help make sure the SBOM lines up with the as-shipped build [2].
If the dependency tree still has gaps, document them clearly. Say what's missing, why it's missing, and what you did to track it down.
Add Support Status and End-of-Support Dates
Add lifecycle metadata for each component: support status, EOS date, and EOL date [2]. Without that, the SBOM is just a parts list. With it, the SBOM becomes useful for postmarket risk management.
If a component is already legacy or abandoned, reflect that in the risk assessment. It also helps to link each SBOM entry to the device's hazard analysis, so it's clear that every software-related risk ties back to a specific component in the inventory.
Use this SBOM as the baseline for premarket validation in the next step.
Checklist Step 3: Validate the SBOM for Premarket Submission
Once you have a complete, machine-readable SBOM, the job isn't done. Now you need to make sure it holds up during FDA review. If the SBOM isn't tied to the submission record, that can lead to FDA deficiency letters or Refuse to Accept (RTA) actions [2].
Cross-Check the SBOM Against Risk Assessment and Configuration Records
After the SBOM is built, check it against every other submission artifact. Each component in the SBOM should connect back to risk, testing, and configuration records. If those records don't line up, reviewers can flag the submission.
Cross-check the SBOM against the risk file, SAD, DMR, and labeling. For any component with a vulnerability, there should be a matching entry in the risk management file that spells out the risk, severity, and mitigation. The SAD should match the SBOM. The DMR should confirm that the SBOM version matches the exact software configuration going into production. Labeling should also line up with the device's connectivity and update features.
Once the SBOM matches the risk file and configuration record, document how it was generated.
Document How the SBOM Is Generated and Maintained
How the SBOM was built matters just as much as what's inside it. Reviewers want proof that the SBOM reflects the product that actually ships.
Document the automated build process used to generate the SBOM. Manual SBOMs often miss transitive dependencies and can drift away from the shipped build [2].
Include the build source, SBOM tool, validation method, and update trigger for each release. It also helps to include Vulnerability Exploitability eXchange (VEX) files. VEX artifacts show which vulnerabilities in the SBOM are not exploitable in the device's specific configuration. That gives reviewers more context and can cut down on unnecessary FDA deficiency letters [2].
Use the comparison below to spot gaps before submission.
Complete vs. Incomplete Submission Packages: A Comparison
A lot of review delays come down to a few missing pieces. This table shows the difference between a package that's ready for review and one that's likely to run into trouble.
| Element | Complete Submission | Incomplete Submission |
|---|---|---|
| SBOM Format | Machine-readable SBOM | Human-readable only |
| Dependency Depth | Full tree, including transitive dependencies | Top-level dependencies only |
| Vulnerability Context | VEX files for non-exploitable CVEs | CVEs listed without exploitability context |
| Traceability | Linked to threat model and risk assessment | Standalone document with no risk linkage |
| Lifecycle Data | EOS/EOL dates for all components | Missing support status or expiration dates |
| Maintenance Plan | Documented postmarket update procedure | No update process |
| Outcome | Smoother review; faster market access | Refuse to Accept (RTA); review clock stops |
Checklist Step 4: Maintain the SBOM for Postmarket Risk Management
Premarket submission is just the beginning. Once a device is in use, the SBOM needs to stay accurate and usable through the product’s full lifecycle. The validated premarket SBOM should serve as the baseline for every postmarket change.
Update the SBOM with Every Software Release and Patch
Every software release, patch, or component replacement should trigger an SBOM update. Under ISO 13485:2016 Clause 7.5.9, SBOM maintenance should sit inside your Quality Management System. That means each update goes through formal change control, with a clear record of what changed, when it changed, and why.
The goal is simple: keep the SBOM matched to the exact configuration running in the field. If those records drift, traceability starts to fall apart.
Monitor SBOM Components for Vulnerabilities and Unsupported Software
This is where postmarket SBOM work gets more hands-on. Manufacturers should continuously check SBOM components against the National Vulnerability Database (NVD), CISA's Known Exploited Vulnerabilities (KEV) Catalog, and vendor security advisories. Use Vulnerability Exploitability eXchange (VEX) files to show whether a known vulnerability in an SBOM component can actually be exploited in the device’s specific setup.
Support status matters too. EOS and EOL dates should be tracked as part of postmarket monitoring, not handled as an afterthought.
Make these checks part of routine change control and vulnerability response:
| Task | Frequency | Responsibility |
|---|---|---|
| Cross-reference components against CISA KEV/NVD | Continuous | Security Team |
| Update SBOM version and metadata | Every release/patch | Engineering/DevOps |
| Generate/update VEX for new CVEs | Upon vulnerability discovery | Security/Risk Management |
| Review component EOS/EOL status | Quarterly | Product Management |
| Notify HDOs of critical vulnerabilities | Within 30 days of discovery | Regulatory/Customer Support |
HDOs use SBOMs to assess procurement risk, watch their installed base for vulnerabilities, and put compensating controls in place for devices with known risks. That’s why timely vendor communication matters so much. Customer notification expectations for discovered vulnerabilities have been elevated to approximately 30 days [1].
Conclusion: Your 2026 FDA SBOM Compliance Checklist
When monitoring, updates, and notification are handled with discipline, SBOM compliance stays part of day-to-day work instead of turning into a scramble after something goes wrong.
FDA SBOM compliance in 2026 comes down to five repeatable steps: confirm which devices qualify as cyber devices, assign clear ownership across teams, generate a machine-readable SBOM that meets NTIA minimum elements, validate it against every submission artifact before filing, and maintain it continuously after the device ships.
Censinet RiskOps™ centralizes SBOM evidence and postmarket risk workflows for HDOs and vendors.
FAQs
How do I know if my device is a cyber device?
A medical device counts as a cyber device under Section 524B of the FD&C Act if it:
- includes software validated, installed, or authorized by the sponsor
- can connect to the internet, either directly or indirectly
- has tech features that could be exposed to cybersecurity threats
If you're not sure whether your device fits this definition, the FDA recommends getting clarification before you submit. A wrong classification can slow down market approval.
What happens if my SBOM is incomplete or outdated?
An incomplete or outdated SBOM can create major regulatory and operational risks.
In a premarket submission, it may trigger a Refuse to Accept notice or an Additional Information letter. And that can push FDA clearance back by 3 to 6 months.
There’s also the day-to-day security side of it. If the SBOM isn’t current, vulnerability tracking and patching get weaker. That can leave gaps that are easy to miss until they become a much bigger problem.
The fallout can include device misbranding, market withdrawal, and risks to patient safety.
How should teams keep the SBOM current after launch?
Treat the SBOM as a living document. It should change with every software release, not sit on a shelf and gather dust.
Create a new versioned SBOM for each release, link it to the exact build, and manage every update through your ISO 13485 quality system and formal change control. That connection matters. If someone asks, “Which components were in this version?” you need a clear, direct answer.
Use machine-readable formats so the SBOM can move through your workflow without manual rework. Automate vulnerability monitoring where you can, and keep current SBOMs in secure central hubs so the latest file is easy to find and review.
Your PSIRT should map new CVEs to the SBOM as they appear. That gives the team a practical way to decide what to do next, whether that means patching the issue or putting compensating controls in place.
