Device Lifecycle Management: The Five Stages and Who Owns Each

TL;DR

• Device lifecycle management is the practice of tracking a company machine from purchase to disposal, and the useful framing is five stages with a named owner for each.
• If you have one office and buy laptops as people join, you do not need a lifecycle programme. You need a spreadsheet somebody maintains.
• Devices are almost never lost inside a stage. They are lost at the handoffs between stages, where ownership changes and nothing enforces the transfer.
• Four of the five stages are owned by IT at most companies. The decision to replace a working machine sits across two of them and is usually owned by nobody.
• The stage everybody underfunds is the gap between return and reissue, because it has no deadline and no customer.
• Measure register accuracy by sampling, not by counting rows. A register with 100 per cent of your devices and 60 per cent accuracy is worse than a shorter one you trust.

The Laptop That Was in Two Stages at Once

A 520-person company ran a device programme that looked healthy. Procurement was centralised, every machine was enrolled in management, offboarding triggered a retrieval request, and the asset register had a row for all 611 devices it believed existed.

An auditor asked a simple question: pick twenty rows at random and show me the device. Fourteen checked out. Three were with people who had left between four and eleven months earlier. Two were in a cupboard in the Dublin office, marked as assigned to employees who had been issued replacements and had forgotten to mention it. One did not exist at all, having been returned, assessed as broken, and sent for disposal eighteen months previously by somebody who no longer worked there.

Every one of those six failures happened at a boundary. Not one device was lost while somebody was using it, or while it sat in procurement, or while it was being disposed of. All six were lost in the moment responsibility moved from one team to another, because at that moment the device belonged to the handoff rather than to a person. The register was not inaccurate because anybody was careless. It was inaccurate because five stages had owners and four transitions did not.

Recommended Tools

Best tools for Device Management

B BambooHR HR management system L Lattice Performance management D Deel Global payroll & EOR

View all recommended tools

That is what lifecycle management is actually for, and it is a different problem from buying a tool.

When You Don't Actually Need a Lifecycle Programme

When the manual way is genuinely fine

Under about fifty devices, one location, and one person who knows where everything is. A spreadsheet with a serial, a name and an issue date genuinely works at that scale, and it works because the person maintaining it can verify it by walking around. Introducing stages and owners adds process without removing anything.

When friction starts appearing

The first signal is somebody asking a question the spreadsheet cannot answer. How many machines are out of warranty. How many are over three years old. What did we spend on hardware last year. These are not tracking failures, they are reporting failures, and they are the point at which the fields you record start to matter more than the fact that you record them.

When it becomes a liability

The point at which you cannot evidence what you hold. An auditor sampling rows, a security review asking about devices with open data obligations, or an acquirer asking for a fixed asset list. The failure is not that a laptop is missing; it is that the register and reality have diverged and nobody knows by how much.

The edge case that forces it

A second country, or an acquisition. Both break the walk-around verification that made the spreadsheet trustworthy, and they break it immediately rather than gradually. The day you can no longer physically see the fleet is the day the register stops being a description and becomes a claim.

Five Questions People Ask First

"Is this the same as IT asset management?" Largely yes, with a difference of emphasis worth knowing. Asset management tends to mean the register and its accuracy. Lifecycle management means the stages and the transitions, with the register as one output. If somebody is selling you lifecycle management and only talking about the database, they are selling asset management.

"Which stages actually matter?" All five matter and two are routinely unowned, which is the practical answer. Procurement and deployment get attention because somebody is waiting for a laptop. Retirement gets attention when an auditor asks. The middle, meaning maintenance and the replacement decision, runs on whoever notices.

"Do we need software for this?" Not at first, and the ordering matters more than the tooling. A tool imposed on undefined ownership produces a well-structured record of a process nobody follows. Define the five owners and the four handoffs on one page, run it for a quarter, and the tool requirement becomes obvious and much narrower.

"How accurate should the register be?" Pick a target and sample against it rather than aiming at perfection. Ninety-five per cent on a quarterly sample of twenty rows is a good, achievable bar for most companies. What matters more than the number is that somebody knows it, because an unmeasured register is treated as either perfect or useless, and it is neither.

"Who should own the programme?" One named person, and seniority matters less than whether they can require other teams to complete a handoff. The common failure is to give it to whoever maintains the spreadsheet, which makes them responsible for data they do not control.

The Five Stages

One: procurement

Specifying, approving and buying the machine. Owned by IT in most companies, with finance approving spend and, increasingly, a platform executing the purchase.

What goes wrong here is specification drift rather than anything dramatic: three models become eleven over two years because each exception was reasonable, and the fleet becomes expensive to support and impossible to compare. The fix is a short standard list and a named person who can say no.

Two: deployment

Getting the device configured, secured and into somebody's hands. Owned by IT, and the stage that has changed most with distributed work, because the assumption that a technician touches the machine no longer holds.

The failure here is a device that reaches a person before it reaches the register, which happens whenever a laptop ships direct from a supplier and somebody intends to record it later. Later is the problem.

Three: maintenance

Patching, management, repair, warranty claims and replacement of failed parts. Owned by IT, usually well, since it is the stage with the clearest day-to-day signals.

What is weak here is the link back to the register. Devices get repaired, swapped under warranty and occasionally replaced entirely without the asset record changing, which is how a serial number in your register stops corresponding to the machine somebody is holding.

Four: retirement from the user

The device comes back, because the person left, got an upgrade, or it broke. This is where the auditor found four of six failures, and it is owned by a mixture of HR, IT and the leaver's manager, which in practice means owned by nobody for a period of days or weeks.

The characteristic failure is a physical device in one state and a record in another. It is in a cupboard and the register says assigned. It is with a departed employee and the register says returned.

Five: disposal or resale

Wiping, evidencing the wipe, and either selling, recycling or certified disposal. Owned by IT with finance interest, and frequently outsourced.

The failure here is evidence rather than logistics. Devices get disposed of properly and the certificate is not linked to the asset, so the register shows a device you no longer hold and cannot account for.

The Four Handoffs, Which Are the Real Subject

Every one of these is a two-line process change rather than a project, and together they address most of what makes a register untrustworthy. The pattern is the same in all four: the record should change at the moment the physical thing moves, performed by the person who moved it. Any design where somebody updates the register afterwards, in a batch, from memory, will drift.

The Decision Nobody Owns

There is a sixth thing that is not a stage, sits between maintenance and retirement, and is unowned at most companies: deciding that a working machine should be replaced.

It is unowned because it has no trigger. Procurement happens when somebody joins. Deployment happens when a device arrives. Maintenance happens when something breaks. Retirement happens when somebody leaves. Replacing a machine that still works happens when somebody decides, and nothing in the lifecycle generates that decision. So in practice it is made by whoever complains loudest, which produces a fleet replaced in the wrong order: the vocal get new laptops and the quiet keep five-year-old ones.

Three ways to give it a trigger, in rough order of how well they work.

Age, as a scheduled replacement. The simplest and the one most companies land on. Everything over a set age gets replaced in a planned round. Predictable for budgeting, and it replaces some machines that did not need it and misses some that did.

Condition, from support signals. Replace on evidence instead: repeat hardware tickets, battery health, storage pressure, failed updates. More accurate and it requires the signals to be collected somewhere somebody looks, which is the part that usually does not exist.

Role, as a standing entitlement. Certain roles get replaced more often because the work demands it. Honest and easy to administer, and it needs stating openly or it reads as favouritism.

Most teams should combine age as the floor with condition as the override, and write down who approves an off-cycle replacement. Which year to set as the floor is a separate question with its own arithmetic, and it is not the same question as who is allowed to make the call.

The reason this matters to lifecycle management specifically: an unowned replacement decision is what fills the cupboard at stage four. Devices get replaced reactively, the old machine comes back with no plan, and the same gap that loses departing employees' laptops loses upgrade returns too.

Specification Drift, and Why the Fleet Gets Expensive

The procurement failure named above deserves its own treatment, because it is slow and nobody notices it happening.

You start with three approved models. Somebody needs more memory for a legitimate reason, so a fourth appears. A designer needs a different screen. A new country has different supply, so two more models enter. An acquisition brings its own standard. Within two years the fleet has eleven configurations and nobody chose that.

The cost shows up in four places. Support gets harder, because every variant has its own quirks and your runbooks cover three of eleven. Spares stop being interchangeable, so a failed part means a new order rather than a swap. Reissue gets harder, because a returned machine only suits some roles. And comparison becomes impossible, since you can no longer say what a laptop costs you.

The fix is not rigidity. It is a short list with a named approver and a recorded reason for each exception, reviewed annually. The review is the part that matters: most exceptions granted two years ago are no longer needed, and nobody has ever gone back to check.

One caution on consolidating. Standardising downward to the cheapest acceptable machine reliably produces a second wave of exceptions within a year from the people whose work genuinely needed more. Set the standard at what the majority of roles actually require rather than at the minimum that boots.

A second caution, specific to distributed teams. Supply differs by country, and a standard list written against what one market can source will generate exceptions everywhere else as a matter of availability rather than preference. Write the standard as a specification, meaning the processor class, the memory and the storage you require, rather than as a list of exact models. Then the same standard survives a supplier substitution in a market you do not buy in often, and your eleven configurations stay three specifications.

How to Choose: Five Questions Before You Talk to Any Vendor

What is your register's actual accuracy? Sample twenty rows and physically verify each. The number you get is the input to every other decision, and most teams have never produced it.

Which handoffs are unowned today? Write the four down and name a person against each. The blanks are your actual problem, and a tool does not fill blanks.

Did you procure the devices you are trying to track? This determines how much any platform can help. A tool that handled the purchase knows the serial, the recipient and the address from the start. A tool pointed at a fleet bought over four years on various cards inherits your existing gaps.

How many countries hold devices? One country is a spreadsheet problem. Several is a logistics problem, and the stage that gets expensive is retirement, because a device recovered in the wrong country loses most of its value to shipping.

What reporting do you actually need? Age distribution, warranty status, spend by period and devices with open data obligations cover almost every real question. If a tool cannot produce those four, the richness of the rest does not matter.

The Options

A note on pricing before the list. The platforms that cover the full lifecycle, including physical logistics, mostly publish nothing. The software that covers the register, and only the register, mostly does. That split is the clearest thing in this category and it tells you what you are buying. Figures below were read from each vendor's own pricing page, most recently 7 and 9 October 2026.

RemoAsset

Disclosure: RemoAsset is owned by the same people who publish HROpsLab. It appears here because it competes in this category and is assessed against the same criteria as everything else on this page, with its limitations stated in the same detail.

Best for: teams whose problem is the handoffs rather than the database, particularly the two physical ones at either end.

Why companies choose it: because it executes procurement and delivery, the supplier-to-register handoff happens automatically rather than relying on somebody recording a despatch. The same is true at retirement, where the return is triggered by offboarding and the record changes when the device is received. Devices can be stored in region and reissued domestically, which is the single biggest lever on retirement economics for a distributed fleet.

Where it struggles: it publishes no price and requires a demo, so sizing it means entering a sales process. It is much weaker if you did not procure through it, because then it inherits whatever register you already have. And it is not a certified IT asset disposition vendor, so stage five with certification is a separate purchase.

Snipe-IT

Best for: teams who want a real register, are comfortable self-hosting, and have no budget.

Why companies choose it: the self-hosted edition is free and open source, which makes it the only genuinely no-cost option here that is not a spreadsheet. Hosted tiers are published at $39.99 and $399.99 for Basic, $99.99 and $999.99 for Small Business, and $249.99 and $2,499.99 for the smaller dedicated plan, monthly and annually. Larger dedicated plans are published at $5,000 and $7,500 a year, which its page abbreviates.

Where it struggles: it is a register and nothing else. It does not ship, recover, store or dispose of anything, so it addresses the data half of the problem and none of the physical half.

AssetTiger

Best for: small teams wanting a hosted register with per-asset tiers rather than per-user pricing.

Why companies choose it: pricing is published and tiered by asset count, at $20 a month for 500 assets, $40 for 2,500, $75 for 10,000, $140 for 50,000 and $275 for 250,000, with annual billing reducing each. An inventory add-on is $15 a month.

Where it struggles: the 250-asset tier that it is widely described as offering free is, on its own pricing page, a 30-day trial rather than a permanent free plan, so plan on paying. Like Snipe-IT it is a register and does no physical work.

Asset Panda

Best for: teams wanting a configurable register with mobile capture and audit workflows.

Where it struggles: publishes no price at all. Its pricing page is a quote request with a 7-day trial attached, so comparison requires a call.

Lansweeper

Best for: discovery, meaning finding the devices on your network that nobody recorded.

Where it struggles: publishes no figures even in a browser. It is also discovery rather than lifecycle, so it tells you what exists and not what stage anything is in, which makes it a complement rather than an alternative.

Workwize, Deel IT, Firstbase, GroWrk and allwhere

All five cover the physical lifecycle to varying depth across different country sets, and none of them publishes a price. Country coverage is the real differentiator and the headline numbers are not comparable, so shortlist on your own markets and expect to compare quotes rather than list prices.

The Comparison

The Decision Table

Measuring the Programme

Four numbers, and the first is the only one that matters at the start.

Register accuracy, by sample. Twenty rows a quarter, physically verified, expressed as a percentage. Do this before anything else, because every other measure is meaningless on a register you have not tested. Sample randomly rather than picking rows somebody can confirm quickly.

Devices with an open data obligation. Issued, not confirmed wiped, not currently managed. This is the population a security review will ask about and most registers cannot produce it, because the field does not exist.

Age distribution, not average age. An average hides the tail, and the tail is your refresh budget. A fleet averaging 2.1 years with nineteen machines over five is a different situation from one evenly spread.

Days at each handoff. Specifically days between device received and record updated, and days between received and reissued. These two expose the handoff failures directly, and they are the numbers that improve fastest when you assign an owner.

Running the Quarterly Sample

This gets recommended four times above and it is twenty minutes a quarter, so here is the whole method. It is deliberately not a full audit, which is a bigger and rarer exercise.

Pick the twenty rows with a random number, not by judgement. The instinct is to check rows you can confirm quickly, which guarantees a flattering result. Number the register and pick twenty at random.

Verify by evidence, not by assertion. A row passes when you can show the device exists where the register says, with the serial matching. A manager saying they think so is not verification. For remote staff the practical evidence is a management console check-in within the last fortnight, plus the assigned name matching the logged-in user.

Record the failure type, not just the count. Each failure is one of four things: device in a different state than recorded, assigned to the wrong person, serial does not match the physical machine, or does not exist. Those four map onto the four handoffs, so a quarter's failures tell you which transition is leaking.

Fix the twenty, then fix the handoff. Correcting the sampled rows is satisfying and worth nothing on its own, because the other 591 rows have the same error rate. The sample's job is to point at the process.

Write the percentage somewhere permanent and date it. Four quarters of figures is the artefact that gets the work funded, because it shows a trend rather than a complaint.

So the output of a good quarter is one number and one sentence: accuracy was 88 per cent, and six of the seven failures were devices in custody still showing as assigned. That sentence names the handoff and the owner, which is the whole point.

The Field Most Registers Are Missing

Two sections above refer to devices with an open data obligation, which is the population a security review will ask about, and almost no register can produce it. It is worth building because it is cheap and it is the question you will be asked.

The field is a simple state with three values. Open means the device has held company data and you cannot evidence that the data is gone. Closed means you can, with a date and a method. Never issued means it has not been in anybody's hands.

Deriving it needs three things you probably already have. Whether the device was ever assigned to a person, which the register knows. Whether it is currently enrolled in management, which the management console knows. And whether a wipe has been recorded against it with a date, which is the part usually missing because wipes get done and not written down.

The rule that populates it: a device that was assigned and has no recorded wipe is open, regardless of where it physically is. That includes devices sitting in your own cupboard, which surprises people and is correct, because an unwiped machine in storage carries the same exposure as one in a departed employee's flat. It just has a lower probability of being read.

Two consequences follow, and both are useful. You will discover that your open population is considerably larger than the set of devices you thought were missing, because it includes everything in storage that was never wiped. And wiping on arrival rather than on reissue, which the offboarding sequence recommends for unrelated reasons, closes most of it at a stroke.

Record the wipe with a date, a method and whoever performed it. An undocumented destruction is close to a destruction that did not happen, and this field is where that distinction lives.

What Getting This Wrong Costs

The direct cost is hardware you own and cannot find, and at mid-size it is a real number without being a frightening one. Six unaccounted devices out of twenty sampled, extrapolated across 611, is not a rounding error.

The second cost is every decision made on the bad data. Refresh budgets built on an age field that no longer matches the machines people hold. Warranty renewals bought for devices already disposed of. A security posture that assumes management coverage the register cannot actually evidence. None of these appear as lifecycle failures in any report; they appear as budget variance and audit findings.

The third is the one that compounds. A register people do not trust gets worked around, and the workaround is local spreadsheets, which fragment the data further and make the central register worse. That cycle is why accuracy tends to fall rather than drift sideways, and why sampling early matters more than tooling.

The fourth cost is organisational rather than financial, and it is the reason these programmes stall. When the register is known to be unreliable, every request that depends on it turns into an investigation. A finance question about hardware spend becomes a week of reconciliation. A security question about coverage becomes a manual export and three conversations. The team that owns the register spends an increasing share of its time defending it rather than improving it, and the people asking the questions learn to stop asking. So the register gets less scrutiny precisely as it gets less accurate, which is the opposite of what you want and is entirely self-reinforcing.

So the question to take into the next planning round is not which platform to buy. It is what percentage of your register is true, and who owns the four moments where it stops being true.

What This Looks Like on One Page

The whole programme fits on a single sheet, and writing it down is most of the implementation. Five rows for the stages, four rows for the handoffs, a name against each, and the control that enforces the transfer.

The reason to keep it to one page is that the document has to be readable by the people who are not in IT. Three of the four handoffs involve somebody outside the team: a supplier despatching, an employee confirming receipt, a manager or HR triggering a return. A twelve-page policy is a document those people will never open, and a one-page table is one they will.

Put the four controls in the imperative and address them to the person doing the work. Not "the asset register shall be updated upon receipt of hardware" but "when you open the box, change the record to In Stock and put your name on it." The second version gets followed because it tells somebody what to do rather than describing a desired state.

Then review the page when anything structural changes: a new country, a new supplier, an acquisition, or a change of owner for any row. Those four events are the ones that invalidate a handoff silently, and a page nobody has revisited since the second country opened is describing a company that no longer exists.

One omission worth avoiding. Most versions of this document cover what happens when things go to plan and say nothing about the exceptions, which is where the register actually breaks. Add three lines: what to do with a device that arrives damaged, what to do with one that arrives and is not on the register at all, and what to do with one nobody can identify. Each of those happens a few times a year, and without a stated answer each one becomes a judgement that leaves no record.

When You're Ready to Move Beyond the Spreadsheet

Most device programmes run on a spreadsheet for far longer than anybody admits, and that is usually the correct decision rather than a failure of ambition. A spreadsheet maintained by one person who can see the fleet is accurate, cheap and fast to query.

What ends it is not size but visibility. The moment devices exist in places the maintainer cannot walk to, the spreadsheet stops being a record of observed reality and becomes a record of what people remembered to report. Accuracy falls from that point whatever the headcount, which is why a 90-person company across four countries often has a worse register than a 300-person company in one building.

The sequence that works is deliberately unglamorous. Sample twenty rows and write down the accuracy figure. Name an owner for each of the five stages and, more importantly, for each of the four handoffs. Change the register at the moment the device moves, by the person who moved it. Run that for a quarter and re-sample. Then, with a real accuracy number and a known set of remaining gaps, go and look at tools, because at that point you will be able to tell which half of the problem you are buying for.

Frequently Asked Questions

HROpsLab takes no vendor money and publishes no paid placements, which is why the owner's own product is listed above with its three limitations rather than its three best features.