Who the statutory requirement covers
FDA explains that section 524B applies to covered cyber-device premarket applications or submissions from March 29, 2023. A cyber device meets three conditions: sponsor-authorized software in or as the device, ability to connect to the internet, and technological characteristics that could be vulnerable to cybersecurity threats. FDA’s FAQ identifies the submission types and discusses modifications. This is not a statement that every medical device, or every hospital software purchase, has the same submission duty.
Source: FDA · Cybersecurity in Medical Devices FAQs · Questions 1–3, 9–10.
Current FDA guidance
FDA’s February 2026 final guidance supersedes the June 2025 guidance. Sections V.A.4 and VII.C.3 address SBOMs. FDA recommends machine-readable documentation, component support information and end-of-support dates; additional support information may be provided separately. Its recommendations also address maintaining inventories through changes and making SBOM information available to users.
Source: FDA · Current guidance publication record.
Source: FDA · Cybersecurity guidance, February 2026 · Sections V.A.4, VI and VII.C.3.
The current guidance still references NTIA’s 2021 framing work. Do not assume the July 2026 minimum-elements publication silently changes FDA’s referenced documentation expectations. Maintain a mapping between the submission guidance, current internal inventory profile and customer delivery needs.
An evidence package for the manufacturer
| Evidence | Practical control | Reviewer question |
|---|---|---|
| Device and software identity | Bind inventory to model, software release and artifact | Does this describe the submitted configuration? |
| First-party and third-party composition | Combine build evidence and supplier inventories | Which components were not discoverable automatically? |
| Support information | Track source and review date for support status | What happens if a component loses support before the device? |
| Known vulnerabilities | Link component findings to product assessment | How was applicability investigated? |
| Changes | Retain inventory revisions and software baselines | Can the manufacturer reconstruct an earlier release? |
| Supplier gaps | Document unknowns, escalation and disposition | Who is responsible for obtaining missing evidence? |
This is a recommended organizing structure, not a substitute for the submission guidance. Cross-reference the device risk-management documentation rather than treating an SBOM upload as the entire cybersecurity case.
Generation and validation for a device
Select representative software and firmware variants. Inspect bundled libraries, static linking, embedded operating systems and licensed components. Upstream inventories can help, but bind each to the exact supplied version and the assembled device configuration.
Validate the declared format and separately test expected component coverage. Preserve the source of manual additions and uncertain identities. A binary scanner may provide useful independent evidence, but uncertainty in stripped firmware needs explicit handling rather than inferred version claims.
Record generator and validator versions, release digest, configuration and approval. Rehearse a corrected supplier inventory arriving after the original submission evidence was assembled.
Maintain through the product lifecycle
Assign ownership across product security, software engineering, regulatory affairs and supplier management. Establish triggers for review when software changes, advisories appear, support status changes or suppliers correct inventory data.
Use a controlled relationship between device models, supported releases and component inventories. Customer access should lead to version-identifiable information. A portal containing only the newest inventory is insufficient for an installed base running several supported versions.
Plan response communications and updates within the organization’s device-security process. Product cybersecurity documentation should be consistent with validated release and change-control evidence.
Procurement questions for supporting software
- Can the platform preserve device model, variant, release and inventory revision separately?
- Can it ingest supplier data without erasing unknowns or unsupported fields?
- Can support status and dates be maintained with attributable evidence?
- Can a reviewer export the original inventory and its approval history?
- Can product-specific vulnerability assessments remain separate from raw matches?
- Can retained data be accessed and exported throughout the intended support period?
Ask vendors to demonstrate these functions with representative artifacts. Review the organization’s specific device and submission facts against the current FDA sources before filing.
Primary sources
- FDA · Cybersecurity in Medical Devices FAQsAgency explanation of statute
- FDA · Cybersecurity guidance, February 2026Final, nonbinding guidance
- FDA · Current guidance publication recordFinal guidance publication record