A used device can pass every electrical and performance test and still be a poor security decision. The unit may run an unsupported operating system, ship with default accounts or depend on a vendor connection that cannot be secured. The assessment has to look at the deployment, not only the box.

Security Is a Property of the Deployment, Not Just the Box

Security is a property of the deployment because the same device can be low-risk on an isolated network and high-risk on a shared one. The network, the users, the remote access and the maintenance process all shape the exposure.

A device that is not connected to anything still has physical, account and service risks. A connected device adds network, authentication and patch risks. The buyer should assess the intended deployment, not a generic product category.

The assessment also depends on the clinical role. A device that stores patient data has a different risk profile from one that only controls a local function. The buyer should also consider the people who will use and service the device. A control that depends on a busy clinical team following an unusual procedure is likely to fail under pressure. The buyer should define the data, the connectivity and the criticality before asking the seller for evidence. The regulatory context varies by market, from FDA rules and the EU Medical Device Regulation 2017/745 to MHRA, TGA and PMDA requirements, while WHO guidance frames the shared principles; the assessment should reflect the rules of the market where the unit will operate.

Evidence to Request Before Purchase

The evidence should come from the manufacturer where possible: security documentation, the software bill of materials, vulnerability and patch history, supported operating systems and the manufacturer\’s disclosure statement for the device.

The manufacturer\’s security disclosure often uses a standard form, such as the MDS2, which describes the device\’s security features, network connections and known limitations. It is not a guarantee, but it is a structured starting point. The buyer should ask for the version that matches the unit, not a generic brochure. A security disclosure for a different software release may describe features the unit does not have or omit features it does. The version should be recorded with the evidence, and the seller should explain any difference between the document and the unit.

Operating System and Support Status

The operating system and support status determine whether the device can receive security fixes. An embedded or end-of-support platform may be unable to run current protections, and the manufacturer may have stopped issuing patches.

A used unit may run an older release because the clinical software depends on it. That is not automatically unacceptable, but it changes the risk. The buyer should ask when support ends, whether extended support is available and what compensating controls the manufacturer recommends.

The assessment should also cover the supporting components: the database, the middleware, the antivirus exclusions and the backup process. A supported device on an unsupported platform is a supported device with a caveat, and the caveat should be written down. The support status should be checked at the component level, not only the device level. A supported application running on an unsupported operating system is still an unsupported platform, and the manufacturer may not be able to patch the underlying library.

Authentication, Accounts and Default Credentials

Authentication is where many deployments fail. The device may ship with default credentials, a shared service account or a password policy that cannot be changed. The buyer should confirm what can be configured before purchase.

The questions are practical: can unique user accounts be created, can roles be assigned, can default passwords be changed, can inactive sessions expire and can administrative access be separated from clinical use? If the answer is no, the control has to come from the network or the physical environment.

Service accounts and vendor access deserve particular attention. A shared account that several technicians use cannot be audited, and a vendor connection that bypasses the hospital\’s access controls can undermine the rest of the design. The buyer should ask how those accounts are managed and logged. Physical access is part of authentication. A device in a locked room with controlled entry is a different risk from one in a public corridor. The assessment should record who can reach the device, the ports and the power switch.

Network Exposure and Connectivity Features

Network exposure includes wired and wireless connections, open ports and protocols, cloud services and remote-support features. A device that was designed for a closed network may not be suitable for a shared one without segmentation.

The buyer should obtain a network diagram or connection description from the manufacturer and compare it with the intended deployment. The device may need inbound access for a service laptop, outbound access for updates or a cloud connection for image transfer. Each connection should have an owner and a control.

Wireless features deserve a separate check. A device with an enabled wireless interface that the clinical team does not use is an unnecessary exposure. The buyer should confirm whether the interface can be disabled and whether the manufacturer supports that configuration. The buyer should also ask whether the device can be operated without a network connection. If the clinical workflow allows offline use, that may be the simplest control. If it does not, the network dependency becomes part of the risk.

Patch Path and Manufacturer Support

The patch path is the manufacturer\’s process for delivering validated security fixes, and it is a better indicator than a one-time vulnerability scan. A device with a clear patch path can be maintained; one without it depends on compensating controls.

The buyer should ask how often patches are released, whether they are validated for the device, whether they can be applied remotely and what happens when the device reaches end of support. A manufacturer that cannot answer those questions is telling the buyer something important. The patch path should be tested, not assumed. The buyer should ask for the date of the last security patch and the process for the next one. A manufacturer that cannot provide a date or a process may still support the device, but the buyer should plan accordingly.

Where patching is not possible, the buyer should ask what the manufacturer recommends: network isolation, application allow-listing, restricted accounts, monitoring or replacement. Those recommendations become the compensating controls, and they should be documented.

What an Assessment Cannot Prove

An assessment cannot prove that the device will never be compromised. It cannot predict a zero-day vulnerability, guarantee that users will follow the procedure or confirm that the network will stay segmented after the next change.

It also cannot prove that the seller\’s configuration matches the manufacturer\’s documentation. A unit may have been modified, a service account may have been added or a remote feature may have been enabled. The buyer should verify the configuration on the unit, not only in the file.

The assessment is a snapshot of evidence and risk, not a certification. A seller\’s security questionnaire is not an assessment. It is an input, and it should be verified against the manufacturer\’s documentation and the unit\’s configuration. The record should say what was reviewed, what was tested, what remains unknown and who accepted the residual risk.

Recording Residual Risk

Residual risk is the risk that remains after the controls are applied. It should be recorded in a form the organization can review: the risk statement, the affected device, the control, the owner, the review date and the acceptance decision.

The record should distinguish risks that can be fixed from those that must be accepted. A default account that can be disabled is a fix; an unsupported operating system may be an accepted risk with compensating controls. Mixing the two makes the register unusable.

The register should be reviewed when the device is installed, when the network changes and when a new vulnerability is published. A one-time assessment that is never revisited is a snapshot, not a control. The review should be documented and dated, not just performed. The review should also happen when the manufacturer announces end of support or a new patch, because those events change the risk profile without changing the device. The risk owner should be named, not implied. A clinical engineering team may own the device risk, while IT owns the network control and the clinical department owns the workflow. The register should show who accepted what and when it will be reviewed.

The remote software upgradeability guide covers the update path, and the Knowledge section has related software and records guides. If you are assessing a unit and want the security evidence reviewed before purchase, send the model and what you hold to the HHG team.