Beyond Laptops: Finding the Devices That Stop the Operation
Your asset register treats every endpoint the same. Your operation doesn't. Three tests separate the devices that merely inconvenience someone from the ones that stop revenue when they die — and the second group deserves a different program.
Open your asset register and every endpoint looks the same: a row, a serial, a model, an owner. A marketing laptop and the terminal that runs patient check-in get identical treatment — same support queue, same refresh logic, same priority when they fail.
Your operation knows better. It knows that some rows in that register are just computers, and some rows are the business, wearing a computer's serial number. When the marketing laptop dies, one person has a bad afternoon. When the check-in terminal dies, the lobby backs up for every provider in the building. When the PC driving the label printer dies, product physically cannot leave the dock.
The register doesn't distinguish them. That's the gap: criticality is an operational property, and it's stored nowhere. Which means the devices that stop the operation get discovered as critical at the worst possible moment — mid-failure — and recovered with the same improvised process as everything else.
The fix starts with an act of classification. Three tests do it.
The three tests
The downtime test: when this device dies, does the operation stop — or just a person?
Trace what actually halts. A device is critical when its failure idles a function: check-in stops, the line stops, dictation stops, shipping stops. The test is unforgiving of job titles — the CEO's laptop usually fails it, while the beat-up PC nobody has looked at in four years, the one running the scale at receiving, passes instantly. Walk the operation and ask, station by station: if this went dark right now, what stops? The devices where the answer is "revenue" are your list.
The config test: is the value in the hardware — or in a state that would be hard to reconstruct?
Many critical endpoints are unremarkable machines running irreplaceable configurations: the specific application version, the driver that talks to the instrument, the settings tuned over years, documented nowhere. For these devices, the disaster isn't the dead hardware — replacement hardware is cheap. The disaster is that nobody can rebuild the state, so a hardware failure becomes a reconstruction project of unknown length, performed under pressure, next to a stopped operation. A device passes the config test when its working state needs to be captured and maintained as a known-good build — so that recovery is a restore, never an archaeology dig.
The swap test: could a staged spare restore this function in minutes?
This is the practicality gate. A critical device belongs in the program when a pre-built spare — imaged to that captured configuration — could be physically exchanged and have the function back fast. Most workstation-class endpoints pass: terminals, line PCs, dictation stations, label-print hosts, scan stations. What the test screens out is equipment whose recovery genuinely isn't a device exchange — and that boundary deserves to be drawn honestly, which is the next point.
A device that passes all three tests has earned something the asset register never gave it: a captured configuration, a staged spare, and a recovery plan that runs in minutes. That's the program.
The boundary that keeps the program honest: up to the port, not past it
Critical endpoints live next to serious equipment — clinical systems in healthcare, production machinery and instruments in manufacturing. A credible critical-device program has to be explicit about where it stops.
The line is the port. The program covers the computer: its identity, its captured configuration, its custody, its spare, its swap. It does not reach past the connector into the regulated or specialized equipment the computer talks to — not the clinical device governed by FDA-regulated servicing, not the PLC, not the instrument. Those domains belong to their manufacturers, their biomedical teams, their controls engineers, and the program's job is to hand them a working, correctly-configured endpoint at the port — and never to touch what's beyond it.
Far from limiting the program, the boundary is what makes it deployable in serious environments. Everyone — compliance officers, equipment vendors, engineers — can see exactly where the responsibility sits, which is what lets them say yes.
Why this is an extension, not a starting point
One sequencing note, learned the honest way: a critical-device program is a second step. It presupposes the machinery of a running device operation — serialized inventory, imaging benches, staged spares, custody records, a recovery loop. That machinery gets built and proven on the laptop fleet, where volume is high and stakes are forgiving. Extending it to the endpoints that stop the operation is then a scope decision, not a new build.
Which is why the program begins the same way for every fleet: an audit. Walk the operation, apply the three tests, and produce the list — the devices that stop the business, their captured states, and the spares they need. Most operators are surprised twice: by which devices make the list, and by how short the list actually is.