A vulnerability score alone does not tell me whether a medical device puts patients at risk. I start by checking affected versions, how an attacker could reach the device, and what harm could follow. FDA’s 2016 guidance calls for a risk-based review; Section 524B adds legal requirements for qualifying cyber devices.
Here’s the process I follow:
- Assign ownership: Gather device records, supplier details, and deployment information.
- Assess patient risk: Check exposure, possible harm, and whether existing safeguards work.
- Plan the fix: Test patches or interim controls, prepare recovery steps, and review reporting duties. Reportable corrections or removals generally have a 10-working-day deadline after initiation.
- Coordinate notices: Give suppliers and healthcare teams clear technical and clinical instructions.
- Verify closure: Confirm installation, document remaining risk, and update device records. Tracking tools can support this work - not replace clinical judgment or regulatory duties.
My bottom line: <u>releasing a patch is not the same as resolving the risk</u>. I verify the result and keep monitoring, even after the case closes.
FDA Postmarket Software Vulnerability Review Workflow
Assess Device Exposure and Patient Safety Risk
Confirm Affected Versions With the Supplier
Compare third-party vendor risk advisories, research reports, government notices, and internal findings against the SBOM, build records, and deployed configuration. Confirm whether the component is present, reachable, and able to affect safety or essential performance. Keep version hashes, configuration snapshots, supplier correspondence, and test results so you can verify whether the vulnerable code is in scope.
Ask the supplier to fill exposure gaps using the device model, software release, component version, and vulnerability ID. Request affected and unaffected versions, attack prerequisites, exploitation evidence, mitigations, patch-testing instructions, and support timelines. If key facts remain unclear, assume exposure and escalate. Close a finding as unaffected only when evidence shows that the vulnerable code or required attack path is absent.
Evaluate Technical Severity and Patient Harm
Record the CVSS version, score, and vector. Then assess attacker access, privileges, user interaction, exploit maturity, and impacts on confidentiality, integrity, and availability. Clinical reviewers should connect attack outcomes to therapy changes, missed alarms, incorrect diagnostic results, or loss of essential performance. Document possible harm, affected device counts, and whether clinicians can detect the failure and respond safely. This assessment is critical as cyberattacks on medical devices increasingly threaten patient care.
FDA’s framework combines exploitability and severity of patient harm. Risk is controlled when mitigations bring residual patient-harm risk to an acceptable level. It is uncontrolled when that risk remains unacceptable.
Check that controls work in practice. Segmentation requires network-validation evidence; service disablement requires a running-configuration check. Combine the technical and clinical findings to assign a risk tier. Use the table as a decision aid - not as a CVSS threshold rule.
| Technical severity | Device exposure | Clinical effect | Compensating controls | Response urgency | Decision approver |
|---|---|---|---|---|---|
| High or critical; confirmed exploitability | Reachable from the internet or across many network locations; vulnerable function enabled | Could alter therapy, disable critical functions, suppress alarms, or cause serious injury or death | Absent, unreliable, or inconsistently deployed | Emergency action; isolate or disable safely, expedite remediation, and assess required notifications | Incident lead, clinical safety, quality/regulatory, executive sponsor |
| High; constrained exposure | Reachable only through controlled clinical or vendor pathways | Could affect diagnosis, monitoring, data integrity, or essential performance | Validated segmentation, authentication, monitoring, and workarounds | Expedited remediation and verified interim controls | Product security, clinical safety, quality, regulatory |
| Moderate | Vulnerable code enabled in a controlled environment | Limited or recoverable effect; no supported serious-harm pathway identified | Tested controls reduce exposure and detect abnormal behavior | Scheduled update with monitoring and reassessment triggers | Product owner, security, clinical risk |
| Low or difficult to exploit | Unreachable, disabled, or confined to a feature that is not in use | No supported effect on safety or essential performance | Verified, maintained configuration or isolation | Monitor supplier updates and review deployment changes | Security, device owner, quality as required |
| Any score | Exposure or clinical effect uncertain | Serious harm cannot be ruled out | Unverified or inconsistent | Escalate, apply conservative interim controls, and gather evidence before closure | Risk committee or senior approver |
Record the residual-risk rationale, decision approver, decision date, and reassessment triggers. Reopen the assessment when exploit code appears, active exploitation is reported, the supplier changes its affected-version statement, or a patch becomes available. Also reassess when network access changes or compensating controls are removed. Keep the prior decision to show what changed, and use the risk decision to select patches, interim controls, and regulatory review.
sbb-itb-535baee
Webinar: Management of Cybersecurity for Medical Devices after Approval
Develop and Approve a Remediation Plan
Once you’ve ranked the risk, use the residual-risk decision to select the least disruptive fix that brings patient risk to an acceptable level.
Choose Patches and Interim Controls
Balance patient safety, cybersecurity benefit, the effect on operations, and residual risk when choosing a fix. Options include an update, software patch, configuration change, access restriction, feature disablement, compensating control, or replacement. Monitoring detects exploitation; it does not remove the vulnerability.
Before restricting functionality, document how the change affects workflows, alarms, fallback procedures, and patient care. If no patch is available or the device cannot be updated, document interim controls, their limits, an owner, a review date, and escalation criteria.
Validate the fix before releasing it to production devices. Let its risk profile guide the scope of testing. Test security, clinical function, interoperability, data integrity, alarm behavior, performance, installation, and rollback. Use representative hardware, software versions, network configurations, and clinically important integrations.
Record acceptance criteria, test results, unresolved defects, and residual risk. FDA recommends validation that shows the fix addresses the vulnerability without introducing unacceptable safety, performance, or security risks.[1][3]
Plan Deployment and Review Regulatory Requirements
After technical and clinical approval, send the same case for regulatory review. Use this response-plan template to document release and deployment decisions so they can be traced:
| Plan field | Required details |
|---|---|
| Correction | Supplier instructions, affected and corrected versions, device models, supported hardware, and prerequisites |
| Validation and approvals | Test evidence; separate technical, clinical, and quality approvals; deployment authorization |
| Delivery and recovery | Authenticated delivery, package integrity checks such as hash or signature verification, installation verification, backups, rollback authorization, and downtime or care-continuity procedures |
| Deployment | Owners, target dates, maintenance windows, pilot devices, staged rollout, and coverage tracking |
| Exceptions | Offline, unsupported, or unupdatable devices; interim controls; replacement plans; escalation triggers; do not count offline devices as complete |
| Regulatory determination | Applicable reporting and premarket obligations, decision rationale, source version, date checked, and responsible reviewer |
Track successful installation and post-deployment verification for every device or validated device group. Identify who can stop deployment if unexpected alarms, performance loss, or integration failures occur. Rollback requires a risk decision if restoring the prior version also restores the vulnerability.
Keep regulatory review separate from technical sign-off. Regulatory staff should assess correction or removal reporting under 21 CFR Part 806, medical device reporting under Part 803, and any premarket submission requirements. Reportable Part 806 actions generally have a reporting deadline of 10 working days after initiation.[8] Routine cybersecurity updates that address controlled risk are treated differently, but staff must document that determination.[6]
Before relying on FDA’s conditional enforcement discretion, check current FDA sources and the applicable 30-day and 60-day framework. Review adverse-event conditions, risk reduction, customer communications, and ISAO participation or information sharing. Record how each applicable condition is met; this policy is not a blanket exemption.[4][7]
Coordinate Disclosure and Stakeholder Notices
Once the remediation plan is set, move from internal approval to disclosure and customer notice.
Assign Communication Roles and Notify Customers
Name one manufacturer contact to own customer follow-up. Acknowledge receipt with a case ID, a secure channel, and the next validation step. Do not confirm exploitability before validation. Send evidence to cybersecurity engineering, the component supplier, clinical safety, and quality/regulatory reviewers.
Agree on investigation and disclosure timing with the reporter and supplier. Get written confirmation of support limits, disclosure restrictions, and notice timing.
Escalate immediately if exploitation is active or patient harm is plausible. Don't wait for a permanent fix to share urgent protections. Document why the disclosure date was chosen, and revisit it if exploitation, mitigations, or clinical impact changes.
Assign communication roles through the manufacturer’s quality system:
| Role | Validation | Disclosure | Follow-up |
|---|---|---|---|
| Manufacturer cybersecurity/product | Validates technical findings and affected versions | Coordinates timing and technical content | Tracks case progress |
| Component supplier | Confirms component facts and dependencies | Coordinates supplier disclosure | Provides updated findings |
| Clinical safety | Assesses medical device security risks and clinical impact | Reviews clinical instructions | Identifies clinical follow-up needs |
| Quality/regulatory | Reviews controlled evidence | Coordinates regulatory communications | Approves closure record |
| Customer support | Routes customer evidence and questions | Distributes notices | Tracks receipt, implementation, and recipient questions |
Turn the risk decision into clear customer instructions. Write two notices: technical and clinical. Include:
- Affected products and versions
- Exploit prerequisites and whether exploitation is known
- Patient impact and interim controls
- Patch availability and installation instructions
- Residual risk
- Technical and clinical contacts
- Next-update date
Ask each HDO to confirm receipt and name local owners. Customer notices and regulatory reports are separate work products. Archive supplier correspondence, disclosure decisions, approvals, notice versions, delivery records, recipient questions, and unresolved-risk decisions in the case file linked to quality records.
Support HDO Risk Reviews With Censinet RiskOps™
Censinet RiskOps™ can help centralize case tracking, vendor evidence, ownership, review status, and correspondence for HDO follow-up. Named HDO reviewers should track receipt, local controls, implementation, exceptions, and unresolved risk.
The platform does not replace manufacturer quality processes, patch validation, clinical judgment, regulatory reporting, or FDA obligations.
Conclusion: Verify Closure and Continue Monitoring
After remediation and notices are complete, verify closure before marking the case resolved. Close the case only after verifying the confirmed exposure, patient-safety review, remediation, and notices. Releasing a patch does not close remediation - installation must be verified. Match each affected deployment to installation evidence, compensating controls, or a documented residual-risk decision. Keep unresolved exposure open in the case record.[1][5]
Track Updates and Revise Device Records
Track installation success by device model and customer. Record failed, deferred, and rolled-back updates, devices that remain exposed, and interim controls. Verify the installed version, update integrity, and whether the update addresses the vulnerability. Confirm that remediation preserves essential clinical performance, including alarms, availability, and interoperability.[1][5]
Use these records to explain why the case can close or must stay open. Update the SBOM, threat model, risk analysis, vulnerability record, and postmarket monitoring plan. Add supplier findings to procurement, support, and end-of-support requirements. Reopen the case through a linked record when exploitation evidence, affected versions, clinical performance, or control effectiveness changes.[2][5]
Before closing the record, confirm technical verification across affected deployments and reassess patient safety. Check that residual risk has documented owners and review dates, all required approvals are complete, stakeholder notifications are confirmed, and device records are updated.
Record the continued-monitoring decision, including metrics, review frequency, escalation thresholds, and reopening triggers. Closure ends the current review - not lifecycle monitoring.[1][5]
FAQs
How does Section 524B apply to devices already in use?
Section 524B of the FD&C Act requires manufacturers to maintain a formal postmarket cybersecurity plan for devices in use. The plan must cover continuous monitoring, vulnerability assessment, and patch development and deployment.
Manufacturers must use their Software Bill of Materials (SBOM) to identify affected devices and components that have reached the end of support. Risk-based triage determines which vulnerabilities need immediate fixes outside the regular update cycle and which can wait for scheduled maintenance. In the meantime, compensating controls must protect patient safety.
What if my vendor cannot confirm vulnerability exposure?
Under FDA’s Total Product Lifecycle framework, the manufacturer remains responsible for inherited risk. Check internally whether your device’s execution flow can reach the vulnerable code. Use your SBOM to map dependencies, then apply an exploitability decision tree to assess configuration and network exposure.
If you can’t patch the component, document a technical justification for the remaining risk. Put compensating controls in place, such as network segmentation or added monitoring, to protect patient safety.
When does a cybersecurity patch require FDA review?
Most cybersecurity patches are routine device updates and don’t require formal FDA reporting under 21 CFR Part 806.10, as long as they introduce no new risks and no patient harm occurs.
Patches that address an uncontrolled safety risk that could cause death or serious injury must be reported within 10 working days. Manufacturers must thoroughly test and validate every patch within their quality system to maintain device safety and performance.
