FDA Premarket Cybersecurity and SBOM: An Evidence Workflow for Medical Device Teams

A medical device software bill of materials, or SBOM, is an inventory of software components and their relationships. For a cyber device covered by section 524B of the Federal Food, Drug, and Cosmetic Act, the submission must include an SBOM covering commercial, open-source and off-the-shelf software components. An inventory alone does not demonstrate that the device is secure.

The Cahir MedTech FDA Premarket Cybersecurity & SBOM Inventory Matrix connects device applicability, documentation ownership, component identity and known-vulnerability decisions. This guide shows how to use it without confusing a spreadsheet with a complete cybersecurity submission.

Start with the current guidance, not an old checklist

FDA's February 2026 final guidance is titled Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions. It supersedes the June 27, 2025 final guidance. Its recommendations cover cybersecurity design, labeling and premarket documentation, including recommendations relating to section 524B. 1

The statute creates binding obligations for covered cyber-device submissions; guidance describes FDA's recommendations and generally does not itself create legally enforceable responsibilities. Do not describe every recommended document as an identical statutory requirement for every device. Check the current guidance, device-specific expectations and the actual submission pathway.

The companion workbook contains some legacy June 2025 guidance labels. Use the February 2026 guidance as the source for current review and record the current reference in your working notes; do not treat legacy section labels as confirmation that the older guidance still controls.

Determine whether section 524B applies

A cyber device must meet all three elements in the statutory definition: sponsor-validated, installed or authorized software; the ability to connect to the internet; and sponsor-validated, installed or authorized technological characteristics that could be vulnerable to cybersecurity threats. The statute applies to covered premarket submissions for qualifying devices, not simply to every product with a processor. Section 524B, 21 U.S.C. 360n-2

Document actual connectivity, including relevant indirect connection paths. A device that communicates through a host computer, gateway or hospital network needs a reasoned assessment; “no built-in Wi-Fi” is not enough to dismiss internet connectivity. The statutory scope includes specified pathways beyond 510(k), including PMA, De Novo and HDE submissions. FDA's broader cybersecurity recommendations may also be relevant to devices with cybersecurity risk outside the statutory cyber-device category.

Turn the statutory obligations into evidence workstreams

Section 524B requires a plan to monitor, identify and address postmarket cybersecurity vulnerabilities and exploits, including coordinated vulnerability disclosure; processes and procedures to provide reasonable assurance of cybersecurity and make appropriate updates and patches available; and an SBOM. Routine updates address known unacceptable vulnerabilities on a reasonably justified regular cycle, while critical vulnerabilities that could cause uncontrolled risks call for updates as soon as possible outside that cycle. Do not replace these distinctions with a universal patch deadline.

This is an evidence-organization workflow, not a mandated FDA table format. Connect security work to your quality management system and safety risk management without assuming that a safety-only analysis captures adversarial cybersecurity risks. Our QMSR implementation guide provides the broader quality-system context.

Work through the matrix in a controlled sequence

The workbook includes Cyber Device Check, Premarket Documentation, SBOM Inventory, Vulnerability Register and Sources and Applicability. Its 13 documentation prompts help assign work; they are not a declaration that every submission needs exactly 13 documents.

First, record Yes, No or Unknown for each applicability criterion and explain the rationale. Unknown is an open question requiring review, not an exemption. Next, use Premarket Documentation to assign an owner, status and controlled evidence ID for the threat model, architecture, security controls, testing, labeling and lifecycle plans.

Then populate SBOM Inventory from the actual released configuration. Use Vulnerability Register for the component-level findings that require assessment and follow-through. Verify your source basis against the current guidance before final submission review.

Build an SBOM that can be reconciled to the device

NTIA's 2021 minimum-element framework identifies supplier name, component name, version, other unique identifiers, dependency relationship, SBOM author and timestamp. It also discusses automation support and practices/processes. This is a baseline framework, not a substitute for the section 524B obligation or FDA's current recommendations. See the NTIA minimum-elements report.

The workbook adds fields for support level, end-of-support date, known vulnerabilities and assessment/mitigation. These supplementary fields are useful for lifecycle decisions; they are not all NTIA minimum data elements. Where the workbook combines author and timestamp in one column, record both distinctly in the cell or link to the controlled SBOM record.

Include relevant dependencies rather than just the names of top-level applications. Reconcile component versions with the build, supplier information and deployed configuration. Where your process uses SPDX or CycloneDX, retain the machine-readable SBOM and its generation/reconciliation records. A manually edited spreadsheet should not silently replace the source inventory or imply that either format is universally mandated by statute.

Assess vulnerabilities in the device context

A CVE match is the start of an assessment, not its conclusion. Record the affected component and version, exposure, relevant attack path, exploitability, clinical consequences, compensating controls and planned action. A CVSS score supports prioritization but is not a patient-safety decision by itself.

Check resources such as the CISA Known Exploited Vulnerabilities catalog, but do not conclude that a component is safe because it is absent from that catalog. Preserve the assessment date and the evidence behind any not-affected determination. Revisit decisions when the device, threat information or operating environment changes.

For an illustrative connected diagnostic device, a vulnerable library may not be reachable in the deployed configuration, or it may support an exposed service. The team needs evidence for that distinction. Assign a technical reviewer and an accountable decision owner rather than closing the finding based only on a scanner's summary. Read our digital pathology release-readiness guide for related software release controls.

Review before calling the package ready

• Device applicability and system boundaries have qualified review.
• The threat model covers interfaces, users and update paths.
• Threats trace to controls and verification evidence.
• SBOM components and versions match the submission build.
• Known vulnerabilities have device-context assessments and accountable actions.
• Monitoring, coordinated disclosure, patching and communication plans are documented.
• Support information and labeling align with the manufacturer's actual capabilities.
• Current FDA references replace assumptions copied from older submissions.

Download the matrix and connect it to submission planning

Visit the cybersecurity and SBOM template card and sign in with your work email to download the free branded Excel workbook. Pair it with our eSTAR 510(k) readiness checklist guide when preparing a 510(k).

Use the company workspace to coordinate the toolkit work available to your team while retaining technical assessments and approvals in controlled records. Downloading this free template does not automatically synchronize its rows or spreadsheet edits with dashboard checklists. For drafting support, explore Cahir MedTech Copilot; qualified engineering, cybersecurity and regulatory review remains necessary.

FDA cybersecurity and SBOM: quick answers

What is an SBOM for a medical device?

An SBOM is an inventory of software components and their relationships. It enables identification of component versions and supports vulnerability review. For covered cyber-device submissions, section 524B requires an SBOM that includes commercial, open-source and off-the-shelf software components.

Which devices are cyber devices under section 524B?

The statutory definition combines sponsor-validated, installed or authorized software, the ability to connect to the internet, and sponsor-validated, installed or authorized technological characteristics that could be vulnerable to cybersecurity threats. All three elements matter; not every software-containing device automatically qualifies.

Is an SBOM enough for an FDA cybersecurity submission?

No. Section 524B also addresses vulnerability monitoring and disclosure plans, cybersecurity processes and appropriate updates and patches. FDA's guidance recommends additional design, testing, labeling and supporting documentation according to the device's cybersecurity risk.

Which FDA premarket cybersecurity guidance applies in 2026?

The February 2026 final guidance, Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions, supersedes the June 27, 2025 final guidance. Confirm that FDA has not issued a newer revision before filing.

Is the Cahir MedTech cybersecurity matrix free?

Yes. The Excel preparation template is free after work-email sign-in. It helps organize applicability, documentation, components and vulnerability decisions; it does not certify compliance or replace a controlled SBOM and supporting cybersecurity evidence.

Primary sources and applicability

• FDA February 2026 cybersecurity guidance: current design, labeling and premarket recommendations for this edition.
• FDA medical device cybersecurity FAQs: section 524B implementation and submission scope.
• 21 U.S.C. 360n-2: cyber-device definition and statutory obligations.
• NTIA SBOM minimum elements: inventory baseline, automation and process considerations.
• CISA KEV catalog: one input to ongoing vulnerability monitoring.

Published October 22, 2026. Sources checked for this edition; confirm current guidance and device-specific applicability before submission. This article and workbook are educational preparation tools, not legal advice, a security certification or FDA authorization.