A CVE match is a lead - not proof that your medical device is affected. I start with 3 checks: Is the affected version present? Can the vulnerable code run or be reached? Could exploitation lead to medical device security risks that harm the device or a patient?
For covered cyber devices, Section 524B requires a postmarket vulnerability plan, cybersecurity processes, updates and patches, and an SBOM. FDA guidance helps explain implementation; it is not the same as the law.
Here’s the approach I use to connect those duties to daily work:
- Check the data: Match component versions and device builds against supplier notices, vulnerability databases, and exploitation reports.
- Set review rules: Assign monitoring schedules and reassess when threats, configurations, or supplier support change. FDA does not set one universal review interval.
- Name owners: Assign validation, patient-risk review, supplier follow-up, response, and approval.
- Keep linked records: Document each finding’s evidence, decision, testing, and closure - including why a flaw does not apply or why a patch is deferred.
My bottom line: <u>the manufacturer remains responsible for device-level validation</u>. Suppliers and tracking tools can support that work, but they cannot replace it.
Medical Device Cybersecurity: From CVE Alert to Closure
Case Study: Why FDA Cybersecurity Expectations Are Really QMS Expectations
sbb-itb-535baee
Data Needed to Identify Software Flaws
Start with the device inventory, then map external vulnerability sources to each component.
SBOM Fields and Device Details
Use a machine-readable SBOM that includes component names, exact versions, suppliers, component types, direct and transitive dependencies, and vulnerability identifiers. Link each component to its asset location, device model, software or firmware release, build number, and relevant configuration. Keep support status and end-of-support dates in linked lifecycle records.[1][6][10]
Before matching vulnerabilities, check for missing, placeholder, or blank versions; duplicate entries; inconsistent supplier names; invalid package identifiers; unresolved dependencies; unsupported components; and missing device links. Reconcile the inventory against the approved build, and give each unresolved data error an owner. These are implementation checks, not separate FDA requirements.[1][6]
Vulnerability Sources to Monitor
Monitor supplier advisories, patch notices, NVD, CISA’s KEV Catalog, researcher reports, and coordinated vulnerability disclosure channels. Each source serves a different purpose: NVD provides vulnerability metadata, KEV identifies known exploitation, and suppliers provide affected-version and fix details. No single source establishes that software is vulnerability-free.[4][5][8][9]
Keep the source name, advisory or CVE identifier, publication and detection dates, affected-version statements, and updates. Every source alert still needs device-level validation.[4][5][8][9]
Validating Findings for a Device
An automated match is only a lead. Check exact affected versions, backported fixes, build options, enabled features, reachable code, network exposure, and exploit prerequisites. Then assess existing controls, affected device functions, connected systems, and potential patient harm. Use CVSS scores to help prioritize findings - not to replace this analysis. A control may reduce risk without making the vulnerability inapplicable.[1][3]
Record each finding as applies, does not apply, or needs further investigation. Include the reviewer, decision date, rationale, and supporting build, configuration, supplier, or test evidence. For unresolved findings, document the unanswered question, owner, due date, and interim control.[1][3][6][7]
Set reassessment triggers for revised advisories, new exploitation or KEV listings, configuration changes, newly reachable code, expired controls, or loss of supplier support.[1][3][6][7]
Review Timing and Task Ownership
Once a finding is validated, review schedules and clear ownership determine whether it leads to monitoring, remediation, or risk acceptance.
Monitoring Frequency and Reassessment Triggers
New flaws and changes in support status can affect devices after clearance or approval. Use annual reviews for governance and inventory reconciliation, but keep continuous monitoring and event-driven reassessment separate. FDA’s framework is risk-based; it does not set a universal review interval.[7][11]
Set separate schedules for monitoring, reassessment, and response. Automate threat intelligence checks continuously or daily, conduct formal triage at least weekly, and reconcile inventories monthly or quarterly based on device risk and the volume of changes. These are suggested schedules, not FDA deadlines. Event-driven reassessment should override the normal schedule.[7][11]
Document each monitoring source, review frequency, responsible owner, escalation deadline, and response criteria. Set shorter response windows for known exploitation, exposed functions, or potential patient harm. Specify when containment, customer communication, regulatory assessment, or remediation is needed. Not every flaw calls for the same action - or a patch.[7][11]
Roles for Identification, Assessment, and Response
Use this responsibility matrix as a template, then name owners and backups in the operating procedure. Set explicit deadlines and escalation paths so work belongs to a person, not just a department.[7][11]
| Task | Primary owner | Approval or handoff |
|---|---|---|
| Maintain and reconcile the SBOM | Engineering or configuration management | Quality approves the inventory |
| Monitor threat intelligence and validate findings | Product cybersecurity, supported by engineering | Cybersecurity manager owns triage completion |
| Assess patient and clinical consequences | Safety and risk management | Designated safety authority reviews patient-risk decisions |
| Obtain supplier analysis and fixes | Supplier owner | Engineering receives patch details and support commitments |
| Implement remediation | Engineering or product owner | Named remediation owner controls the schedule |
| Verify the fix or mitigation | Independent validation, quality, or cybersecurity personnel | Verification owner confirms effectiveness and residual risk |
| Accept risk, approve action, and close findings | Designated risk owner and approval authority | Named closure owner confirms required work is complete |
| Coordinate incident response and risk management | Manufacturer and health care delivery organization (HDO) incident-response leads | Manufacturer directs product actions; HDO directs local containment |
| Assess reporting and control changes | Quality and regulatory affairs | Determine applicable notifications and approve controlled changes |
Suppliers provide component analysis, fixes, and support details. Health care delivery organizations (HDOs) provide deployment context, local logs, network controls, and implementation support. The manufacturer remains responsible for device-level assessment, validating design changes, and documenting response decisions.[11][12]
Record the owner, deadline, and approval authority with each finding.
Records That Support Compliance
After assigning owners, link each component to its SBOM version, device release, finding, assessment, response, testing, approval, and closure. The record trail should let reviewers follow the case from start to finish.[1][3][11]
Records, Owners, and Review Triggers
Use this matrix as a starting point, then tailor it to the device, requirements, and quality procedures. Give each record a revision history and links to supporting evidence. Use the same case identifier across all records to keep that evidence connected.
| Record | Evidence to preserve | Accountable owner | Trigger | System of record |
|---|---|---|---|---|
| SBOM history and support status | Current and superseded SBOMs linked to build and support status | Configuration management | Release, component change, support notice | Controlled configuration repository |
| Monitoring and discovery | Source, search date, tool or analyst, match logic, advisory ID, discovery timestamp | Product security | New alert, changed source, missed review | Quality system and linked vulnerability case |
| Device-specific assessment | Affected configurations, exploit conditions, safety/security impact, safeguards, assumptions, residual risk | Engineering with safety/risk-management support | Confirmed flaw, new exposure, changed impact | Controlled risk-management file |
| Supplier communications | Notices, affected-version statements, patch commitments, unanswered requests, escalations | Supplier management | Advisory, overdue response, support change | Supplier record linked to finding |
| Response decision | Selected control, rationale, affected versions, implementation evidence, planned and actual dates | Remediation owner | Assessment completed, risk changed | Controlled change record |
| Update testing | Approved plan, tested builds, safety, security, and regression results, failures, retests, acceptance criteria | Validation engineering | Patch, configuration change, failed test | Controlled test repository |
| Reporting assessment | Triggering facts, reporting path, reporting or nonreporting rationale, approver, submissions | Regulatory affairs and quality | Incident, correction, new impact information | Regulatory record |
| Approvals and exceptions | Exception scope, alternatives, compensating controls, residual risk, review or expiration date, authorization | Designated risk owner | Exception deadline, control failure, changed risk | Controlled approval/exception register |
| Closure | Implemented control, verification results, required communications, remaining actions, final approval | Case owner with quality approval | Verification complete, risk decision approved | Controlled case record |
Keep failed tests and unresolved supplier questions in the record. A “not affected” conclusion needs evidence that connects the reported flaw to the device’s actual configuration. If patching is deferred, document the interim control, the residual-risk rationale, and the trigger for reassessment.[1][11]
Follow the retention, access, and preservation rules in applicable FDA, quality, contractual, and legal requirements. Do not assume one universal retention period. Use least-privilege access, controlled revisions, timestamps, audit trails, backups, and retrieval checks. Keep original evidence and superseded records instead of overwriting them.[1][11]
Coordinating Evidence and Approvals
Route evidence, approvals, and remediation through one controlled case file using these records.
Censinet RiskOps™ can help coordinate third-party risk, evidence requests, and approval tracking across vendors, clinical applications, medical devices, and supply chains. It does not replace manufacturer validation, quality records, or regulatory judgment. Any platform used should preserve role-based access, version control, audit trails, and traceability to the evidence reviewed.
Conclusion: Check Data, Owners, and Records
The review cycle is complete only when data, validation, ownership, and records stay linked. Keep monitoring active, and reassess after new exploits, software changes, supplier advisories, or end-of-support notices.
Check one medical device’s SBOM against its deployed build. Confirm component versions, suppliers, support status, and end-of-support dates. Review supplier advisories, the NIST National Vulnerability Database, and CISA’s Known Exploited Vulnerabilities Catalog.
Apply the same approach to every finding. Centralizing these workflows within Censinet RiskOps™ ensures consistency across the enterprise. Trace one finding from discovery through validation to its documented disposition.
Readiness means information, ownership, escalation, and evidence work together from start to finish.
FAQs
What if my supplier provides an incomplete SBOM?
Document SBOM gaps and explain your exposure assessment in FDA cybersecurity risk records. Use supplemental binary static analysis to help identify components - not to prove the SBOM is complete. Assess whether vulnerable code could be present and reachable in your device’s configuration.
If you can’t patch, document the technical justification and put compensating controls in place, such as network segmentation and monitoring, to protect patient safety. Retain configuration snapshots, test results, and supplier correspondence. [1][2]
Who reassesses vulnerabilities when supplier support ends?
Under the FDA’s Total Product Lifecycle framework, the manufacturer remains responsible for inherited risks even after supplier support ends. Once patches stop, the manufacturer must put compensating controls in place, plan a move to a different component, or document a technical justification for the remaining risk.
Any change to - or removal of - compensating controls must trigger a reassessment. The manufacturer must also continuously monitor and address vulnerabilities throughout the device’s commercial life.
What evidence justifies deferring a device security patch?
To maintain compliance, document the technical justification for the residual risk. Identify the specific vulnerability, explain why patching isn’t currently feasible, and record the approved compensating controls in place to protect patient safety, such as network segmentation or added monitoring.
Assign an accountable owner, set a review date, and define clear triggers for reassessment. Store these records in your quality management system to show that the risk remains controlled without a patch.
