Definition
IMEI (International Mobile Equipment Identity) is the global unique identifier of a mobile device, usually consisting of 15 digits (or 14 digits + check digit). The IMEI, together with the ICCID card identifier, is used for device-SIM binding, Card Diagnostics, usage attribution, anti-theft and blacklist scenarios, and is one of the important identifiers for IoT connection management.
Structure and Application
IMEI is composed of TAC (Type Approval Code), FAC (Final Assembly Code), SNR (Serial Number), and CD (Check Digit). When a device attaches to the network, it may report the IMEI to the core network. Operators and platforms can use this to identify device models and perform Card Diagnostics diagnostics. ICMP supports IMEI and ICCID binding to achieve "one device, one SIM" control; it supports IMEI blacklists to prevent stolen devices from accessing the network; CDR may include IMEI for usage attribution and anomaly analysis.
Privacy and Compliance
IMEI is a device identifier, and some regulations consider it as information that can be associated with an individual. The platform needs to comply with requirements like GDPR by clearly defining the purpose of IMEI collection, retention period, and supporting data subject rights. In Audit Trail and logs, IMEI can be stored in a de-identified manner to reduce the risk of leakage.
Implementation in ICMP
SimtoLink ICMP supports IMEI entry, binding with ICCID, and Card Diagnostics queries; supports IMEI blacklists and whitelists; RESTful API allows querying device and card information by IMEI; meets compliance requirements for IMEI storage and processing.
Device Identity and Subscription Identity
An international mobile equipment identity names the handset or the communications module, the hardware. It is usually a type-approval code, a serial number, and a check digit. It answers which device is trying to join the network. It does not answer which carrier this SIM is subscribed with. The subscription identity lives in the subscriber identity on the SIM. The SIM’s own serial number is a different string. Connectivity management binds the device identity to the SIM identity so it can see a SIM moved onto an unplanned device, or a device whose module was swapped for one that was never registered. In diagnostics, the device identity also helps tell a model-wide failure from a problem on a single SIM.
Use a device identity only when the purpose of collection, the retention period, and who may view it are already clear, and when the value the device reports can be trusted. Some modules can be configured not to report. If the site turns reporting off, the platform sees only the SIM, not the device. A deny list is suitable for stopping a known stolen or scrapped device from continuing to use a registered SIM, but the list needs a source and a removal process. Recording the device identity that first appears at activation, and alerting when a later attach changes it, is more reliable than hunting through CDRs afterward. A device identity is not an account, and it is not a sign-in credential.
Wrong Binding after a Module Swap or a Cloned Report
Replacing the module during repair is the most common source of a wrong binding. The old device identity stays on the SIM, and the new module is treated as an unexpected device as soon as it attaches, sometimes enough to trigger suspension. If the system keeps only the latest report and not the time of the change, there is no way to show that this was a legitimate repair. Another error is to treat the device identity as globally unique and unchangeable. Some terminals report an incomplete number, or the production line writes a duplicate value. Merging usage only by device identity counts traffic from several devices onto one record.
Do not let the device identity stand in for the SIM lifecycle. Scrapping a device does not mean the SIM may continue on another device without provisioning. After the SIM is decommissioned, the old device identity should not automatically pass to the next SIM. When a device identity crosses a border, use it only for the purpose agreed when it was collected. Where a log can be masked, do not keep the full number. A binding should record which SIM, which device, and from when until when, not only a current value.
If the check digit does not pass, do not write that number straight onto a deny list. Send it back to the site first, and confirm whether the report was truncated or the module was misconfigured. Duplicate numbers written on the production line should be marked on their own. They must not share a block reason with a stolen device. A module-replacement ticket should record the old number, the new number, and the time of the swap. Later CDRs should be compared with the new number only after that time, so a normal attach on the day of repair is not counted as a cloned device.
The type segment inside a fifteen-digit identity only says where that device model was type-approved. It does not replace the serial of one device. Many devices of the same model share the type segment. Counting failures by type segment can show a hardware problem common to a batch. It cannot justify suspending every SIM of that model. The serial is what points to one device. The check digit is for catching a transcription error. When the check fails, read the number again. A truncated number is not another device.
An extended report that carries a software version is not the same field as the base identity. A version change may only be a module firmware update. The hardware has not been replaced. If a version change is treated as a device replacement, the repair log fills up and a real module swap is buried. The binding rule should say that only a change in the base identity raises a rebind alert. A version change is recorded on its own and does not suspend automatically. A multi-module device must also be allowed to map one SIM to several identities, or a gateway may sit in front of sub-devices that do not report on their own. Do not force one SIM to one identity.
Limit collection to the comparison connectivity management needs. Do not put the identity and personally identifiable account information in the same export unless that is necessary. When supporting an outside party, give the last few digits if the full number is not required. Adding to and removing from a deny list both need a ticket reason. After removal, a new attach is treated as legitimate again. Historical alerts from before the removal stay, so the audit chain is not rewritten.