Medical Device Cybersecurity: The SBOM and Patch Handoff

A connected medical device arrives with more than a power cable. It brings software dependencies, update arrangements, service connections, and decisions about who responds when a vulnerability appears. A purchasing team needs those decisions to remain usable after the sales conversation ends. An impressive security questionnaire cannot substitute for an identifiable installed version and a working route to the responsible manufacturer.

The FDA issued its final Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions guidance on February 3, 2026, superseding the June 27, 2025 final guidance. The revision history describes alignment with the Quality Management System Regulation. This is a dated regulatory update, checked for this article on October 14, rather than a new announcement today. FDA guidance and dated PDF

Guidance and statutory duties are different

FDA guidance expresses the agency's recommendations; it generally does not create binding obligations. Section 524B of the Federal Food, Drug, and Cosmetic Act supplies statutory duties for applicable cyber-device premarket submissions. The FDA FAQ identifies the covered submission pathways and explains that the requirements began with submissions from March 29, 2023. A previously authorized device can enter this scope when a change requires a new premarket submission. FDA cybersecurity FAQ, questions 1–5

The final two rows are an original procurement framework, not additional FDA requirements. Keeping these categories separate prevents a request for a useful operational document from being mislabeled as a universal legal mandate.

What the manufacturer must be able to address

Section 524B includes a postmarket vulnerability-management plan, processes supporting reasonable cybersecurity assurance, and an SBOM provided to FDA. Its patch provisions distinguish regular, justified cycles for known unacceptable vulnerabilities from out-of-cycle action as soon as possible for critical vulnerabilities that could cause uncontrolled risks. These duties belong to the applicable sponsor; installing a device in a hospital does not turn the hospital into its software manufacturer. FDA final guidance, section VII.C

The FDA also describes manufacturer vigilance and hospital protection of their systems as complementary responsibilities. FDA cybersecurity overview

For procurement, translate that division into questions with named owners. Who receives the vendor's advisory? Who determines which serial numbers have the affected build? Who can authorize a service session? Who signs off that a planned update has completed? An answer such as “IT handles security” is too broad to execute when several departments share the system.

An SBOM answers a version question

A software bill of materials is a component inventory. FDA recommends maintaining it with configuration changes and supplying component support information. FDA final guidance, section V.A.4

Its practical value depends on a join between three records: a component version, the device release containing it, and the installation running that release. A vulnerability notice naming a library does not alone establish whether a particular device is exploitable. An inventory match prompts an assessment of the component's use, exposure, and controls.

Ask a vendor to demonstrate that join on a sample delivery. A spreadsheet may be readable but difficult to merge automatically. A machine-readable inventory may still omit the relationship between an application and its embedded component. A procurement team can test both usefulness and coverage by selecting one component and tracing it through the delivered release and a sample asset record.

Also record the inventory's date and release identifier. “SBOM available” is a weak acceptance criterion if the file describes a release that was never installed. A later service visit can change software while leaving the original procurement folder untouched.

A fictional handoff with no patient information

Consider a fictional purchase of twelve connected laboratory instruments. Their manufacturer, models, components, and dates below are invented. The exercise concerns technical records and does not describe a real product or clinical workflow.

Now imagine an advisory names the example library. The local team opens a ticket connecting the advisory to these twelve assets. It requests the manufacturer's product-specific assessment rather than replacing a library independently. The manufacturer might identify an affected release, a remediation release, or reasons the vulnerable functionality is not present. The ticket should distinguish each possibility and retain the supporting evidence.

If an update is supplied, the record captures its authorized installation procedure, dependencies, validation arrangement, and final version. This exercise improves traceability; it cannot establish that a fictional or real device is secure.

Test the patch route before relying on it

Purchasers often ask how quickly a manufacturer can release a patch. They should also ask how the patch reaches the installed asset. A release date and a completed deployment date describe different stages.

An original acceptance exercise can use a nonproduction demonstration environment and an ordinary authorized update. Document how the package's authenticity is checked, what access the installer needs, and how an interrupted installation is handled under the manufacturer's instructions. Measure coordination time as well as installation time. A brief update may still require a long approval queue or a vendor visit.

The test should produce an evidence packet: starting version, authorized package reference, test configuration, observed outcome, and ending version. Failed checks should have owners and resolution dates. A screenshot of a success message is useful only if it is tied to the correct asset and release.

Avoid turning this exercise into an unsupervised security experiment on deployed equipment. Its purpose is to verify the agreed delivery and recordkeeping process in an appropriate environment, not to infer operational suitability from a generic checklist.

Purchase a lifecycle, including its ending

An instrument may remain physically functional after a software component loses support. Buyers therefore need dates and responsibilities that extend beyond installation. FDA recommends communicating cybersecurity support and end-of-life information, including handling risk when support ends. FDA final guidance, section VI.A

An original contract-review checklist is:

1. Identify the delivered release and obtain its corresponding component inventory.
2. Name the advisory recipient, local asset owner, and vendor escalation route.
3. Describe routine and urgent remediation communication, without inventing a universal patch deadline.
4. Agree how updates are evaluated, authorized, installed, and recorded.
5. Specify what support information changes when an embedded component reaches its support limit.
6. Set a review milestone for device support, replacement planning, and decommissioning records.

A calendar reminder needs an owner authorized to act. Otherwise the purchasing document can acknowledge an expiry date while leaving everyone surprised when it arrives.

Evaluate evidence rather than a security label

For the fictional instruments, a sensible procurement decision records unresolved questions separately from completed evidence. An available SBOM, a successful demonstration update, and an accessible vendor contact each establish something specific. None establishes the absence of future vulnerabilities.

Use explicit states such as requested, received, checked, and unresolved. If an important item remains unresolved, document the decision maker, the reason for proceeding or deferring, and the date for reassessment. This creates an accountable handoff that can survive staff changes and future software releases.

The central engineering question is whether a new piece of information can be traced to the installed equipment and an authorized response. That traceability is what makes cybersecurity procurement evidence useful throughout the device's working life.

Sources and version notes

• FDA guidance landing page: current final guidance, February 2026.
• FDA final guidance PDF: issued February 3, 2026; sections V.A.4, VI, and VII; supersedes June 27, 2025.
• FDA cybersecurity FAQ: statutory scope and submission timing. Some linked titles retain earlier wording; use the dated final PDF for the guidance version.
• FDA cybersecurity overview: manufacturer and health care organization responsibilities. Its historical guidance listing still names June 2025; that listing does not override the February 2026 supersession statement.