TL;DR
- A rehire goes through onboarding, and onboarding assumes a new person with no history. Almost every equipment assumption in that process is wrong for somebody returning.
- The old device is usually gone, and when it is not, giving it back is rarely the right call. Age, condition and what happened to it in between all argue against it.
- The records are the real problem. A returner frequently has an open item from their first departure, an unreturned device or an unclosed charge, and nobody checks because the rehire process does not look backwards.
- Returners have expectations the process does not expect. They remember what they had, they compare it to what they are given, and they notice when the answer is worse.
- Duplicate records are the quiet cost. Rehires routinely produce a second identity in your systems, and equipment assigned to the new one while the old one still shows an open device is how a fleet count goes wrong.
- Check three things before day one: what they had, whether it came back, and whether anything was left open. That is the whole fix and it takes ten minutes.
The returner who was issued a machine they already had
A product manager left a 350-person company and came back fourteen months later into a more senior role. The rehire went well: the offer moved quickly, the manager was delighted, and onboarding ran through the standard process on the standard timeline.
On day one she was issued a laptop. It was the same model she had used before, one generation newer, which was correct. What nobody had checked was that her original machine had never been returned. She had left during a period when retrieval was handled by whoever had time, her device had gone onto a list, the list had been worked through for about three weeks and then abandoned, and the entry had sat there since.
So the company now had two machines assigned to the same person, one of which it believed was with a former employee and one of which was in front of her. The register showed both. Nobody reconciled them, because the rehire created a new employee record and the old one was closed, and the open device was attached to the closed record where no active process would ever look at it again.
Best tools for HR Operations
She still had the original laptop in a drawer at home. She mentioned it in week three, to her manager, who did not know who to tell. It came back eventually. The point is that nobody asked, and the only reason the company recovered it was that she volunteered it.
When a rehire needs no special handling
They were gone for a long time and left cleanly. Somebody who departed three years ago with a documented return and a closed record is, for equipment purposes, a new joiner. The history exists but nothing in it is open.
They were a contractor who became an employee without a gap. This is a conversion rather than a rehire. The device never went anywhere and the question is about the asset record and the assignment, not about issuing anything.
They left and returned inside a few weeks. An offer that fell through, a resignation withdrawn, a short gap between contracts. Here the right answer usually is to give back the same device, because it is still current, still assigned and probably still in your possession.
Your fleet is leased and refreshed on a fixed cycle. If every device is replaced on a schedule regardless of holder, the old machine question resolves itself and only the records question remains.
Why onboarding gets rehires wrong
Onboarding is built on a set of assumptions that are correct for a first-time joiner and wrong for a returner, and the process has no step that notices the difference.
It assumes no prior record. The equipment workflow creates a fresh assignment against a fresh employee record, which is exactly right for somebody new and exactly how you end up with two active records for one person.
It assumes nothing outstanding. There is no step that asks whether this person previously held company property, because for a new joiner that question is nonsense. For a returner it is the most important question in the process.
It assumes the person has no expectations. A new joiner receives what they are given and has nothing to compare it to. A returner remembers precisely what they had, including the monitor and the chair, and will notice if the new arrangement is worse.
And it assumes the standard timeline. Rehires frequently move faster than external hires, because the interview process is shorter and the notice period may be too, which compresses the equipment lead time that the process was designed around.
None of these are failures of design. They are a process doing exactly what it was built to do, applied to a case it was not built for.
The three checks that take ten minutes
Run these before day one, ideally at the point the offer is accepted.
What did they have? Look up the previous assignment in the asset record. You want the device, the serial number, the issue date and anything else that was assigned alongside it. This tells you what to expect and gives you a reference point for the conversation about what they get now.
Did it come back? This is the one that matters. Check whether the previous device was returned, and if the record says returned, check what happened to it afterwards. If the record says outstanding, you have found an open item that was never going to surface any other way, and you have found it at the one moment when the person is reachable and well-disposed.
Was anything left open? Charges, deductions, a damage claim, a signed undertaking about returning equipment. These sit in different systems from the asset record and are easy to miss. An unresolved charge from a first departure surfacing after a rehire is an unpleasant conversation that is much easier to have before the person starts than after.
| Check | Where it lives | What you are looking for |
|---|---|---|
| Previous assignment | Asset register, closed employee record | Device, serial, issue date, peripherals |
| Return status | Same record, often a separate field | Returned, outstanding, or never updated |
| Open items | Payroll, finance, HR case notes | Charges, deductions, unresolved claims |
| Duplicate identity | HR system, directory, asset system | Two records for one person |
Should they get their old device back
Usually no, and the reasons are practical rather than policy.
It is probably not there. Most companies either redeployed it, sold it or retired it within months of the original departure. If your process works, the old machine is in somebody else's hands or gone.
If it is there, it has aged in storage. A machine held for a year has consumed warranty, degraded its battery and fallen behind on operating system updates, all while doing no work. Issuing it to a returner means issuing a device that is simultaneously old and unused, which is the worst combination available.
The condition is unknown. Unless it was inspected on return and the result recorded, nobody knows what state it is in. Handing somebody a machine you have not checked is how a first day goes wrong.
And the symbolism is poor. A returner given the laptop they used two years ago will read it as the company's view of their return, fairly or not. The cost difference between that machine and a current one is small relative to the message.
The exception is the short gap. Somebody back within weeks, whose device is still current and still in your possession, should get it back, and doing anything else is wasteful. The dividing line is roughly whether the machine is still within your normal issue specification. If it is, give it back. If it is not, do not.
What they had before, and the expectations that come with it
Returners compare. It is unavoidable and it is not unreasonable.
They remember the machine, the monitor, the chair and whatever else was arranged, and they remember how long it took to arrive. If they are returning into a more senior role, which many rehires are, they will reasonably expect the arrangement to be at least as good as before.
Two things usually cause friction. The first is that company policy has changed in the interim. A stipend model replaced a direct issue model, or a device standard got tightened, or a peripheral that used to be automatic now needs approval. The returner is not being treated worse than colleagues, but they are being treated worse than they were, and nobody has explained why.
The second is that something they had was a one-off exception, granted informally by a manager who has since left. The returner remembers an entitlement; the company has no record of one. This is awkward precisely because both parties are being honest.
The fix in both cases is the same and it is a conversation before day one rather than a discovery on it. Tell them what the current arrangement is, acknowledge explicitly where it differs from what they had, and say why. That takes five minutes and removes almost all of the friction, because the problem was never the equipment, it was finding out by surprise.
The duplicate record problem
This is the one with the longest tail and the least visibility.
A rehire usually produces a new record in the HR system, because the old one is closed and most systems are not designed to reopen a departed employee. That new record flows into your directory, your asset system and anywhere else that provisions from HR. The person now exists twice.
For most purposes that is harmless. For equipment it is specifically harmful, because device assignment is tied to identity. The new record gets the new machine. The old record keeps whatever was attached to it, including anything never returned. Your fleet count now shows one more device in the field than actually exists, attributed to somebody who does not work for you, and no active process will ever look at that record again.
Multiply across a few years of rehires and you have a measurable gap between your register and reality, concentrated entirely in closed records where nobody is looking.
The fix is a step in the rehire process that reconciles the two records explicitly. Not merging them, which many systems will not do, but checking the old one for open items and closing them properly before the new one is populated. Ten minutes per rehire, and it is the only time anybody will ever have a reason to open that record.
The old device still carries their enrolment, and that is a security question
This is the part the article has not addressed and it is arguably the most important one.
A device that was never returned is still enrolled. Depending on how your estate is configured, that can mean it still holds a management profile, still has certificates, still has cached credentials, and in some configurations still appears to your systems as a managed company asset belonging to somebody who stopped working for you a year ago.
That is a different problem from a missing asset. A missing asset is a cost. A device that is still enrolled, still trusted by your systems and physically outside your control is a standing exposure, and the fact that the person is friendly enough to return as an employee does not change what it was for the intervening year.
Three things to do when a rehire surfaces an unreturned device. Check what the device still has, meaning enrolment status, profiles and any access that was never revoked. Revoke first, collect second, because those are independent steps and the first one does not require anybody to post anything, agree to anything or be available on a particular afternoon. And treat anything you cannot verify as still live, since a device you cannot reach is a device you cannot confirm anything about.
The same logic applies in the other direction for devices that did come back. A machine returned a year ago and stored without being wiped still holds whatever was on it. If your return process inspects and wipes on arrival, this is already handled; if returns get stacked, the rehire is a good prompt to check whether the stack has been processed.
None of this needs to be alarming in tone when you talk to the returner. It is housekeeping and framing it as housekeeping is both accurate and more likely to get a quick result than framing it as a security incident.
What the departure process should have done
Every failure in this article is really a departure failure surfacing late. Fixing rehires at the rehire is treating a symptom, and the upstream fix is cheaper.
Close the asset record at departure, explicitly. Not when the device arrives back, which may be never, but as a step that forces a status: returned, outstanding, written off. A record left in neither state is the one that sits for a year and reappears during a rehire.
Set a point at which outstanding becomes a decision. If a device has not come back in sixty days, somebody should decide what happens rather than leaving it on a list. Write it off, escalate it, or keep chasing with a named owner. The list that gets worked for three weeks and then abandoned is the specific failure in the story at the top of this article.
Record the condition of what did come back. A returned device with no condition note is a device nobody can make a decision about later, which is how machines end up stored indefinitely because nobody will take responsibility for saying they are fine.
And capture whether anything was left informally. Peripherals, a chair, a second monitor. These are small individually and they are what returners remember, because they are also what the person still has in their spare room. A laptop gets chased because it is valuable and traceable; a monitor and a dock rarely do, which means they are both the most commonly retained items and the least commonly recorded. If your departure checklist lists only the machine, it is capturing perhaps half of what actually went out.
A departure process that does these four things makes the rehire checks trivial, because the answers are already recorded. A departure process that does none of them means the rehire check is genuinely investigative work, which is why it gets skipped.
Rehires into a different country
A meaningful share of returners come back somewhere else. People leave, move, and return to the same company in a different market, and that combination breaks more assumptions than either event alone.
The old device, if it exists, is in the wrong country and almost certainly should not be shipped to the new one. The arithmetic from any relocation applies: moving an aged machine internationally rarely beats issuing a current one locally, and the old machine's residual value is better realised where it already sits.
The old record is attached to the old market, which matters if you held a local arrangement for that person. If they were your only employee there, that arrangement may have lapsed, and the equipment that was in it may be unaccounted for.
And the new market may have different lead times, different device standards and different support arrangements than the person remembers. A returner coming back into a market your company entered recently will have expectations formed in a market where you were established, which is a specific version of the expectations gap described earlier.
The practical approach is to treat a cross-market rehire as a new joiner for equipment purposes and as a returner for records purposes. Issue locally against current standards, and run the three checks against the old record in the old market. The two halves are independent and treating them as one thing is what causes confusion.
Who actually owns this
The reason the three checks get skipped is that no function owns them, which is worth naming rather than leaving implicit.
Recruitment owns the hire and has no reason to look at asset records. HR owns onboarding and its process is built for new joiners. IT owns equipment and receives a ticket that looks identical to every other new-joiner ticket, with no indication that this person has a history. Finance owns any outstanding charge and has no visibility of the rehire at all.
Every one of those is a function doing its job correctly. The gap exists between them, which is why it persists through process improvements that each function makes independently.
The cheapest fix is to attach the check to the thing that already happens: the onboarding ticket. One field on the request asking whether this person has worked here before, and a short checklist that appears when the answer is yes. That puts the work with IT, who are the only function with access to the asset record anyway, and triggers it from a process that already runs every time.
What does not work is a policy document stating that rehires should be checked. That relies on somebody remembering at the moment they are busy, which is exactly the condition under which this has been failing.
The compressed timeline nobody plans for
Rehires move fast. The interview process is shorter because the person is known, references are a formality, and the gap between offer and start is frequently weeks rather than a month.
That compresses the equipment lead time, and the lead time is the one part of the process that does not compress. Procurement still takes what it takes, shipping still takes what it takes, and if the person is in a market with longer lead times none of that improves because the hire was quick.
Two practical responses. Start the equipment process at offer acceptance rather than at contract signature, which is often a week or more earlier and costs nothing if the hire falls through. And check the pool first, because a rehire is exactly the case where an existing machine in stock is both faster and entirely appropriate.
The thing to avoid is treating the rehire timeline as the standard timeline and discovering in the final week that the device will not arrive. That is a bad first day for somebody who chose to come back, and it is the version of this failure people talk about afterwards.
| Stage | External hire | Rehire | What changes |
|---|---|---|---|
| Offer to start | Often 4 to 12 weeks | Frequently 2 to 4 | Equipment lead time does not compress |
| Prior record check | Not applicable | Essential | No existing process step does this |
| Expectations | None to manage | Specific and remembered | Needs a conversation before day one |
| Identity | Created once | Risk of duplication | Old record holds open items |
The alumni case, and devices that were never company property
Two adjacent situations get confused with rehires and need handling differently.
The person who left on a stipend arrangement. If your model is that people buy their own equipment with a company contribution, the machine they used was theirs, and there is nothing to recover or reissue. What there may be is an unamortised contribution, depending on how your scheme is written, and that is a finance question rather than an equipment one. The rehire check still matters, because the records may show an assignment that was never really an assignment.
The contractor returning as an employee. Frequently the device never left, because the engagement ended and restarted without anybody collecting anything in between. That is convenient and it is also the most common source of a device with no clear owner in the register, since it was assigned against a contractor record that has since closed. Reconcile the record rather than assuming the continuity means it is fine.
And the long-gap alumnus. Somebody returning after three or four years is, for practical purposes, a new joiner. The old record is unlikely to contain anything actionable and the device is certainly gone. The reason to run the check anyway is that it costs ten minutes and the occasional long-gap returner does turn out to have an open item, usually a write-off that was recorded as outstanding and never closed.
The pattern across all three is that the register is more likely to be wrong than the person is to be withholding something. Almost every unreturned device that surfaces during a rehire has been sitting in a drawer with the person entirely willing to return it and nobody having asked.
What to do in the first week rather than before day one
Some of this cannot be done in advance, either because the rehire moved too fast or because nobody ran the checks. The first week is a workable fallback and it is considerably better than month three.
Ask directly, in a low-key way. A single message saying you are tidying up records from their previous time and asking whether they still have any company equipment at home. Framed that way it gets an honest answer almost every time, because there is no implication of wrongdoing and the person usually does not want the laptop in their drawer either.
Reconcile the two records while somebody is thinking about it. The rehire is the only moment when anybody has a reason to open the closed record. Once the first week passes, it returns to being invisible.
Confirm what they were actually issued this time. Rehires move fast and the compressed timeline means more is done informally, so it is worth confirming that what the register says they have matches what is on their desk.
And close any open charge explicitly, even if the decision is to write it off. An unresolved deduction from a previous departure that surfaces later is a genuinely unpleasant conversation, and resolving it in week one while goodwill is high costs almost nothing.
Where the vendors fit
Handling it internally with your existing process. Entirely workable, and the fix is procedural rather than technological: three checks and a conversation. This struggles when rehire volume rises, because the checks depend on somebody remembering to do them.
An asset system with history against a person. The structural fix. A register that keeps device history against an individual rather than against an employment record will surface the previous assignment automatically, which removes the dependency on somebody remembering. It struggles if your HR system creates a genuinely new identity, since the link has to be made somewhere.
An equipment platform with HR integration. The same benefit, with the advantage that the joiner trigger comes from the HR system directly. It struggles for the same reason: a new HR record for a returning person looks like a new person unless something reconciles them.
RemoAsset is our own product and that is the disclosure rather than a footnote. It covers procurement and retrieval across 80+ countries, publishes a Subscription tier from $1,499 a year, and includes HRMS integration at that tier, which is the relevant capability here because the rehire problem is fundamentally one of joining an identity to a history. Three limits worth stating plainly: it enrols devices but is not an MDM in its own right; it wipes devices but is not a certified ITAD, so formal disposal of a returner's old machine is a separate arrangement; and coverage and lead times vary by market, which matters on the compressed rehire timeline described above.
The decision table
| Situation | Scale | Setup | Primary Pain | Recommended Starting Point |
|---|---|---|---|---|
| Returner after a few weeks | Any | Device still in your possession | None, really | Give the same machine back |
| Returner after a year or more | Any | Old device gone or aged | Expectation gap | Issue current standard, have the conversation first |
| Rehire with an unreturned device | Any | Open item on a closed record | Nobody checks backwards | Run the three checks at offer acceptance |
| Frequent rehires | 300 plus | Several a quarter | Checks depend on memory | Make the prior-record check a process step |
| Policy changed since they left | Any | Stipend replaced direct issue, or similar | They remember the old arrangement | Explain the change before day one |
| Compressed timeline | Any | Two to four weeks to start | Lead time does not compress | Start at offer acceptance, check the pool first |
What this tells you about your register generally
A rehire is an unplanned audit of one record, and what it finds is rarely specific to that person.
If a returner's device was never returned and nobody noticed for a year, the question worth asking is how many other closed records are in the same state. The rehire did not create that problem; it revealed it, in the only circumstance where anybody had a reason to look.
So treat each one as a sample. If the first few rehires you check turn up open items, that is evidence about the departure process rather than about those individuals, and it is better evidence than an audit would give you because it is unprompted and specific. Three rehires with three open devices is a stronger signal than a general sense that retrieval could be tighter.
The cheap follow-up is to query closed employee records for any device still showing as assigned or outstanding. That query takes minutes, it only works if your asset system keeps the link after an employee record closes, and the result is usually larger than people expect. Whether you then act on it is a separate decision about effort against recovery value, but knowing the number is worth having.
What makes this worth doing at the point of a rehire specifically is that you have just proven the failure mode exists with a concrete example. A number in isolation is easy to deprioritise. A number alongside one named case that everybody in the room remembers is considerably harder to ignore.
What getting this wrong actually costs
The visible cost is a device that never came back, and for a single rehire that is one machine.
The accumulating cost is register accuracy. Every rehire that creates a duplicate identity leaves an open assignment on a record nobody will reopen, and those entries are invisible to every audit that works from active employees. A company with a few years of rehires behind it has a gap between its fleet count and its actual fleet that is concentrated entirely in the places nobody looks. That gap surfaces during an insurance question, a certification or a vendor migration, which are all bad moments to discover it.
The cost that does the most damage is the one with no number attached. Somebody chose to come back, which is a meaningful endorsement of the company, and their first day involved being handed worse equipment than they had before with no explanation, or waiting a week because nobody started the process, or being asked about an unreturned laptop in month three. Rehires talk to the people who stayed. That experience travels.
So the question is not what a missing laptop costs. It is whether anything in your process looks backwards at all, because if the answer is no then every one of these outcomes is waiting rather than unlikely.
When rehires stop being exceptions
Most companies treat rehires as one-offs and handle them case by case, which is right while they are rare.
They stop being rare in two situations. A company that went through a reduction and is hiring again will see returners in volume, and the people coming back are frequently the ones who left with the least closure around their departure. And a company in a sector with high mobility, where people circulate between a handful of employers, will see the same names repeatedly over a decade.
In both cases the fix is the same and it is small: one step in the rehire checklist that looks up the previous record before equipment is ordered. Not a policy, not a system change, one lookup with three things to check.
If your company is at that volume and nothing in the process looks backwards, that is the gap. It costs ten minutes per rehire and it closes every failure described in this article.
Frequently asked questions
Should a returning employee get their old laptop back?
Only if the gap was short enough that the machine is still within your current issue specification and still in your possession, which usually means weeks rather than months. Beyond that, the old device has consumed warranty and degraded its battery while doing no work, its condition is unknown unless somebody inspected it on return, and handing it to a returner reads as a statement about how much their return is valued. The cost difference against a current machine is small relative to that.
What should we check before a rehire's first day?
Three things, ideally at offer acceptance rather than the week before. What they previously held, from the asset record against their old employee record. Whether it was actually returned, which is the check that matters most and the one no existing process performs. And whether anything was left open from their departure, meaning charges, deductions or unresolved claims, which live in different systems from the asset register. Together these take about ten minutes and they catch every failure described here.
Why do rehires create duplicate records?
Because most HR systems close a departed employee's record rather than allowing it to be reopened, so a returning person gets a new one. That new record flows into your directory and your asset system, and the person now exists twice. The new identity receives the new device while the old identity retains whatever was attached to it, including anything never returned. No active process will look at the closed record again, so the open assignment sits there indefinitely and your fleet count overstates reality.
How do we handle a returner who expects what they had before?
Have the conversation before day one rather than letting them discover it. Tell them what the current arrangement is, name explicitly where it differs from what they had, and explain why. The friction almost never comes from the equipment itself; it comes from finding out by surprise. Two situations cause most of it: policy genuinely changed while they were away, or what they remember was an informal exception granted by a manager who has since left, which leaves both parties being honest and disagreeing.
Does the equipment lead time change for a rehire?
No, and that is the problem. Rehires move faster because the interview process is shorter and references are a formality, so offer-to-start is frequently two to four weeks rather than the month or more an external hire takes. Procurement and shipping do not compress to match. Start the equipment process at offer acceptance rather than contract signature, which is often a week earlier and costs nothing if the hire falls through, and check your existing pool first since a rehire is exactly the case where stock is appropriate.
What if the returner still has the old device at home?
Ask them, because they very often do and almost nobody asks. A departure handled loosely leaves the device in a drawer, the person has no particular reason to raise it, and the rehire is the one moment when they are both reachable and well-disposed toward the company. Frame it as housekeeping rather than as a recovery, arrange the collection through your normal process, and close the record. The alternative is that it surfaces in month three through their manager, if it surfaces at all.
How do we stop this happening repeatedly?
Add one step to the rehire checklist that performs the previous-record lookup before equipment is ordered. The failure is not that people make bad decisions, it is that nothing in the onboarding process looks backwards, because for a genuine new joiner looking backwards is meaningless. A structural alternative is an asset system that holds device history against the individual rather than against an employment record, which surfaces the prior assignment automatically rather than depending on somebody remembering to check.
Is this worth worrying about if we only rehire occasionally?
The checks are worth running every time because they cost ten minutes, but the systemic fix is only worth building at volume. Two situations create that volume: a company hiring again after a reduction, where returners arrive in numbers and frequently departed with the least closure, and a sector with high mobility where the same people circulate between a few employers over years. If you are in either, the lookup should be a process step rather than something that depends on whoever handles the onboarding remembering.
Where this leaves you
A rehire is the one case where onboarding needs to look backwards, and almost no onboarding process does.
Run three checks at offer acceptance: what they had, whether it came back, and whether anything was left open. Issue current equipment rather than the old machine unless the gap was genuinely short. Have the expectations conversation before day one rather than letting them find out. And reconcile the old record before the new one is populated, because that closed record is where the open items live and nobody will ever open it again.
Ten minutes per rehire. Every failure in this article comes from nobody spending them.
The reason to bother, beyond the recovered laptop, is that a rehire is the clearest signal a company gets that it is somewhere people choose to return to. That is worth more than any individual device, and it is undercut by a first day where the equipment is worse than last time with no explanation, or by a message in month three asking about a machine the company lost track of. Neither of those is a serious failure on its own. Both are entirely avoidable, and avoiding them is the same ten minutes.
If you want a single thing to change after reading this, make it the onboarding form. One field asking whether this person has worked here before, and a short checklist that appears when the answer is yes. That puts the work with the only function that can do it, triggers it from a process that already runs, and removes the dependency on anybody remembering.
