Developing and Deploying Patches

Patching a medical device follows the same change control as any other software change: reproduce the issue, develop the fix, then run security, safety, and regression testing before release. Distribution depends on the device, from automatic updates down to technician visits for air-gapped systems, and every update package must be cryptographically signed.

The scale can be significant. Abbott's 2017 firmware update for cybersecurity vulnerabilities in former St. Jude Medical pacemakers covered roughly 465,000 implanted devices in the US, and FDA's accompanying safety communication directed that the update be applied during an in-person clinic visit.

5.5.1 Patch Development Process

Your patch development must balance speed with safety:

flowchart LR
    A[Vulnerability Identified] --> B[Reproduce Issue]
    B --> C[Develop Fix]
    C --> D[Security Testing]
    D --> E[Safety Testing]
    E --> F[Regression Testing]
    F --> G[Documentation]
    G --> H[Release Preparation]

Development Considerations

Fix Approaches:

• Direct vulnerability patch
• Compensating controls
• Feature disable option
• Workaround procedures

Testing Requirements:

• Verify fix effectiveness
• Ensure no new vulnerabilities
• Confirm safety maintained
• Check performance impact

Documentation Needs:

• Change description
• Installation instructions
• Rollback procedures
• Known issues

5.5.2 FDA Reporting Considerations

When do you need to notify FDA?

Mandatory Reporting:

• Changes affecting safety/effectiveness
• Cybersecurity signals per MDR
• Recalls for critical vulnerabilities

Voluntary Reporting:

• Proactive communication
• Industry coordination
• Lessons learned sharing

Documentation for FDA:

• Vulnerability details
• Risk assessment
• Mitigation approach
• Deployment timeline

5.5.3 Patch Distribution Methods

Choose distribution based on urgency and capability:

Automatic Updates:

• Fastest deployment
• Minimal user action
• Requires infrastructure
• Needs failsafes

Manual Updates:

• User-controlled timing
• Requires notification
• Slower deployment
• More predictable

Physical Updates:

• For air-gapped devices
• Service technician required
• Slowest method
• Most controlled

For building the policy and process around this, see How to establish a patch management and security update process. For why remote update capability is now effectively mandatory, see New cybersecurity regulations make remote software updates practically mandatory.

Update Package Security

Ensure patches can't become attack vectors:

sequenceDiagram
    participant Device
    participant Update Server
    participant Manufacturer
    
    Manufacturer->>Manufacturer: Create patch
    Manufacturer->>Manufacturer: Sign with private key
    Manufacturer->>Update Server: Upload signed package
    Device->>Update Server: Check for updates
    Update Server->>Device: Send signed package
    Device->>Device: Verify signature
    Device->>Device: Install if valid