Every mobile phone on the planet carries a 15-digit identity string. Carriers use it to attach your SIM to the network, manufacturers use it to track warranty claims, and a global registry called the GSMA uses it to blacklist stolen devices across every operator in every country. That string is the IMEI, and if you have ever tried to generate a realistic one for a test fixture, a development environment, or a device-management sandbox, you have almost certainly hit the same wall: a number that looks right but fails the moment any production-grade validator touches it.
The reason is that an IMEI is not a random 15-digit number. It is a deliberately structured identifier with three non-negotiable parts, and a generator that gets any of them wrong produces output that a validator will reject on the first try. The good news is that the structure is fully documented and the math is simple enough to do in your head. This post walks through the three things every IMEI generator must get right, the Luhn shortcut that lets you validate the result in under thirty seconds, and the three traps that turn a “valid” IMEI into a silent failure in production.
What an IMEI actually is
An IMEI is fifteen digits long, but the three logical fields inside it have very different jobs. Reading from left to right:
- TAC (Type Allocation Code, 8 digits) — the first eight digits identify the model of the device, not the individual phone. The first two of those eight are the Reporting Body Identifier (RBI) — 35 is always an Apple iPhone, 49 is a Samsung, 86 is a Huawei, 01 is a Nokia from the old days, 99 is a test allocation that the GSMA explicitly reserves for development hardware. The remaining six digits of the TAC are model-specific and are assigned by the GSMA to the manufacturer.
- Serial number (6 digits) — the next six digits identify the individual device within that model. This is the part that varies unit-to-unit off the assembly line.
- Luhn check digit (1 digit) — the final digit is not random. It is computed from the first fourteen digits using the Luhn algorithm, and it is what lets any validator in the world confirm the rest of the number is structurally sound without having to look it up in a database.
There is a sibling identifier called the IMEISV (IMEI Software Version) that is sixteen digits long and reserves the last two digits for a software-version code instead of a check digit. Most production validators accept either, but the fifteen-digit IMEI is the form the GSMA’s Equipment Identity Register (EIR) actually stores.
So the generator’s job is: pick a real-looking TAC, draw six random digits for the serial, and compute the right check digit for the combination. Get any one of those three wrong, and the result fails validation. Let us walk through each one.
The three things a generator has to get right
1. The TAC has to come from a real allocation table — or at least look like one
This is the rule people break most often. A generator that does not know about the RBI space will happily produce an IMEI starting with 10, which is a TAC prefix the GSMA has never assigned. A production EIR will flag it as structurally invalid before the Luhn check even runs. You do not need to ship with the full GSMA database, but you should at minimum restrict the first two digits to one of the live RBIs: 01, 35, 49, 86, 91, 98, 99, and a dozen or so others. If you are generating test fixtures, the safest default is RBI 99 (test allocations) or a known-good RBI from a real model you are actually emulating — 49015420 is a Samsung allocation you can verify in any TAC database.
The TAC also has to be exactly eight digits. A common bug is a generator that produces a seven-digit prefix and pads with a leading zero — that produces a TAC that no real device has ever used, and a careful validator will catch it.
2. The middle six digits have to be uniformly random
The serial number field is the easiest part to get right, and the easiest part to get dangerously wrong. A serial that comes from a deterministic PRNG seeded with the same value on every run will produce a recognizable pattern, and any batch of test IMEIs that all share a serial prefix will fail randomization audits in any MDM platform that bothers to check. Use a cryptographically secure random source for these six digits. crypto.randomInt in JavaScript, secrets.randbelow in Python, RandomNumberGenerator in Go — any of these is fine, the point is that the per-device serial must be uniformly distributed across 000000–999999 and must not correlate with the TAC.
The six digits have to be six digits, including leading zeros. 042318 is a valid serial; padding it to 42318 for display and then forgetting to pad it back when you assemble the IMEI is a classic generator bug.
3. The Luhn check digit has to be the one that validates the rest
This is the only part of the IMEI that the standard requires to be computed rather than generated. The check digit is not free to be anything — it has to be the single value that makes the full fifteen-digit number pass the Luhn algorithm. A generator that picks a random digit for the last position and hopes for the best will produce IMEIs that look like noise to validators. The right approach is: generate the first fourteen digits, then run the Luhn computation against them, and use the result as the fifteenth digit. There is no faster way, and every shortcut you see online that promises to skip the computation is wrong.
The Luhn shortcut nobody tells you about
The Luhn algorithm is the same one used to validate credit card numbers, Canadian SIN numbers, and a handful of other identification formats. It is a single-pass checksum designed to catch any single-digit error and most transposition errors. Here is the entire algorithm applied to an IMEI:
Starting IMEI (first 14 digits, check digit not yet computed): 49015420342351? — the ? is the placeholder where the check digit will go.
- From the rightmost digit (the
?position), double every second digit moving left. So we double the 5, the 3, the 2, the 0, the 4, the 1, the 9. We leave the 1, the 4, the 5, the 0, the 3, the 5, the 4 alone. - After doubling, add up all the digits. The doubled values that were 10 or more contribute both their digits to the sum (e.g., doubled 9 = 18, contributes 1 + 8 = 9 to the sum).
- The check digit is whatever value makes the total sum a multiple of 10.
Walking through it for 49015420342351?:
- Doubled digits, left to right: 8, 2, 10 (1+0=1), 4, 4, 0, 18 (1+8=9).
- Undoubled digits: 4, 0, 5, 4, 0, 3, 5, 1.
- Sum = 8 + 2 + 1 + 4 + 4 + 0 + 9 + 4 + 0 + 5 + 4 + 0 + 3 + 5 + 1 = 50.
- 50 is already a multiple of 10, so the check digit is 0, and the full IMEI is
490154203423510.
The shortcut nobody tells you about: if you are validating an existing IMEI rather than generating one, you do not have to walk the digits left to right. Take the first fourteen digits, apply the same doubling pattern, sum the digits, and add the final digit. If the total is a multiple of 10, the IMEI is structurally valid. This is what every production EIR does, and it runs in microseconds.
There is one more shortcut worth knowing: the doubled-digit sum for a 14-digit number is always between 0 and 126, so the check digit has only ten possible values, and the search space for brute-forcing an IMEI from a known TAC is exactly ten attempts per TAC. That is why IMEI security relies on the EIR blacklist, not on the Luhn check.
When a “valid” IMEI is still wrong
Even with a correct Luhn check digit, three patterns will turn a “valid” IMEI into a silent failure in production.
Trap 1 — fabricating a TAC that the GSMA has not assigned. The Luhn check only proves structural validity, not that the device exists. A validator that cross-references the TAC against the GSMA’s allocation database will reject any TAC prefix that has not been registered. A generator that picks a random eight-digit prefix will produce a structurally valid IMEI roughly 10% of the time (Luhn success rate) but a database-valid IMEI with effectively zero probability. For development fixtures, either use RBI 99 (test allocations) or hard-code a real TAC you have verified.
Trap 2 — the 14-digit vs 15-digit confusion. The IMEISV format is sixteen digits and uses the last two for a software version, with no Luhn check. A generator that emits fifteen digits but applies the IMEISV structure (check digit as a software version) will produce numbers that look like IMEIs but fail Luhn validation. If your tool advertises IMEI output, the fifteenth digit must be the Luhn check, full stop.
Trap 3 — the parity-bit / SV-bit confusion in some legacy EIR implementations. A few older EIR systems store an “SV flag” alongside the IMEI and reject any IMEI where the SV flag and the actual fifteenth digit disagree. This is rare in modern systems but does happen in some carrier-side implementations from the early 2010s. If you are generating IMEIs for a device-management system that predates 2018, double-check whether it expects the IMEISV form.
When you actually need a generated IMEI
Generated IMEIs are useful in a small but well-defined set of contexts. The most common: test fixtures for a mobile-application development pipeline, where you need a valid-looking IMEI to seed a device profile but you do not want a real production device’s IMEI in your logs. The second: MDM sandboxing, where a device-management platform like Intune, Jamf, or Kandji expects a real-looking IMEI in its enrollment payload and rejects the field when it fails Luhn. The third: repair-shop asset management, where a technician needs to register a board-swap or a refurbished device and the new IMEI must validate against the EIR before the device is allowed back on the carrier network. The fourth: end-of-life device wiping, where a decommissioned device’s IMEI needs to be replaced in internal records with a non-traceable but valid-looking identifier before the device is physically destroyed.
For all four use cases, the requirement is the same: the IMEI must be structurally valid (Luhn passes), must come from a recognized RBI prefix, and must not collide with any IMEI the production EIR has ever seen. The first two are mechanical; the third is what makes a generated IMEI different from a counterfeit one.
If you are looking for a tool that handles all three, the IMEI Generator at Elysia Tools lets you generate batches of up to one hundred IMEIs at a time, optionally anchored to a specific TAC prefix if you want a particular manufacturer in your fixtures, and every number it produces passes the Luhn check on the first try. It also lets you inspect the TAC, serial, and check-digit fields independently, which is the only way to debug a “the validator says my IMEI is bad but I generated it correctly” situation. The full implementation, including the Luhn walk-through above, runs in a few milliseconds per number, and the output is plain text you can paste into whatever test fixture or MDM payload needs it.
Generate a few, paste them through any Luhn validator you trust, and you will see why the algorithm is worth understanding: it is the difference between a test fixture that survives contact with a production system and one that fails the first time a careful validator looks at it.
Explore more tools at elysiatools.com.
