Do you have old smartphones sitting in a drawer or cabinet at your desk?  Many people do. Establishing a robust mobile asset management and recovery solution—also known as IT asset disposition (ITAD)—would almost certainly be worthwhile for most organizations. However, it can also be extremely challenging to implement.

Let’s start by determining the circumstances in which hardware should be recovered:

  1. Employee exit: This scenario would include voluntary exit, non-voluntary exit, or retirement of an employee with a mobile device.
  2. Change in ownership model: This scenario would include the shift from corporate ownership to personal ownership of the mobile device.
  3. Shift in role: This scenario would involve an employee shifting roles which would require an alternate device or no device at all.
  4. Damaged device: This scenario would obviously include a damaged device, but that damage could be in-warranty or out-of-warranty (including water damage).
  5. Irrecoverable device: This scenario is similar to a damaged device but would refer to situations where the device cannot be recovered to a productive state.  For example, troubleshooting efforts may be exhausted, or the device may be locked out due to a forgotten passcode or activation lock.
  6. Upgrade / Hardware refresh: This scenario would be due to an upgrade of the device or a mass refresh of devices. 
  7. Project completion: This scenario would be the recovery of hardware after it has served its purpose for specialized projects.  This would typically be for specialized deployments like customer or patient-facing applications or for re-imaging after being deployed for a specific purpose.

A robust ITAD program would start with automated procedures and communication to prompt users or managers to return devices to the centralized facility for processing.  Once again, we are assuming we have solved the significant challenge of associating the device to be returned with the appropriate user and manager.  Automation is important here to ensure auditability of the device from the initiation of the process to the final action related to the device (including the possibility of identifying the device as lost/stolen).  Automation is also essential to allow for process-driven escalation of communication.  For example, let’s assume a user is upgrading their existing device, and the system/solution has identified that their old device should be returned.  The communication procedure could proceed as follows:

  • Upon upgrade, the end-user receives an email that includes a warning that they will have to return their old device and a link for return instructions.
  • Three weeks after the new device has been sent, an automated email goes to the end user with a reminder and instructions.
  • Four weeks after the new device has been sent, another automated email but with the direct manager copied.
  • Five weeks after the new device has been sent, another automated email with the direct manager, the director, and the mobility program lead.

The return procedure could take place in any number of ways.  The return instructions to an individual user could include a shipping label to allow for a direct shipment of their individual device.  However, this could get costly due to the quantities.  For most return scenarios outlined above, there is no urgency for the return shipment.  If there is no urgency, a more common procedure would be to send or drop off the device to a staging location or locations within the organization.  From there, devices can be shipped in bulk.

Upon arrival of the returned device at the reclamation facility, a precise workflow should be followed, and those tasks should be captured in the associated IT service management (ITSM) ticket for that specific return.  Here are activities that may be executed along with some details for each:

  • Capture of device details
    Common information would include date of device receipt, device serial numbers, make, model, memory, quality (see below), and ultimately the action taken with the device.  Additional accessories and pieces of hardware should be included in the information captured as well, such as cases, SIM cards, and especially media cards.
  • Completion of a visual mechanism inspection (VMI) and/or on-device diagnostic
    This will be an important step to determine the subsequent procedure to take.  In case the device is of high quality, it may be slated for entry to the spare pool or for resale.  In case of damage, this activity will be important for the repair vendor to confirm if the device can be repaired or is covered under warranty.
  • Removal of the device from vendor systems and wiping of data
    Examples of applicable vendor systems would be Apple device enrollment program (DEP), Samsung Knox mobile enrollment (KME).  This is an essential step for two reasons.  First, in case the device is resold, this will prevent the device from automatically attempting to enroll in the corporate endpoint management solution.  Second, in case the device is resold, this will allow the device to subsequently operate upon factory reset.  Performing a wipe or factory reset is also an important step.  In some cases, a more detailed scrubbing procedure may be required by some organizations.
  • Submit device for repair
    Obviously, for warranty replacement devices, a repair or replacement exercise will take place.  Typically, when it comes to the end-user, organizations will replace a damaged device with a spare pool device, regardless of warranty coverage, in order to minimize downtime.  Therefore, when the repaired or replacement device is received, it would be added to the spare pool inventory rather than being returned to the end user.  For non-warranty replacement, a cost threshold would typically be identified to confirm if a repair is worthwhile.  This exercise should also take into account shipping costs.  In this workflow, it would be important not to close the ITSM ticket until the device has been returned or replaced.
  • Add device to spare pool inventory
    In a well-thought-out ITAD program, many devices will begin to get returned that are perfectly operational, typically from the employee exit scenario.  Upon capturing device details and the completion of VMI, it would typically be suggested that the device be added to the spare pool inventory for future use cases.  Maintaining a healthy spare pool could significantly lower costs for hardware as out-of-contract hardware purchases could largely be avoided.  However, it is important not to maintain too much inventory in the spare pool as a device refresh may be upcoming, and excessive inventory would largely be wasted at that time.  Therefore, if the spare pool inventory is exceeded, the resale of returned hardware would be recommended.
  • Submit device for resale
    There is a very healthy market in the industry for the resale of old mobility hardware.  An agreement should be put in place with a resale vendor.  Returned devices that are not ultimately destined for the spare pool should typically be slated for resale, assuming that they are of sufficient quality.  It would be reasonable to assume that a well-thought-out ITAD program will be cost-effective, even when taking into account the cost of the program and shipping costs.
  • Submit device for destruction
    Most resale vendors will also destroy and recycle devices that are not deemed to have value.  Some reimbursement from the precious metals can be expected as part of this exercise, but this is typically minimal.  The determination of a device being slated for destruction or resale will be based on a combination of the make/model of the device and the quality, both of which can be documented and assessed upon receipt of the device at the reclamation facility.
  • Submit device for forensics
    This would be a specialized destination for returned hardware.  There may be circumstances in which corporate and insider threat investigations are required.  This would include activities such as employee misconduct, IP theft, fraud, data exfiltration, and root cause analysis.  Highly specialized vendors do exist to cover this circumstance, and this can be deemed applicable depending on the returned device circumstances, escalations from corporate security, or even the user segment where the device originated.
  • Submit device for legal hold
    Similar to forensics, the requirement for legal hold would be a specialized destination for returned hardware.  However, in this case, the requirement is not for the hardware, but the underlying data.  If a legal hold is required, the data on the device can be backed up in a recoverable and secure state, allowing for the hardware to be processed as per the above circumstances.  Stratix has encountered scenarios in which an organization required infinite legal hold on devices resulting in an ever-increasing stockpile of hardware.  In such a case, a process of secure data extraction and storage would be recommended.

There are additional details and tasks involved in each of the activities captured above.  Certainly not all extreme use cases must be put in place, and the implementation of such a program can be phased.  However, the complete lack of such a program is not recommended, given the potential benefit from a financial, security, and productivity perspective.