TL;DR
Giving somebody two machines doubles more than the hardware. It doubles the enrolment, the patching, the licences, the retrieval and the number of devices that can go missing. Four situations genuinely justify it. Most requests are one of those four wearing a disguise, or a workaround for a problem that has a cheaper fix.
- The second device costs far more than its price. Count the recurring lines.
- Four cases justify it: isolation, platform testing, travel risk, field work.
- Personal preference is not one of them, however reasonably it is argued.
- A second machine doubles the retrieval problem, which is already the weak point.
- Check whether a virtual machine or a second screen solves it first.
- If you do issue two, record them as a pair or one will be forgotten at exit.
What a second device actually costs
The purchase price is the part everybody sees and the smallest part of the total.
Each additional machine carries a management licence, a share of security tooling, patching attention, an enrolment record that has to stay accurate, and eventually a collection, a wipe and a disposal certificate.
Best tools for Device Management
It also adds a second chance to fail. Two machines means two devices that can be lost, two that can go unreturned when somebody leaves, and two that can sit unpatched if one is used rarely.
The rarely used machine problem
That last point is the one that bites. A second device used occasionally checks in rarely, falls behind on updates, and drifts into the unknown category in your compliance reporting.
So the quiet cost of a lightly used second machine is not the hardware. It is that it becomes the least secure device in your fleet while nobody is looking at it.
Under ISO/IEC 27001, the information security management standard the asset inventory is expected to be accurate rather than approximately right, and pairs of devices assigned to one person are a common source of drift because the register was designed around one device per human.
The four cases where two machines are right
These hold up. Everything else deserves a second look.
Isolation requirements. Someone handling production access, regulated data or customer environments where the security model genuinely requires separation from general browsing and email. The requirement should be written down somewhere other than the request.
Platform testing. Engineers and support staff who must reproduce issues on a second operating system. A virtual machine covers much of this and not all of it, particularly for hardware behaviour and performance work.
Travel risk. Staff travelling to locations where a device may be inspected, seized or is simply likely to be stolen. A clean travel machine is a legitimate control rather than a perk.
Field or shared environments. Work where the machine lives in a lab, a workshop or a vehicle and cannot reasonably be the same device that goes home.
What does not qualify
Wanting a desktop at home and a laptop for the office. Preferring a different keyboard. Not wanting to carry one between sites. Each is reasonable as a preference and none is a second device, because the cheaper answers are a dock with a monitor and keyboard at each location.
Saying that clearly in the policy saves a great deal of case by case negotiation, and it is fairer than deciding on who argues most persuasively.
The alternatives worth trying first
Disclosure: RemoAsset, named below, is owned by the same people who publish HROpsLab. It is described with its limitations stated, on the same terms as every other supplier. This site takes no vendor money and sells no placements.
Three, and between them they resolve most requests.
A virtual machine. Covers most platform testing, costs nothing in hardware or retrieval, and keeps everything inside one managed device. It fails for performance-sensitive work and for anything testing actual hardware behaviour.
A second workspace rather than a second computer. A dock, monitor and keyboard at the other location. Far cheaper than a machine, nothing to retrieve beyond accessories, and it solves the carrying problem completely.
A loaner pool. For travel and for short-term needs, a small pool of clean machines issued and returned beats permanent second devices. Three loaners can serve a lot of trips.
The loaner pool is the most underused of the three. It converts a permanent per-person cost into a shared one, and it keeps the machines in your hands between uses, which means they stay patched.
Where the pool needs support
Pools work when somebody wipes and reconfigures devices between users, and they decay when that is nobody’s job. A machine returned from a trip and reissued without a clean rebuild is a risk rather than a saving.
Where collection, wiping and reissue run through one supplier, a loaner pool is easier to sustain because the turnaround is a service rather than an internal chore. That is part of what storage and redeployment of returned devices covers. It does not remove the need to decide who is eligible for a loaner, which stays an internal policy question.
The decision table
| Situation | Scale | Setup | Primary pain | Recommended starting point |
|---|---|---|---|---|
| Wants desktop plus laptop | Any | Single machine policy | Carrying between sites | Dock and screen at each location |
| Testing another platform | Any | Engineering team | Cannot reproduce issues | Virtual machine first, hardware if it fails |
| Regular high risk travel | Any | Normal laptop travels | Inspection or theft risk | Small loaner pool of clean machines |
| Production access isolation | Any | One machine for all | Security model requires split | Issue two, record as a pair |
| Second device rarely used | Any | Pairs already issued | Falling out of compliance | Reclaim it into a pool |
Reclaiming pairs you already issued
Most companies reading this already have pairs in the field, issued over years by people who have since left, for reasons nobody recorded.
Do not reclaim them all. A blanket recall generates a lot of resentment and a few genuinely broken workflows, and it will be remembered longer than the saving.
Run the list instead and sort it into three groups.
Still justified. Matches one of the four cases. Leave it, record the reason, and add a review date so it does not become permanent by forgetting.
No longer justified. The project ended or the role changed. Ask for it back with notice and a collection arranged, not as an instruction.
Unknown. Nobody can say why it was issued. These are the majority and they are also the easiest, because the person usually knows whether they use it.
The question that sorts the unknowns
Ask when they last switched it on. Anybody who has to think about it is not using it, and most people offer the device back without being pushed once the question is framed that way rather than as an accusation.
Expect roughly half of a legacy pair population to come back from that single question. The rest will have a reason, and those reasons are worth recording because they often reveal a missing tier or a workflow nobody designed for.
If you do issue two, do these three things
Most of the trouble with pairs comes from treating them as two unrelated records.
Record them as a pair. The register should show that this person holds two devices and that both are expected back. Offboarding checklists built around one device per person will collect one and close the ticket.
Put an expiry on the second one. Issue it against a reason and a review date. When the project ends, the travel stops or the role changes, the device comes back rather than becoming permanent by default.
Apply the same standard to both. The lightly used machine needs the same encryption, enrolment and patching as the primary. In practice it often gets less attention, which inverts the risk, because the neglected device is the one most likely to hold stale credentials.
The exit check worth adding
Add one line to the leaver process: does this person hold more than one device? It takes a second to check against the register and it is the single most effective guard against the second machine quietly staying out.
Where the second machine is being disposed of rather than reissued, the same sanitization standard applies to it as to the primary, and NIST Special Publication 800-88 on media sanitization is the reference most disposal contracts name. A lightly used device is not a lower risk one.
Teams that skip it discover the gap months later during an audit, by which point the person has moved on and the machine is genuinely gone. Every unreturned device is a forced purchase, and a retrieval service that collects from former employees is the mechanism for closing it, though it works far better when the register knew there were two in the first place.
For the specification question that often sits underneath these requests, see our guide to laptop specs by role.
See how a loaner pool stays serviceable with storage and redeployment of returned devices, or read our guide to laptop specs by role.
Frequently asked questions
When does somebody genuinely need two machines?
Four situations hold up. Isolation requirements where the security model separates production or regulated access from general browsing. Platform testing that a virtual machine cannot cover, usually hardware behaviour or performance work. Travel to places where a device may be inspected, seized or stolen. And field work where the machine lives in a lab, workshop or vehicle. Everything else deserves a second look.
Is wanting a desktop and a laptop a good reason?
No, though it is a reasonable preference. The cheaper answer is a dock, monitor and keyboard at each location, which solves the carrying problem completely for a fraction of the cost and with nothing extra to retrieve beyond accessories. Writing that into the policy saves a lot of case by case negotiation and is fairer than deciding by who argues most persuasively.
What does a second device really cost?
Far more than its price. Each machine carries a management licence, a share of security tooling, patching attention, a register entry that must stay accurate, and eventually a collection, a wipe and a disposal certificate. It also adds a second thing to lose and a second thing that can go unreturned when somebody leaves, which is already the weakest point in most equipment processes.
Why are rarely used second machines a problem?
Because they check in infrequently, fall behind on updates, and drift into the unknown category of your compliance reporting while nobody is watching. The quiet cost is not the hardware but that the lightly used device becomes the least secure machine in the fleet, often holding stale credentials, precisely because it attracts the least attention.
What should we try before issuing a second machine?
A virtual machine, which covers most platform testing at no hardware or retrieval cost. A second workspace rather than a second computer, meaning a dock and screen at the other location. Or a small loaner pool for travel and short term needs, which converts a permanent per person cost into a shared one and keeps the machines patched between uses.
How do we stop the second device being forgotten at exit?
Record the two as a pair in the register, so it is visible that both are expected back, and add one line to the leaver checklist asking whether the person holds more than one device. Offboarding processes built around one device per person will collect one and close the ticket. The gap usually surfaces months later in an audit, by which point the machine is genuinely gone.
Should a second device be permanent?
Issue it against a stated reason and a review date instead. When the project finishes, the travel stops or the role changes, it comes back rather than becoming permanent by default. Also apply the same encryption, enrolment and patching standard to both machines, because in practice the secondary gets less attention and that inverts the risk.
