FDA SBOM Requirements for Medical Devices

For medical device manufacturers, a software bill of materials (SBOM) is no longer simply a software-development convenience. For a device that meets the statutory definition of a “cyber device,” an SBOM is part of the information required in specified FDA premarket submissions. It is also one of the most useful artifacts a manufacturer can maintain for vulnerability assessment, patch planning, customer communication, and audit readiness.

The compliance dates are easy to confuse. Section 524B of the Federal Food, Drug, and Cosmetic Act (FD&C Act) became effective on March 29, 2023. From that date, sponsors of cyber devices were required to submit information showing compliance with the section's cybersecurity requirements. FDA initially used enforcement discretion for Refuse-to-Accept (RTA) decisions based solely on missing Section 524B information. That transition period ended October 1, 2023. FDA now expects complete Section 524B information, and an eSTAR submission can be placed on Technical Screening hold if its cybersecurity responses or attachments are inadequate.

Understanding FDA SBOM requirements early can help manufacturers avoid documentation gaps and review friction. This guide explains which devices require an SBOM, what submissions should contain, and how manufacturers can maintain it throughout the product lifecycle.

Organizations pursuing medical device regulatory compliance should not assemble the SBOM shortly before filing. Build it into development, configuration management, the quality management system (QMS), and postmarket cybersecurity operations.

What Is an SBOM for a Medical Device?

An SBOM is a structured inventory of the software components and supply-chain relationships within a product. For medical devices, that can cover manufacturer-developed software, firmware, commercial components, open-source libraries, off-the-shelf software, and relevant upstream dependencies.

For nontechnical reviewers, an SBOM resembles an ingredient list—but it must identify components precisely enough to determine whether a new vulnerability affects a device version.

FDA's current cybersecurity guidance recommends machine-readable SBOM documentation consistent with the baseline attributes in the National Telecommunications and Information Administration's (NTIA's) Framing Software Component Transparency. Those attributes include:

• Supplier name
• Component name
• Component version
• Unique identifier
• Dependency relationship
• Author of the SBOM data
• Timestamp of assembly

FDA also recommends giving the support level and end-of-support date for every component. This additional information matters because a technically functional component may still create unacceptable lifecycle risk when its supplier no longer monitors or patches it.

FDA SBOM Requirements Under Section 524B

Section 524B applies to a sponsor that submits a 510(k), Premarket Approval Application (PMA), Product Development Protocol (PDP), De Novo request, or Humanitarian Device Exemption (HDE) for a cyber device. Special and Abbreviated 510(k)s and relevant PMA or HDE supplements are included.

The statute requires the sponsor to provide information demonstrating that the device meets three central obligations:

1. Submit a plan to monitor, identify, and address postmarket cybersecurity vulnerabilities and exploits in a reasonable time, including coordinated vulnerability disclosure procedures.
2. Design, develop, and maintain processes that provide reasonable assurance that the device and related systems are cybersecure, and make postmarket updates and patches available.
3. Provide an SBOM covering commercial, open-source, and off-the-shelf software components.

These requirements should be read alongside FDA's February 2026 final cybersecurity guidance. Guidance recommendations are generally nonbinding, but Section 524B creates statutory requirements. The guidance explains the documentation FDA considers useful for demonstrating compliance and reasonable assurance of safety and effectiveness.

Which Devices Are “Cyber Devices”?

A device is a cyber device under Section 524B when it meets all three statutory criteria:

• It includes software validated, installed, or authorized by the sponsor as a device or in a device.
• It can connect to the internet.
• It contains sponsor-authorized technological characteristics that could be vulnerable to cybersecurity threats.

Examples include an infusion pump with network-connected firmware, an imaging system that exchanges hospital data, a connected diagnostic instrument, or Software as a Medical Device (SaMD) using web or cloud architecture. The connection need not be continuous; capability may be direct or indirect, including through another device, network, or removable media.

Manufacturers should prescreen applicability at the beginning of regulatory strategy, not during submission assembly. Document the analysis even when the device falls outside the definition. FDA's broader cybersecurity guidance also covers devices with cybersecurity considerations beyond the narrower statutory subset of cyber devices, including some devices for which no premarket submission is required.

What Should an FDA-Ready SBOM Package Contain?

The machine-readable SBOM is the foundation, not the entire package. A reviewer-ready submission should place it in the context of the device, build, risks, and controls.

Start with a complete inventory, including direct and relevant transitive dependencies. For each entry, supply the NTIA baseline attributes plus FDA's recommended support status and end-of-support date. If information is unavailable, identify the gap and provide a credible justification rather than leaving an unexplained blank.

Next, tie the SBOM to the exact released build. Common industry formats include SPDX and CycloneDX. FDA recommends a machine-readable, industry-accepted format; it does not prescribe one universal syntax. A short human-readable appendix can help reviewers navigate the file, understand scope and exclusions, locate support information, and connect the SBOM to other cybersecurity evidence.

For configuration integrity, record the device model, software release, build identifier, generation date, and approval status. Where feasible, use a cryptographic hash or signed attestation to link the SBOM to its build. This is a sound traceability control, not a specific Section 524B mandate.

Finally, link components to the cybersecurity risk file. FDA recommends identifying known vulnerabilities, explaining how they were found, assessing their safety and security impact, and documenting applicable controls. Cross-references to threat models, architecture views, security testing, and residual-risk conclusions help reviewers see that risks are understood and controlled.

SBOM, Vulnerability Analysis, and VEX

An SBOM answers, “What software is present?” It does not answer, “Is this device exploitable?” A scanner may flag a CVE even though the vulnerable module is absent, the affected function is unreachable, or a compensating control exists.

A Vulnerability Exploitability eXchange (VEX) statement can communicate that status in a structured way. VEX is useful for documenting whether a product is affected, not affected, fixed, or still under investigation, together with the supporting rationale. FDA's guidance does not make VEX a universal submission requirement, but a well-supported VEX addendum can reduce ambiguity when an SBOM produces numerous apparent matches.

A “not affected” VEX conclusion should be supported by architecture, configuration, reachability, testing, or other objective evidence. Known exploited vulnerabilities, especially those in CISA's Known Exploited Vulnerabilities Catalog, deserve explicit attention.

SBOMs Within the Cybersecurity Plan and QMS

FDA treats cybersecurity as part of device safety and effectiveness and connects cybersecurity practices with the Quality Management System Regulation (QMSR). The QMSR took effect February 2, 2026, and incorporates ISO 13485:2016 by reference. An SBOM process should therefore produce controlled evidence, not an isolated spreadsheet owned only by engineering.

Define procedures for SBOM generation, review, approval, release, retention, and authorized disclosure. Assign owners across engineering, security, quality, regulatory, and postmarket teams. Set acceptance criteria for completeness, dependency depth, identifiers, unsupported components, vulnerability review, and build reconciliation.

Integrate SBOM changes with development, configuration management, supplier controls, and change control. A new component, update, end-of-support notice, or vulnerability may require a risk-file update and, depending on impact, investigation, CAPA, field remediation, reporting analysis, or a new-submission assessment.

A Secure Product Development Framework (SPDF) is one way to organize these activities across design, development, release, support, and decommissioning. FDA encourages an SPDF but allows other approaches that satisfy applicable requirements.

Postmarket Maintenance: Treat the SBOM as a Living Artifact

The submission SBOM is a versioned baseline, not a final deliverable. Postmarket teams must know which device models and fielded versions are exposed when a new vulnerability appears.

A durable operating model should:

• Monitor authoritative vulnerability sources and supplier notices.
• Map findings to affected components, builds, device models, and deployed versions.
• Assess exploitability, clinical impact, and existing controls.
• Update VEX or equivalent status records when appropriate.
• Initiate remediation and communicate patches or mitigations.
• Update the SBOM whenever released software changes.
• Preserve prior SBOM versions for traceability.

FDA recommends making current SBOM information continuously available to users, such as through a controlled portal. Plan access, revision status, notifications, and support commitments so it stays accurate.

Practical Generation and Tooling Guidance

Generate SBOMs within the integration and delivery pipeline where possible, then verify them through software composition analysis and release controls. Automation improves reproducibility, but output still needs qualified review.

Compare tools on stack coverage, transitive and embedded dependency detection, SPDX and CycloneDX support, identifier quality, vulnerability integration, VEX and attestation features, access controls, audit logs, and QMS integration. Test candidates against a representative build.

Common Submission Pitfalls

The most common failures are operational rather than conceptual:

• Stale SBOM: The file represents an earlier build. Tie generation and approval to release configuration.
• Incomplete scope: Firmware, containers, commercial packages, or transitive dependencies are missing. Define scope and reconcile multiple scanning methods.
• Weak identifiers: Component names cannot be reliably matched to vulnerability sources. Normalize identifiers and document exceptions.
• Missing support data: Upstream end-of-support dates are absent. Include lifecycle evidence in supplier monitoring and purchasing controls.
• Unresolved vulnerability hits: A raw scanner report is attached without safety, exploitability, or control analysis. Add evidence-based dispositions.
• Poor traceability: The SBOM is disconnected from threat models, architecture views, testing, and risk controls. Build explicit cross-references.
• No postmarket ownership: No team is responsible after authorization. Assign responsibilities, monitoring cadence, escalation criteria, and records.

These gaps can create reviewer friction. For 510(k)s submitted through eSTAR, inaccurate cybersecurity answers or missing attachments can lead to a Technical Screening hold. Failure to supply required Section 524B information creates RTA risk and can delay substantive review. This is an acceptance and review risk; an imperfect SBOM does not automatically produce a rejection or recall.

FDA SBOM Compliance Checklist

Before submission, confirm that the team can answer yes to the following:

• The cyber-device applicability assessment is documented.
• The SBOM matches the submitted software build and includes relevant dependency depth.
• Commercial, open-source, and off-the-shelf components are covered.
• NTIA baseline attributes, support status, and end-of-support dates are included or gaps are justified.
• A machine-readable, industry-accepted file is provided, with a concise reviewer guide or appendix.
• Known vulnerabilities have documented safety and security assessments and controls.
• VEX or an equivalent addendum is included where it clarifies exploitability status.
• The SBOM links to threat modeling, architecture, testing, and residual-risk documentation.
• The postmarket vulnerability management and coordinated disclosure plan is complete.
• Secure update and patch processes are supported by objective evidence.
• SBOM generation, approval, maintenance, and retention are controlled within the QMS.

Do Class I Devices Need a 510(k)?

Most Class I devices are exempt from 510(k), but “Class I” does not automatically mean “no premarket notification.” Exemptions are subject to limitations, and some Class I devices still require a 510(k). Manufacturers should verify the regulation and product code in FDA's Product Classification database and evaluate applicable limitations.

Even when a device is 510(k)-exempt, other regulatory controls still apply, and FDA's broader cybersecurity recommendations may remain relevant. Companies that need help determining the right pathway can seek experienced FDA 510(k) submission support.

How Quality Commercial Consultants Can Help

Quality Commercial Consultants helps medical device and health-technology companies turn SBOM output into submission-ready cybersecurity evidence. QCC can perform a 510(k), De Novo, or PMA SBOM readiness review; support SBOM generation and normalization; draft evidence-based VEX statements; connect component findings to threat models and risk controls; and integrate SBOM governance into QMS, change-control, supplier-control, CAPA, and postmarket workflows.

A practical next step is a compliance gap analysis followed by a pilot on one device build. This can reveal inventory blind spots, unsupported dependencies, unclear ownership, and weak regulatory links before submission.

Contact Us Today

We provide clear regulatory and cybersecurity guidance that meets you where you are today. Contact our team to schedule an SBOM readiness assessment and build a practical roadmap for an FDA-ready submission and sustainable postmarket program.