The FDA's 2023 cybersecurity guidance was a turning point for medical device manufacturers. For the first time, the agency stated unambiguously that submissions for cyber devices would be expected to include software bills of materials, vulnerability management plans, and evidence of supply chain controls. The 2025 update to that guidance tightened expectations further, and the agency has now refused to accept submissions that lack adequate cybersecurity documentation. By 2026, supply chain cybersecurity is not an optional adjacent topic. It is a gating factor for clearance.
This article describes what FDA actually expects in 2026, what evidence to deliver at premarket, and how to build a lifecycle program that maintains compliance without consuming the entire post-market quality engineering budget.
What FDA actually expects
FDA's expectations live in three documents. The premarket cybersecurity guidance, the postmarket cybersecurity guidance, and the supply chain provisions of the 524B language added by the Consolidated Appropriations Act. Together they establish the framework that reviewers use when evaluating a submission.
At premarket, the manufacturer must provide a software bill of materials covering all software components in the device. The SBOM has to include direct dependencies, transitive dependencies, the source of each component, the version, and any known vulnerabilities at the time of submission. The format must be machine-readable, which in practice means CycloneDX or SPDX. The SBOM has to be linked to the device's threat model, demonstrating that the manufacturer has analyzed the security implications of each significant component.
The submission must also include a vulnerability management plan covering how the manufacturer will identify, evaluate, and remediate vulnerabilities discovered after clearance. The plan needs to specify cadence, decision criteria, and customer communication mechanisms. It also needs to demonstrate that the manufacturer has established relationships with the open source projects and commercial vendors whose components ship in the device.
Postmarket, the manufacturer is responsible for ongoing surveillance, vulnerability triage, coordinated disclosure, and update delivery. The supply chain provisions of 524B further require that the manufacturer ensure security updates can be delivered for the supported lifetime of the device.
Building the SBOM correctly
The SBOM is the single most reviewed artifact in the cybersecurity submission. Reviewers read it carefully, cross-check it against the threat model, and use it to evaluate the depth of the manufacturer's analysis. SBOMs that are mechanically generated and dropped in without curation get flagged for additional information requests, which can delay clearance by months.
The discipline that makes SBOMs reviewable starts with curation at build time. Each entry should include not just the component name and version but the specific reason it is in the device, the alternative components considered, and the security analysis that justified the choice. Safeguard's SBOM tooling supports this metadata directly, attaching curation notes that travel with the SBOM through the lifecycle.
Transitive dependencies are where most submissions fall down. A device that pulls in a logging framework which pulls in a compression library which pulls in a vulnerable older version of zlib has to disclose the zlib dependency. The SBOM must be deep enough to show the full chain. Most build tools generate this automatically; the manufacturer's job is to verify completeness and explain anything that looks unexpected.
Vulnerability management for cleared devices
Vulnerability management for medical devices is fundamentally different from enterprise IT vulnerability management. The patching cycle is constrained by the change control process required to maintain device clearance, which means most patches require a formal evaluation before deployment. The clinical workflow constraints further limit when patches can be applied. A device used in surgical workflows cannot be patched in the middle of an operation.
The implication is that the prioritization decisions matter even more than they do in enterprise environments. A small number of critical patches will get pushed quickly. The rest will be batched into scheduled maintenance windows and grouped with other changes. Safeguard's exploitability triage produces the prioritization signal that lets the manufacturer make these decisions defensibly.
The plan needs to articulate the prioritization criteria explicitly. Reviewers will check that the criteria are reasonable, that they account for clinical context, and that they are applied consistently. A plan that lists CVSS thresholds without considering exploitability and clinical impact will receive review questions.
Coordinated disclosure and customer communication
The customer communication side of the program is often underbuilt. When a vulnerability is discovered in a device, the manufacturer has to decide whether to notify customers, when to notify them, what to say, and what compensating controls to recommend. The decision matrix needs to account for the criticality of the device, the severity of the vulnerability, the availability of a fix, and the realistic timeline for fix deployment.
FDA expects manufacturers to have established relationships with the security research community, accept and respond to vulnerability reports through a documented channel, and coordinate disclosure timelines that balance public safety against patch readiness. The infrastructure for this is straightforward to set up; the cultural shift inside the manufacturer is the harder part.
Lifecycle evidence
Beyond the initial submission, the manufacturer must maintain evidence that the program is functioning. Quarterly SBOM updates, vulnerability tracking logs, patch deployment records, and customer communication archives are all expected to be available on request. Safeguard maintains this evidence automatically as a side effect of running the program, eliminating the post-hoc evidence-collection scramble that traditional approaches require.
The evidence pack should be organized to support both routine FDA inquiries and ad-hoc investigations triggered by reported incidents. The packs should be retainable for the supported lifetime of the device, which for some classes can extend ten years or more.
Practical advice for 2026 submissions
If you are preparing a submission for filing in 2026, three pieces of advice produce disproportionate impact.
First, generate the SBOM early in the development cycle and treat it as a living artifact rather than a submission deliverable. The SBOM should be reviewed and curated continuously, not assembled in the weeks before filing.
Second, write the vulnerability management plan with specific cadences, criteria, and example decisions. Reviewers respond well to plans that demonstrate operational thinking and respond poorly to plans that stay at the policy level.
Third, build the coordinated-disclosure infrastructure before you need it. The first time a researcher contacts you about a vulnerability is not the time to be establishing your reporting channel.
Manufacturers that internalize the supply chain cybersecurity expectations as engineering discipline rather than regulatory burden will move through FDA review faster, ship more securely, and spend less effort on post-market firefighting. The work is real, but the payoff is durable.