FDA cybersecurity deficiency letter: SBOM missing support status

Does it seem like it's "always something?"

So, you've put together your medical device's software bill of materials (SBOM). You were careful, even meticulous. You took your time to make sure every component was listed and the versions were documented. Your team was happy and confident the inventory was complete.

Then out of nowhere, pow, FDA comes back with a question you weren't expecting: Are these software components still supported, and when does that support end?

Sure, it's disturbing. An FDA cybersecurity deficiency letter identifies gaps or concerns in the cybersecurity information submitted for a medical device. In this case, the issue is missing SBOM support status information, which helps establish whether software components are still maintained and whether security updates remain available.

Why is SBOM support information so important? In the eyes of FDA, it helps establish whether software components are still maintained and whether security updates remain available.

It's an easy detail to overlook. After all, isn't an SBOM supposed to be an inventory of software components?

Yes, but here's the problem: FDA expects more than a list of names and version numbers. That's because FDA reviewers also need information that helps them understand how manufacturers will manage software-related cybersecurity risks throughout the device's lifecycle.

But you don't need to lose sleep over it all. Missing info is fixable.

In this article you will take a look at why FDA flags incomplete SBOM support information, how to correct the problem, and what documentation manufacturers should provide in their response.

What does an FDA SBOM deficiency look like?

Imagine submitting a software bill of materials (SBOM) that lists every software component in your medical device. You've included the names, versions, and suppliers. Everything seems accounted for.

But FDA reviewers notice something missing. They can't tell which components are still supported, which are no longer maintained, or when that support is expected to end.

That's enough to raise questions about how the manufacturer plans to manage software-related cybersecurity risks over the device's lifecycle.

And here's an important distinction. Missing support information doesn't necessarily mean the software is unsafe or vulnerable. It means FDA doesn't have enough information to evaluate how the manufacturer is addressing its software maintenance responsibilities.

Common wording patterns in an SBOM deficiency request

An FDA deficiency request might read something like this:

The submitted software bill of materials does not adequately identify the support status or end-of-support dates for the listed software components. Please provide this information or explain how the support lifecycle of these components is documented and managed.

This is an illustrative example, not language from an actual FDA deficiency letter.

In plain English, FDA wants to know whether the manufacturer understands the support lifecycle of the software included in its device.

If a component is no longer maintained, what does that mean for future security updates? If support is scheduled to end soon, how will the manufacturer address that change?

These are questions manufacturers should be prepared to answer, preferably before FDA has to ask.

Why SBOM support status matters for medical devices

Software doesn't stop working just because its developer stops supporting it. A medical device might continue operating perfectly well for years after one of its software components reaches the end of support.

But there's a catch. What happens when someone discovers a security vulnerability in that component?

If the supplier no longer provides patches or updates, the manufacturer may have fewer options for fixing the problem. That's why support information is an important part of managing medical device cybersecurity throughout the product's lifecycle.

Supported software isn't the same as secure software

Just because a software component is still supported doesn't mean it's free of vulnerabilities.

Even actively maintained software can contain security flaws. The difference is that supported components generally have an established process for receiving patches, updates, or other maintenance when problems are discovered.

Unsupported software presents a different challenge. Manufacturers may need to develop their own fixes, replace the component, or introduce additional security controls to manage the risk.

Neither situation automatically tells you whether a device is secure. That's something manufacturers must evaluate based on the component, its function, and the potential consequences of a cybersecurity incident.

What happens when software reaches its end-of-support date?

An SBOM end of support date helps manufacturers identify when a software supplier plans to stop maintaining a particular component or version.

Consider a medical device that relies on a third-party communications library. The library works as intended, but its developer announces that security updates will end next year.

That doesn't mean the manufacturer must immediately replace it. However, the team needs to understand the potential risks and decide how to manage them.

Options might include upgrading the component, finding a supported alternative, or implementing additional safeguards.

The important thing is having a documented plan before the lack of supplier support becomes a cybersecurity problem.

Why manufacturers leave support information out of an SBOM

Most manufacturers don't intentionally leave support information out of their SBOM. More often, the problem comes down to how the inventory was created, who maintains it, and whether anyone checked that it contained everything FDA expects.

Here are four common reasons support information goes missing.

The SBOM only lists components and versions

Automated SBOM tools can do a good job identifying software components, their versions, and dependencies. But they don't always capture whether those components are still supported or when that support will end.

The result? A detailed software inventory that still lacks important lifecycle information.

Manufacturers may need to supplement automated SBOM data with supplier documentation or their own support-status records.

Support information isn't available from the supplier

Not every software supplier publishes a clear maintenance schedule.

This is especially common with open-source software, where projects may rely on volunteer contributors rather than formal support agreements.

When an end-of-support date isn't available, manufacturers shouldn't guess or leave the issue unexplained. Instead, document what information was available, how it was verified, and how the component's cybersecurity risks will be managed.

The SBOM hasn't been updated

Software changes throughout development. A library gets upgraded, a dependency is replaced, or a new component is added to support a feature.

Unfortunately, the SBOM doesn't always keep pace.

That can leave manufacturers submitting outdated support information or missing newly introduced components altogether.

Regular reviews help ensure the SBOM reflects the software actually included in the device.

Nobody owns the support-status review

Sometimes the problem isn't technical. It's organizational.

Engineering maintains the software inventory. Cybersecurity evaluates vulnerabilities. Regulatory affairs prepare the submission.

But who's responsible for checking support dates?

If nobody has that assignment, important information can fall through the cracks.

Assigning clear responsibility for verifying and updating support information helps prevent these gaps from becoming FDA submission deficiencies.

What FDA SBOM requirements expect

Understanding FDA SBOM requirements for medical devices starts with knowing what's inside their software and how manufacturers plan to manage cybersecurity risks as that software ages.

Under Section 524B of the Federal Food, Drug, and Cosmetic Act, manufacturers of devices that meet the definition of a cyber device must submit a software bill of materials covering commercial, open-source, and off-the-shelf software components.

But that's only part of the picture. The FDA premarket cybersecurity guidance provides additional recommendations about the information manufacturers should include to support cybersecurity risk management.

An SBOM needs more than component names

An inventory of software names and version numbers is a starting point. FDA also recommends documenting the support level and end-of-support date for each component.

That information may appear directly in the SBOM or in a separate addendum.

Why does this matter? Because knowing which software components are approaching the end of support helps manufacturers anticipate maintenance challenges before they become security problems.

FDA expects manufacturers to address unsupported components

An unsupported component isn't automatically unsafe. But manufacturers need to understand what happens when security patches and maintenance updates are no longer available.

That means evaluating potential vulnerabilities, documenting associated cybersecurity risks, and determining whether additional controls or other actions are necessary.

If a supplier doesn't publish an end-of-support date, manufacturers should explain that limitation and document how they plan to monitor the component.

The goal isn't simply to satisfy an FDA documentation request. It's to show that the manufacturer has a workable process for managing software-related cybersecurity risks throughout the device's lifecycle.

How to fix missing SBOM support status information

Finding out that FDA has questions about your SBOM can be frustrating, especially when you've already spent considerable time putting it together.

But here's the good news. Missing support information doesn't necessarily mean you need to rebuild the entire inventory. The better approach is to identify the gaps, verify the missing details, and document how you've addressed them.

Step 1: Review FDA's request

Start by reading the deficiency request carefully. Is FDA asking for missing support dates, clarification about unsupported components, or an explanation of how you manage software maintenance?

Don't assume every SBOM entry needs to be revised.

Identify the specific concerns and determine which components or documents are affected. This gives your team a clear starting point and helps avoid unnecessary work.

Step 2: Verify the software inventory

Before adding support information, make sure your SBOM accurately reflects the software in your device.

Check component names, versions, suppliers, and dependencies against the actual software configuration.

Pay particular attention to third-party libraries and components that may have changed during development.

There's little value in adding support dates to an inventory that no longer matches the device you're submitting.

Step 3: Determine each component's support status

Now comes the research.

Check supplier websites, maintenance policies, release notes, and other reliable sources to determine whether each component is actively supported.

For open-source software, review the project's official documentation and maintenance information.

Record what you find and where the information came from. If support status can't be confirmed, document that uncertainty rather than assuming the component is unsupported.

Step 4: Document support and end-of-support dates

Once you've verified the support status, record the available lifecycle information.

Include published end-of-support dates where available, along with the source and date of verification.

Some suppliers don't publish formal support schedules. In those cases, explain what's known, what remains uncertain, and how your team plans to monitor future changes.

The important thing is accuracy. Don't invent dates just to fill an empty field.

Step 5: Evaluate unsupported components

If you discover unsupported software, determine what that means for your device's cybersecurity.

Could an unpatched vulnerability affect device performance or patient safety? Are alternative components available? Can additional security controls reduce the risk?

Document the assessment and any actions your team decides to take.

Unsupported software doesn't automatically require replacement, but it does deserve a closer look.

Step 6: Prepare the updated SBOM and response

Finally, put everything together.

Update the SBOM or supporting addendum with the verified support information. Include any revised risk assessments, mitigation plans, or other evidence needed to address FDA's concerns.

Your written response should explain what changed and point reviewers to the relevant documents.

If your team needs help organizing these materials, CyberMed's FDA cybersecurity documentation services can support the process.

The goal is to give FDA a clear, complete answer without making reviewers search through unrelated paperwork.

Show FDA exactly what you corrected

After you have identified the missing support information and updated your SBOM, the response has to make the correction easy for FDA to follow.

The goal isn't to bury reviewers in paperwork. It's to provide clear documentation that addresses the deficiency and explains how your team manages software support throughout the device's lifecycle.

Depending on FDA's request, the response may include the following materials.

The corrected SBOM

Start with an updated SBOM that identifies the affected software components, their versions, suppliers, support status, and available end-of-support dates.

Make sure the information matches the software configuration in your submission.

If you maintain support information in a separate addendum, clearly reference it so reviewers can find the relevant details without searching through multiple documents.

Evidence supporting the status information

FDA reviewers need to understand where your support information came from.

Include relevant supplier maintenance policies, official release documentation, or other reliable evidence supporting the status and dates you've reported.

For components without published support schedules, explain how you attempted to verify the information and what remains unknown.

You don't necessarily need to attach every supplier document. The important thing is providing enough evidence to support your conclusions and address FDA's specific questions.

A plan for unsupported components

If your SBOM includes unsupported software, explain how your team plans to manage the associated cybersecurity risks.

That might involve additional security controls, vulnerability monitoring, medical device penetration testing, software replacement, or a documented maintenance strategy.

Make sure the plan reflects the component's role in the device and the potential consequences of a cybersecurity incident. Techniques such as STRIDE threat modeling for medical devices can help manufacturers identify potential threats involving unsupported software and evaluate how those threats might affect the device.

A component that's no longer supported doesn't automatically make a device unsafe. What matters is whether the manufacturer has adequately evaluated and addressed the risks.

A clear response to FDA

Finally, prepare a written response that connects each deficiency to the information you've provided.

Explain what was missing, what changed, and where reviewers can find the corrected documentation.

Reference specific SBOM entries, supporting tables, or risk assessment sections whenever possible.

The easier you make it for FDA to follow your response, the less room there is for confusion or additional questions.

How to avoid another FDA cybersecurity deficiency letter

The best way to avoid another FDA cybersecurity deficiency letter is to stop treating your SBOM as a document you create once and file away.

Software changes. Suppliers discontinue products. Support agreements expire. And a component that's fully supported today might reach the end of its maintenance lifecycle while your medical device is still in use.

That's why manufacturers should make SBOM maintenance part of their regular cybersecurity activities.

Assign someone responsibility for monitoring supplier support announcements and tracking upcoming end-of-support dates. Update the SBOM whenever software components change, and periodically verify that the support information remains accurate.

It's also worth checking the entire SBOM package and related FDA cybersecurity documentation before submitting it to FDA. Are support dates documented? Have unsupported components been evaluated? Does the inventory match the device's current software configuration?

These checks won't guarantee a deficiency-free review. But they can help catch missing information before it becomes another regulatory headache.

How CyberMed Helps Manufacturers Resolve SBOM Deficiencies

When FDA identifies missing SBOM support information, figuring out what needs to change isn't always straightforward.

CyberMed helps medical device manufacturers review their cybersecurity documentation, identify missing information, and prepare responses that address FDA's specific concerns.

That may involve verifying software support status, reviewing unsupported components, updating cybersecurity risk assessments, or organizing the evidence reviewers need to evaluate the submission.

CyberMed's cybersecurity documentation support services can also help manufacturers connect their SBOM information with broader cybersecurity risk management activities.

The objective isn't simply to correct a spreadsheet or fill in missing dates. It's to give FDA a clearer picture of how the manufacturer understands and manages software-related cybersecurity risks throughout the device's lifecycle.

Sources

1. U.S. Food and Drug Administration. Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions. February 2026. https://www.fda.gov/media/119933/download
2. U.S. Food and Drug Administration. Developing and Responding to Deficiencies in Accordance with the Least Burdensome Provisions. https://www.fda.gov/regulatory-information/search-fda-guidance-documents/developing-and-responding-deficiencies-accordance-least-burdensome-provisions
3. U.S. Food and Drug Administration. Types of Communication During the Review of Medical Device Submissions. April 2014. https://www.fda.gov/regulatory-information/search-fda-guidance-documents/types-communication-during-review-medical-device-submissions
4. U.S. Congress. 21 U.S.C. § 360n-2: Ensuring Cybersecurity of Devices (Section 524B of the Federal Food, Drug, and Cosmetic Act). https://uscode.house.gov/view.xhtml?req=granuleid:USC-prelim-title21-section360n-2&num=0&edition=prelim
5. U.S. Food and Drug Administration. Cybersecurity. https://www.fda.gov/medical-devices/digital-health-center-excellence/cybersecurity