Medical device software teams should put four items first: a current software bill of materials, a plan for finding and fixing vulnerabilities after release, design records showing security was built in, and a way to deliver updates. Regulators in the United States and Europe ask for evidence of each, so keep it in the engineering workflow, not in a binder.
A note on sources: I could not retrieve the FDA's current premarket cybersecurity guidance page on 18 October 2026, so this post names requirements at a general level. Read the current FDA guidance and the EU medical device regulation text for your device class before you plan a submission. Nothing here is legal advice.
Why is the order important?
A device submission is reviewed once, but a device stays in use for years. Teams that treat cybersecurity as a premarket document end up with an inventory that is stale by the first patch. Teams that treat it as an engineering process produce the documents as a by-product. So the priority list follows the product lifecycle.
1. Which inventory do reviewers expect?
An SBOM that lists commercial, open source and off-the-shelf software components in the device, with versions. In the United States, the law that added section 524B to the Federal Food, Drug, and Cosmetic Act requires certain "cyber devices" to include an SBOM and a plan to monitor and address vulnerabilities. Confirm the current definition of a cyber device and the exact wording with FDA materials.
Practical steps: generate the SBOM in the build, from the same lockfiles and firmware image as the release, and store it with the release record. Include the operating system, libraries, and bootloader. Keep end-of-support dates next to each component, because an unsupported component is a risk you must explain.
2. What does a vulnerability handling plan contain?
Who watches for new advisories against your components, how often, and with what sources. How you assess whether a flaw affects your device in its actual configuration. Target timelines for assessment and for delivering a fix, based on risk. A coordinated disclosure policy and a contact so researchers can reach you. Communication to customers and, where required, regulators.
A constructed example: a library in the device's networking stack gets a critical advisory. The plan lets you say, in a day, that the device uses the library, that the vulnerable function is reachable only from an interface disabled by default, and what the update path is. Without an inventory and a triage owner, that answer takes weeks.
3. How do you show security was designed in?
Keep records engineers already make: a threat model of the device and its connections, security requirements traced to tests, a list of trust boundaries, evidence of testing such as static analysis, dependency checks and penetration test reports, and review of third party components. Tie each threat to a control and each control to a test. NIST's Secure Software Development Framework offers a vocabulary for these practices that auditors recognize.
4. Can the device be updated safely?
An update mechanism with signed images, rollback protection and a safe failure mode. A plan for devices that cannot be updated remotely, such as a hospital procedure to apply patches. Documentation of what the clinical environment must do: network segmentation, account management and so on, since the device sits inside a hospital's network.
What else belongs on the list?
Quality system records connect all of this to design controls, so security changes follow the same change management as other changes. Check the current text of the quality system regulation for how those records are handled. Postmarket monitoring links back to item two.
What to do
- Generate an SBOM per release in the build and archive it with the release.
- Add end-of-support dates for each component.
- Write the vulnerability handling plan and name its owner.
- Keep a threat model that changes with the design.
- Trace each security requirement to a test.
- Design signed updates with rollback protection.
- Read the current FDA and EU texts for your device class and map your evidence to them.
Safeguard's SBOM generation, dependency scanning and reachability analysis can support items one and two. It does not certify a device or a submission.
Quick check
Is an SBOM alone enough for a submission?
No. Regulators also expect a plan to monitor and fix vulnerabilities, design evidence and update capability. The SBOM is the inventory those other items depend on.
Do open source components count?
Yes. They are software components in the device, and they usually carry most of the vulnerability exposure.
Sources
- NIST SP 800-218: Secure Software Development Framework
- CycloneDX specification overview
- NIST SP 800-161 Rev. 1
Last reviewed: 18 October 2026.
