When an instrument PC cannot be patched, stop treating the finding as a to-do and treat it as an accepted risk with controls. Inventory the machine, take it off the general network, limit what plugs into it, and write down an owner and a review date. Then push the vendor for a supported path.
Why these machines exist
A microscope, sequencer or spectrometer may ship with a computer whose software was validated on one specific operating system version. Updating the system can void support or break the instrument driver. So the PC stays as it is, sometimes for the life of the instrument.
That is a normal situation in research, and scanners will flag these systems loudly. The aim is not a clean report. The aim is a defensible position.
Step 1: inventory without disturbing it
List each instrument computer with its location, operating system, owner, network connection and what data it holds. Get the operating system version from the machine or the vendor. Be careful with active scanning: fragile devices can misbehave when probed, so ask the vendor or the instrument manager before running a network scan against one.
Step 2: isolate
The most effective control is network placement.
| Control | What it does |
|---|---|
| Separate network segment | Limits who can reach the PC and where it can connect |
| No direct internet | Removes the most common attack paths |
| Allow list for data transfer | Only the file server or transfer host it needs |
| Disable unused services | Fewer listening ports to find |
| Removable media rules | Scan or restrict USB drives, a common route for malware |
Ask your campus network team whether a restricted segment exists. If it does, moving the instrument is usually quick.
Step 3: reduce what the PC can do
- Remove or disable email, web browsing and chat on the instrument PC.
- Use a standard, non-administrator account for daily operation where the vendor allows it.
- Keep backups of settings and calibration data, stored elsewhere.
- Move data off the machine promptly, so a compromise does not hold years of results.
Step 4: write the exception
For each machine, record: operating system and version, reason it cannot be patched, controls in place, owner, and a review date. This one page answers an auditor, a funder or a security office faster than any scan report.
Step 5: plan the exit
Ask the vendor in writing for a supported operating system path or a replacement PC. Add the answer to the exception record. When the instrument is up for renewal, make a supported platform a condition of the purchase.
What dependency scanning can and cannot do here
A dependency scan reads software manifests, so it helps with analysis code that runs on your own systems after data leaves the instrument. It cannot patch a vendor operating system, and you should not expect it to. Safeguard's dependency scanning fits the downstream analysis code, and a free scan can check it.
Talking to the vendor
Vendors respond to specific, written requests. Ask which operating system versions the instrument software supports, whether security updates have been validated, what network access the instrument needs and why, and what the vendor recommends for isolation. Keep the replies with the exception record. If the vendor has no answer, that fact helps justify a supported replacement at the next purchase.
Quick check
Is it acceptable to leave an unpatched machine running?
It can be, if the risk is documented, the machine is isolated, and someone owns the decision and a review date.
Should we scan instrument PCs?
Ask the vendor or instrument manager first. Passive inventory is safer than active probing on fragile equipment.
Last reviewed: 19 October 2026.
