Medical device vulnerability management

What the law requires after launch

For a cyber device, Section 524B of the FD&C Act sets three obligations. The manufacturer must submit a plan to monitor, identify and address postmarket vulnerabilities and exploits, including coordinated vulnerability disclosure (524B(b)(1)). It must maintain processes that give reasonable assurance the device is cybersecure, with updates on a reasonably justified regular cycle and out of cycle as soon as possible for critical vulnerabilities (524B(b)(2)). And it must provide a software bill of materials covering commercial, open-source and off-the-shelf components (524B(b)(3)).

FDA's guidance treats failure to comply with 524B(b)(2) as a prohibited act under section 301(q) of the FD&C Act (Section IV.D). The cybersecurity management plan in Section VI.B is where the commitments are written down: who is responsible, where vulnerabilities are monitored, how entries in CISA's Known Exploited Vulnerabilities catalog are handled, the patch timeline, and how customers hear about fixes.

Section V.A.6 sets the minimum metrics to track and report: the percentage of identified vulnerabilities patched, the time from identification to patch, and the time from patch availability to field implementation.

The work behind the tooling

Every release goes through the same loop. Ingest the SBOM, match its components against the National Vulnerability Database, CISA KEV and supplier advisories, decide what each match means for this device as built and configured, record the decision, fix or mitigate what matters, and report the metrics.

Deciding is the expensive step. A raw match list is long, and a score such as CVSS describes a flaw in general rather than its reach into one device. A tool earns its fee by shortening the list with evidence a reviewer will accept, and by keeping each decision attached to the release it was made for.

Four kinds of product

• SBOM and compliance platforms. Manage SBOMs per release, match vulnerabilities and keep audit trails. They suit teams that already test elsewhere and need the record kept in one place.
• Product security platforms. Add firmware and binary analysis, so the component list reflects what actually shipped.
• Managed testing and verification. Test and verify exploitability on the device itself and deliver the evidence, with people or automation doing the work for the manufacturer.
• Hospital-side IoMT tools. Built for providers: inventory, segmentation and risk across the hospital network. A device maker's postmarket obligations sit upstream, in the release and the submission, so these tools answer a different buyer's question. See the IoMT security companies.

Questions to ask a vendor

1. Which SBOM formats does it ingest, and does it track each released version separately?
2. Which sources does it match against: the National Vulnerability Database, CISA KEV, supplier advisories?
3. How does it decide exploitability for our device, and can we see the evidence behind each decision?
4. Does each decision link to the security risk assessment and the safety risk file?
5. Can it handle several fielded versions at once, each with its own risk profile?
6. Does it track level of support and end-of-support dates for each component, as the guidance asks?
7. Does it export the three FDA metrics without manual work?
8. Is there an audit trail showing who decided what, and when?
9. How does it take in coordinated vulnerability disclosure reports and feed them to engineering?
10. What does it hand us when FDA asks about a specific component?