FDA, Off-the-Shelf Software, and the EOL Component Problem

What changed, and when

Three dates matter, and they compound.

• 29 December 2022 — Section 524B was added to the Federal Food, Drug, and Cosmetic Act by the Consolidated Appropriations Act, 2023. It requires manufacturers of a “cyber device” to provide cybersecurity information in premarket submissions, including a software bill of materials covering commercial, open-source and off-the-shelf components.
• 1 October 2023 — the FDA began issuing Refuse-to-Accept decisions against submissions that do not meet it. This is the part that changed behaviour: the requirement acquired teeth on that date.
• 11 August 2023 — the FDA finalised its guidance on Off-The-Shelf Software Use in Medical Devices, superseding the September 2019 version. It sets out what documentation a submission should carry for OTS software specifically.

The SBOM has to be machine-readable and conform to a recognised format — SPDX or CycloneDX — with supplier and component names, version numbers, unique identifiers and dependency relationships.

The part that catches device manufacturers

Producing an SBOM is a solved problem. Syft, Trivy, the build-system plugins — the tooling is mature and generating a conformant document is an afternoon of work.

The difficulty arrives immediately afterwards, and it is not a documentation problem. The SBOM enumerates every component in the device, and for a device built on open source middleware that list will contain versions whose upstream projects stopped publishing fixes years ago. The FDA does not merely want to know what is in there. It wants to know how you will keep it secure across the device's supported life — and a component nobody patches has no answer to that question unless someone has been engaged to patch it.

This is the specific bind for medical devices, and it is structural rather than careless. Device lifecycles run ten to fifteen years and sometimes longer. Open source release lines are supported for three to five. The arithmetic does not work, and it was never going to: a device validated in 2019 on a runtime that reached end of life in 2024 still has a decade of field life ahead of it.

Why “we will just upgrade” is harder here than anywhere else

In most industries the answer to an EOL component is to upgrade it. In a regulated device it is a change subject to design controls.

Changing a middleware version in a device means assessing the change against your risk analysis, deciding whether it affects the device's safety or effectiveness, potentially re-validating, potentially re-submitting. Under 21 CFR 820.30 that is a documented design change with verification behind it, not a dependency bump. Teams that have been through it describe timelines in quarters, and a cost that makes the decision genuinely contested rather than obvious.

So the realistic options are narrower than they look:

• Upgrade and re-validate. Correct, expensive, slow. Appropriate when you were going to revise the device anyway and can absorb the change into planned work.
• Get the existing version patched. A security patch that preserves the API and behaviour of the validated version is a materially smaller change than a version upgrade, which is precisely why extended support exists for this market.
• Document a mitigation. Sometimes defensible — network isolation, a compensating control — but it is an argument you have to win, and it gets harder each year the component ages.
• Do nothing and hope. This is the common one, and it is the one that surfaces during a submission or an inspection rather than at a time of your choosing.

What the documentation actually has to establish

Reading the OTS guidance and 524B together, a submission needs to answer a coherent set of questions about each off-the-shelf component:

• What it is, which version, and who supplies it.
• Why it is in the device and what it does.
• What hazards it could contribute to, assessed against your risk analysis.
• How vulnerabilities in it will be identified once the device is in the field.
• How they will be remediated, and by whom, for as long as the device is supported.

That last line is where an EOL component fails. “We monitor NVD” answers identification. It does not answer remediation. If the upstream project has stopped shipping fixes for your line, the honest completion of that sentence is either “we will upgrade and re-validate”, or “we have a support agreement that covers this version”, or a mitigation argument you will need to defend.

The layer that gets missed

One thing worth checking specifically, because it is consistently absent from device SBOMs: the runtime beneath the application, not just the application.

A device using RabbitMQ for internal messaging has RabbitMQ in the SBOM. It frequently does not have the Erlang/OTP release the broker executes on, even though that is where a great deal of the relevant advisory activity is — the TLS implementation, the SSH application, the crypto libraries. We looked at this in the EOL exposure study: Erlang/OTP 24 accumulated twenty-two CVE records after its end-of-life date while RabbitMQ itself accumulated none. An SBOM that stops at the application layer will show you a clean component and miss the exposure entirely.

The same pattern applies to the JVM under a Java application, the servlet container under a web service, and the coordination layer under a cluster.

Where we fit, and where we do not

Stated plainly: we sell extended support, so we have an interest in the second option above. Weigh this accordingly.

What OSSeva does is patch the version you validated, preserving its API and behaviour, so the change stays within what a design-change assessment can reasonably absorb, and supply the remediation documentation that the “how, and by whom” question requires. That covers the middleware and data infrastructure layer and the runtimes beneath it.

What we do not do is patch the JVM, and we will say so early rather than late. If your exposure is the Java runtime itself, that is a different vendor and we will name one. We also do not write your regulatory submission — that is your regulatory team's work, and anyone telling a device manufacturer otherwise should be treated with suspicion.

Related reading

• SBOMs find your EOL components. They do not fix them.
• EOL Exposure Study 2026 — what actually gets disclosed after an end-of-life date.
• Healthcare and regulated device estates