I start postmarket risk management with one rule: protect patient care, not just the device. Give every medical device a named owner and a current risk record. Then check threats against its actual use before deciding whether to patch, restrict access, or remove it from service.

Here’s the approach I follow from clinical use through retirement:

  • Track devices and threats: Record versions, connections, support dates, and clinical use. Verify alerts before assigning risk.
  • Set response priorities: Weigh attack exposure against possible harm to patients - not just a security score.
  • Test changes before use: Check therapy, alarms, data, and recovery. A patch is not a safety sign-off.
  • Control unresolved risks: Give temporary controls an owner, approval, expiration date, and review schedule.
  • Check field actions and reporting: Account for affected devices and confirm which FDA duties apply. Qualifying user facilities generally have 10 work days to report suspected device-related deaths or serious injuries.
  • Plan replacement: Keep decision records and arrange funding, migration, and safe retirement before support ends.

My closure rule: <u>verify the result, review patient safety, and document who accepts the remaining risk.</u>

Module 8 Postmarket Cybersecurity and Vulnerability Disclosure

Monitor Threats and Prioritize Device Risks

Medical Device Risk Triage Decision Tree

Medical Device Risk Triage Decision Tree

Before assigning risk, compare each new finding with the device record and its deployed configuration.

Collect and Verify Security Findings

Send all security findings to one intake queue. Sources should include manufacturer advisories, coordinated vulnerability disclosure reports, CISA alerts and Known Exploited Vulnerabilities, NIST’s National Vulnerability Database, and third-party software or component notices. Also include device and network logs, incident reports, biomedical-engineering tickets, and observations from clinicians or patient-safety staff. Give each source an owner, review schedule, severity screen, and escalation path. Review confirmed exploitation and high-risk manufacturer advisories immediately.

Check each finding against the manufacturer advisory, affected-version list, asset inventory, available SBOMs, and controlled log or configuration evidence. Record the device identifier, source, discovery date, affected instances, and symptoms.

Label each event as a vulnerability, incident, malfunction, availability issue, or suspected patient-safety event. Use multiple labels when needed. An unconfirmed scanner alert is not proof of exposure. Do not probe or attempt exploitation on a clinical device unless the manufacturer and change control explicitly authorize it.

Only verified findings move to exploitability review.

Assess Exploitability and Patient-Safety Risk

Use CVSS as one input - not the final decision. Establish exposure by checking affected versions and configurations, reachable network paths, authentication requirements, exploit evidence, and safeguards already in place.

Then assess what the weakness could do to care for the affected patient population. Could it alter therapy, suppress alarms, corrupt measurements, or interrupt critical care? Review older and customized deployments separately; instances may carry different risks.

Technical severity Exploit likelihood and exposure Clinical impact Response priority
Low No known exploit; difficult prerequisites No effect on essential performance; limited data exposure Track, document the rationale, and address during normal maintenance
High Public exploit code, active exploitation, or a simple remote attack path Could alter therapy, suppress alarms, corrupt measurements, or interrupt critical care Urgent containment, clinical review, manufacturer coordination, and executive visibility
Critical Confirmed compromise or a highly reliable attack path Could cause severe injury, death, broad loss of essential performance, or compromise many connected devices Immediate incident and patient-safety escalation, emergency controls, and continuous reassessment

Use the response priority to set the deadlines below.

Set Response Deadlines and Escalation Rules

The table is an illustration, not a replacement for an approved risk matrix. Set internal response targets before findings arrive. Base them on potential clinical consequences and whether the device can safely remain in use.

For example, a critical tier may require acknowledgment within 4 hours, clinical and security review within 24 hours, immediate containment where safe, and an executive decision on continued operation; a high tier may require assessment within 2 business days and a documented mitigation plan within 10 business days.

Moderate and low tiers may follow scheduled maintenance with periodic review. These are internal targets, not regulatory deadlines.

Document affected versions, exposure, exploitability, patient-safety impact, manufacturer communications, chosen controls, test results, risk acceptance, and the reassessment date. Review reporting obligations separately with legal, quality, privacy, regulatory, and clinical-safety teams.

Preserve evidence and the reasoning behind decisions at every step. Escalate suspected harm or lost essential performance to clinical leadership immediately. Require executive review when continued operation carries unresolved critical risk.

Reassess when exploit activity, integrations, dependencies, controls, clinical use, or manufacturer guidance changes - and when a mitigation expires.

  • Does the report have supporting evidence and identify a device, component, version, or observable event? No → request evidence, monitor, and document the disposition; yes → verify affected status.
  • Is the version or configuration affected? No → retain the finding for monitoring and verify asset data; yes → assess impact and exposure.
  • Is there evidence of exploitation, compromise, patient harm, unsafe performance, or loss of essential availability? Yes → activate applicable incident, clinical-safety, and regulatory escalation; no → assess exposure and safe containment.
  • Is the device exposed through the internet, remote access, shared networks, or vulnerable integrations? Yes → apply safe containment and coordinate with the manufacturer; no → continue monitoring.
  • Can the recommended update or mitigation preserve safety and availability? Yes → test and deploy under change control; no → document compensating controls, obtain clinical and technical approval, and set a reassessment date.
  • Does the evidence show that risk meets the approved threshold? Yes → close or monitor; no → escalate and keep the risk record open.

Manage Software Updates and Residual Risk

Choose the Update Approach

Use the risk priority from the previous section to choose the safest remediation path. An available patch still needs a safety review before deployment. Confirm that the manufacturer’s fix applies to the deployed model, version, configuration, and deployment environment. Weigh the risk of waiting against the risk of therapy, alarm, availability, or integration failures. Coordinate changes with the manufacturer, which remains responsible for validating design changes.[2][5][6]

Change type Urgency Testing Deployment Regulatory review and documentation
Routine cybersecurity update Scheduled when patient-harm risk is controlled Manufacturer validation and risk-based clinical testing Planned maintenance with recovery procedures FDA generally treats routine cybersecurity patches as enhancements rather than reportable corrections under 21 CFR Part 806.[2]
Urgent security patch Expedited for active threats or potentially uncontrolled risk Focused safety and interoperability checks Out-of-cycle deployment with immediate verification Coordinate regulatory review with the manufacturer.
Configuration change Prompt when a patch is unavailable or unsafe Check alarms, interfaces, access, and remote support Controlled change with monitoring Record clinical effects, residual risk, ownership, and expiration.
Major software or firmware change Planned according to risk and scope Broader regression, workflow, failover, and recovery testing Staged rollout where feasible Obtain manufacturer guidance; regulatory treatment depends on the change’s nature and effect.[2][5]

Document the risk decision and regulatory basis for every update.

Test, Deploy, and Verify Updates

Validate the selected remediation in a controlled environment before deployment. Where feasible, test models and configurations that represent the devices in use. Cover startup and shutdown, clinical workflows, settings, alarms and notifications, data integrity, user authentication, network communications, interoperability with the EHR and other connected systems, failover, recovery, and performance under expected load. Record acceptance criteria, test results, unresolved defects, and limitations.

Plan the maintenance window, staffing, communications, backups or exports, rollback conditions, downtime workflow, and escalation contacts. Confirm which backup or export methods are supported. Do not assume firmware can be rolled back. Check the supported recovery path before deployment.[4][7]

Get approval from the device owner and the relevant clinical, biomedical, security, and IT leads. Include the manufacturer when vendor intervention is needed. For urgent changes, use an expedited review that includes minimum required safety tests, a documented risk decision, clinical or executive authorization, and a scheduled post-deployment review. Urgency can shorten the process, but it should not remove safety checks.

After installation, verify the software or firmware version, device configuration, security settings, time synchronization, connectivity, and communication with all critical connected systems. Check alarms, controls, displays, orders, results, and failover behavior. Confirm that the mitigation works using the manufacturer’s validation method or an approved technical check. Avoid disruptive testing on a live device.

Record each device’s identifier, installation time, operator, result, exceptions, and any rollback. Reassess residual risk, including new defects, reduced functionality, or unsupported components. Track remaining risk by device, location, software version, and patient-care context. Close the change only when verification meets the acceptance criteria. If it does not, assign controls, an owner, a deadline, and a follow-up review.[2][7]

Record Temporary Controls and Exceptions

If remediation must wait - or patching is unsafe or impractical - document the compensating controls that allow the device to stay safely in service. Consider temporary network isolation, restrictions on administrative or remote access, disabling affected services, or increased monitoring. If safe operation cannot be maintained, consider temporary removal from service. Check that controls preserve alarm delivery, remote clinical support, and required laboratory and EHR interfaces.

Each exception must record the affected assets and versions, vulnerability identifier or advisory, rationale, alternatives considered, residual-risk rating, and compensating controls. Include a named owner and approving authority, creation and expiration dates, communication requirements, and a monitoring plan with a review schedule.

Define triggers for patching, replacement, or reassessment. These may include manufacturer validation, an approved patch, evidence of exploitation, a device configuration change, a new safety concern, or a change in patient-care use. Every exception must expire or be renewed in writing. Keep its risk record open until residual risk meets the approved acceptance threshold.

Review Field Actions and Patient Safety

Use this section when a vulnerability leads to a manufacturer-directed repair, removal, replacement, or recall.

Identify Affected Devices and Track Field Actions

Verify each notice through the manufacturer, FDA recall database, FDA safety communications, and internal vendor channels. Record the notice date, affected models and versions, required action, deadline, and source.

Check inventory, procurement, configuration, and discovery records to confirm which devices are affected. Link each device to its serial number, UDI where applicable, location, owner, network segment, and clinical function. Include loaner, leased, offline, backup, and retired devices. A cybersecurity advisory is not automatically a recall. Keep the manufacturer’s classification, and send unclear wording to quality or regulatory staff.[10]

Assign a field-action owner. Notify clinical engineering, security, quality, supply chain, patient safety, and affected departments. Track every affected asset through repair, update, removal, or replacement, including failed attempts and approved exceptions.

Before isolating or removing devices, clinical teams must arrange backup equipment, patient transfers, staffing, and downtime procedures. Keep service reports, removal records, and the manufacturer’s confirmation of completion. Check that the action reached all affected devices.

Once the scope is confirmed, assign reporting ownership before the field action begins.

Determine Reporting and Escalation Requirements

FDA Medical Device Reporting (MDR) duties depend on the organization’s role:

  • Manufacturers generally report deaths, serious injuries, and qualifying malfunctions within 30 calendar days. Certain events require a 5-work-day report.
  • Importers report deaths and serious injuries to FDA and the manufacturer, and qualifying malfunctions to the manufacturer.
  • Qualifying user facilities report suspected device-related deaths to FDA and the manufacturer within 10 work days. They report serious injuries to the manufacturer, or to FDA if the manufacturer is unknown, within the same period. They must maintain event files and submit required annual reports, but MDR does not require them to report malfunctions.[8][9][11][13]

For corrections and removals, manufacturers and importers generally have 10 working days after initiating a reportable action to notify FDA under 21 CFR Part 806. Reporting applies when an action reduces a risk to health or remedies a violation that may present a health risk. Regulatory staff should review exceptions and recordkeeping requirements.[10][12]

The HDO should preserve evidence, notify the manufacturer promptly, and support surveillance - not take on the manufacturer’s reporting duties. Use the matrix below to guide escalation, not replace regulatory review. Let reporting status guide containment, communication, and closure timing.

Finding and affected population Potential harm Responsible parties and escalation
Unexploited vulnerability; affected devices have effective controls and no clinical malfunction Exposure without demonstrated patient harm Security and clinical engineering coordinate manufacturer remediation and continued monitoring; no automatic recall.
Exploitation affecting confidentiality across affected devices PHI or operational data exposure Security, privacy, legal, and manufacturer investigate; assess breach obligations separately from device-event reporting.
Exploitation affecting therapy, alarms, diagnosis, or availability; prioritize high-acuity patients Incorrect or delayed care Immediately involve clinical leadership, patient safety, security, manufacturer, and quality/regulatory; arrange safe containment and assess reporting.
Malfunction that could recur and cause serious injury Potential future patient harm Manufacturer assesses MDR obligations; HDO preserves device evidence and logs and supports investigation.
Suspected device-related death or serious injury Actual patient harm Qualifying user facility, manufacturer, and importer follow their respective MDR duties; escalate promptly to patient safety and regulatory staff.
Manufacturer correction, removal, or recall affecting identified models and versions Product-specific safety risk Manufacturer/importer assess Part 806 duties; HDO tracks affected assets, clinical communications, completion, and effectiveness.

Assess Safety Effects and Approve Closure

After completing the field action, check whether it created new availability, alarm, or workflow risks. Review changes to availability, data integrity, alarms, therapy, diagnosis, monitoring, clinician decisions, and downtime risk.

Clinical engineering, patient safety, clinical leadership, security, quality, and regulatory teams should approve the safety review. Completed work orders alone are not enough to close the action. Require inventory reconciliation, asset-level completion evidence, documented staff communications, a review of downtime consequences, and an effectiveness check for missed devices and recurring problems.

Every unresolved asset needs an approved exception and documented acceptance of residual risk. Without both, keep the action open.

Maintain Governance and Lifecycle Records

Bring the results of updates, field actions, and exceptions into one lifecycle record.

Retain Evidence and Review Performance

Keep one searchable record per device, linked to its asset ID, model, version, and owner. Include assessments, threat models, test results, approvals, manufacturer communications, exceptions, and closure records. Preserve timestamps, approvals, and version history. Set access controls and retention periods based on legal, regulatory, quality, privacy, and organizational requirements.

Review operational metrics monthly and governance trends quarterly. Track inventory coverage, triage and mitigation time, patch success and rollback rates, unsupported devices, aging high-risk exceptions, field-action completion, and care-related incidents.

Break down results by clinical criticality. Hospital-wide averages shouldn't hide problems in intensive care or life-support settings. For each decision that follows, record the budget owner, target date, and expected risk reduction.

Coordinate Risk Assessments With Censinet

Use Censinet RiskOps™ to bring device and vendor risk reviews into one place, track commitments, and route open questions among clinical engineering, security, procurement, and clinical teams. It supports governance - not monitoring, patching, validation, reporting, or risk acceptance.

Plan for End of Support and Device Replacement

Use the same record to plan replacement as support windows close. Track end-of-support and end-of-security-update dates, the last available patch, replacement lead times, and required integrations.

Before support ends, assess whether restricted connectivity, segmentation, increased monitoring, or other compatible controls can keep clinical risk acceptable. Temporary controls need an owner, evidence that they work, an expiration date, and a funded replacement plan.

Define clear replacement triggers: expired support, unavailable security updates, repeated high-risk findings, recurring safety incidents, or controls that limit safe clinical use. Include clinical engineering, security, procurement, and accountable risk owners in the decision.

Use these trends to shape future purchasing requirements for support duration, update commitments, incident notice, secure remote access, and notice periods.

Conclusion: Postmarket Risk Management Checklist

Closing a risk doesn’t end oversight. Use device records, named owners, monitoring, updates, and field-action tracking to guide patient-safety decisions from deployment through retirement.

Apply this checklist to the device record used for monitoring, updates, and field actions. Treat it as the final gate before continued operation, remediation closure, or replacement planning.

  • [ ] Deployment approved: Confirm device identity, version, use, dependencies, support status, controls, and owner approval.
  • [ ] Monitoring active: Confirm that monitoring sources are active and assigned.
  • [ ] Deadlines set: Assign an owner and due date to each open finding. Potential immediate patient harm triggers same-day clinical and security review.
  • [ ] Update verified: Verify the update, prepare the recovery path, and check device function after installation.
  • [ ] Safety impact documented: Record safety effects, residual risk, and the rationale for each action.
  • [ ] Exceptions time-boxed: Set expiration dates for temporary controls and reapprove them before they expire.
  • [ ] Closure complete: Account for all affected devices, complete corrective actions, retain evidence, and formally accept residual risk.
  • [ ] Replacement scheduled: Confirm support deadlines, funding, procurement, migration, interoperability, and safe decommissioning.

FAQs

How can we test device patches without a dedicated test environment?

Test patches in a bench environment that closely matches your hospital’s VLANs, authentication protocols, and network load. Start with a small pilot group before deploying across the hospital. Watch for CPU spikes, unexpected reboots, and errors in logs [1].

If you can’t patch right away, document and apply compensating controls to manage the remaining risk. These may include network segmentation, added monitoring, or changes to clinical workflows [2][3][1].

What should we do if a manufacturer stops responding to security concerns?

Use established communication channels and follow your internal incident response playbooks. This includes escalating incidents to leadership and regulatory bodies. Report medical device cybersecurity incidents to the FDA at CyberMed@fda.hhs.gov.

Document every outreach attempt and nonresponse to support regulatory compliance and potential enforcement actions. Under Section 524B of the FD&C Act, manufacturers must address vulnerabilities within a reasonable time.

How do we balance device replacement costs against patient-safety risks?

Use risk-based triage to put clinical impact ahead of technical severity alone. Assess how likely exploitation is and how much harm it could cause patients. Then classify each risk as controlled or uncontrolled.

When clinical workflows or uptime requirements delay patching, manufacturers and healthcare organizations should apply compensating controls, such as network segmentation, access restrictions, or increased monitoring. Document every remediation decision - including device replacement - with a technical justification, an assessment of residual risk, and clear clinical oversight.

Related Blog Posts