Device Lifecycle Management

What does device lifecycle management cover?

Device lifecycle management follows a business device through its operational life, linking the people who use it, the organization that owns or finances it, its technical controls, and the records needed for support, cost, data handling and eventual disposition.

Devices, ownership and deployment models

A DLM program can cover laptops and desktops, smartphones and tablets, peripherals, and rugged equipment such as warehouse scanners and field handhelds. The appropriate device and management method depend on the work rather than on a universal hardware list.

A remote employee’s company laptop may need enrollment, role-specific software, encryption, multi-factor authentication, remote support and a recorded return at the end of the assignment. A developer’s laptop has different performance, software and peripheral requirements, but those requirements should be derived from actual workloads rather than a standard configuration assumed to fit every role. A warehouse scanner must tolerate its operating environment and remain supportable for the period in which it will be used. NIST SP 800-124 Rev. 2 treats deployment planning as a joint business and IT decision that starts with users, tasks and operating conditions.

IoT and network equipment share many of the same lifecycle questions: how the device is identified, configured, updated, monitored, supported and retired. Their capabilities differ from those of employee laptops, however. A field sensor, network switch and rugged handheld may require different update mechanisms, hardware support periods and configuration controls. IoT guidance highlights device identification, configuration, software updating and cybersecurity-state awareness as relevant capabilities. Network lifecycle tools can add another layer by linking hardware and software to support notices, contracts and vulnerability information. Nautobot’s device lifecycle documentation illustrates this network-focused use case; it does not make a network inventory system a complete program for every kind of business device.

Ownership changes who may manage a device, what happens when it is returned, and which data or privacy boundaries apply. A company-owned laptop can normally be assigned, recovered, sanitized and redeployed under the organization’s policies. A leased device adds contractual return conditions, while shared equipment can move between users without becoming a separately owned asset. A personally owned phone used for work introduces a different boundary: the organization may manage an authorized work profile without treating the entire handset as company property.

Monitoring, remote actions and data removal must reflect the ownership model and the agreed enrollment. For example, Microsoft documents that Retire on an Android Enterprise personally owned device with a work profile removes work-profile data, apps and settings; it does not provide a general factory reset of the personal device through that work-profile path. See Microsoft Intune’s Retire documentation.

A usable DLM record therefore needs to answer several connected questions: what the device is, who owns or finances it, who currently holds it, which management method is authorized, where it is, and what must happen at return or retirement. Recording only that a person has a device misses the physical custody, cost, support and data responsibilities that continue after delivery. It also misses the fact that a departure or assignment change may return a usable device to stock rather than mark the hardware as permanently retired.

DLM, MDM, ITAM and Device as a Service

DLM is the coordinated business process for managing devices over their usable lives. It covers decisions and physical work that may sit outside any management console: identifying requirements, sourcing equipment, assigning custodians, supporting failures, collecting returns, preparing hardware for another user, sanitizing data and selecting reuse or permanent disposal.

MDM and the related EMM and UEM categories support the technical side of that process. These tools can enroll devices, apply configuration and security policies, distribute or manage applications, report technical state and issue remote actions. NIST SP 800-124 Rev. 2 describes enterprise mobile-device selection and deployment around the deployment model, configuration and operational controls. An MDM platform may connect to procurement, ticketing or asset systems, but a connection does not itself arrange a purchase, repair, shipment, collection or disposal.

ITAM has a broader scope. It combines inventory records with financial, contractual and lifecycle information for hardware, software and licenses. DLM overlaps with ITAM when a device record needs to show acquisition details, ownership, custodian, cost center, condition, support and final disposition. The practical distinction is the emphasis: ITAM manages the asset and its associated records across the organization, while DLM concentrates on the operational handoffs affecting devices during use, recovery and retirement.

The failed-device test makes the boundary clear. Suppose a management portal detects a failed laptop and opens a ticket. The portal has supplied a signal and a workflow record; it has not repaired the device. Someone or an agreed service provider must diagnose the fault, decide whether to repair or replace it, arrange a suitable loaner or spare, transfer the assignment, track the failed unit and update its eventual custody. A service agreement may assign those physical tasks to a vendor, but the customer still needs a clear acceptance point and visibility of the resulting records.

Device as a Service, or DaaS, is a commercial arrangement that can bundle hardware, software, support and lifecycle services under a subscription. It is therefore a procurement and service model rather than another name for an MDM console. DLM software and a managed DLM service are also different purchases: the first organizes workflows or records, while the second may perform tasks such as kitting, delivery, repair, collection and disposition. Ricoh UK’s description of managed device lifecycle services, for example, presents Device-as-a-Service as a bundled operating model rather than a technical enrollment feature.

A subscription also does not settle every question by itself. The agreement should identify which tasks are included, who holds title or bears specified contractual responsibilities, what happens at the end of the term, whether devices must be returned in a particular condition, and which repair, freight, storage, disposal and exit costs are additional. Finance may need to assess the actual arrangement; a monthly payment alone does not establish a universal accounting or tax treatment. Likewise, outsourcing a stage does not eliminate the need to accept its outcome or decide what happens when the service ends.

How does the device lifecycle work?

The first stage of device lifecycle management establishes what the organization needs, what equipment it already has, and how long each device must remain usable and supportable. The remaining stages then depend on those decisions.

Plan requirements and support life

Start with users and work rather than with a preferred model or a list of devices to buy. Identify the people who will use each device, the tasks they need to perform, the applications and peripherals involved, and the conditions in which the equipment must work. Existing inventory deserves the same attention: a compatible device already in stock may meet a new hire’s needs and avoid an unnecessary purchase.

Workload and environment materially change the selection. A developer may need sustained processing capacity, a particular development environment and multiple peripherals. A warehouse scanner may need durability, replaceable batteries and rapid access to replacement equipment. NIST SP 800-124 Rev. 2 supports beginning with business requirements, deployment models and use cases rather than assuming one device profile fits every role. It does not prescribe specifications for a particular job.

Assess the usable support life alongside the purchase price. Check whether the selected operating system, applications and firmware will remain compatible and supported for the intended period, and whether updates and security maintenance are available when the device is still expected to be in service. The Canadian Centre for Cyber Security’s obsolete-products guidance recommends considering support longevity, update availability and advance notice of support ending when selecting products. That is purchasing guidance, not a universal legal replacement deadline.

Hardware support, application support and operating-system support may also end at different times. A vendor may continue repairing a device after the operating system used on it has passed its supported phase. Warranty coverage should therefore be recorded separately from the support dates for the operating system, firmware, drivers and required applications. Microsoft’s Surface driver and firmware lifecycle policy illustrates the distinction for Windows-based Surface devices: driver and firmware servicing follows a separate policy from Windows operating-system support.

Demand planning then turns those requirements into an operating decision. Account for expected hiring, growth, seasonal needs and device failures. Decide how much spare capacity to hold, where it will be stored and who can retrieve it. Define approved configurations for recurring roles so that deployment, support and eventual reuse follow known baselines. Where a transition from one model or operating-system generation to another is likely, plan the overlap rather than assuming every device can be replaced on the same date.

The plan should also assign owners and assumptions. Procurement needs an expected demand and delivery profile; IT needs supported device and software lists; PeopleOps or managers can identify expected joiners and movers; finance needs the commercial and cost assumptions; users and support teams need a route for exceptions. Those allocations depend on the organization’s arrangement, but leaving them implicit usually creates gaps between purchasing, deployment and support.

Stage labels vary among DLM frameworks, and there is no universal number of stages that must be used. Security, recordkeeping, cost control and data responsibility do not end when setup is complete. Updates, configuration checks, support records and eventual disposition continue throughout the device’s life. The planning stage succeeds when it establishes not only what to buy, but also the support horizon, ownership, custody rules and evidence that will determine when a device can be repaired, reused, transferred or retired.

Procure devices and establish the asset record

Procurement succeeds when the chosen arrangement is manageable throughout the device’s life. Compare direct purchase, leasing or rental, and Device-as-a-Service or similar bundles by their included work, contract duration, end-of-term conditions, support coverage and whole-scope cost. A monthly payment does not by itself establish title, a universal accounting treatment or the party responsible for every task.

Before ordering, confirm supplier availability, delivery lead times, supported configurations and compatibility with the organization’s existing equipment. Mixed hardware from different manufacturers can remain a practical choice, but it may complicate imaging, accessory support, repairs and spare management. Record which configurations have been approved. Do not assume that a volume purchase will produce a discount or that a low purchase price will offset weak warranty coverage, incompatible peripherals or a short support life.

The commercial terms should answer the operational questions that will arise later:

• Who owns the device, and when does title transfer?
• Is the arrangement fixed-term, renewable or open-ended?
• What condition is required at return?
• Which repairs, replacements, freight, storage and disposal costs are included?
• Which operating-system, application and firmware versions are supported during the term?
• What happens to carrier services, software licenses and other associated arrangements?

Those answers belong in the acquisition record. Finance should assess the actual arrangement and its accounting implications, while IT and procurement should review the service scope. No universal CapEx or OpEx conclusion follows merely from calling an arrangement a lease or a subscription.

Each device also needs a durable identity that survives later changes. Link its serial number or other persistent asset identifier to acquisition details, the applicable ownership terms, current custodian, cost center, location and condition. Record acquisition date, price or financing reference, warranty and support dates, lease or return date, and relevant software or service history. This creates one auditable history rather than separate records for procurement, assignment, repair and retirement.

A later repair or reassignment should update that same identity. If a failed laptop goes to a repair center and a spare is issued, the original unit must remain linked to the repair event while the spare receives a current assignment. Keeping both units visible prevents an invisible spare from being counted twice or a failed device from disappearing from the fleet.

Mobile fleets need additional relationships between the device, its user and its communications service. Where relevant, associate the device with its SIM or carrier plan and record the service owner. Ending a worker’s assignment does not, by itself, cancel the carrier agreement or prove that a lease has ended. Finance must reconcile the device assignment separately with the underlying lease, contract and invoice. A returned laptop may still appear on a lease bill if its return and contract-close events were not recorded and processed.

Useful stock can also change procurement decisions. Before ordering another device, check whether a compatible unit is available in storage or being repaired. A usable returned or repaired laptop may serve a new starter, while its reuse still requires appropriate data handling, reconfiguration and testing. This does not make every existing device a substitute; suitability depends on condition, compatibility, support status and the role’s requirements.

The asset record should therefore answer two different questions throughout the lifecycle: what does the organization own or owe under the arrangement, and who or what currently holds the device? Confusing those questions can obscure continuing commercial commitments or leave custody unverified. Recording both commercial commitments and physical accountability gives later teams a dependable basis for deployment, repair, reconciliation and disposition.

Enroll, configure, test and deliver

A device becomes ready when it is technically managed, correctly configured and successfully handed over—not merely when it is boxed or shipped. These are separate activities, and each can fail without preventing the others from appearing complete.

Registration and enrollment establish different relationships with the organization’s services. Microsoft Autopilot makes the distinction explicit: registration associates a device’s hardware identity with Autopilot and the organization’s tenant, while Intune enrolment adds the device to mobile-device management. Other management systems use different terminology, but the underlying handoff remains the same: authorize a device for management before assuming it can receive organizational configuration or policy.

Provisioning then applies the approved setup for that device and role. Depending on the deployment model, this may include operating-system and security settings, encryption, authentication and update policy, required applications, role-specific access, peripherals and network configuration. NIST SP 800-124 Rev. 2 describes configuration choices for the actual device, role and deployment model, rather than one control set that applies equally to every owned, leased or personally managed device.

A selected baseline is not a compliance guarantee. IT must verify that the intended settings were applied and that they work together. A device may report as enrolled while missing an application, unable to reach a required service or blocked by an authentication problem. Those failures belong in the readiness record, rather than being hidden behind an enrolment status.

Automation can make provisioning repeatable, but it still has prerequisites. Windows Autopilot, for example, depends on supported client features, licensing, network connectivity and the necessary Entra and MDM configuration. Its requirements documentation gives a product-specific example of why “zero-touch” does not mean zero preparation. Other deployment methods may use imaging, scripts, remote support or manual configuration, but IT or the agreed provider still needs to complete any required registration, establish connectivity and confirm that the required software and policies have been applied.

Physical deployment completes the technical work. IT or an agreed service provider may image or configure the device, bundle accessories, record its asset identity, ship it and assign it to a custodian. These tasks require their own records. A serial number attached to the shipment should match the serial number enrolled and entered in the asset system; otherwise the organization may have excellent technical records for one device and physical custody of another.

The final step is a practical acceptance test. For a new starter, IT should verify that the required login works, the necessary applications and access are available, multi-factor authentication works, required peripherals are present and the device can connect to the services needed for the role. The user should know where to obtain help, and receipt of the device should be recorded. If the test fails, the onboarding exception stays open until the problem is corrected and the device is retested.

This distinction matters most for remote hires, where delivery can arrive before enrollment or connectivity is ready. A delivered laptop that cannot complete management or login is not a successful handoff merely because it reached the correct address. The practical test is whether the assigned person can perform the required work safely and reliably on the device.

Maintain, monitor and repair devices in use

Once a device is in use, IT must keep its software, configuration and support aligned with the role it performs. Deployment creates the initial control state; it does not complete the ongoing work of patching, monitoring, reconciling records or repairing failures.

Operating-system, application and firmware updates need a continuing control process. IT should know which versions and configurations are approved, apply updates through the supported method, and account for devices that are offline, unavailable or assigned to users in different locations. The relevant support record must remain visible as software moves through its lifecycle. If the operating system, firmware or a required application has passed its supported period, the device needs a deliberate review rather than indefinite maintenance under a generic policy. NIST SP 800-124 Rev. 2 treats ongoing operation, configuration control and periodic review as separate requirements from initial deployment.

Asset records and assignments must be reconciled with what is happening in the fleet. Health alerts, battery condition, storage pressure, crashes and unusual activity can help identify devices that need attention, but technical telemetry describes the management system’s view rather than physical custody. A recent last-seen timestamp can show that a device contacted the management service; it cannot prove who holds it or where it is now. Likewise, a missing heartbeat can indicate that a device is offline, incorrectly assigned or no longer present. Such records should enter an exception queue with an owner who can investigate them.

Monitoring also depends on the deployment model. A company-owned laptop can fall within an organization’s documented technical controls. A personally owned phone managed through a work profile may require a narrower monitoring approach that reflects the user relationship, ownership, data and applicable privacy considerations. NIST SP 800-124 Rev. 2 treats these choices as part of the deployment model rather than assuming that enterprise-device controls automatically fit personal equipment.

Support covers both routine assistance and physical failure. Users need a help desk or self-service route, with remote and onsite assistance selected according to the device, location and service arrangement. Support hours and language coverage matter for distributed teams; a published service description alone does not prove that a technician is available at a particular time or location.

A failed device then requires an explicit handoff. Suppose a field worker reports a failed scanner with a damaged screen or exhausted battery. IT assesses whether the device is repairable and whether warranty or another service route applies. If work must continue, IT issues a suitable spare and records it against the worker. The failed scanner remains linked to the repair event and has a defined custodian or logistics status. When the repair is complete, the unit returns to stock, goes back into use or moves toward retirement. Updating only the original assignment would leave the spare’s status unclear and make the repair inventory inaccurate.

Loaners and swap pools therefore need the same controls as deployed equipment. Each unit should have a current state, location, custodian and intended use. The records should show whether it is available, issued, in transit or under repair. A pool cannot provide continuity if the staff responsible for it cannot identify the equipment quickly.

Significant changes should be tested before they reach the entire fleet. A new operating-system build, management policy, application version or configuration template can be applied to a limited group first, then checked for security, functionality and user experience. NIST SP 800-124 Rev. 2 supports deployment testing and limited trials before broad use. Analytics can help identify patterns or possible failures, but the results depend on accurate inputs and a process for reviewing exceptions. They do not prove that a failure will be prevented.

A workable maintenance process consequently combines four forms of evidence: the technical state of each device, its current assignment and custody, the support action taken, and the result of testing or repair. The device may be healthy in the management portal and still be assigned to the wrong person. It may be assigned correctly and still have a failing component. Recording the distinction keeps monitoring useful without turning a dashboard status into proof of every operational outcome.

Recover, store and redeploy usable devices

The end of a worker’s assignment is not automatically the end of the hardware’s life. A device can leave service and remain useful in stock, move to another user, enter repair or reach permanent retirement. Recovery should determine that next state rather than treating departure as disposal.

The first task is to recover the physical device. The worker may have received a return label, shipping kit or collection instructions, but those are request artifacts rather than proof that the organization has regained custody. Collection, delivery and receipt are separate events. Until receipt is confirmed, the asset record should retain the device as outstanding, identify the person or service responsible for the return and maintain the applicable exception process.

When the device arrives, IT should identify it by its serial or asset identifier and compare that identity with the expected return. It should also record its physical condition and visible damage. Missing accessories or a mismatched serial number require investigation before the unit is added to available stock. A repair ticket may be opened, but the device should remain linked to the previous assignment, collection event and current location rather than disappearing from the history.

Storage is an operational state that belongs in the device record. A returned device awaiting inspection, sanitization, repair or reassignment needs a visible location, condition and status. If it is unsuitable for immediate use, stock should not be counted as deployable capacity. This visibility helps avoid two opposing failures: purchasing a replacement while a usable machine is available, and promising a spare that remains buried in a repair or storage queue.

Before a returned device is issued to someone else, its data and management state must be handled for that next use. Required business data should be preserved before it is erased. A device moving internally may need its previous user’s data removed, its role configuration cleared or replaced, and its enrollment and identity relationships reviewed. These actions differ from permanent transfer and from retirement. The full route is not always the same: a usable company laptop may be sanitized, reconfigured, tested and issued to a new starter; a lessor-return device may instead need to reach a specified condition before it leaves the organization.

Caption: Illustrative company-device routes. Reuse requires suitable, supported hardware and appropriate data handling. Permanent exit adds data, contract and platform-release checks. Windows Autopilot release follows its own cleanup sequence. NIST: mobile device lifecycle · NIST: media sanitization · Microsoft: Windows Autopilot release

The next custodian and the device’s current configuration should be recorded when a unit is reassigned. A newly issued laptop must have the appropriate applications, access, security settings and support route for its new role. It should also pass a practical readiness test. Reassigning hardware without resetting the previous role’s access or updating the assignment record can leave both a control gap and an inventory discrepancy.

Repair creates another route back into the fleet. A repaired unit may return to spares, be assigned to another user or be unsuitable for further service. The original asset identity should travel with the repair event so that the record shows what happened. A device cannot be counted simultaneously as deployed to a worker, available in stock and under repair merely because three different systems contain parts of its history.

A useful recovery record therefore distinguishes collection from receipt, physical custody from deployment, and temporary storage from permanent disposition. It also distinguishes the end of an assignment from the end of the device’s useful life. That distinction lets an organization recover value from suitable equipment without weakening the data, support and custody controls that apply during its next use.

Sanitize data, release controls and retire devices

A device is not ready to leave the fleet merely because its data has been erased or its management record has been removed. Permanent exit requires three related outcomes: authorized business data has been preserved, the device’s data has been handled appropriately, and organizational controls or platform relationships have been released for the intended destination.

Before sanitization begins, preserve the business information that must remain available. Confirm what needs to be retained, who authorizes the transfer and where the retained copy will be stored. Then assess the device’s media, the sensitivity of the data, the confidentiality risk and the destination. The NIST SP 800-88 Rev. 2 guidance uses three broad sanitization concepts: clear, purge and destroy. Their suitability depends on the media and circumstances; the guidance does not support one factory reset, overwrite count or destruction method for every device.

The scope must include more than the operating system’s internal drive. Removable storage, associated SIM or SD media and possible copies of encryption keys may need separate attention. A reset of the main device cannot be presumed to address all associated media or every backup of a cryptographic key. Manufacturer-specific instructions and the device’s media characteristics matter.

The destination also changes the work. Internal reuse requires appropriate data handling, reconfiguration and testing. A lessor return may require a particular condition, packing process and release process. Resale or transfer outside the organization may require the platform and identity records to be released as well as the data to be sanitized.

Verify the operation and validate the sanitization outcome

Verification and validation answer different questions. Verification checks whether the sanitization operation ran as intended, including its completion status, errors, anomalies and relevant evidence. Validation decides whether the resulting condition adequately protects the target data and leaves an acceptable residual risk for the intended disposition.

A completed operation can still produce an inadequate outcome. NIST SP 800-88 Rev. 2 illustrates this with degaussing an SSD: the operation may complete, but it does not sanitize the data on that media. The example is a warning about method–media mismatch, not a recommendation to apply degaussing to SSDs. See the current NIST publication and its verification and validation FAQ.

This distinction changes the acceptance workflow. IT should not treat a tool’s success message as final approval. It should review the evidence from the operation, assess whether the method and scope suit the data and destination, and record who accepted the result. An inadequate result remains open: the device is not released for transfer or disposal until the process is repeated, replaced or escalated appropriately.

Caption: NIST SP 800-88 Rev. 2 distinguishes verification of the operation from validation that target data was sanitized and residual risk is acceptable. Rejected outcomes require rework. Media, sensitivity and intended disposition determine the method. NIST: SP 800-88 Rev. 2

The evidence should remain tied to the specific device or media. NIST SP 800-88 Rev. 2 describes documentation that can connect manufacturer, model and serial or media identity with the method, technique and tool version, verification and validation activities, responsible people and dates, and the tracked destination. That serial-linked history makes an assurance decision reviewable.

A certificate may support that record, but its scope matters. A certificate covering one batch or service operation does not establish that every device in the fleet was included, that every associated medium was covered or that an unsuitable method was corrected. The organization should accept evidence that identifies what was treated, how it was treated, who checked the result and where the device went.

Choose reuse, resale, lease return or responsible disposal

Use the intended destination to select the data-handling and contractual checks. Release the device to that destination only after the data outcome has been accepted and the applicable conditions have been met. The options serve different purposes:

• Reuse or refurbishment keeps suitable equipment in the organization. It requires the right role configuration, a current custodian, support coverage and a readiness test.
• Resale or trade-in may recover residual value, but the device must be ready for a new owner rather than merely removed from the active fleet.
• Lease return requires compliance with the agreement’s return date, condition, data and release conditions.
• Recycling or disposal ends the equipment’s useful life and requires an appropriate chain of custody and responsible handling.

Residual value should be recorded only when it is reasonably supported. A speculative resale estimate is not cash recovered, and a possible reuse does not become a saving merely because the organization labels the device as reusable. Finance should compare the realistic cost and value of each route with the cost of retaining or replacing the equipment.

Batteries and e-waste need their own checks. A device may require a separate battery-handling route, particularly when it is damaged. The US Environmental Protection Agency’s electronics recycling guidance advises checking the condition and appropriate handling before donating or recycling electronics. Its US guidance does not establish one recycling or e-waste rule for every jurisdiction; local requirements and qualified handlers must be checked for the actual route.

Platform release is separate from data sanitization. For Windows Autopilot, permanent organizational exit calls for deregistration in addition to data handling. Registration, Intune enrolment and Entra device records are distinct, and the correct cleanup depends on the device’s join and enrolment state. Microsoft’s Autopilot registration overview also warns against indiscriminate identity-record deletion and explains that partner-side Autopilot deregistration alone does not unenrol MDM or disjoin Entra. The sequence is platform-specific; it should not be generalized to Apple or Android, and the organization should follow the applicable product process rather than delete records manually by assumption.

For permanent transfers, this creates an acceptance test with several parts: business data preserved, target data sanitized appropriately, the operation verified and validated, platform ownership released where applicable, contractual return conditions met, and the final custodian or disposal handler recorded. Access closure remains a separate identity task. For Intune, Retire does not revoke access tokens; account and application-session handling requires the separate identity process.

A device can therefore leave the fleet through several routes without moving through a single universal “retirement” button. The acceptable outcome depends on whether it will be reused, returned, transferred or destroyed. Recording those distinct decisions and their evidence keeps data handling, platform release, contract compliance and physical accountability connected.

What changes for remote and international teams?

Remote work moves several lifecycle handoffs out of an office. Delivery, setup, support, repair and return must work without someone standing beside the device to complete them.

Day-one delivery and ongoing support

Remote readiness begins before the equipment arrives. Confirm the delivery address, expected lead time, network requirements, available support routes and the person responsible for the handoff. The shipping window and support coverage should reflect the new starter’s actual working location and start date rather than an average delivery promise.

A delivered laptop is not necessarily usable. It may reach the right address while still awaiting registration, management enrolment, configuration or access to the services needed for enrolment. Microsoft Autopilot’s requirements illustrate the prerequisites behind an automated deployment: supported client features, licensing, connectivity and the necessary Entra and MDM configuration. Those requirements are product-specific, but the broader rule applies everywhere—automation begins with preparation, not with delivery.

The first-use test should confirm that the assigned person can log in, use multi-factor authentication, open the required applications, reach role-specific services and connect any necessary peripherals. The user should also know whom to contact if setup fails. A failed test remains an open readiness exception with a named owner and a plan for correction and retest.

Receipt should be recorded, but a delivery confirmation does not close the readiness task by itself. A useful remote handoff links the shipment to the device’s asset identifier, assigned custodian and technical state. The same identity should appear in the management platform and the asset record. If the two records identify different hardware, the organization has not established accountability for the device the user is actually holding.

Remote support must cover both software and physical failures. The support route should clarify whether the user receives remote assistance, self-service instructions, an onsite visit, a replacement or a loaner. Coverage and response times need confirmation for the relevant location, working hours and language. A provider’s general service description does not prove local availability.

A distributed fleet also needs continuity when equipment fails in the field. Suppose a remote employee’s device stops working and a repair would take several days. The continuity plan should specify whether IT or the agreed service will provide a suitable replacement or loaner, while a named owner tracks the failed unit’s return and repair. The replacement needs a current asset assignment and its own setup test. The failed device must remain linked to the repair event rather than being marked available merely because a replacement was shipped.

Local spare stock can reduce the delay, but only if someone can retrieve, prepare and issue it. The same applies to regional technicians: their existence in a provider’s network does not prove that one is available in the user’s location. Contracts should identify who handles physical work, what falls outside coverage and how exceptions are escalated. 4dev.com’s guide to onboarding remote employees develops the human onboarding side of this handoff, while the device process must separately confirm that the equipment and access are operational.

The practical day-one test is therefore whether the assigned person can begin the required work on a supported, correctly recorded device, with a known route for help. Ongoing support then preserves that condition through updates, repairs and replacements. Delivery, management and human onboarding are connected, but each still needs its own completion evidence.

Offboarding, loss and remote-action verification

A remote departure or lost-device incident remains open until the organization has dealt with physical custody, device data and account access. Issuing a return label, submitting a wipe command or removing a portal object does not establish that all three outcomes are complete.

For an ordinary return, provide the worker with clear instructions, a return kit where appropriate, a shipping method or local collection option and a deadline. Record the request, but keep it separate from collection and receipt. Creating a return label proves that an instruction was issued; it does not prove that the device entered the carrier’s network, reached the designated facility or was accepted by the organization. The asset record should retain the device as outstanding until receipt is confirmed.

A lost, stolen or unreturned device follows a different path. It needs an assigned incident owner who can use the available recovery evidence, coordinate the applicable return or recovery process and keep the exception visible. Tracking information may help locate a device, while a remote command may help protect it if it reconnects. Neither proves a particular outcome, and this process does not decide legal recovery rights, breach-reportability obligations or whether a remote action will eventually succeed.

BYOD arrangements require particular care. A personally owned phone may hold personal data outside the organization’s control. On Android Enterprise personally owned devices with a work profile, Intune Retire removes work-profile data, apps and settings; it does not provide a general factory reset of the personal handset through that path. The applicable enrolment and platform process must therefore govern the authorized scope rather than a generic “wipe the phone” instruction.

Keep physical return, device data and access closure separate

Track three branches of closure in parallel:

1. Physical custody: document what happened to the hardware, including return, receipt, loss or confirmed recovery.
2. Device-data outcome: verify what the authorized endpoint action actually did to managed data.
3. Identity and application access: revoke or close the applicable account, refresh-token and application sessions through the identity process.

Microsoft Intune shows why portal status cannot substitute for this evidence. For Intune-managed devices, a completed Delete hides the device and initiates Retire. “Completed” for Delete confirms server-side completion, not completion of the client-side Retire action. See Microsoft’s device actions documentation.

An offline device adds another qualification. A Retire or Wipe action may remain pending while the device is out of contact, but Microsoft also notes that a successful reset or removal may fail to report back, leaving the action pending indefinitely. Pending therefore proves neither failure nor success. The Intune device-action troubleshooting guidance explains that some endpoint outcomes require separate confirmation rather than reliance on the portal state.

Device removal is also distinct from access revocation. Retiring an Intune device does not revoke its access tokens. Account blocking, refresh-token revocation and application-session handling are separate controls, and effective revocation can take longer than the request to initiate it. Microsoft documents these distinctions in its Entra access-revocation guidance.

Caption: Company-device offboarding: these are parallel checks, not alternatives. Intune Delete completion is server-side, not proof of endpoint Retire completion. Retire does not revoke access tokens; identity and app-session handling is separate. Microsoft: Intune device actions · Microsoft: Intune troubleshooting · Microsoft: revoke user access · NIST: sanitization records

Consider a hypothetical remote exit. The organization creates a return label, but the device is offline. An administrator deletes its Intune object and sees Delete marked completed. The device may still be physically missing, the endpoint Retire outcome may not be confirmed, and the user’s account or application sessions may remain active until the relevant identity controls are applied. The correct response is to keep three exceptions open with their respective owners: recovery and custody, device-data verification, and identity access. None should be closed solely because the portal no longer displays the device.

That structure also applies to internal transfers. A device returned by one worker and intended for another remains part of the fleet until it is received, handled, reconfigured and assigned. It should not be entered in an early offboarding state that makes it appear retired. Conversely, a device confirmed as lost does not become reusable merely because its portal record was removed.

The closure standard is evidence in each relevant branch, not a convenient portal status. Physical receipt proves custody; endpoint evidence supports the data outcome; the identity process supports access closure. When one branch cannot be completed, the record should explain why and keep the exception with an accountable owner.

Country coverage, returns and local requirements

An international DLM program must be verified location by location. A provider’s country count or global portal does not establish that equipment can be purchased, delivered, repaired or collected at a particular site. Ask for the actual country and location coverage behind each promised service, including local warranty handling, supported work, operating hours, language and any exclusions.

The procurement question comes first. Confirm that the chosen model can be obtained in each operating country and that its local warranty or repair route remains available for the intended period. A device bought in one country may have different local support from the same model bought elsewhere. If work is subcontracted, the contract should reveal that arrangement and the party accountable for accepting the result.

Delivery and return routes require their own checks. Cross-border movements may involve import, export, customs or other route-specific requirements. Battery-powered equipment also needs to be checked against the current rules of the actual transport method and carrier. The International Air Transport Association’s lithium-battery guidance explains why battery configuration and rating affect transport conditions, but its live material should not be treated as a substitute for the rules applicable to a particular shipment on the day it moves. The competent shipper or carrier should confirm the current requirements for that route.

Data and telemetry require a similarly precise review. The contract should identify what information the service collects, where it is processed, who can access it and how long it is retained. The organization must compare those terms with the actual device ownership, user relationship, data and applicable jurisdiction. A global processing arrangement does not answer every local privacy question, and the answer must be established for the actual arrangement rather than inferred from a provider’s location list.

Returns create a choice between sending equipment back to one central facility and using local or regional storage, repair and redeployment. A regional depot can shorten the route to a nearby technician or make it easier to issue a device locally. Centralized processing may provide a single specialist facility and standardized records. Cross-border return can add freight, customs, battery-transport and delay considerations. Neither design is universally cheaper or legally sufficient.

A local model also has to preserve traceability. The same device identity, ownership terms, current custodian, support status and sanitization evidence should remain visible across locations. A regional stock system that cannot distinguish “available,” “in repair,” “awaiting sanitization” and “ready for deployment” will obstruct reuse, regardless of where equipment is stored. Common fields and a shared exception queue matter more than the physical location of the warehouse.

The operating decision depends on the route and local facts. For a device that can be repaired and redeployed in its country of use, local handling may preserve availability and avoid a cross-border journey. A lessor-return device may have to follow the lessor’s specified route even if local reuse would otherwise be practical. A battery or electronic item may need an approved local disposal route after its data and contractual checks are complete.

For each country, record four answers that can be verified rather than assumed:

• Can the organization procure the specified configuration, and through which route?
• Who will deliver, accept, repair and collect equipment at that site?
• Which transport, import/export and battery checks apply to the actual shipment?
• Where will data be processed, and what contractual and local terms govern it?

These checks belong in the operating design and service agreements. They are not a substitute for route-specific legal or tax advice, but they prevent a broad international promise from being mistaken for proven local capability.

Who owns the process and which tools support it?

A workable device lifecycle has named owners, explicit handoffs and evidence that each handoff was accepted. The titles below describe a practical coordination model; actual duties should follow the organization’s structure and contracts.

Responsibilities across IT, HR, finance and users

Business and IT stakeholders should define the requirements together and assign accountability for the work. NIST SP 800-124 Rev. 2 presents enterprise device deployment as a joint business and IT decision. That principle extends across the full lifecycle: a process can be well documented and still fail when responsibility ends at the boundary between teams.

A lifecycle owner or steering group should maintain the overall design, resolve conflicting requirements and decide which exceptions require escalation. That owner may sit within IT, operations or another business function, depending on the arrangement. The owner needs authority to connect procurement, technical deployment, people events, finance and user support so that the teams’ tasks form a complete process.

The operating responsibilities can be allocated as follows:

• IT and security define supported devices and configurations, enrol and prepare devices, apply technical controls, maintain updates, operate the help desk, manage repairs, coordinate device-data actions and provide evidence for sanitization acceptance. Security should set the criteria for acceptable configuration and approve exceptions or risk decisions.
• Procurement and finance select suppliers and commercial arrangements, track purchase and lease commitments, reconcile invoices, manage carrier or service arrangements where applicable, and record acquisition, return and disposal costs. They should not decide that a returned asset is fully recovered merely because a return label was issued.
• HR or PeopleOps provide joiner, mover and leaver events and the agreed employment or engagement dates. These events trigger work; they do not by themselves prove that a device has been collected, its data handled or its access closed.
• Managers and users provide or confirm role requirements, receive and acknowledge the assigned device, report loss or damage, follow return instructions and test the equipment for operational readiness. User acceptance of a device is separate from IT’s technical acceptance.
• Vendors and service providers perform the tasks assigned in their agreements, such as kitting, delivery, repair, collection or disposal, and provide the agreed records. They remain accountable under those contracts rather than becoming interchangeable with the customer’s internal acceptance process.

Joiner, mover and leaver events make these roles work as a sequence. For a joiner, HR supplies the start date, IT prepares and tests the device, the manager confirms role requirements, finance creates any relevant procurement or service records, and the user acknowledges the handoff. For a mover, the current custodian and role change must be updated, along with any required configuration, accessory or contract changes. For a leaver, the organization starts access review, collection, data handling, service reconciliation and asset-disposition work in parallel.

Each completion event needs its own evidence. A single status field cannot establish that all the following tasks are complete. A recorded return label demonstrates that instructions were issued. A management-platform action may indicate that a server-side instruction was processed. A cancellation or invoice adjustment establishes only what the relevant provider reports about a commercial service. Physical receipt, endpoint-data handling, identity access and finance reconciliation need separate confirmations.

An exception should remain visible when a handoff fails. If a remote new hire receives a laptop that cannot complete enrolment, IT owns the technical correction while the manager and PeopleOps track the employment readiness impact. If a leaver does not return a device, the responsible team must follow the organization’s loss and recovery procedure while keeping physical, data and access exceptions distinct. If a lease invoice continues after assignment, finance investigates the contract and invoice rather than assuming the asset record is wrong.

The same coordination applies when contractors receive or use equipment. The agreement should state who provides, owns, controls, supports and may recover the device. Supplying equipment or recovering it after an engagement does not determine the person’s worker classification. That question belongs to the applicable legal and employment arrangements, not to the device workflow.

Assign an owner for every output, a trigger for starting the work, a defined acceptance point and an escalation route when the evidence is missing. The model should remain proportional to the organization, but every major handoff needs someone who is answerable for it.

Connected records, workflows and exception handling

Connected lifecycle records should let a team answer what is known, what is outstanding and who must act. The records do not all describe the same state, and a link between systems is useful only when each side preserves its own evidence.

Use a persistent device or asset identifier as the common reference. The ITAM or asset system can hold ownership, acquisition, cost, location, condition and contract history. An MDM or UEM system holds enrolment, configuration, technical state and remote-action information. HR or PeopleOps supplies joiner, mover and leaver events. The ITSM system records support and repair work. Procurement and finance hold purchase, lease and invoice data, while sanitization and disposal records show what happened before a device changed hands.

These connections support a flow rather than producing one authoritative status. When a new starter is recorded in HR, the workflow can request enrollment, configuration, shipping and assignment. If a device fails, the support ticket can link to its asset record and current custodian. When a worker leaves, collection, data handling, access revocation and contract reconciliation can proceed as separate tasks under one incident or case. The shared identifier lets the responsible teams reconcile their results.

Several states must remain distinct:

• Assignment identifies the person or role expected to use the device.
• Physical custody and location describe who actually holds it and where it is believed to be.
• Technical heartbeat records the device’s last contact with a management or telemetry service.
• Billable service reflects the lease, carrier line, license or other commercial arrangement.
• Data outcome records what happened to the targeted device data and how that outcome was checked.

A last-seen timestamp is evidence of technical contact, not proof of current physical custody. An active carrier line can continue independently of the worker’s assignment. A deleted portal object may conceal the endpoint record without proving that the device completed a remote action. Conversely, a device can remain visible in a management system after it has been received into storage. Connecting the records does not make these states interchangeable.

Automation should make exceptions visible. Joiner and leaver events can trigger approvals, task creation and reminders. Asset records can detect a device that is overdue for return. Fleet records can identify configurations that have drifted from the approved baseline. Support and disposal workflows can produce queues for failed actions, unmatched serial numbers, missing receipts or incomplete sanitization evidence.

Every automated task still needs an owner and an error route. A failed synchronization should enter a queue rather than disappear into a log. Periodic reconciliation should compare the asset inventory with management state, ticket outcomes, lease schedules and disposal records, then investigate stale or missing entries. A device present in one system and absent from another may be in transit, under repair or simply misrecorded; the difference requires investigation, not an automatic assumption.

Software and support lifecycle information adds another dimension. Hardware repair status, operating-system support, firmware servicing and application support can have different end dates. A support notice should therefore identify what is affected and which approved version or replacement path applies. Nautobot’s device lifecycle documentation provides a network-focused example of associating hardware and software with support notices, contracts and vulnerability information. The same principle applies to other device classes without implying that the network tool covers the entire DLM process.

A connected workflow should also preserve distinctions between a request and its result. A return-label request is not receipt. A remote-action submission is not verified endpoint completion. A repair ticket is not a closed repair. A disposal instruction is not proof of sanitization or custody transfer. Each task should have separate fields for the instruction, execution evidence and acceptance decision where those stages exist.

The workflow needs a reliable exception queue. Every unresolved mismatch should name an owner, an expected next action and the evidence required for closure. That structure lets automation handle routine coordination while preserving human judgment where records conflict, a device is offline, personal-property boundaries apply or the underlying contract needs interpretation.

In-house work, managed services and buying criteria

Choose the operating model by examining the work that must be performed, the skills and capacity available, the device and location mix, and which decisions the organization needs to retain. DLM can remain internal, divide selected stages between internal teams and a service provider, or be commissioned as a managed lifecycle operation.

An internal model gives the organization direct control over procurement, configuration, support and disposition, but it requires the organization to fund and maintain the necessary skills. It may suit a fleet with straightforward configurations and nearby service facilities. It becomes harder when staff must support many operating systems, remote locations, physical logistics and recovery or disposal work around the clock.

A modular or co-managed model assigns defined stages to a provider while internal teams retain responsibility for other decisions. A full-service model may include sourcing, staging, deployment, support, repair, collection, refurbishment and disposal. SHI and Ricoh UK offer modular and broader lifecycle arrangements, but these offers establish available models rather than uniform quality or coverage.

A failed device tests which tasks the service will perform. A software portal may detect a failure and create a ticket. A managed service may ship a spare, arrange collection and repair the original device. The agreement must say who acts, who pays, when the task is complete and what evidence reaches the customer. Outsourcing the activity does not remove the need for the organization to accept the outcome and retain a usable inventory record.

Before comparing quotes, verify that the proposed service fits the actual fleet:

• Which operating systems, device models, enrolment types and ownership arrangements are supported?
• Can the service work with the organization’s asset, identity, ticketing and procurement systems?
• What data will the provider access, where will it be processed and can the organization export its records?
• Which security and privacy controls apply to devices, users and telemetry?
• Which physical activities are performed directly and which are subcontracted?
• Where are facilities located, and which countries or sites fall outside coverage?
• What happens to records, spare devices and customer property when the contract ends?

Compatibility questions need the same attention as feature lists. A service that supports Windows Autopilot does not thereby support every Windows deployment path or every Android or Apple arrangement. If a provider supports personal work-profile devices, its actions should be assessed against the work-profile boundary rather than treated as authority over the entire handset. The service description must fit the organization’s ownership and management model.

Physical accountability deserves a separate line in the evaluation. Ask who actually ships, receives, repairs, collects and disposes of equipment. Identify the facilities and subcontractors involved. Review service-level commitments for their start and end points, exclusions, after-hours handling and locations outside coverage. A repair turnaround that assumes the device is available at a central depot may not describe a field failure in another country.

Quote structures can differ. A supplier may charge a recurring amount per managed device, price a rollout per unit or project, bundle hardware and services under a Device-as-a-Service agreement, or quote recovery and disposition separately. These structures are not directly comparable until the included scope is aligned. Freight, loaners, spare handling, repair, collection, storage, sanitization and disposal may be included, capped or charged separately. Ask for the complete scope rather than comparing headline rates.

Data and disposition evidence should be evaluated as operating evidence, not as marketing labels. A provider can offer a certificate or describe its process as aligned with a recognized guidance framework. Ask what the certificate covers, how media and serial numbers are identified, who performed the work, how the result was checked and where the device went. NIST SP 800-88 Rev. 2 distinguishes verification that an operation ran from validation that its outcome adequately protects the target data. Neither a portal entry nor a provider label proves that the organization’s particular device and data were handled appropriately.

The contract should also address custody and exit. ITAM records, sanitization evidence, device locations and unresolved exceptions need to remain available when the service ends. The exit plan should identify the inventory transferred back, outstanding returns, data evidence, responsibilities for warranty claims and the process for deleting or retaining provider-held data according to the agreement.

Choose a model that matches the organization’s capacity and risk. Establish who performs each task, under what terms and with what acceptance evidence, including responsibilities, exclusions, physical work and exit obligations.

How do you measure value and decide when to replace devices?

DLM creates value by making the full cost and operational performance of business devices visible across planning, acquisition, deployment, support, recovery and retirement.

Lifecycle cost, service outcomes and recovery value

Measure the whole lifecycle rather than the purchase price of a device. Relevant costs include acquisition or financing, configuration and administrative time, shipping, support, user or business downtime, repairs and spares, software and management subscriptions, loaners, storage, returns, sanitization and disposal. Include carrier or lease charges where they remain payable after an assignment ends. Subtract recovery value only when it is reasonably supported, such as proceeds from an actual resale or the accepted value of equipment prepared for reuse.

This is an operational cost view, not a universal accounting model. Finance should assess the actual purchase, lease or service arrangement. Avoid double-counting items bundled in a provider’s fee, and do not treat estimated resale value, avoided risk or hypothetical carbon savings as cash already recovered.

A useful worksheet separates costs into categories that have different owners:

Cost area	What to include
Acquisition and financing	Purchase price, financing charge, lease payment, DaaS fee and included services
Deployment	Imaging, configuration, enrollment, testing, accessories, packaging and freight
Operation and support	Management tools, applications, support time, spares, loaners and downtime
Recovery and repair	Return logistics, inspection, repair, parts, refurbishment and transport
End of life	Sanitization, platform release, storage, disposal, certificates and residual value

A fleet dashboard also needs service measures with explicit start points, end points and denominators. The following definitions are illustrative operating choices rather than industry benchmarks:

• Readiness time: measure from the approved request or approved stock allocation to the first successful user test, rather than from order placement alone. The successful test should confirm the required login, applications, access and multi-factor authentication. A separate delivery measure can run from dispatch to receipt, while an enrollment measure can run from registration or enrollment to management completion. This separation shows whether a delay arose in sourcing, transport, technical setup or the final user handoff.
• Repair turnaround: measure from receipt of the failed device by the repair party to completion of its repair and return to service. Track a separate replacement-readiness measure from the request for help or spare to the point at which the user receives a usable device. A ticket marked resolved is not enough if the failed unit remains in transit, the replacement has not been assigned or the original device has not reached its recorded disposition.
• Return rate: define one eligible-device cohort first: company devices whose departure or assignment-end event occurred during the stated observation window and whose contractual or approved return due date was on or before the measurement cutoff. Use as the numerator the members of that same cohort that were physically received by the cutoff. Use as the denominator all members of that cohort. This keeps the numerator and denominator aligned. A device whose return period has not expired by the cutoff is excluded from that cohort until it becomes eligible; a late device remains eligible and is not counted as returned until receipt is confirmed. Receipts from devices outside the cohort are excluded. A return label, carrier tracking update or remote-action submission is not receipt evidence. Receipt should be tied to the device’s persistent identifier, the expected custodian and an inspection or intake record.
• Inventory accuracy: compare the persistent device identifier and current state in the asset record with the corresponding records in management, ticketing, lease and service systems. Check at least assignment, custody or location, lifecycle state, condition and relevant contract or support status. Define expected exceptions before calculating the measure: a device in transit may legitimately be assigned to the previous custodian in one system and in return transit in another; a unit under repair may correctly appear as assigned to the service desk; and a recently received device may await inspection or sanitization before entering stock. These are timing or state differences to reconcile, not automatic errors.

Keep physical receipt, endpoint-data handling and identity access separate in these measures. A returned device is not a successfully recovered device until receipt is confirmed, and receipt does not prove that endpoint data was handled or that account and application sessions were closed. The leaver workflow should retain separate completion evidence for custody, device-data outcome and identity access. For example, a portal status can support the management record, but it cannot replace receipt evidence or an identity-process result.

Operational measures should complement the cost view:

• the proportion of devices in approved, supported configurations;
• the share receiving required operating-system, application and firmware updates;
• readiness and repair turnaround;
• return and receipt rates against assigned departures;
• accuracy of asset, assignment and custody records;
• reuse or redeployment of suitable recovered equipment;
• completed and accepted sanitization evidence;
• closure of physical, data and access exceptions;
• available spare capacity and time spent waiting for equipment.

Use an actual baseline when evaluating improvement. Compare equivalent fleets, workloads, locations and service scopes over the same period. A reduced order count may reflect better use of suitable stock, while shorter readiness time may reflect a tested deployment process. Neither should be attributed automatically to a particular tool or provider. NIST SP 800-124 Rev. 2 supports deployment testing and ongoing review, while NIST SP 800-88 Rev. 2 supports evidence that connects sanitization work to specific media and outcomes.

Benefits also need a mechanism. Suitable, visible spares can prevent an unnecessary purchase. A tested configuration and support route can reduce readiness delays. Accurate custody records can help locate missing equipment. Accepted sanitization evidence supports data-risk decisions and audits. Reuse and responsible recycling can preserve equipment resources, but any financial or environmental result should be supported by the actual outcome.

Keep evidence quality separate from cash savings. A completed portal action may improve recordkeeping without proving that a device was returned or its data erased. Likewise, evidence that sanitization was accepted reduces a different uncertainty from a lower purchase price. The measure should say which mechanism changed and which result followed.

A useful DLM scorecard therefore combines four things: total lifecycle cost, service performance, control completion and realized recovery value. It shows both whether the fleet is working and whether the organization can explain why the result changed. Connect the cost and operational measures so that invoice totals and dashboard figures can be interpreted together.

Repair, refresh or retire based on condition and support

A device should be repaired, redeployed or replaced based on its actual suitability for the work, not on its age alone. The decision combines physical condition, workload, compatibility, battery performance, repair cost, contract terms, residual value and the continuing support available for its software and firmware.

Start by defining what the device must still do. A laptop that runs administrative applications may be adequate after reassignment even if it is unsuitable for the developer workload it previously supported. A scanner with a failed screen may be repairable and suitable for a less demanding role, provided it is restored to a usable condition and meets that role’s requirements. Conversely, a device that powers on may still be unable to receive the operating-system or application updates required by the organization.

The repair case is strongest when the device is physically sound, remains compatible with the required workload and can operate within an acceptable support horizon. Compare the full cost of repair with replacement, including parts, labor, logistics, staff time and the disruption caused while the device is unavailable. A warranty or out-of-warranty repair service may extend the physical life of equipment, but it does not by itself extend the support life of the software running on it.

Hardware repair and software security support are separate questions. The Canadian Centre for Cyber Security’s obsolete-products guidance notes that a product can remain functional after support ends and recommends considering support longevity, update availability and security maintenance. A working device or a repair contract therefore does not prove that patches will continue.

Platform support policies can divide these periods further. Microsoft’s Surface driver and firmware lifecycle policy, for example, treats driver and firmware servicing separately from Windows operating-system support and OS lifecycle updates for Windows-based Surface devices. The exact periods and models vary, but the decision principle is portable: check the policy for the operating system, firmware or drivers, applications and other components used on the device.

Caption: Check actual repair terms and each vendor support policy. Repair coverage alone does not prove patch availability. For Windows-based Surface devices, driver/firmware servicing and Windows OS support have separate policies; no universal age applies. Canadian Centre for Cyber Security: obsolete products · Microsoft: Surface support policies

Contract commitments may affect the choice without determining the technical outcome. A leased device may need to be returned at the end of its term even if it could continue working. A service agreement may cover certain repairs while excluding issues such as liquid damage or accidental loss. Review the actual terms, warranty exclusions and end-of-term requirements rather than infer coverage from the label “managed service.”

Residual value should also be realistic. The organization should compare the likely value of retaining, repairing or redeploying the device with the cost and risks of the alternatives. An estimated resale price is not recovered cash, and a device that is merely labeled reusable is not available capacity unless it has been checked and prepared for its intended use.

Replacement can be necessary even when the hardware remains operational. If a supported configuration is unavailable for the required work, the device may need a deliberate transition rather than indefinite extension. The organization should record why it is accepting the security or support risk, what compensating controls apply if any, and when the transition will occur. The Canadian Centre for Cyber Security’s guidance recommends moving away from obsolete products and considering advance support-end notice; it does not impose one universal replacement age.

A staged refresh protects continuity. Replace one group at a time, test the new configuration and give affected users an overlap period for migration. A suitable device can be repaired and reassigned while another model or operating system is introduced. Significant changes should be tested before wider deployment, as NIST SP 800-124 Rev. 2 recommends for deployment changes and limited trials.

The practical decision follows from four questions:

1. Can the device perform the required work reliably?
2. Can its operating system, firmware and required applications continue receiving appropriate support?
3. Is repair or continued use cheaper and operationally safer than transition, taking account of downtime and residual value?
4. Do lease terms, warranties, data-handling requirements and reassignment constraints permit the chosen route?

The answer may differ by device. Repair and redeploy a supported unit that still meets a role’s needs. Refresh equipment that has become unsuitable or lacks a supportable software path. Retire it when repair, transition and reuse cannot meet the organization’s requirements. No fixed device age answers those questions by itself.

How do you establish a workable DLM process?

Begin by finding the gaps in the current lifecycle, then test a complete path through it before buying a platform or adding automation.

First, create an inventory that can be trusted. Record each device’s persistent identifier, model, ownership or financing arrangement, current custodian, location and condition. Add its software, warranty, support, lease, carrier and contract information where relevant. Flag devices with missing identifiers, unclear ownership, unsupported software, inconsistent records or no named person responsible for them. NIST SP 800-124 Rev. 2 supports using business and IT requirements together and provides the basis for deployment testing and ongoing review.

Next, classify the fleet by the management and support treatment each group needs. A company-owned laptop, a leased device, shared equipment and a personally owned work-profile phone have different custody, return, monitoring and data-handling boundaries. The classification should also capture operating-system and application support, device role, location and known exceptions. The Canadian Centre for Cyber Security’s obsolete-products guidance reinforces the need to track support status and update availability rather than discovering obsolescence when a device fails.

The gaps should determine the next work. If inventory accuracy is poor, fix identity and reconciliation before adding remote actions. If devices reach users without tested access or applications, improve deployment and acceptance. If returns are missing, build collection and receipt procedures. If support and sanitization evidence are weak, assign owners and required records for those tasks. A new portal cannot repair an undefined process; it can only make an existing process easier to execute.

Define the lifecycle states and their transitions next. A workable model may distinguish planned, ordered, received, in stock, assigned, in repair, returned, awaiting sanitization, redeployment-ready and retired. The labels should fit the organization, but each transition needs an event, an owner and the evidence that shows it occurred. “Assigned” and “in stock” should not be inferred from each other. A return request should remain separate from receipt, and a repair request from a completed repair.

Assign responsibility for each handoff. IT and security can own technical readiness, updates, endpoint-data actions and sanitization acceptance. Procurement and finance can own sourcing, leases, invoices and contract closure. HR or PeopleOps can supply joiner, mover and leaver triggers. Managers and users can confirm requirements, acknowledge receipt and report problems. Vendors can perform the physical tasks assigned to them. These roles vary by organization, but no significant handoff should have two implicit owners or none.

The next step is a limited, full-path pilot. A hypothetical remote hire and leaver can expose whether the process works as a whole. For the hire, order or reuse a suitable laptop, enroll and configure it, test the required login, applications and MFA, deliver it, record receipt and provide a named help route. A failed first-use test stays open until the device is corrected and retested.

For the leaver, run the branches in parallel. Track the identity and application-access closure, submit the appropriate endpoint action, arrange collection or handle the loss incident, and reconcile the lease, carrier and other billable services. The physical device must not be treated as recovered until receipt is confirmed. An endpoint command must not be treated as completed because its server-side status says so. For Intune, Microsoft explains that a completed Delete is server-side completion and does not confirm client-side Retire completion; Retire also does not revoke access tokens. See Microsoft’s device actions documentation and Intune device-action troubleshooting guidance.

The pilot must also exercise recovery and repair. Return a usable device, confirm its identity and condition, handle its data appropriately, reconfigure it and assign it to another role or place it in visible stock. Send another device for repair, issue a suitable spare and reconcile both records. Test sanitization on a representative device and compare the evidence with the intended destination. NIST SP 800-88 Rev. 2 distinguishes verification that the sanitization operation ran from validation that the outcome adequately protects the target data.

Train the people who will perform and use the process. Users need to know how to request equipment, test readiness, report loss or failure and return a device. Support staff need a consistent escalation path for setup, repair and recovery exceptions. Procurement, finance, PeopleOps and IT need to understand the triggers, records and acceptance points that they share. Training should include the failures observed during the pilot rather than only the intended workflow.

Finally, review the evidence. Examine readiness delays, incomplete returns, unresolved tickets, inventory mismatches, unsupported devices and missing sanitization or disposal records. Assign each exception to an owner and revise the policy, handoff or system that allowed it to remain unresolved. Then decide which additional integration or automation would remove a demonstrated coordination burden.

Scale from those results rather than from an arbitrary device count. A small, well-controlled fleet may need only a shared record and a disciplined exception queue. A larger or more dispersed operation may justify integrated asset, management, ticketing, people-event and service-contract workflows. The threshold for investment should reflect the number and cost of unresolved handoffs, not a universal benchmark.

A shared device identity, explicit states, named owners, tested handoffs and completion evidence give the process a practical foundation. Use the pilot and subsequent review to check whether those arrangements work in practice.