Medical device cybersecurity in 2026: more than an SBOM

Use the February 2026 guidance

FDA issued its current final cybersecurity guidance on February 3, 2026, replacing the June 2025 version. Its title now refers to Quality Management System considerations. If your team is preparing a submission using an older checklist, verify which guidance version it references.

The guidance addresses security risk management, threat modeling, security architecture, testing and submission documentation. It recommends a secure product development framework as a way to manage cybersecurity throughout development and maintenance. The practical lesson is to include security in product design, rather than scheduling it as a final document-writing task.

Sources: FDA: Final cybersecurity guidance (February 3, 2026; PDF)

First establish whether section 524B applies

The statutory “cyber device” definition has three elements: sponsor-validated, installed or authorized software as or in the device; an ability to connect to the internet; and sponsor-validated, installed or authorized technological characteristics that could be vulnerable to cybersecurity threats. Do not assume that every medical device automatically meets this definition.

FDA’s FAQ explains that sponsors making relevant premarket submissions for cyber devices must provide information demonstrating the cybersecurity requirements in section 524B(b). This includes applicable 510(k), De Novo and PMA submissions, among other pathways. Scope and submission history matter; confirm them for your product.

Sources: FDA: Cybersecurity in Medical Devices FAQs and section 524B scope

An SBOM needs to support real decisions

For cyber devices, section 524B requires a software bill of materials covering commercial, open-source and off-the-shelf components. The 2026 guidance also recommends machine-readable SBOM documentation and information about component support and end-of-support dates.

An inventory is useful when the team can act on it. Our recommendation is to link each released device version to its component inventory and identify who evaluates newly disclosed vulnerabilities. Ask a concrete question during a release review: if a dependency has a critical issue tomorrow, can we identify the affected product versions and the person responsible for responding?

Sources: FDA: Final cybersecurity guidance (February 3, 2026; PDF); FDA: Cybersecurity in Medical Devices FAQs and section 524B scope

Build the response process while building the device

A founder should be able to explain how a security report reaches the team, how the team assesses patient and operational impact, and how a fix reaches users. A penetration test can reveal weaknesses, but a test report alone does not provide ownership, a release process or a maintenance budget.

Our suggested planning exercise is to rehearse one scenario: a supplier stops supporting a component used in the shipped device. Identify the affected versions, assess the implications, decide on a response, validate any change and plan the communication. Record gaps in responsibilities and tooling before an actual incident forces the same decisions.

This is an operational exercise, not evidence that the product is FDA compliant. The security evidence and documentation must fit the actual device, its risks, the applicable law and the submission pathway.

A practical starting checklist

Use this list to assign work across engineering, quality and regulatory staff. It is deliberately a starting point rather than a complete submission checklist.

• Document connectivity, system boundaries, important assets and foreseeable threats.
• Maintain a version-specific component inventory and track supplier support.
• Assign responsibility for vulnerability intake, assessment and follow-up.
• Plan how security changes will be tested, released and communicated.
• Budget for monitoring and maintenance after launch, not only the initial submission.
• Review the current FDA guidance and confirm the product-specific evidence with qualified specialists.