How to Secure Medical Device Software Updates
Post Summary
Securing medical device software updates is critical for patient safety and cybersecurity. Cyberattacks targeting healthcare devices can lead to compromised patient data, operational disruptions, or even life-threatening consequences. Here's what you need to know:
- Cyber Risks: 99% of healthcare organizations have known device vulnerabilities, with 276 million health records exposed in 2024 alone.
- FDA Requirements: As of March 2023, manufacturers must create plans to monitor, identify, and address device vulnerabilities under Section 524B of the FD&C Act.
- Key Steps:
- Risk Assessments: Identify vulnerabilities through testing and scanning.
- SBOM (Software Bill of Materials): Maintain a detailed inventory of all software components.
- Secure Update Delivery: Use encryption, authentication, and anti-rollback protection.
- Testing & Validation: Ensure updates don’t introduce new risks.
- Compliance: Follow FDA guidelines, document processes, and establish a Coordinated Vulnerability Disclosure (CVD) policy.
- Lifecycle Oversight: Use automated tools like Censinet RiskOps™ to monitor and manage risks.
Medical Device Cybersecurity Statistics and Key Security Steps
Cybersecurity in Medical Devices – What QA/RA Must Do Today
sbb-itb-535baee
Conduct a Risk Assessment
Before rolling out any software update, it's essential to evaluate potential risks. This step acts as a critical safeguard against vulnerabilities that could compromise patient safety or expose sensitive health data. With 53% of connected medical devices in hospitals containing known critical vulnerabilities [2], skipping this process isn't an option.
Start by creating a complete inventory of your devices. Then, perform security assessments like penetration testing and vulnerability scanning to uncover potential weaknesses. Frameworks such as the Playbook for Threat Modeling Medical Devices can help identify specific attack vectors that could target your technology [1][2]. This process helps distinguish between controlled risks, which pose minimal harm, and uncontrolled risks, which could severely impact patient safety or data integrity [2].
"MedTech cybersecurity is not just about protecting data; it's about safeguarding human lives. Compromised devices could cause harm to a patient, misdiagnosis, or delayed diagnosis."
– Christian Espinosa, Founder and CEO, Blue Goat Cyber [2]
Identify Vulnerabilities and Threats
Building on your initial assessment, systematically pinpoint vulnerabilities using established tools and frameworks. The Common Vulnerability Scoring System (CVSS) is particularly useful for categorizing and prioritizing security flaws based on their severity and exploitability. Cross-reference your findings with the CISA Known Exploited Vulnerabilities (KEV) list to identify threats that attackers are actively exploiting.
Don't overlook third-party components like external software or off-the-shelf applications, as these can introduce supply chain vulnerabilities. For instance, in March 2022, the FDA issued guidance to address vulnerabilities in the PTC Axeda agent and Axeda Desktop Server, recommending upgrades to Axeda agent Version 6.9.2 build 1049 or higher and limiting the agent’s configuration to local host interfaces [1][3].
Medical devices often remain in use for 10 to 15 years, far outlasting the support lifecycle of their software [2]. This longevity makes it crucial to address not only current vulnerabilities but also potential risks that could emerge as software ages. Alarmingly, 33% of healthcare IoT devices have critical risks that could disrupt operations or compromise device functionality [2].
Ensure that any backdoors left for development or testing purposes are fully disabled in production versions. Additionally, validate all software changes, updates, and patches in a controlled environment before deployment to ensure they don't negatively impact device safety or performance [3].
Create a Software Bill of Materials (SBOM)
An SBOM is a powerful tool for managing software risks throughout a device's lifecycle. It lists every software component - covering open-source libraries, third-party code, and off-the-shelf software - giving you the visibility needed to uncover hidden vulnerabilities. A well-maintained SBOM not only simplifies vulnerability tracking but also strengthens your risk assessment process. On June 27, 2025, the FDA released updated guidance titled "Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions," emphasizing the importance of SBOMs for connected devices [4].
"The SBOM has moved from 'nice-to-have' to essential cybersecurity documentation for medical device submissions."
– Viktor Petersson, CEO, sbomify [4]
Document each software component with details like supplier name, component name, version, unique identifier, dependency relationships, author, and timestamp. Use machine-readable formats like SPDX or CycloneDX to ensure consistency [4]. Remember, an SBOM is a dynamic document that must be updated with every software release or patch.
By assigning unique identifiers to each component, you can cross-check them with the National Vulnerability Database (NVD) to detect known security issues. Integrate SBOM generation into your CI/CD pipelines so that updates are automatically scanned for vulnerabilities, reducing the risk of introducing outdated or unsupported components [4]. Under Section 524B of the FD&C Act, the FDA can reject premarket submissions for devices that lack sufficient SBOM and cybersecurity documentation [4]. For example, in early 2025, the U.S. Department of Justice settled a $9.8 million False Claims Act case with Illumina after allegations that the company misrepresented its cybersecurity capabilities when selling sequencing platforms to federally funded institutions [2].
Platforms like Censinet RiskOps™ can simplify medical device risk assessments by centralizing vulnerability tracking, automating risk prioritization, and monitoring remediation efforts across your entire device ecosystem.
With a thorough risk assessment and SBOM in place, the next focus should be securing the update delivery process.
Implement Secure Update Delivery Mechanisms
This section emphasizes the importance of safeguarding update delivery, especially after completing a risk assessment and establishing a Software Bill of Materials (SBOM). The 2020 SolarWinds attack serves as a stark reminder of the risks involved - threat actors managed to infect 18,000 companies by embedding malware into an over-the-air (OTA) software patch [6]. For medical devices, where patient safety is critical, a compromised update could result in dire consequences.
"A secure Over-the-Air (OTA) update mechanism is the process of delivering new firmware to a device in a way that protects the integrity and authenticity of the software. It is the only practical way to patch security vulnerabilities discovered after a product has been shipped."
– Secure by Design Handbook [5]
The foundation of secure update delivery relies on three key principles: authenticity (ensuring updates come from a trusted source), integrity (verifying updates remain unchanged), and confidentiality (preventing unauthorized access or reverse-engineering). With only 22% of healthcare organizations running up-to-date software across all equipment [6], implementing strong delivery mechanisms is crucial.
Use Encryption and Authentication Protocols
To ensure secure updates, firmware images should be signed using a private key stored securely (e.g., in a Hardware Security Module, or HSM) and verified with a corresponding public key. This process ensures that only authorized updates are installed. For secure communication, protocols like TLS 1.3 should be used, along with standards such as JSON Web Signature (JWS – RFC 7515) for signing and SHA-256 for integrity verification. Encrypting the update package using symmetric encryption can also help protect intellectual property and prevent reverse-engineering.
Securing the transmission channel is equally important. Establishing a chain of trust with a multi-tier key model - including root and signing keys - adds another layer of security. Root keys can be protected on devices using Trusted Platform Modules (TPM), Software Guard Extensions (SGX), or HSMs. For example, services like Azure IoT Hub generate signed update manifests that include file hashes, allowing devices to verify the integrity of downloaded binaries. Anti-rollback protection is another essential measure - this involves storing the current firmware version in tamper-proof storage (e.g., hardware fuses) to block outdated firmware. Additionally, secure boot mechanisms validate firmware signatures during every startup, with modern implementations requiring fewer resources [6].
Regulatory frameworks, such as the Cyber-Resilience Act (CRA), and advancements in post-quantum cryptography highlight the need to stay prepared for evolving threats [6].
Establish Secure Communication Channels
Securing the communication pathway requires a well-thought-out network architecture and stringent access controls. An A/B partition scheme can enhance reliability by writing updates to an inactive slot and activating them only after successful verification, reducing the risk of interruptions. Devices should also perform hostname verification during the TLS handshake to ensure they are connecting to a legitimate update server. Further, isolating update agent components by running them under dedicated accounts and restricting network communications to localhost can help minimize vulnerabilities.
"The risk of an attacker compromising the OTA update server and pushing a malicious update to the entire fleet is greater than the risk of an individual device being exploited by a local attacker."
– Secure by Design Handbook [5]
To mitigate this risk, harden your update server and cloud infrastructure against unauthorized access that could lead to malicious firmware distribution. Automated network monitoring can quickly detect and address suspicious activity or tampered updates across your Internet of Medical Things (IoMT) network. If updates are delivered through intermediaries - such as a technician's laptop or a mobile app via Bluetooth or USB - ensure that these "last hop" connections are as secure as the primary transmission channel.
Platforms like Censinet RiskOps™ can help healthcare organizations manage their medical device ecosystems by centralizing vulnerability tracking and monitoring remediation efforts. This approach ensures that secure update delivery mechanisms remain effective throughout a device's lifecycle.
Once secure delivery channels are in place, the next step is to develop and rigorously test update procedures to maintain device integrity in real-world conditions.
Develop and Test Update Procedures
Once you've set up secure delivery channels, the next step is creating a solid process for validating software updates. This step ensures updates not only enhance device security but also avoid introducing new weaknesses. It's about maintaining the balance between improving functionality and safeguarding device integrity.
Apply Risk-Based Patch Management
Not every patch carries the same level of urgency. A risk-based approach allows you to focus on what matters most by categorizing updates into two groups: "controlled risk" (low likelihood of causing harm) and "uncontrolled risk" (high potential for safety or data threats) [2]. This prioritization ensures critical vulnerabilities are addressed first, minimizing potential risks.
Perform Testing and Validation
Once patches are prioritized, thorough testing is key to ensuring updates don’t inadvertently create new issues. Each update should go through detailed validation before being rolled out. For high-risk medical devices, such as those classified under IEC 62304 Class C, manufacturers should aim for 100% statement coverage, branch coverage, and modified condition/decision coverage (MC/DC) as a baseline [7].
To ensure comprehensive testing, establish bidirectional traceability. This means linking requirements, design specs, code modules, and test cases so that every security requirement is fully tested, and every code change is traceable back to its original purpose. This approach not only improves reliability but also provides a clear audit trail for compliance and quality assurance.
Ensure Compliance with FDA Guidelines
Regulatory compliance is a cornerstone of maintaining secure update procedures for connected medical devices. As of March 29, 2023, Section 524B of the FD&C Act mandates cybersecurity standards for all internet-connected medical devices [1][10]. Starting October 1, 2023, the FDA began enforcing a "Refuse to Accept" policy, rejecting submissions that fail to meet these standards [10].
The FDA's guidance from February 3, 2026, emphasizes that cybersecurity is a critical part of device safety and quality management [8]. This means update processes must be integrated into your Quality Management System (QMS) and adhere to applicable standards. Non-compliance isn't just a procedural issue - it’s a prohibited act under section 301(q) of the FD&C Act [8].
Document Update Processes
Updates must be classified based on their cybersecurity impact. The FDA requires a clear distinction between changes that affect cybersecurity and those that do not [8][10]. This categorization determines the level of documentation needed for premarket or postmarket submissions.
Key documentation requirements include:
- Software Bill of Materials (SBOM): Must be provided in both machine-readable and human-readable formats, as detailed in earlier sections [8][9][10].
- Secure Product Development Framework (SPDF): A comprehensive record of processes for design, development, release, and support throughout the product lifecycle [8].
- Risk Assessments: Detailed evaluations for each modification to assess its impact on the device's cybersecurity.
- Device Labeling: Clear instructions for end-users on securely configuring and updating the device.
"The primary goal of using an SPDF is to manufacture and maintain safe and effective devices. From a security standpoint, these are also trustworthy and resilient devices."
– U.S. Food and Drug Administration [8]
To demonstrate compliance, align your processes with recognized standards like ANSI/AAMI SW96, AAMI TIR57, or IEC 81001-5-1 [8][9]. Inadequate labeling or unclear instructions can lead to your device being labeled as "misbranded." These practices should seamlessly integrate into your QMS for ongoing oversight and accountability.
Adopt Coordinated Vulnerability Disclosure (CVD) Practices
Under Section 524B, a Coordinated Vulnerability Disclosure (CVD) policy is now required for all connected medical devices [8][10]. This policy ensures collaboration with security researchers, healthcare facilities, and regulatory bodies to address vulnerabilities promptly.
Your CVD policy should include:
- Contact information on device labeling for researchers and users to report vulnerabilities.
- Clear timelines for validating, addressing, and patching reported issues.
"Healthcare facilities require clear, timely information about vulnerabilities, available patches, and recommended configurations."
– Christian Espinosa, Founder and CEO, Blue Goat Cyber [2]
Transparency and timely disclosure aren’t just best practices - they’re legal obligations with potential financial repercussions. By embedding CVD procedures into your QMS, you ensure these practices become a standard part of your design controls. This approach not only supports compliance but also fosters trust with healthcare providers relying on your devices for patient care.
Incorporating detailed documentation, risk assessments, and a robust CVD policy strengthens both regulatory adherence and device security throughout the product's lifecycle.
Use Risk Management Solutions for Lifecycle Oversight
Keeping medical devices secure throughout their lifecycle requires more than manual tracking - it calls for continuous oversight, automated processes, and integration with your Quality Management System (QMS) as outlined in IEC 62304 [11]. The sheer volume and complexity of vulnerabilities in connected devices make manual efforts impractical. Centralized risk management platforms fill this gap by automating repetitive tasks, while still relying on human oversight to ensure patient safety. These platforms seamlessly integrate with your existing QMS, providing traceability across all stages - planning, development, and postmarket surveillance - while staying aligned with global standards like IEC 62304 [11].
Automate Risk Assessments
Automation has revolutionized how healthcare organizations handle risk assessments for medical devices. Tools like Censinet RiskOps™ simplify the process by automatically validating evidence, routing issues to the right people, and generating compliance reports. Meanwhile, Censinet AI™ speeds up security questionnaires and creates automatic documentation summaries, cutting down the time needed for assessments without compromising accuracy.
Importantly, these systems don’t eliminate human judgment. Risk teams remain involved, configuring rules and reviewing processes to ensure automation supports decision-making instead of replacing it. For devices under IEC 62304 safety classifications (e.g., Class C devices, which pose risks of death or serious injury), automated tools flag high-priority vulnerabilities and route them to designated reviewers for final approval [11]. This approach ensures risks are identified faster, without sacrificing the thoroughness needed to protect patients. Additionally, platforms like Censinet RiskOps™ support real-time monitoring, offering a comprehensive view of ongoing risks.
Monitor and Benchmark Cybersecurity Performance
Once risk assessments are automated, consistent monitoring becomes the next critical step. A centralized platform offers real-time insights into your cybersecurity posture, consolidating data on vulnerabilities, patch statuses, and compliance gaps into user-friendly dashboards. For example, Censinet RiskOps™ acts as a command center, providing the oversight necessary to manage postmarket surveillance for distributed devices - an essential aspect of current FDA guidance [1].
Benchmarking capabilities add another layer of value, allowing you to compare your performance against industry standards and peer organizations. This helps prioritize improvements and demonstrate compliance to regulators. By joining collaborative risk networks and Information Sharing and Analysis Organizations (ISAOs), you can share vulnerability data with the FDA and other manufacturers, reinforcing security across the healthcare ecosystem [1]. Continuous monitoring is not just about compliance - it’s essential for safeguarding patient safety and ensuring secure updates throughout a device’s lifecycle.
Conclusion
Securing medical device software updates isn’t just a technical requirement - it’s essential for protecting patients and meeting regulatory demands. A multi-layered approach works best: start with thorough risk assessments and maintain an SBOM to keep tabs on every software component. Use protocols like TLS 1.3 and mTLS to safeguard updates, and rigorously test to catch vulnerabilities before they emerge.
Stay aligned with FDA requirements by developing strong cybersecurity plans [12]. Incorporate coordinated vulnerability disclosure (CVD) practices to streamline how vulnerabilities are reported and resolved.
Managing a growing network of connected devices often calls for automation. Tools like Censinet RiskOps™ can simplify the process by automating risk assessments, tracking performance, and managing risks from third-party vendors. These platforms aren’t replacements for human input - they’re designed to amplify it, ensuring critical issues reach the right people while maintaining the necessary oversight to keep patients safe.
FAQs
What makes a medical device software update “secure”?
A medical device software update is considered secure when it addresses vulnerabilities through verified patching methods, maintains continuous risk management, and aligns with FDA cybersecurity guidelines. This involves adopting secure development techniques, monitoring for potential threats, and promptly reporting vulnerabilities. These steps are key to safeguarding patient safety, protecting sensitive information, and ensuring the device continues to function as intended.
How do SBOMs help prevent vulnerable components from slipping into updates?
SBOMs, or Software Bills of Materials, offer a clear view of all the software components within a medical device. This transparency allows manufacturers to spot and address vulnerabilities before deploying updates. By keeping an up-to-date SBOM, manufacturers can actively monitor potential risks, prioritize patches effectively, and ensure that updates include only secure components. This not only helps meet regulatory requirements but also minimizes the chance of introducing security flaws into medical devices.
When should an update be delayed to avoid patient safety risks?
According to the FDA's guidance, updates should only be delayed if they pose a risk to patient safety or could interfere with critical operations. Before deploying patches, thorough testing and validation are crucial to ensure they don’t introduce new vulnerabilities or cause device malfunctions. A risk-based approach to patching helps prioritize updates based on the severity of the vulnerability and the importance of the device. In some cases, delays might be unavoidable, particularly if testing isn’t finished or if rolling out the update could disrupt essential clinical functions, putting patient safety at risk.
