Who Patched That Device? Your Service Record Probably Can't Say
Cybersecurity has moved to the front of the medical equipment buying cycle. HTM teams are no longer running a security checklist the week before the PO goes out. They are asking manufacturers for patch timelines, end-of-support dates, SBOMs, and a written answer to one plain question: when a vulnerability lands, who applies the fix, and how fast?
Those are the right questions. Ask them.
Here is the part almost nobody has gotten to yet. Every one of those answers becomes a promise. And a promise is only worth what you can later show it delivered. Two years into that contract, when it comes up for renewal, where exactly do you look to see whether the patch actually got applied inside the window you negotiated?
Most HTM programs would have to look in three places, and would come back with three partial answers.
What just changed in the buying cycle?
24x7 reported this week that cybersecurity has become one of the main purchasing criteria, not a late-stage checkbox. Scott Skinner of HTMPOWER put the timing problem bluntly: if the security review happens right before you cut the PO, it is already too late, because that is the moment you stop having leverage.
The survey numbers in that piece, from RunSafe Security's 2026 Medical Device Cybersecurity Index, back it up. 84% of organizations now put cybersecurity requirements into vendor RFPs, and 56% have rejected a device over security concerns, up from 46% the year before. The harder number: 44% acknowledge running end-of-support devices with known, unpatched vulnerabilities.
Katie Connor, senior director of cybersecurity at Intermountain Health, described where this is heading in the same article. Health systems are moving from asking a manufacturer whether a device is secure, to asking them to demonstrate how security will be maintained across the device's whole life, and writing that into the contract terms.
Demonstrate. That word is doing a lot of work, and the same shift is about to arrive on the hospital's side of the table. If the contract says a validated patch gets pushed within a week, somebody eventually has to open a record and show that it did.
Who actually touches a device when it gets hardened?
Ask an HTM director what happens when a connected device needs its software version checked, its default credentials changed, and a security agent installed. You rarely get one answer, because it is rarely one team.
Across HTM programs we keep hearing the same shape. The work is split: the HTM shop handles physical access and the device side, IT handles the network piece, and a dedicated security team owns the vulnerability and the agent. That split is often sensible.
The problem is what it does to the record. Each group logs its part where its own team logs things. Different work orders, sometimes different systems entirely. In more than one program we have heard about, the security side documents in a general-purpose tracking tool and never in the CMMS at all, and nobody ever needed the two reconciled.
So the device gets hardened. Three teams did real work. And there is no single place you can open that says what was done to that asset, by whom, on what date, and how long it took.
This is not a discipline problem, and it is certainly not a technician problem. Nobody skipped a step. The record fragmented because the work was structured to fragment, and no system was ever asked to put the pieces back together.
So why doesn't the work order just say?
Because of when it gets written.
The rest of HTM has the same problem, and security work makes it worse. A tech is on a device with a laptop, a vendor on the phone, a clinical unit waiting to get the room back. The documentation happens afterward, from memory, at a desk, at the end of a shift that already contained five other things. What survives that trip is a summary. "Updated per vendor." "Patched." "Complete."
Then that summary becomes the permanent answer to a question somebody will ask two years later in a renewal meeting.
We have written before about how thin work order notes get born at the capture moment rather than at the review stage. Security work is that same story with higher stakes: it is the work most likely to be split across teams, and the most likely to be asked about later.
What does a thin record cost you at renewal?
You now have patch commitments, disclosure timelines, and support obligations written into your purchase agreements. Good. But hospitals were already struggling to check the agreements they had. PartsSource's 2023 study of service agreements found that 92% of surveyed hospitals had no procedures to consistently monitor vendor performance against contract terms, across roughly 146 service contracts at a typical hospital and around half the HTM budget.
Adding cybersecurity clauses to contracts you cannot yet verify does not automatically make you safer. It makes the gap between what you bought and what you can show more expensive.
None of this is an argument about who should hold the contract, or about whether the vendor is doing right by you. Plenty are. It is a narrower and more awkward point: you are heading into renewal conversations with obligations you negotiated carefully and evidence you assembled by hand, from three systems, the week before the meeting.
The same problem shows up in fleet decisions. A framework published this week on legacy ultrasound systems argues that age alone is a bad basis for deciding whether to patch, segment, isolate, or replace, and that programs should reason from evidence instead. That is right. It also assumes a service history detailed enough to reason from. Most fleets do not have one.
What would a record that answers the question look like?
Nothing exotic. Four things, on the asset, not scattered across three teams' tools:
What was actually done. Version before and after, what was changed, what was verified. Not "patched."
Who did it, and when. Including the parts done by IT and by the security team, on the same asset record as the physical work.
How long it took. Security work is real labor. If it is invisible, it is unfunded, and it competes with PMs and repairs for hours nobody budgeted.
Captured while it happened. This is the one that makes the other three possible. A record written at a desk three hours later is a reconstruction, and reconstructions flatten exactly the detail you will need.
That last point is why Leera AI exists. A technician talks through the work with their hands on the device, and the documentation writes itself into the CMMS with the versions, the exceptions, and the time. Not a dictation button pressed afterward.
The buying cycle has already changed. The next question points inward, and it is coming: can you show what your own program did?
FAQ
Should cybersecurity work be logged in the CMMS or in the IT system? Both teams need their own tooling, and that is fine. What matters is that the asset has one history a person can open and read. Today that work usually lives in two or three systems that were never reconciled.
Isn't a completed work order enough proof that a patch was applied? It proves a task was closed. It rarely proves what was done. A note that says "updated per vendor" cannot tell you the version, the verification step, or the elapsed time, which is what a renewal conversation or an incident review will ask about.
We already require SBOMs and MDS2 forms from vendors. Isn't that the documentation problem solved? Those documents describe what the manufacturer built and what it knows about. They say nothing about what your team did to that specific device, on what date. Manufacturer documentation and service documentation are two different records, and only one of them is yours to produce.
Does capturing more detail mean asking technicians to type more? It should mean the opposite. Longer notes typed at the end of a shift is the failed version of this. The workable version is capture during the work, in speech, so the record is a byproduct of the job rather than a second job after it.