End-of-Life Planning for Medical Device Software

Modern medical devices rely on software that eventually becomes outdated. When software reaches its end-of-life (EOL), vendors stop providing updates, bug fixes, and security patches, creating risks for patient safety, cybersecurity, and regulatory compliance. To address these challenges, the FDA now requires manufacturers to proactively plan for EOL, including submitting a Software Bill of Materials (SBOM) and maintaining risk management processes.

Key takeaways:

• EOL Risks: Unsupported software can lead to unpatched vulnerabilities, regulatory delays, and increased cybersecurity threats.
• FDA Requirements: As of October 2023, cyber device submissions must include an SBOM, EOL plans, and vulnerability management strategies.
• Governance: Effective EOL planning requires clear responsibilities, automated workflows, and ongoing lifecycle tracking and cybersecurity benchmarks.
• Risk Assessments: Use ISO 14971 standards to prioritize and address high-risk components with defined triggers for action.
• Mitigation Strategies: Options include patching, replacing, or sandboxing outdated software, aligned with regulatory timelines.
• Continuous Management: Embed EOL planning into product design and automate updates to maintain compliance and safety.

Medical Device Software Versioning

sbb-itb-535baee

Setting Up Governance and Building a Component Inventory

Managing end-of-life (EOL) processes effectively requires two key elements: a well-defined governance structure and a complete, up-to-date component inventory. Without these, EOL planning can quickly devolve into a disorganized, reactionary process - leading to FDA submission delays and exposing devices to unpatched vulnerabilities.

How to Set Up Governance for EOL Planning

Successful EOL governance involves collaboration across multiple departments, including engineering, quality, regulatory affairs, and cybersecurity. While compliance and quality teams often oversee lifecycle tracking, relying on manual processes can stretch this work into weeks or even months.

To streamline the process, assign clear responsibilities for every EOL-related task using a RACI framework (Responsible, Accountable, Consulted, Informed). The framework ensures that every step - from identifying components to regulatory disclosures - is handled efficiently and in alignment with FDA requirements.

One major pitfall in governance is the overreliance on spreadsheets. As Daniel Bardenstein from Manifest Cyber explains:

"Without a systematic way to aggregate and monitor lifecycle data, manufacturers face FDA delays, avoidable cybersecurity exposures, and ultimately risks to patient safety." ^[2]

The solution lies in adopting automated and auditable workflows. These workflows ensure lifecycle data remains current, accurate, and defensible during FDA reviews, reducing the risks tied to outdated manual tracking methods.

How to Build and Maintain a Component Inventory

When submitting a cybersecurity-related device to the FDA, manufacturers must include a Software Bill of Materials (SBOM) in a machine-readable format, such as SPDX or CycloneDX, that complies with NTIA standards.

Interestingly, at least 75% of the software in a typical medical device originates from external sources, like open-source packages, cloud frameworks, or vendor SDKs ^[4]. This makes automation tools indispensable. Software Composition Analysis (SCA) tools - such as Syft, FOSSA, or Black Duck - can scan codebases to map out full dependency trees, including transitive dependencies.

Under the QMSR (effective February 2, 2026), SBOM management must be integrated into design controls, supplier controls, and change control processes. Any updates or replacements to components should trigger a formal change control process and an updated SBOM ^[3][4].

Maintaining an automated, up-to-date inventory helps teams track lifecycle changes and prepare for risk assessments more efficiently.

Tracking Lifecycle Status and EOL Notifications

Keeping your inventory updated is the backbone of effective EOL management. On average, teams spend 8 hours per SBOM manually verifying lifecycle details, with some companies dedicating as much as two weeks per quarter to maintaining outdated spreadsheets ^[5].

The FDA's 2025 Cybersecurity Guidance requires manufacturers to disclose the level of support for each component - whether it’s actively maintained, legacy, or abandoned - as part of SBOM submissions ^[2]. This applies to proprietary software, open-source libraries, and third-party integrations. Tracking these categories presents unique challenges:

• Proprietary Software: Vendors often use vague language in contracts regarding support timelines.
• Open-Source Libraries: Many projects lack official EOL policies, requiring teams to analyze GitHub activity or release schedules.
• Third-Party Integrations: Cooperation from integrators may require direct outreach.

Platforms like Censinet RiskOps™ simplify this process by providing continuous monitoring. These tools help manufacturers maintain a live risk inventory that updates as vendor contracts evolve or open-source projects slow down ^[2][6]. Pairing such platforms with resources like the National Vulnerability Database (NVD) and CISA's Known Exploited Vulnerabilities (KEV) catalog ensures real-time visibility into emerging risks affecting components already deployed in the field.

Running Risk Assessments and Setting EOL Triggers

Once your component inventory is up-to-date and your governance framework is in place, the next step is to pinpoint high-risk components and establish clear response triggers. This step builds on the foundation of your inventory and governance efforts.

How to Prioritize EOL-Relevant Components

After setting up your inventory, it's essential to prioritize components based on their risk level to allocate resources wisely. For example, a UI framework without network access carries far less risk than an OS-level library that directly interacts with patient data or device control systems. A tiered classification system can help:

For context, a connected medical device like an infusion pump may include anywhere from 50 to 200 third-party open-source components ^[8]. By tiering these components, you can focus your resources where they’re needed most.

Running Risk Assessments Aligned with ISO 14971 and FDA Guidance

With a complete inventory in hand, risk assessments help identify areas that demand immediate attention. ISO 14971 requires treating cybersecurity risks as sources of potential hazards within your broader risk management process. Each risk, from vulnerability detection to potential patient harm, must be documented.

The FDA advises against relying solely on probability-based scoring for cybersecurity risks. Instead, an exploitability-focused approach should be used, evaluating factors like attack vector, complexity, required privileges, and potential impact ^[7]. While CVSS v4.0 base scores provide a solid starting point, they should be adjusted to reflect the specific clinical context of your device.

To address vulnerabilities in EOL components, Vulnerability Exploitability eXchange (VEX) documents can be invaluable. These allow you to explain why a known vulnerability might not be exploitable in your device’s specific configuration. All of this must integrate into your Quality Management System (QMS) under the updated QMSR, effective February 2, 2026. Security risks must also be linked to the ISO 14971 safety risk file ^[7][1].

Defining EOL Triggers

A robust risk evaluation process should define clear triggers that initiate predefined responses. These triggers ensure your team is ready to act when certain conditions arise - whether that’s creating a migration plan, implementing compensating controls, or submitting regulatory disclosures.

Triggers may include vendor EOL announcements, the emergence of critical vulnerabilities (CVSS 9.0–10.0), active exploits, or the end of support for an open-source library ^[7][1]. Each trigger should align with a specific response timeline and regulatory pathway:

When immediate patching isn’t possible - due to regulatory timelines or technical hurdles - temporary measures like network segmentation or firewall rules can help reduce exposure while a long-term fix is underway ^[8].

To stay ahead, automate monthly CVE triage against your SBOM using tools like NVD feeds, the CISA KEV catalog, and ISAC feeds ^[7]. Platforms like Censinet RiskOps™ can streamline this process further by automating vulnerability triage and centralizing risk management throughout your device lifecycle.

Implementing EOL Strategies and Mitigation Plans

Once you've identified risks and triggers, it's time to focus on execution. This involves selecting the right approach for each component, ensuring safe decommissioning, and keeping your healthcare delivery organization (HDO) partners in the loop throughout the process.

Planning a Migration or Replacement

Each EOL component requires a specific response. These strategies must align with FDA and ISO 14971 standards to ensure patient safety and meet regulatory requirements. Start with a gap analysis to identify differences between the legacy component and its replacement, focusing on how these affect clinical performance or safety.

After choosing a strategy, test it in a controlled environment to ensure it meets safety and performance standards before deploying it live. Update the ISO 14971 risk management file to document how the migration addresses EOL-related risks.

For implementation, consider a phased migration. Start with pilot sites to identify and address unexpected issues before rolling out changes broadly. During this process, ensure patient data and device logs are either accurately migrated or securely archived. Document all actions in the Design History File (DHF) to comply with FDA QMSR requirements during postmarket audits.

Once your migration strategy is in place, the next step is secure decommissioning.

How to Securely Decommission Unsupported Devices

Decommissioning a device involves more than just turning it off. Improper handling of unsanitized media can lead to data breaches and HIPAA violations. Follow NIST Special Publication 800-88 (Guidelines for Media Sanitization) to manage hardware and software storage media appropriately. This includes methods like clearing, purging, or physically destroying data, depending on its sensitivity.

In addition to sanitizing data, maintain a detailed record of what was removed, how data was handled, and who authorized the actions. This documentation is essential for FDA audits and demonstrates the effectiveness of your postmarket cybersecurity program, as required under Section 524B of the FD&C Act.

Coordinating EOL Activities with HDOs

After securely decommissioning devices, work closely with HDO stakeholders to integrate your plans. HDOs need sufficient time - typically 12–24 months - to align budgets, manage procurement, and train clinical staff.

Your communication should clearly differentiate between End of Support (no technical assistance or patches) and End of Life (complete manufacturer withdrawal). Use the Manufacturer Disclosure Statement for Medical Device Security (MDS2) to standardize how you communicate changes in support status and security features.

For devices that remain in use after support ends, provide detailed containment recommendations. This might include network segmentation rules, disabling certain services, or blocking specific ports. Include a written residual risk assessment to outline any remaining cybersecurity and safety risks. These steps help meet FDA postmarket cybersecurity requirements and emphasize the shared responsibility model: manufacturers manage the technical roadmap, while HDOs handle local implementation. Tools like Censinet RiskOps™ can simplify coordination by centralizing risk documentation and improving communication between manufacturers and HDOs throughout the EOL process.

Building a Continuous EOL Lifecycle Management Process

End-of-Life (EOL) planning isn't a one-and-done task - it’s an ongoing effort. Once you’ve established migration strategies and decommissioning procedures, the challenge lies in ensuring these processes are consistently applied across your entire portfolio. By integrating EOL planning into device development from the start, you can tackle future risks head-on.

How to Embed EOL Planning into Device Lifecycle Management

To seamlessly incorporate EOL planning, it’s essential to start early - right at the design phase. This involves scheduling regular lifecycle reviews for all devices and embedding EOL checkpoints during the design process. For example, evaluating component support windows before a product even ships can save significant headaches down the road.

Here’s how to make it happen:

• Collect detailed lifecycle data: Gather comprehensive information about the lifecycle of every component in your devices.
• Enrich SBOMs with EOL context: Add EOL-related details to your Software Bill of Materials (SBOMs), ensuring they reflect the latest vendor commitments and the health of open-source projects.
• Keep data updated: Continuously monitor vendor updates or changes in open-source project activity, like update frequency and contributor engagement ^[2][5].

For contract-based components, expiration dates can serve as clear EOL triggers. For open-source elements, metrics such as release recency and contributor activity help estimate their lifecycle status ^[5].

A smart way to streamline this process is through the "Single Data Entry" principle. Once EOL information for a component is entered, it automatically updates across all SBOMs - past, present, and future - ensuring consistency across your portfolio ^[5].

With this structure in place, the next step is defining metrics to measure how well your EOL program is performing.

Metrics for Measuring EOL Program Effectiveness

Metrics are essential for gauging whether your EOL program delivers results. Instead of tracking everything, focus on a few indicators that truly matter:

"The burden of proof lies with manufacturers, forcing teams to justify their criteria for determining EOL/EOS." - Medcrypt ^[5]

This becomes even more critical with the FDA’s 2025 Cybersecurity Guidance, which requires manufacturers to include EOL details in their SBOM submissions ^[2]. Tracking these metrics not only ensures compliance but also strengthens your case during audits.

Using Automation to Manage EOL at Scale

Automation transforms lifecycle management from a reactive scramble to a predictable, efficient process. It can shrink the time spent tracking lifecycles from weeks to mere seconds ^[2].

"Instead of a last-minute scramble, lifecycle management becomes an automated, monitored, and defensible part of your daily workflow." - Daniel Bardenstein, Manifest Cyber ^[2]

Platforms like Censinet RiskOps™ make this shift possible. They centralize risk documentation, enable ongoing third-party risk assessments, and maintain audit-ready records across your portfolio. Instead of relying on static snapshots, these tools create a living risk inventory that updates automatically as contracts change or open-source projects evolve ^[2].

Conclusion: Key Steps for Effective EOL Planning

Effective end-of-life (EOL) planning hinges on strong governance, detailed insights from a comprehensive Software Bill of Materials (SBOM), and proactive risk management. It’s not just a step in the pre-submission process - it’s an ongoing commitment to device safety and regulatory compliance. As Christian Espinosa, Founder & CEO of Blue Goat Cyber, aptly states:

"Medical device cybersecurity is not a documentation exercise you complete before submission. It is a full lifecycle commitment that starts at the first design decision and runs through decommissioning." ^[9]

The backbone of successful EOL planning lies in clear governance and enhanced visibility. An enriched SBOM provides the granular component-level transparency needed to pinpoint EOL risks before they jeopardize patient safety. With over half (53%) of networked medical devices containing at least one known critical vulnerability ^[9], overlooking this critical inventory can result in significant exposure. Addressing vulnerabilities early also ensures alignment with required remediation timelines.

Risk assessments guided by ISO 14971 and FDA recommendations help prioritize the most pressing cybersecurity challenges. According to IMDRF guidance, manufacturers should notify healthcare providers at least two years before any end-of-support milestone ^[9].

But the responsibility doesn’t end there. As highlighted in the IMDRF Final Guidance:

"Cybersecurity obligations do not expire when the product line does." ^[9]

To maintain a defensible program and protect patients, EOL planning should be integrated into your Quality Management System (QMS). Automating lifecycle tracking and keeping audit-ready records are essential steps. Leveraging advanced risk management tools like Censinet RiskOps™ can simplify these processes and help ensure continuous compliance throughout the software lifecycle.

FAQs

What should an EOL plan include for FDA submissions?

When preparing FDA submissions, it's essential to include an end-of-life (EOL) plan as part of your Software Bill of Materials (SBOM). This step is critical for ensuring both compliance and patient safety.

Your EOL plan should clearly document the support status of all software components. This includes details like:

• EOL/EOS dates: When each software component will no longer be supported.
• Support renewability: Whether support can be extended beyond the initial period.
• Risk management: Strategies for handling components with unknown EOL data.

Make sure to submit these lifecycle details in machine-readable formats such as CycloneDX or SPDX, as these formats are preferred for regulatory purposes.

Using tools like Censinet RiskOps can simplify this process by helping you maintain a regulator-ready inventory of software components, ensuring you're always prepared for compliance requirements.

How do I decide when an EOL component needs immediate action?

When deciding if an end-of-life component needs urgent attention, it's important to carry out a thorough risk assessment. A framework like ISO 14971 can be particularly helpful in evaluating risks, especially those tied to security and patient safety.

Here are key scenarios that demand immediate action:

• The component introduces a system vulnerability.
• It lacks essential security measures, such as encryption.
• It’s listed in the CISA Known Exploited Vulnerabilities catalog.

To stay ahead, implement continuous monitoring and keep a close eye on end-of-support dates. This proactive approach ensures you can plan replacements before issues arise.

What should I do if I can’t patch or replace an unsupported component quickly?

If replacing or patching an unsupported component isn’t an immediate option, there are ways to minimize risks and prioritize patient safety. Consider these strategies:

• Network segmentation: Separate vulnerable devices from the main network to limit exposure.
• Virtual patching: Use firewall rules or intrusion prevention systems to block potential threats.
• AI-based anomaly detection: Monitor for unusual or unauthorized activity that could indicate a security breach.

Make sure to document all these measures and perform formal risk assessments. Tools like Censinet RiskOps can help you stay compliant and manage risks more effectively.

Related Blog Posts

• FDA Cybersecurity Labeling: What HDOs Need to Know