Medical Device End of Support: What Your Service Plan Should Record

An OEM letter says that a system your hospital still runs is reaching End of Support (EOS). The date alone does not establish whether the device remains clinically usable: support status and clinical function need separate checks. Your service plan should identify who can still supply parts and software, who manages the remaining risk, and what evidence supports either continued use or retirement.

This checklist turns the letter into that plan. It does not give repair procedures for unsupported equipment, set universal service limits, or predict EOS dates for any product line. Every date in your plan has to come from your own OEM letters and contracts.

One distinction runs through everything below: most lifecycle documents are guidance, not law. Know which kind of document you are relying on before you cite it in a risk decision.

Lifecycle vocabulary is not uniform. HIC-MaLTS opens its terminology section by warning that one organization's "end of support" might be another organization's "end of life." Decode the letter against published definitions before you plan anything else. HIC-MaLTS terminology.

IMDRF N70 describes EOS as the point where responsibility for a device's cybersecurity primarily transfers to the healthcare provider, while noting that the manufacturer may retain certain post-market obligations depending on the jurisdiction. N60's earlier conceptual framework recommends decommissioning devices at cybersecurity EOS, but its healthcare-provider recommendations also address continued use when decommissioning would disrupt continuity of care: the provider assumes security management and risk. N70 expands the recommendations for providers that continue using devices past EOS. Neither document makes EOS an automatic legal retirement date. General maintenance duties remain with the hospital. IMDRF N60, section 6.6.2. IMDRF N70, sections 4 and 9.

Next, establish what actually lost support. HIC-MaLTS says EOS can mean the technology itself entering its planned EOS stage, an individual component (including an upstream software component) becoming unsupported, or the technology entering EOS for another reason, and that documentation should make clear which applies and why. Its Responsibility Transfer Framework separates three use cases that call for different plans:

• Hardware supported, software unsupported. The common example is an embedded operating system that its developer no longer patches; HIC-MaLTS cites Windows 7. HSCC notes that such a device could be considered a legacy technology even inside its originally communicated support period, because it may no longer be capable of being reasonably protected against current threats. The plan centers on vulnerability management and compensating controls.

• Hardware unsupported, software still supported. The manufacturer ends support for the system while software patches remain available through other parties. The plan centers on parts, service capability, and repair evidence.

• Both unsupported. Both workstreams apply, and the revisit decision described below carries more weight.

Record the use case, the date and source of the notice, and its exact scope (models, software versions, components) on the asset records in your CMMS before anyone acts on it. Check one dependency that HSCC flags specifically: a device may keep working clinically on its EOS date while a cloud service or other connected system it relies on stops working on that date.

Siemens Healthineers' public End of Support hub links pages for CT, MR, angiography, fluoroscopy, mammography, mobile X-ray, molecular imaging, radiography, mobile C-arms, and ultrasound. Its MR page says that owners of systems approaching or at EOS should expect that the manufacturer "can no longer guarantee spare parts" and warns that unavailable parts may lengthen downtime. It presents replacement as a way to maintain cybersecurity and improve clinical workflow, then promotes new MAGNETOM and refurbished ecoline systems. Neither page gives model-specific EOS dates. Treat this as an example of OEM communication, then obtain the dates and coverage for the exact model and version in your own fleet. Siemens MR end-of-support page. Siemens end-of-support hub.

The parts warning and replacement recommendation call for separate decisions. Confirm which parts and services the OEM will still supply, then compare the offered replacement with a documented continued-service plan. A third-party service offer needs the same scrutiny: parts availability alone does not establish cybersecurity support, qualified maintenance, or acceptable clinical risk. Judge the evidence for your affected fleet rather than treating either a replacement offer or a service offer as the decision itself.

Regulator and sector documents describe what a complete notice package should contain. FDA's premarket cybersecurity guidance, finalized on June 27, 2025 and revised on February 3, 2026 to align with the Quality Management System Regulation (QMSR), recommends that labeling include information, if known or anticipated, on cybersecurity end of support and end of life for the device and its components. It states that at end of support a manufacturer "may no longer be able to reasonably provide security patches or software updates," and that if the device remains in service, the manufacturer should have "a pre-established and pre-communicated process for transferring the risks," highlighting that cybersecurity risks for end users can be expected to increase over time. The same labeling list recommends a software bill of materials (SBOM), a list of network ports and other interfaces, secure-configuration information, and information on securely decommissioning the device by sanitizing sensitive data. These are recommendations to manufacturers, not obligations on your hospital, but they are a fair benchmark for what to ask for. FDA cybersecurity guidance, section VI.A.

HIC-MaLTS recommends that manufacturers communicate approaching EOGS, EOS, and EOL milestones as soon as they are announced, preferably three years ahead; make those dates available to customers; and include them in technical documentation. It recommends that contracts specify support timeframes, and that EOS communications include the steps hospitals should take to prepare, such as contact changes or license transfer. IMDRF N70 adds that by EOS the manufacturer should tell the provider which additional responsibilities it will assume, what support is available beyond the EOS date, the upgrade path, and how to decommission the device.

Before the support relationship ends, ask the OEM to confirm in writing:

• Milestone dates for each affected model and software version: EOL, any EOGS, EOS, and separate dates for parts, field service, remote service, and security patches if they differ.

• Limited-support scope: which parts, services, and software updates remain available until EOS, on what terms, and whether any support continues afterward.

• Final parts and consumables orders: whether the OEM will accept final orders before stock is withdrawn, and by what deadline.

• Final authorized software baseline: the last authorized software and firmware versions and any remaining authorized updates, so that whoever services the device can restore it to, or hold it at, that baseline.

• Security documentation: an SBOM with component support status, the network ports and IP addresses the device needs, and recommended compensating controls. N70 lists port and IP information and product security documentation, including the SBOM, among what manufacturers should provide during the transfer of responsibility.

• Servicing information: key performance and safety specifications, recommended maintenance activities and schedule, routine tests with acceptance criteria, and error-code descriptions. FDA's remanufacturing guidance recommends that OEM labeling for reusable devices include this information.

• Licenses and service tools: whether service software, keys, and licenses stay usable after EOS, and whether they can be transferred to a third-party servicer.

• Decommissioning and data-sanitization information for the day the device is retired.

If the OEM declines a request, record the refusal and its date. A documented gap is itself planning evidence: it shows which risks you could not hand back.

An EOS letter is an inventory event, not a single work order. CMS's 2013 interpretive letter describes a well-designed inventory as including a unique identification number, manufacturer, model, serial number, location, owning department, and service provider, with critical equipment readily identifiable. The Joint Commission review tool effective March 1, 2024 similarly lists an all-equipment inventory for deemed-status hospitals and identification of high-risk equipment. These record categories help you scope an EOS notice; check the current survey guidance and your accreditation program before using the dated documents as a requirements checklist. See our guide to CMMS inventory and unique identification.

For each affected model family, record:

• Every unit: asset ID, serial number, location, owning department, and installed software version. HIC-MaLTS recommends adding MDS2 and SBOM data to inventory records, and N70 recommends a robust inventory management system for any device kept past EOS.

• Clinical role: whether units are high-risk or life-support equipment, whether they are the only source of a service, and what happens to care if one fails. HSCC's clinical factors include effects on the services offered, the number of patients who can be served, and workflow in integrated systems such as radiology, telemetry, and patient monitoring.

• Connectivity: network connections, remote-service links, required ports, and any cloud dependency.

• Service history: corrective work orders, recurring faults, and which assemblies have been replaced. Use your own records to decide which parts matter; this checklist does not supply failure rates.

• Current service arrangement: the provider of record and when the contract ends, since both may change when the OEM exits.

Then give the result to capital planning in the format it already uses. HSCC frames the core trade-off plainly: the budget and resources needed to replace a technology have to be weighed against those needed to keep using it past EOS. It also recommends a standard decommissioning checklist and developing more than one EOS option rather than a single plan.

For US Medicare-certified hospitals, OEM support ending does not remove the maintenance obligation. The current Condition of Participation at 42 CFR 482.41(d)(2) says that facilities, supplies, and equipment must be maintained to an acceptable level of safety and quality. CMS's S&C 14-07-Hospital letter, issued in December 2013, explains the requirement under its earlier paragraph number, 482.41(c)(2), Tag A-0724. The letter is dated interpretive guidance rather than the current State Operations Manual. Its following points remain useful planning questions; verify their current wording and applicability before treating them as survey requirements: 42 CFR 482.41. CMS S&C 14-07-Hospital.

• Inspection and testing. The 2013 letter calls for performance and safety inspection and testing before initial use and after major repairs or upgrades, regardless of the service provider. Plan the required checks and retain the results; see when a repair counts as major.

• Qualified people, in-house or contracted. The letter permits maintenance by hospital personnel, contracted services, or both, and calls for qualification records and evidence of how the hospital assures contractor competence. File this evidence for the provider that will maintain the unsupported fleet.

• Manufacturer recommendations and AEM limits. The letter describes manufacturer-recommended activities and schedules as the maintenance basis. Its Alternate Equipment Management (AEM) provisions allow some changes to activities and frequencies, but exclude specified cases, including imaging and radiologic equipment, medical lasers, and new equipment without sufficient maintenance history. Confirm the applicable exclusions before changing an unsupported device's maintenance program.

An EOS notice is not evidence that equipment qualifies for AEM. For an affected imaging fleet, secure the manufacturer's maintenance activities and schedules while they remain available, and have the responsible team confirm the applicable maintenance basis. That basis will matter whichever provider takes over. Our comparison of AEM and manufacturer maintenance covers documentation where an alternative program is allowed.

The Joint Commission review tool effective March 1, 2024 provides another dated record benchmark. Its EC.02.04.01 checklist lists an inventory of all medical equipment for deemed-status hospitals, identification of high-risk equipment, and maintenance, inspection, and testing activities and frequencies. Its EC.02.04.03 checklist includes high-risk equipment activities and a 100% completion note. These are references from that tool, not a statement of current hospital standard numbering or a complete current accreditation checklist. Use your program's current manual to confirm requirements; keep the inventory, maintenance basis, and completion evidence together when planning continued service. Joint Commission dated review tool.

So a work order that says scheduled maintenance was not done because the OEM no longer supplies parts records a missed activity, not an exemption. If a device can no longer be maintained the way your program requires, the defensible record is the decision that follows: a qualified alternative source, a documented change where the rules allow one, or removal from service. Our guide to service record requirements covers what each work order must contain.

After EOS, the realistic options are whatever continued support the manufacturer offers, an independent service organization (ISO), your own staff, or a combination. N70 suggests that providers ask whether additional support is available, for example through extended contracts or third-party support. HIC-MaLTS notes that qualified third-party servicers are often familiar with legacy equipment because they have serviced it for other hospitals. Compare the paths on the same questions:

Whichever path you choose, FDA classifies the activity, not the organization. Its May 2024 final guidance defines servicing as repair or maintenance "for purposes of returning it to the safety and performance specifications established by the OEM and to meet its original intended use," and remanufacturing as an act that "significantly changes the finished device's performance or safety specifications, or intended use." FDA states that, irrespective of whether an entity calls itself a servicer or a remanufacturer, it focuses on the specific activities performed on a particular device. FDA remanufacturing guidance.

EOS makes the line easier to cross by accident. The guidance warns that unintentional remanufacturing can occur when entities do not have the instructions needed to return a device to its original specifications, which is exactly the documentation that becomes hard to get once the OEM leaves. Substitute parts are the next risk: one of FDA's examples is an MR gradient coil replaced with one of larger peak gradient strength, which FDA classifies as remanufacturing because the change significantly alters imaging performance specifications. Our article on replacement parts and remanufacturing risk covers how to document part equivalence.

Software is the third risk, and the one most specific to EOS. FDA lists software activities that are likely not remanufacturing, including implementing OEM-authorized updates, reinstalling OEM software to restore original specifications, reverting to a previous configuration, installing OEM-authorized cybersecurity updates, assessing for malware, turning connectivity features on or off consistent with the OEM's intended use, and managing user accounts. FDA considers other software changes likely to be remanufacturing, and says an entity that believes a particular change does not significantly alter performance or safety specifications should document that decision. After EOS, when no further OEM-authorized updates arrive, that is the boundary to check before anyone patches an embedded operating system on their own. HIC-MaLTS asks the same question from the hospital side: is the organization prepared to take on applicable regulatory requirements if it patches a device without the manufacturer's support? See software updates and remanufacturing and servicing vs remanufacturing.

Clinical function and security support come apart at EOS. HIC-MaLTS notes that a technology does not stop functioning clinically on its EOS date, while FDA's guidance says cybersecurity risks for end users can be expected to increase over time after end of support. If your organization accepts the risk of using a device past EOS, N70 recommends that it: IMDRF N70, section 9.2.2.

• ensure a strong, qualified, adequately resourced cybersecurity program with senior-leadership endorsement;

• maintain a robust inventory management system, automated where possible;

• include the legacy device in ongoing organizational risk management;

• proactively monitor trusted sources, including information sharing and analysis organizations, computer emergency response teams, regulators, and vulnerability databases that cover third-party components;

• enhance countermeasures, including network segmentation, user access roles, security testing, network monitoring, and disconnection from the network;

• periodically evaluate alternative products and revisit the decision to operate the device past EOS.

Two cautions shape how you apply those countermeasures. First, N70 says to consider how segmentation and firewalls affect device function, and warns that controlling a legacy device's vulnerabilities this way adds administrative burden, can affect patient care, and reduces the integration benefits the device was designed to deliver. After any network change, confirm that required clinical data flows still work and record the result. Second, keep compensating controls outside the device unless the change is one FDA lists as likely not remanufacturing, such as turning off a connectivity feature consistent with intended use or managing user accounts. Segmentation, access rules, and monitoring act on the network around the device; ad hoc changes to the device's own software configuration may not stay on the servicing side of the line.

HIC-MaLTS supplies the technical questions for the risk assessment. Is the device exposed to any vulnerability on CISA's Known Exploited Vulnerabilities list, or to other known vulnerabilities from vendor advisories, ICS-CERT, or the National Vulnerability Database? Are they exploitable in your environment, and locally or remotely? Could a successful exploit spread beyond the device, and how would you detect it? Can compensating controls mitigate the risk? Where known risks cannot be reasonably mitigated, HSCC says the organization must assess the risk level and decide whether that risk is worth accepting. The FDA-contracted MITRE paper, which FDA's cybersecurity page lists as a legacy-device resource but which is not FDA policy, adds a point for outsourced arrangements: when a service provider implements patches or mitigations, the hospital remains responsible for managing the overall risk. MITRE legacy-device report, section 3.3. FDA cybersecurity resources.

Neither cited EOS framework specifies a fixed interval for the continued-use decision. N70 asks providers to revisit the decision periodically; HIC-MaLTS asks for reassessment as new vulnerabilities are discovered, new network architectures are implemented, or other changes occur in the hospital environment. Put a scheduled review date in your equipment management plan, and define event triggers that force an earlier review:

• a new vulnerability affecting the device or its software components, especially a Known Exploited Vulnerabilities listing;

• a network change, a new connection, or a device moved outside the network zone its controls were designed for;

• loss of a parts source, or a repair that could not restore the OEM's specifications;

• a unit that fails inspection and testing after a major repair;

• a change in the manufacturer's support status or terms;

• a replacement that becomes available or funded, or a change in the capital plan.

Keep the decision trail linked to the asset record so it remains retrievable after staff or service-provider changes. The cited CMS letter and Joint Commission tool identify inventory and maintenance records for review; lifecycle guidance also supports documenting the continued-use risk decision. Use the following planning file for each affected model family, and confirm which records your current survey and accreditation program requires:

Apply the record to the exact model and installed version named in the notice. For an affected MR fleet, Siemens' public MR page can prompt questions about parts and cybersecurity, but it cannot supply an EOS date or identify which of your units is affected. File the model-specific OEM letter, match each unit to its scope, record the available service and software support separately, and identify who will approve the continued-use decision. Replacement products advertised on that page are alternatives, not evidence that those products themselves have reached EOS. If the specifications, service information, or security assessment remain incomplete, record the unresolved item and its owner before approving the plan. HIC-MaLTS recommends considering replacement when outreach and technical investigation cannot produce enough information to manage the risk.

The map links each lifecycle stage to an action and an escalation point. It does not set universal limits: your risk thresholds belong in your equipment management and security policies. Whatever its support status, a device that fails its required inspection and testing should not go back into clinical use.

flowchart TD
    A["OEM notice received"] --> B["Decode stage and exact model, version, and component scope"]
    B --> C["Get dates, support terms, and service information in writing"]
    C --> D["Size fleet exposure and assess clinical and cybersecurity risks"]
    D --> E["Select and qualify service path and compensating controls"]
    E --> F{"Can the plan restore OEM specifications and intended use?"}
    F -->|"No"| G["Hold from clinical use and escalate the change or replacement decision"]
    G --> H{"Is a qualified alternative service plan feasible?"}
    H -->|"Yes"| E
    H -->|"No"| N["Plan replacement and controlled decommissioning"]
    F -->|"Yes"| I["Complete required inspection, testing, and clinical data-flow checks"]
    I --> J{"Do the checks pass?"}
    J -->|"No"| G
    J -->|"Yes"| K{"Is remaining risk acceptable to the responsible organization?"}
    K -->|"No"| G
    K -->|"Yes"| L["Document release, owner, next review date, and event triggers"]
    L --> M["Review on schedule or when conditions change"]
    M --> D

End of support transfers risk. It does not end the hospital's duties, and on its own it does not end the device's useful life. A dated, sourced record of the notice, the service path, the controls, and each revisit decision is what lets you defend either keeping the device or retiring it.