HAM for Mobile Devices
Phones and tablets are not small laptops. Faster lifecycles, different identifiers, MDM as the operational reality, and lost-or-stolen response on a clock measured in hours, not days.
Last reviewed on 2026-04-27
Why Mobile Devices Need a Distinct Playbook
The standard HAM model maps cleanly onto laptops and servers. Mobile devices break enough of its assumptions that pretending they are "just smaller laptops" produces real problems. Phones and tablets identify themselves with IMEIs and eSIM identifiers rather than serial-number-and-MAC. They depreciate faster, churn faster, and walk out of buildings more often. Their connectivity passes through carriers as well as Wi-Fi, which means a carrier account is part of the asset picture. And the operational center of gravity for managing them sits in the mobile device management (MDM) platform, not in the HAM system.
The right model is to treat HAM as the system of record for the asset (ownership, cost, custody, disposal) and the MDM as the source of operational truth (what the device is doing right now, where it last checked in, whether it is encrypted). Each system has authoritative answers to different questions; the integration between them is what makes the picture complete.
What Counts as a Mobile Device
The HAM-tracked mobile population, in roughly descending order of how rigorously to track:
- Smartphones (corporate-owned). Highest scrutiny: high turnover, high theft risk, high data exposure, carrier costs.
- Tablets. Smaller fleet in most organizations, longer life than phones, often deployed for specific roles (field service, retail, healthcare bedside).
- Cellular-connected laptops. Treated as laptops with a SIM/eSIM attribute, but the carrier-account side belongs in mobile-device workflows.
- Ruggedized devices. Industrial scanners, healthcare carts, point-of-sale tablets. Lower turnover, more demanding repair workflows.
- Mobile hotspots. Carrier-connected access points; tracked because of the carrier account and SIM more than the hardware value.
- Wearables. Smartwatches and similar; often below the threshold for full asset tracking but worth tracking when issued for specific role-based purposes.
Personal smartwatches paired to corporate phones are not company assets; the corporate phone is. The boundary follows ownership, not connectivity.
Identifiers: IMEI, eSIM, and What They're Good For
Mobile devices carry several identifiers, each with its own role.
| Identifier | Purpose | Notes |
|---|---|---|
| Serial Number | Manufacturer support, warranty | Apple uses serial; some Android vendors use serial; both work for warranty. |
| IMEI (or MEID on older CDMA) | Carrier identification of the device on cellular networks | Two on dual-SIM devices. Required for blocking a stolen device from networks. |
| ICCID | SIM card identifier | Changes when the SIM is swapped — separate identity from the device itself. |
| eSIM EID | Embedded SIM identifier | Burned into the device; activations are by profile, not by physical card. |
| Phone Number (MSISDN) | Reachability; carrier account reference | Belongs in HAM as an attribute, but it can change without the device changing — handle as a current-value attribute, not a primary key. |
| MDM Device ID | The MDM platform's identifier | The bridge from HAM to operational reality. |
| UDID / Apple ID / Google account binding | Identity for app store and ecosystem services | Less stable than serial; tracked on the MDM side, referenced from HAM only when needed. |
For HAM purposes, the load-bearing identifiers are serial number, IMEI, and MDM device ID. Phone number and SIM identifier are attributes that change during the device's life. eSIM EID matters when a device supports profile-based activation; capturing it once, when received, costs nothing and avoids future confusion.
MDM as the Operational Twin of HAM
HAM tells you the company owns this device, what it cost, who it's assigned to, and what its disposal evidence looks like. The MDM tells you whether the device has checked in today, whether encryption is enabled, what OS version it's on, and whether it's been jailbroken or rooted.
What HAM Pulls From MDM
- Last check-in time. A device that hasn't reached the MDM in 30 days is either lost, stolen, or with someone who left without returning it. The threshold is configurable; the alert behind it should exist.
- Encryption status. Mandatory for almost all corporate use; HAM should record it as an attribute synced from the MDM, with non-encrypted devices flagged for investigation.
- OS version. Old OS versions stop receiving security updates. The MDM has the version; HAM uses it for refresh and compliance reporting.
- Jailbreak / root status. A jailbroken corporate phone is a security incident; the MDM detects it, the HAM record shows it as a flag for the security team.
- Compliance posture. Most MDMs evaluate a set of policies (encryption, passcode strength, OS version, etc.) and report a single compliance state per device. HAM consumes this as an attribute.
What HAM Pushes to MDM (or Validates Against It)
- Assigned user. The MDM uses this for self-service portals and notification targeting; it should match HAM, not drift independently.
- Asset tag and cost-center attributes. Many MDMs support custom attributes; populating them from HAM lets MDM reports use the same identifiers HAM does.
- Lifecycle state hints. A device HAM marks as Retired should be removed from MDM; a device HAM marks as Lost/Stolen should trigger MDM lock or wipe (depending on policy).
Devices in HAM but Not in MDM (and Vice Versa)
Both directions are worth investigating:
- HAM record exists, MDM record doesn't. Usually a device that was issued without enrollment, or a device that was wiped and never re-enrolled. Either way, the device is operating outside the management plane and should be enrolled or recovered.
- MDM record exists, HAM record doesn't. Usually a personally owned device that was enrolled into a corporate profile, an acquisition that brought in unmanaged devices, or a record migration gap. Investigate per device.
Reconciling the two is the equivalent of the reverse-test in the audit methodology guide, applied specifically to the mobile fleet.
Carrier Accounts and SIM Management
The hardware side of mobile device HAM is only half of the asset picture. The carrier account — the contracts, the lines, the data plans — is the other half, and it can drift independently.
- Lines and devices are separate. A line can move between devices when a SIM is swapped or an eSIM profile is reassigned. HAM records the current device-to-line binding as an attribute, with date.
- Suspended lines are common ghosts. Lines whose devices have been retired but whose accounts were never closed continue to bill. The mobile-device equivalent of a software license assigned to a separated employee.
- International roaming and data plans. Often role-based attributes that move with the user, not with the device. Tracked at the line level rather than the device level.
- BYOD with corporate plan. Some organizations pay for service on personally owned devices. The line is in HAM; the device is not. Treat the line as the asset record in this case.
The carrier portal is usually the source of truth for line-level state; reconciling it against HAM monthly catches both unexpected charges and devices that have been lost without anyone formally reporting them.
BYOD vs Corporate-Owned
The choice between BYOD (bring your own device) and COBO (corporate-owned, business-only) — and the variations between them — has direct HAM implications.
| Model | Who Owns the Device | HAM Treatment | MDM Scope |
|---|---|---|---|
| COBO (Corporate-Owned, Business-Only) | Company | Full asset record, full lifecycle | Full management; restrictive policies acceptable |
| COPE (Corporate-Owned, Personally Enabled) | Company | Full asset record, full lifecycle | Full management with personal-use carve-outs |
| BYOD with MDM | Employee | No asset record (or a minimal one tied to the line if the company pays for service) | Limited: corporate work profile or app management only |
| BYOD without MDM | Employee | Not in HAM; not in MDM | None — typically restricted to web-based access only |
The HAM rule of thumb: if the company owns the device, it's a HAM asset all the way through to disposal. If the company owns only the service, the line is the asset. If neither, HAM has no record at all and the security boundary is enforced through identity and conditional-access policies, not through asset management.
Lost or Stolen Device Response
Mobile devices are the asset class most likely to actually go missing. The response procedure has to be fast and rehearsed, not improvised at 9pm on a Saturday.
Hour One
- Confirm the report. User reports the device lost or stolen via help desk, security hotline, or self-service portal. Capture: when last seen, where, whether passcode-locked, whether they tried Find-My-Device, whether police are involved.
- Pull HAM and MDM records. Identify the device, its IMEI, its assigned user, its data classification, its last MDM check-in, and its encryption status.
- MDM action. Issue Lost Mode (locks the device, displays a recovery message, captures location if possible) or Remote Wipe — the choice depends on data sensitivity and the likelihood of recovery. Lost Mode is reversible; Wipe is not.
- Identity action. Revoke the device's certificates and refresh tokens so it cannot resume corporate access if it is unlocked elsewhere.
- HAM update. Status moves to Lost/Stolen with the report timestamp and the actions taken.
Hour Two to Twenty-Four
- Carrier action. Suspend the line to prevent unauthorized usage charges. Do not cancel yet — a suspended line preserves the option to restore service if the device is recovered.
- IMEI block (theft cases). Report the IMEI to the carrier as stolen so the device cannot be activated on the same network. Many countries also share IMEI blocklists across carriers.
- Police report. Required for theft cases and for any insurance claim.
- Data exposure assessment. Was the device encrypted? Was it locked? What data classifications was it cleared for? The answer drives whether breach-notification obligations are triggered.
Day Two to Seven
- Recovery or replacement. If the device is recovered, restore it via the MDM (or wipe and re-enroll if there is any doubt). If not, issue a replacement and complete the insurance/warranty process for the missing device.
- HAM closeout. Recovered: status returns to Deployed. Not recovered: status moves to Disposed/Lost-Stolen with the disposition evidence (police report number, insurance claim, carrier IMEI-block confirmation).
The Pattern Detection Layer
One lost device is an incident. A pattern of losses concentrated in one role, one site, or one user is a control problem. HAM should keep the historical record long enough to support this analysis — even after a device is disposed of, the record of the loss is part of the loss-rate metric.
Lifecycle Specifics
The lifecycle stages from the main lifecycle guide apply, with mobile-specific timing and details.
- Receive. Photograph the box (it carries the IMEI) and the device. Capture serial, IMEI, eSIM EID, model, and color. Apply asset tag — for phones, an interior tag (battery cover or bottom of the case) plus an external small tag is the typical approach.
- Provision. MDM enrollment via Apple Business Manager or Android Enterprise zero-touch enrollment (where supported). The provisioning is what binds the device to the corporate identity layer.
- Deploy. Hand over with the carrier line activated, MDM enrolled, encryption confirmed, and a signed acceptable-use acknowledgement (the same evidence requirement as laptop deployment).
- Maintain. Most "maintenance" is software: OS updates, app updates, MDM policy changes. Hardware maintenance is usually limited to battery health monitoring and screen replacement.
- Refresh. Typical refresh cycle is 2–3 years for phones, 3–5 for tablets. Often driven by OS support windows rather than hardware aging — a device that no longer receives security updates is effectively at end of useful life regardless of its physical condition.
- Retire. Sanitize, eject the SIM and destroy or reuse it, deactivate the carrier line or transfer it to the replacement device, remove from MDM, update HAM. The ITAD guide covers the sanitization piece in depth.
Sanitization Specific to Mobile
Mobile devices store data in flash memory with hardware-backed encryption on most modern platforms. The sanitization implications:
- Crypto erase is the practical default. A factory reset on a modern iOS or Android device discards the encryption keys protecting user data, rendering the data unrecoverable. This is acceptable under NIST SP 800-88 Purge for most data sensitivities, provided device encryption was enabled (which it is by default on managed devices).
- Multi-pass overwrite is not applicable. Flash storage controllers don't expose the underlying blocks the way HDDs do; software overwrite passes don't reach what they think they're reaching.
- Physical destruction for highest sensitivity. Devices that handled top-secret or particularly sensitive regulated data are physically destroyed regardless of the encryption story. The certainty is worth the lost residual value.
- Removable media. SD cards in older or ruggedized devices have to be sanitized separately — they are not necessarily included in the device's encryption boundary.
- SIM cards. Eject and destroy or repurpose deliberately. SIMs hold credentials for the carrier network and, for some uses, additional cryptographic material.
Common Mistakes
- Treating IMEI as the primary key. Dual-SIM devices have two IMEIs. Use serial number as the primary key and store IMEIs as attributes.
- Tracking the phone number, not the device. Phone numbers move between devices; if HAM records use the number as the identifier, swapping a SIM creates a "ghost" device.
- Treating BYOD devices as company assets. Pollutes the HAM register with records the organization has no authority to dispose of. The line is the asset; the device isn't.
- Ignoring the carrier account side. The hardware fleet is reconciled, the carrier bill isn't, and three years of suspended-but-still-billed lines accumulate.
- Not testing the lost-device response. The first time anyone uses the procedure is a real lost-device incident, and the gaps surface under pressure. Tabletop the procedure once a quarter.
- Skipping factory reset before redeployment. Reissuing a phone without resetting it preserves the previous user's accounts in unobvious places (saved Wi-Fi networks, certain app caches). The reset is non-negotiable between users.
- Forgetting eSIM cleanup. Disposing a device with an active eSIM profile can leave the line attached to it; the carrier might not bill, but the recovery later is awkward. Deactivate eSIM profiles as part of decommission.
Metrics to Track for Mobile
- MDM enrollment rate. Percentage of HAM-deployed mobile devices that are enrolled in MDM and have checked in within the policy window. Target: ≥98%.
- Encryption posture. Percentage of MDM-enrolled devices reporting encryption-enabled. Target: 100% for managed corporate devices.
- Loss/theft rate per 1,000 devices per year. Driven by industry, geography, and role mix. Track the trend more than the absolute number.
- Time to MDM action on loss. Hours between loss report and Lost-Mode or Wipe being executed. Target: under one hour during business hours, under four hours otherwise.
- Recovery rate on separation. Same metric as the rest of HAM, but separately for mobile because the rate is usually different (often lower) than for laptops.
- Suspended-line accumulation. Carrier lines whose corresponding devices are no longer Deployed. Target: zero standing for more than 30 days.
Next Steps
Remote Work HAM
Mobile devices are the most-remote of the remote fleet; the shipping, security, and recovery procedures live there.
Read the remote work guide →Onboarding & Offboarding
The IT-side procedure for getting a phone into a new hire's hands and recovering it on the last day, including carrier-account closeout.
Read the onboarding guide →ITAD & Disposal
Crypto-erase, physical destruction, and the sanitization standards that apply to mobile devices specifically.
Read the ITAD guide →