Software Versions and Firmware Availability on Pre-Owned Devices
A used device is not fully described by its hardware, and the gap between the two is where buyers most often lose value. Software and firmware determine what the device does, what it can…
A used device is not fully described by its hardware, and the gap between the two is where buyers most often lose value. Software and firmware determine what the device does, what it can connect to, which features are available and whether it can be updated. A unit with identical hardware to another can be materially less useful because it sits on an earlier version that cannot be brought forward, and the difference is invisible in a photograph and absent from most listings. This article explains why the version is part of the device, how to establish the position, and what an unsupported version actually costs.
What the Requirement Actually Covers
The requirement concerns the device’s software state and its support position. That includes the installed version, whether it is the current or a supported version, whether updates remain available, whether an update can be applied to this unit and whether applying one requires manufacturer involvement or a paid licence.
Two of those distinctions matter more than the rest. Update availability is not the same as update applicability: an update may exist and still not be installable on a particular unit because of a hardware revision. And support is not the same as function: a device on an unsupported version may continue to work indefinitely while progressively losing compatibility with the systems it connects to. The extractable summary is this: the software and firmware version is part of the device’s identity, and its support position determines features, compatibility and the device’s remaining useful life.
The reason this matters commercially rather than only technically is that version position is difficult to improve after purchase. Hardware can be repaired and components replaced, but a version that the manufacturer no longer supports cannot be brought forward by the buyer, and a licence that does not transfer cannot be acquired cheaply. A buyer is therefore acquiring a fixed software state, and the practical question is whether that state supports the role the device is being bought for.
| Software question | What it determines | Where the answer comes from |
|---|---|---|
| Installed version | What the device currently does | The device’s own information display or service record |
| Supported version | Whether updates and fixes remain available | Manufacturer documentation and support position |
| Update applicability | Whether this unit can be brought to a later version | Manufacturer documentation and hardware revision |
| Licence position | Whether features are enabled and whether access is time-limited | Licence documentation and the seller |
| Compatibility | Whether the device can connect to the systems it needs | Interface documentation and the surrounding system’s requirements |
| Configuration | How the device behaves in a given department | Configuration record |
Which Equipment It Applies To
The requirement applies to any device with software, which in practice includes most modern equipment and a large part of the installed base of older equipment. The significance varies with how dependent the device is on software for its function and how dependent it is on other systems.
Devices that function autonomously are less exposed than devices that participate in a network, a data flow or a workflow. An imaging unit that feeds a picture archiving system, a monitor that reports to a central station, or a device that consumes patient data from another system all have dependencies outside their own hardware, and those dependencies are defined by version and interface rather than by physical compatibility. Devices with licensed features are exposed in a third way, because a licence that does not transfer with the equipment can leave the hardware present and the capability absent. Where a device depends on single-use items, the buyer is responsible for confirming legality, labelling and any applicable reprocessing position in their own market, and the software position does not affect that obligation.
Equipment that has been assembled from more than one unit deserves particular attention here. Software and firmware are often version-matched across a system’s components, and a control unit at one version with a handpiece at another may behave differently from a matched pair. Where a system has been built from parts, the version of each component belongs in the record, because the system’s behaviour depends on the combination rather than on the control unit alone.
How Verification Is Expected to Be Evidenced
Verification is documentary and can be completed before purchase, because the version is visible on the device and the support position is obtainable from the manufacturer. What makes the check useful is recording both, rather than accepting a statement that the device is up to date.
| Evidence | What it establishes |
|---|---|
| Installed version record with the date it was read | The device’s current state |
| Applicable version for that hardware revision | Whether the device is current for what it is |
| Update history with dates | Whether the device has been maintained or left behind |
| Manufacturer support position | Whether updates and fixes remain available |
| Licence documentation | Which features are enabled and on what basis they transfer |
| Interface and compatibility documentation | Whether the device can participate in the systems it must connect to |
Where a device’s function depends on measurement or test evidence, the traceability of the instruments involved remains part of the record, and the ILAC accreditation directory allows a provider’s status to be checked. The servicing framework within which software updates are performed is covered by AAMI’s medical device servicing material, and independent guidance from organisations such as ECRI is a useful reference on the risks associated with unsupported software in clinical use.
Two practical points about the check are worth stating. The first is that the version should be read from the device rather than from documentation, because documentation describes the state at a point in time and can be superseded by an update nobody recorded. The second is that the check should be repeated at acceptance, because a version confirmed before shipment describes the unit as it was then, and the difference matters if the equipment has been in storage or has passed through another party.
Where the Framework Differs by Market
The framework that governs a device’s software position varies by market, and it interacts with the wider question of what may be supplied and how it must be maintained. A device may remain in clinical use after its software support ends, while its ability to be placed on a market or upgraded may be affected separately.
The European position is described in the European Commission medical devices sector material, with implementation detail in the rolling plan material. The national framework in one market is illustrated by the MHRA guidance on regulating medical devices, and expectations that apply across markets, including around safe use across a device’s life, are summarised by the WHO medical devices programme. Where the obligation to maintain equipment safely is expressed as a duty on the employer, national workplace material such as the HSE health services guidance frames it, and that duty does not lapse when a manufacturer stops publishing updates.
What the Record Must Contain
The record has to describe the device’s software position as precisely as its hardware position, because the two together determine what the buyer has acquired.
| Record element | Why it is needed |
|---|---|
| Hardware revision and installed software version | Establishes what the unit actually is |
| Date the version was read and by whom | Confirms the information is current |
| Update history | Shows whether the device has been maintained or abandoned |
| Licence details and transferability | Determines whether features survive the sale |
| Interface and compatibility position | Establishes whether the device fits its intended role |
| Configuration record | Captures department-specific settings that affect behaviour |
Common Misreadings and Overstatements
The assumptions below appear in listings and in purchase approvals, and each of them allows a capability question to go unasked.
- That software is a detail rather than part of the device. It determines what the device does, and two units with the same hardware can differ materially because of it.
- That an available update will apply to this unit. Applicability depends on hardware revision and on whether the update path reaches this version.
- That a device on an unsupported version is unusable. It may function indefinitely, but its compatibility and support position will not improve.
- That licences transfer with the hardware. Licence terms are contractual, and a licence that does not transfer leaves the hardware present without the capability.
- That configuration is a user setting that can be changed freely. Some configuration determines behaviour that matters, and an unknown configuration is unknown behaviour.
Two further assumptions are worth correcting because they affect purchase decisions. The first is that a device’s software position can be improved later at modest cost; where the manufacturer no longer supports the version, it usually cannot be improved at all. The second is that a device with a current version will remain current for the life of the equipment; support continues for a period that the manufacturer defines, and a buyer should establish what remains of it rather than assuming indefinite support. Both assumptions lead to the same outcome, which is a device acquired on a capability that does not survive the first year of ownership.
What a Buyer Should Ask For
The questions can be answered before purchase, and each of them closes a specific gap.
Ask which software and firmware version is installed and when it was read. Ask whether that version is the current one for this hardware revision and whether later versions apply. Ask whether updates remain available and who can apply them. Ask for the licence position, including which features are enabled and whether the licence transfers. Ask how the device interfaces with the systems it will need to work with, and what the surrounding system requires. Ask for the configuration record, including any department-specific settings. Ask what happens to the device’s support position over the next few years, so that the purchase decision reflects the remaining life rather than only the current state. Buyers who want the wider context can start from the knowledge hub, compare how equipment is described on the marketplace store, or use the lifecycle material in the industry hub. Our overview of how pre-owned equipment changes procurement efficiency covers the commercial framing of the same decision.
Buying a pre-owned system or preparing one for sale? Send the hardware and software details and the intended use and we will identify which capability questions remain open.
FAQ
Does firmware matter when buying a used medical device?
It does, because firmware and software determine what the device does and what it can connect to. Two units with identical hardware can differ in capability because of their versions, and a unit on an unsupported version may have limited options for future updates. The version should be recorded before purchase alongside the hardware details, and the support position established for that version.
How do I find out which software version a used device is running?
The version is normally displayed in the device’s own information or service screen, and it is often recorded in service documentation. Where the device cannot be powered up before purchase, the version should be established during acceptance, and the purchase terms should allow for the possibility that it differs from what was stated. A version recorded without a date is of limited use, because it can be superseded by an update at any time.
Can software licences be transferred with used equipment?
That depends on the terms of the licence rather than on the hardware, and the answer varies between manufacturers and products. Some licences transfer with the device, others are tied to an organisation, and some are time-limited. Because the consequence of a non-transferable licence is a device that is present but functionally limited, the position should be documented by the seller and confirmed before purchase.
What happens when a device reaches the end of software support?
It can continue to function, but it stops receiving fixes and its compatibility with surrounding systems will not improve and may decline. Security exposure increases, and the effort required to keep the device connected rises. The practical consequence is that the device’s remaining useful life is finite and should be planned for, rather than being treated as an indefinite extension of its current capability.
Does an old software version affect resale value?
It does, because a buyer is acquiring the device as it is rather than as the model could be. A unit on an unsupported version with a non-transferable licence is less useful than one that is current and fully licensed, and the difference is a commercial rather than a technical matter. Recording the position accurately supports the sale instead of leaving the buyer to discover it.
Part of the Buying Pre-Owned Medical Equipment guide.
