IMEI / Device Identifier: Data Point Intelligence Guide

An IMEI identifies a handset, not a person and not a phone number. Confusing device identity with subscriber identity is the fastest route to accusing the wrong person.

Understanding the IMEI / Device Identifier as an intelligence artifact

An IMEI is a fifteen-digit identifier for mobile equipment defined in 3GPP specifications. The first eight digits form the type allocation code, assigned by the GSMA to a specific make and model of device. The following six digits are the manufacturer's serial number within that model, and the final digit is a Luhn check digit. The IMEISV variant replaces the check digit with a two-digit software version. Dual-SIM handsets carry one identifier per radio, usually issued sequentially.

The type allocation code is the analytically useful portion: it identifies manufacturer, model and often the regional variant, which in turn indicates supported bands, capabilities and likely market of sale. Networks record the identifier at attachment and store it in equipment identity registers that maintain blacklists of devices reported stolen. Counterfeit and reflashed handsets carry duplicated, invalid or all-zero identifiers, breaking uniqueness entirely.

Why it matters

The identifier separates device from subscriber, which is exactly the distinction that matters when SIM cards are swapped to defeat number-based tracking. A handset appearing under successive subscriber identities is a strong link between those identities. The type allocation code tells you what hardware a subject actually uses, which drives forensic acquisition planning, capability assessment, and the plausibility of claims about what a device could or could not have done.

What analysts actually look for

These are the concrete, observable signals that carry weight in this area of work:

• The type allocation code identifies manufacturer, model and market variant, defining device capabilities and supported bands.
• One identifier observed across multiple subscriber identities links those identities to a single physical handset.
• Sequential identifiers across a group of devices indicate a bulk purchase drawn from one production batch.
• Invalid check digits or all-zero identifiers indicate spoofed, reflashed, counterfeit or engineering test devices.
• Blacklist status shows the device was reported stolen and, importantly, in which market that report was filed.
• Device model and firmware version determine which forensic acquisition methods are technically viable.
• Regional model variants indicate where the handset was originally sold, potentially contradicting claimed provenance.
• Duplicate identifiers appearing simultaneously on different networks indicate cloned or counterfeit hardware.

Where the data comes from

Authoritative and openly available collection points. Always confirm licensing and terms before operational or commercial use:

• GSMA TAC allocation and IMEI database — Authoritative mapping of type allocation codes to device make, model and variant.
• 3GPP TS 23.003 — Specification defining identifier structure, the IMEISV variant and check digit rules.
• Public TAC datasets — Open lists mapping allocation code prefixes to models where industry access is unavailable.
• GSMA Device Check and national CEIR — Industry and national equipment identity registers holding blacklist and barring status.
• Manufacturer specifications and device databases — Capability, band support and variant detail once the model has been resolved.
• National stolen device checkers — Public services confirming whether a handset is barred within a given market.
• Carrier and regulator records via legal process — Authoritative attachment history and identifier pairings available only under lawful production.

A working method

A repeatable sequence beats ad-hoc searching. This is a practical starting workflow:

1. Validate the identifier — Confirm fifteen digits and a correct Luhn check digit, flagging repeated or obviously synthetic values immediately.
2. Decode the allocation code — Resolve the first eight digits to manufacturer, model and market variant using an authoritative allocation source.
3. Establish device capability — Look up specifications, bands, operating system and firmware options to plan forensic and analytic work.
4. Check status registers — Query blacklist and stolen-device services in relevant markets and record the reporting jurisdiction for each result.
5. Separate device from subscriber — Treat any link between the identifier and a named person as a hypothesis requiring independent corroboration.
6. Seek network records lawfully — Obtain attachment history and device-to-subscriber pairings only through warrant or equivalent judicial authority.
7. Handle as evidence — Record where the identifier was observed, by whom and when, and preserve the source artifact unmodified.

How this connects across the intelligence taxonomy

Intelligence work does not respect neat boundaries. The mission domain you are working, the disciplines you practise, and the data points you pivot on are one connected system. These are the direct relationships for this entry — every link is also a tag, so you can follow any thread across the whole library.

Collected by these disciplines

• Radio Frequency Intelligence — The Electromagnetic Spectrum as an Intelligence Source
• Signals Intelligence — Intelligence from Intercepted Communications and Emissions
• Measurement & Signature Intel — Signatures, Measurements, and Physical Phenomena
• Technical Intelligence — Technology Capability, Design, and Exploitation
• Space Intelligence — Orbital Activity, Space Assets, and Counterspace
• Aviation Intelligence — Aircraft, Flights, and the Aviation Domain

Investigated in these domains

• RF & Signals Intel

Pivots to these data points

• Cell Tower / Cell ID — A mobile network cell identifier (MCC/MNC/LAC/CID) usable for coarse device geolocation.

Inside the platform: where IMEI / Device Identifier lives

The Quantus platform is 204 pages behind a 147-item sidebar organised into six working groups: Command (24 items), Dashboards (15), Threat Theaters (14), Intelligence Domains (15), Investigate (34), and Administration (45). This entry is not a page in isolation — it is a thread running through several of them.

The modules that matter most here:

• datapoint.php?dp=dp_imei — Data point hub
• domain.php?d=rf — RF & Signals Intel dashboard
• search.php — Advanced search, filter and pivot
• correlate.php — Correlation graph
• cases.php — Case management

Each dashboard is local-first: it renders from the platform’s own database rather than depending on a live third-party call, so it still works when an upstream API is unreachable or rate-limited. Heavy aggregates are cached with a hard query time cap and degrade to the last good value instead of hanging the page.

Automation, playbooks and AI skills

Analysis that only happens when someone remembers to run it is not a capability. The platform ships a 30-step automation pipeline (cron.php) that collects, ingests, resolves, enriches, correlates and scores on a schedule — 25 seeders, 11 resolvers and 7 enrichment runners, all idempotent and cursor-based so a run can be interrupted and resumed without duplicating or losing work.

AI skills that apply

The 16 one-click operations in ai-skills.php are deterministic jobs, not free-text generation. The ones that matter here:

• Enrichment Runner
• Enrichment → Local
• Correlate Infrastructure
• Summarise (Copilot)
• Generate Report

Alerting closes the loop: rules in alerts.php fire on new indicators matching a saved query, so a first sighting in this area raises a notification rather than waiting to be noticed at the next review.

Feeds, data sources and the API

The collection layer runs a feed registry of free, machine-readable sources — bulk blocklists and trackers (Maltrail, IPsum, FireHOL, the full abuse.ch corpora, phishing databases, Emerging Threats, Spamhaus, DigitalSide, ThreatView), authoritative government feeds (CISA KEV, OFAC, UN and EU sanctions lists), and reference datasets (RIR allocations, ip-to-ASN and geolocation tables, MITRE ATT&CK, EPSS). collect.php pulls them server-side on a schedule; feeds.php and source-catalog.php show what is registered, what it covers and when it last ran.

Anything the platform holds is reachable programmatically. The REST API in api.php exposes 11 endpoints — status, stats, search, lookup, recent, export, bulk_check, top_threats, by_category, categories, check — and export.php streams 18 formats in bounded chunks, so a million-row export neither exhausts memory nor times out:

STIX 2.1, MISP, OpenIOC 1.1, CEF (ArcSight), LEEF 2.0 (QRadar), Zeek/Bro intel, Snort/Suricata rules, Palo Alto EDL, BIND RPZ, hosts blackhole, iptables, CSV, JSON, NDJSON/JSONL, XML.

That covers the CTI standards (STIX 2.1, MISP, OpenIOC), SIEM ingestion (CEF, LEEF, Zeek), detection engines (Snort/Suricata), and direct enforcement (Palo Alto EDL, BIND RPZ, hosts, iptables) — so intelligence developed here can be actioned in the tools you already run, without a manual reformatting step. A TAXII 2.1 server and a MISP/RSS feed are also served for pull-based sharing.

Use cases

Three ways this entry earns its keep in day-to-day work:

1. Triage under time pressure. An artifact or report lands and you need a defensible read in minutes, not days. Validate the identifier is the first move; the platform pre-computes the enrichment so the analyst spends the time on judgement rather than lookups.
2. Building the picture. A single indicator is rarely the story. Establish device capability turns one artifact into a network — shared infrastructure, repeated selectors, the same operator behind different names — via the correlation graph and the cross-entity link engine.
3. Producing something actionable. Analysis that ends in a document nobody can use is wasted. Handle as evidence feeds the case file, the detection rule, the block list or the referral — with sourcing attached so the recipient can verify it.

Case management (cases.php), watchlists, saved searches and scheduled reports mean the work persists between sessions and survives an analyst leaving the team.

How each sector uses IMEI / Device Identifier

The same entry is worked very differently depending on who you are, what authority you hold, and what you are ultimately producing. A military analyst is supporting a commander’s decision; a journalist is meeting a publication standard; an NGO caseworker is protecting a person. The underlying artifacts are shared — the constraints, outputs and thresholds are not.

🎖 Military and defence

Device identifiers matter to defence mainly as an operational security and force protection problem rather than a collection opportunity. Personal and issued devices carried into an operational area broadcast identifiers that characterise the force, and the type allocation code reveals make, model and market variant of every handset a unit carries. Analysts therefore use the identifier to assess a friendly unit's electromagnetic and device signature and to enforce device policy. Where recovered equipment is exploited, the identifier supports technical exploitation reporting and links devices to procurement chains. Collection against individuals requires legal authority that a military intelligence function does not hold in most circumstances.

🕵 National intelligence

The identifier separates equipment from subscriber, which is exactly the distinction that matters when a target rotates SIM cards to defeat number-based tracking. A handset appearing under successive subscriber identities is a strong link between those identities, and the type allocation code characterises the hardware, which drives assessment of capability and of what forensic access is technically possible. Handling is strict: any dataset linking an identifier to a person is highly sensitive personal data, and network records pairing device to subscriber require authorisation. Open decoding of the allocation code is unclassified and can support releasable technical assessments.

👮 Law enforcement

For investigators the identifier is a device fingerprint that survives SIM changes. Lawfully obtained network records showing a device attaching under multiple subscriber identities can link accounts, and equipment identity registers show whether a handset was reported stolen and in which market. Evidentially, the identifier must be recorded from the device, its packaging, the network record or the extraction, with the source documented, and the device-versus-user distinction preserved throughout: device presence never establishes who was holding it. Physical examination requires consent or a warrant, and forensic acquisition must preserve integrity with a documented chain of custody.

🔍 Private investigation and corporate security

Private investigators encounter identifiers on devices their client owns, on packaging and in corporate mobile device management records, and those are lawful sources with the client's authority. Beyond that the boundaries are hard: a private actor cannot obtain network attachment records, cannot obtain device-to-subscriber pairings, and must not use services claiming to locate or identify a handset, which trade in unlawfully obtained data. Examining an employee's personal device requires consent and usually a policy basis. Corporate asset recovery is a legitimate use, working through the manufacturer, the carrier and law enforcement rather than around them.

📰 Journalism and OSINT media

Identifiers appear in leaked records, device forensics reports and surveillance investigations, and they have been central to reporting on commercial spyware targeting. The reporting discipline is to treat the identifier as identifying a handset, not a person, and to explain that distinction to readers, since conflating device and user is the error that turns a strong story into a correction. Do not publish full identifiers linked to individuals, as they facilitate targeting and cloning. Where forensic analysis of a device underpins a story, have it reviewed independently and describe the method well enough that others can assess it.

🌍 NGO, humanitarian and human rights

Digital security and human-rights organisations use device identifiers when investigating targeted surveillance, device seizure and confiscation, and phone theft affecting at-risk communities. Forensic examination of an activist's or journalist's device must be consensual, explained, and conducted with the subject's understanding of what will be found and shared, because the device usually contains far more than the surveillance evidence sought. Store any identifiers securely and separately from names. Blacklist and equipment register work supports victims of device theft. Staff conducting forensic work on devices belonging to people at risk need both technical training and clear consent protocols.

🎓 University and research

Researchers use type allocation codes for device population studies, security research and market analysis, which involves no personal data if the identifiers are not linked to users. Once identifiers are linked to individuals the work becomes human subjects research requiring ethics approval, and boards will normally require hashing, aggregation and a prohibition on publishing full identifiers. Public allocation datasets lag industry assignments, so coverage limitations should be reported explicitly. Where research involves device forensics on participants' phones, informed consent must cover incidental findings. Deposit code and aggregated results rather than raw identifier sets.

Playbook: working IMEI / Device Identifier end to end

A repeatable sequence, from the moment the requirement lands to the moment a product is delivered and the case is closed out. Each phase states what you are trying to establish, not merely what to click — the point is a defensible chain of reasoning, not a checklist.

Phase 1 — Record the identifier and its provenance

Capture the value exactly as observed and record where it came from: the device screen, the packaging or label, a network record, a device extraction or a document. The provenance determines both evidential weight and what lawful process was required. A good output pairs the identifier with source, observer and date. Stop when the origin of the value is documented, not just the value.

Phase 2 — Validate the structure

Confirm fifteen digits and a correct Luhn check digit, and identify whether you are holding an IMEI or an IMEISV, where the last two digits carry a software version instead of a check digit. Flag repeated, sequential or all-zero values as synthetic. A good output states the format and the validation result. Stop when you know whether the value could be a real device identifier.

Phase 3 — Decode the allocation code

Resolve the first eight digits to manufacturer, model and market variant using an authoritative allocation source, noting that public datasets lag industry assignments and new models may resolve to unknown. A good output names the device or explicitly records that the allocation code is unresolved. Stop when the hardware is identified or the gap is attributed to dataset currency. Record the dataset and its version, because allocation data is updated and a lookup is not reproducible without it.

Phase 4 — Establish device capability

Look up the resolved model's specifications: supported bands, operating system, chipset, storage, security features and known firmware versions. This determines what the device could have done and what forensic acquisition is technically viable. A good output is a capability profile relevant to the investigative question. Stop when the technical constraints on both the subject's use and your own access are understood.

Phase 5 — Check equipment identity registers

Query blacklist and stolen device services in the relevant markets, recording each service, the reporting jurisdiction and the query date. Registers are national and fragmented, so a device barred in one market may operate freely in another. A good output is a status log with explicit coverage caveats. Stop when the relevant markets have been checked rather than the first one.

Phase 6 — Assess authenticity

Consider whether the identifier is duplicated, invalid, reflashed or belongs to a counterfeit handset, all of which break the uniqueness assumption that the rest of the analysis depends on. Duplicate identifiers appearing simultaneously on different networks are diagnostic. A good output states whether uniqueness can be relied on. Stop when the authenticity question has been actively considered rather than assumed.

Phase 7 — Separate device from subscriber

Treat any link between the identifier and a named person as a hypothesis requiring independent corroboration. Devices are shared, resold, borrowed, gifted and stolen, and the identifier evidences hardware presence, not human presence. A good output labels every device-to-person link with its supporting evidence. Stop when no unsupported identity inference remains in the working notes. Where a device links to several people, say so explicitly rather than selecting the one the case prefers.

Phase 8 — Seek network records lawfully

Obtain attachment history, device-to-subscriber pairings and equipment register entries only through warrant, production order or equivalent judicial authority, and record the authorisation. Cross-border requests go through mutual legal assistance or designated cooperation channels. A good output is a request with its legal basis documented. Stop when the request is submitted through the proper channel. Record what was requested and what was returned, since operators frequently hold less history than investigators expect.

Phase 9 — Analyse identity rotation

Where lawfully obtained records show one device attaching under multiple subscriber identities, or one subscriber identity across multiple devices, map the pairings with dates. This is the highest-value analytic product from device identifiers. A good output is a device and subscriber pairing timeline. Stop when the rotation pattern is either established or shown to be absent from the available records.

Phase 10 — Plan forensic acquisition

Where a device is lawfully available, use the model profile to plan acquisition method, tooling and expected coverage, and ensure the examiner is competent and the process documented. Acquisition choices determine what can later be presented and challenged. A good output is an acquisition plan tied to the specific model and firmware. Stop when the method is chosen for technical reasons that can be explained.

Phase 11 — Preserve forensic integrity

Hash acquisitions, work on copies, document every action taken on the device, and maintain an unbroken chain of custody from seizure to examination to storage. A good output is a continuity record that survives challenge from an opposing expert. Stop when the record would allow another examiner to verify what was done and when. Record the tool, its version and the acquisition method, because coverage differs between tools and firmware versions.

Phase 12 — Restrict and minimise

Store identifier-to-person links under access control with logging, exclude full identifiers from circulated products, and retain only for the case lifetime. Device identifiers are personal data once linked to a user and are directly usable for targeting. A good output is a product that supports the finding without exposing the identifier. Stop when the retention and access position is enforced by system rather than policy.

The platform ships this as a step-checked workflow in playbooks.php, so progress is recorded against a case rather than held in someone’s head.

Source register: what to collect from, and how

Sources are listed with their access model so you can plan around cost and licensing before you build a dependency on them. Open means no account required; registration means a free account or API key; licensed means paid or institutional access. Always confirm current terms — licensing changes, and a source that was free for research may not be free for commercial or evidential use.

Source	Access	What it gives you	How it is used here
GSMA type allocation code and IMEI database	Licensed	The authoritative industry register mapping type allocation codes to device make, model and variant, administered for the mobile industry.	Definitive resolution of the first eight digits to a specific handset model and market variant.
3GPP TS 23.003	Open	The specification defining identifier structure, the IMEISV variant, check digit rules and how identifiers relate to subscriber identities.	The technical authority for validation, for the IMEI versus IMEISV distinction and for what the network actually records.
GSMA Device Check	Licensed	Industry service allowing authorised parties to check device status against the international equipment identity register blacklist.	Authoritative check on whether a handset has been reported stolen or barred across participating operators.
National central equipment identity registers	Registration	State-operated device registries in a growing number of countries, holding registration, import and blacklist status for handsets.	Establishes device status within a specific national market, where the register exists and is queryable.
Public TAC datasets	Open	Openly maintained lists mapping type allocation code prefixes to device models, assembled from public sources and community contribution.	Practical decoding where industry access is unavailable, with the caveat that new models lag or are missing.
Manufacturer specification resources	Open	Official device specifications covering bands, chipsets, storage, operating system versions, security features and regional variants.	Establishes what the identified handset can do, which drives capability assessment and forensic planning.
GSMArena and device databases	Open	Comprehensive community device catalogues with detailed specifications, variant listings and release dates for most handsets.	Fast lookup of specifications and regional variants once the model has been resolved from the allocation code.
National stolen device checkers	Open	Public services operated by regulators or industry bodies allowing anyone to check whether a handset is barred in that market.	Free market-specific status check useful for second-hand device verification and theft investigation support.
Carrier records via legal process	Licensed	Network attachment history, device and subscriber identity pairings and equipment register entries held by operators.	The only authoritative source linking a device to subscriber identities over time, obtainable under judicial authority.
Mobile device forensics vendor documentation	Licensed	Technical documentation on supported devices, acquisition methods and coverage limitations for forensic extraction tooling.	Determines whether the identified model and firmware can be acquired, and by which method, before seizure planning.
NIST computer forensics tool testing	Open	Independent test reports on mobile forensic tools, documenting what each acquires accurately and where it fails.	Provides independent validation evidence for the acquisition method used, which an opposing expert will test.
Amnesty Security Lab and Citizen Lab methodologies	Open	Published forensic methodologies for detecting targeted surveillance on mobile devices, with indicators and analytical tooling.	The reference methodology when device analysis concerns spyware targeting of journalists, activists or defenders.

Prefer sources that publish a methodology and a revision history. A dataset that changes silently is a liability in any product that has to survive challenge.

Tooling

Tools commonly used against IMEI / Device Identifier. None of these replace judgement, and each carries its own failure modes — know what a tool infers versus what it observes.

• Luhn check digit validators — Confirm the fifteenth digit is consistent with the preceding fourteen; a valid check digit says nothing about whether the device exists or is genuine.
• TAC lookup services — Resolve allocation codes to models from public datasets; coverage lags industry assignment so recent devices commonly return unknown.
• Mobile forensic suites — Acquire logical, file system or physical images depending on model and firmware; coverage changes with every operating system update and licences are expensive.
• Mobile Verification Toolkit — Open tooling for analysing device backups and records for surveillance indicators; requires careful interpretation as indicators are not proof of compromise.
• Hashing and evidence management tools — Preserve acquisition integrity with checksums and continuity records; effective only if applied at seizure rather than after examination begins.
• Mobile device management consoles — Enumerate corporate device identifiers and status with the organisation's authority; personal devices under bring-your-own policies raise separate consent questions.
• Case management with access control — Restricts and logs identifier-to-person links as data protection requires; the joined dataset is far more sensitive than either component.

AI skills and automation in detail

These are deterministic jobs with defined inputs and outputs, not open-ended prompting. Each is idempotent and cursor-based: interrupt one and it resumes where it stopped rather than duplicating work or losing progress.

• Enrichment Runner — Walks the indicator set through a chosen provider in time-boxed, cursor-based batches that resume rather than restart.
• Enrichment → Local — Materialises enrichment into the local store so dashboards render from your own database instead of a live third-party call.
• Correlate Infrastructure — Builds the cross-entity link graph: shared hosting, reused certificates, overlapping registrants, repeated selectors.
• Summarise (Copilot) — Produces a narrative summary beside the underlying records. It explains; it never creates indicators or assigns attribution.
• Generate Report — Assembles a sourced product from the current case or query, with provenance attached to each element.

A note on the boundary: the only skill that involves a language model is Summarise (Copilot), and it writes prose about records that already exist. Nothing else on this list involves generation of any kind. No indicator, relationship or attribution in the platform originates from a model. See the full skill list.

Tradecraft notes

The distinctions that separate a competent analyst from a fast one:

• The identifier is the handset, never the person. Devices are shared within families, borrowed, resold in second-hand markets and stolen, so device presence is evidence about equipment and only ever a hypothesis about people.
• The type allocation code is the analytically rich part. It gives manufacturer, model and often the regional variant, which tells you supported bands, likely market of sale and, critically, what forensic acquisition is technically possible before you plan a seizure.
• Confusing IMEI with IMEISV causes silent lookup failures. The software version form replaces the check digit with two version digits, so a value that fails validation may simply be the wrong form rather than a fabricated number.
• Counterfeit and reflashed handsets carry duplicated, invalid or all-zero identifiers, which destroys the uniqueness assumption everything else rests on. Test for duplicates before building any analysis on a device being unique.
• One device across several subscriber identities is the highest-value pattern in this data, because it defeats the SIM-rotation tradecraft it was designed to survive. It requires lawfully obtained network records; nothing open will show it.
• Blacklists are national and fragmented by design. A device barred in one market frequently works in the next country, which is precisely the economics behind cross-border handset theft, and it means a clean status check proves very little.

Measuring whether it is working

Capability claims should be falsifiable. These are the measures that show whether work on IMEI / Device Identifier is producing anything, and they are worth baselining before you change process or tooling.

• Proportion of identifiers validated and correctly classified as IMEI or IMEISV before any lookup was attempted.
• Rate at which allocation codes resolve to a specific model, tracked over time as an indicator of reference dataset currency.
• Share of device-to-person links appearing in products that carry explicit independent corroboration rather than resting on device presence alone.
• Proportion of network record requests submitted with documented judicial authorisation recorded on the case file.
• Rate at which planned forensic acquisitions succeeded on the target model and firmware, as a measure of pre-seizure planning quality.
• Proportion of circulated products in which full identifiers are withheld or truncated, audited by sample.

Beware of measuring volume alone. Indicator counts and report counts rise easily and say little; time-to-attribution, proportion of findings that survive review, and how often a product changed a decision say a great deal.

Common pitfalls

• Devices are shared, resold, borrowed and stolen, so device presence never establishes who was actually using it.
• Counterfeit and reflashed handsets carry duplicated or invalid identifiers, destroying uniqueness assumptions entirely.
• Public allocation datasets lag industry assignments, so new models resolve to unknown or to the wrong variant.
• The IMEI and IMEISV forms are frequently confused, causing failed lookups when a software version is included.
• Blacklists are national and fragmented, so a device barred in one market may operate freely in another.
• Reading an identifier from a device requires lawful access; it cannot be obtained remotely by legitimate means.

Legal and ethical considerations

Device identifiers are personal data once linked to a user, and network records mapping a device to subscribers require judicial authorisation in most jurisdictions. Never attempt remote acquisition of identifiers or rely on services trading in unlawfully obtained device data. Physical examination requires consent or a warrant, and handling must preserve forensic integrity with a documented chain of custody. Minimise retention, restrict access to identifier-to-person links, and keep the device-versus-user distinction explicit in every product.

Data integrity: no fabrication, no drift, no hallucination

Intelligence that cannot be traced back to a source is not intelligence, it is assertion. Everything in this entry — and everything in the platform behind it — is built on a small number of non-negotiable rules.

Provenance on every record

Every indicator carries the source that supplied it, a first-seen and last-seen timestamp, and a sighting count. Where several feeds report the same artifact, each contribution is recorded separately rather than collapsed, so you can see whether a finding rests on one source or twelve. Source attribution travels with the data into every export, so a recipient can audit a claim without asking you for the working.

Nothing is invented to fill a gap

If the platform has no data for IMEI / Device Identifier, it says so. Empty is displayed as empty — never padded with plausible-looking placeholder values, sample records or illustrative examples that a reader might mistake for observations. A dashboard with no rows is a true statement about collection coverage, and it is treated as a gap to close, not a blemish to hide.

Scoring is deterministic and reproducible

Threat scores, reputation grades and risk tiers are computed from stated inputs with fixed weights, not estimated. The same inputs always produce the same output, and the formula is visible rather than a black box. Aggregates are cached with an explicit time-to-live so a figure on screen is never silently stale — and when a heavy query exceeds its time budget the platform serves the last known-good value and labels it, rather than inventing a fresh number or hanging.

Where AI is used, and where it is not

Language models summarise and explain. They do not create indicators, assign attribution or manufacture relationships. No IP address, wallet, hash or identity in the platform originates from a model — every one is ingested from a named feed, resolved from a reference dataset, or entered by an analyst with a source recorded. Copilot output is presented as narrative alongside the underlying records, never in place of them, so a reader can always check the summary against the evidence.

Guarding against drift

Enrichment is additive and timestamped rather than overwriting. Reference data — sanctions lists, allocations, taxonomies — is re-synchronised from the authority on a schedule instead of being edited in place, so local copies cannot quietly diverge from the source of truth. Attribution is recorded with a confidence level and the reporting it rests on, and inferred relationships are labelled as inferred. When a source retracts or corrects, the correction propagates rather than leaving a stale assertion behind.

What this means for you

You can put a finding from this platform in front of a regulator, a court, a board or a partner agency and show where each element came from. That is the standard the tooling is built to — because in this work, being confidently wrong is more damaging than being usefully uncertain.

By the numbers

The taxonomy this entry belongs to is not a marketing list — it is the actual structure of the platform: 52 mission domains, 52 intelligence disciplines and 65 data points, each with a live dashboard behind it. Supporting that: 18 indicator types, 14 playbooks, 16 AI skills, 18 export formats and a 30-step automated pipeline.

This particular entry connects directly to 6 intelligence disciplines, 1 mission domains, 1 closely related entries — every one of them a tag you can follow, and a dashboard you can open.

Questions analysts actually ask

Can I find out who owns a phone from the IMEI?

No. The identifier describes hardware and nothing else. Linking it to a subscriber requires network records held by the operator, which are obtainable only under warrant, production order or equivalent judicial authority in almost every jurisdiction. Services advertising owner lookup from an identifier are either returning the model, which is public, or trading in unlawfully obtained data, and buying from them creates criminal exposure and destroys evidential value. Even with lawful records, the pairing establishes which subscriber identity was in the device, not who was holding it, which remains a separate question requiring separate evidence.

The identifier fails the check digit. Is it fake?

Check the form first. The software version variant replaces the check digit with two digits identifying firmware, so a fifteen or sixteen digit value that fails Luhn validation may simply be an IMEISV recorded from a network log rather than a fabricated number. Transcription error is the next most likely cause, particularly from a photograph or a handwritten note. After those, genuine possibilities are a counterfeit or reflashed handset carrying an invalid or all-zero identifier, or an engineering test device. Record the failure and its likely cause rather than correcting the value silently.

What does the allocation code actually tell me?

Manufacturer, model and often the regional variant, which unlocks a lot. Regional variant indicates supported frequency bands, the likely market of original sale, which can contradict a claimed provenance, and the operating system and security features shipped. For investigators the most practical consequence is forensic: acquisition method, tooling support and expected data coverage all depend on the exact model and firmware, so decoding the allocation code before a device is seized changes how the seizure is planned. It also supports capability assessment, meaning what the device could and could not plausibly have done.

Two devices are reporting the same identifier. What does that mean?

That at least one of them is not what it claims to be. Genuine identifiers are unique, so simultaneous appearance on different networks indicates cloned or counterfeit hardware, or reflashed devices where the identifier has been rewritten. This is common in some markets where cheap handsets ship with duplicated or sequential identifiers from the factory. The analytic consequence is significant: any conclusion resting on the device being uniquely identified fails, and network records will conflate two devices. Flag it explicitly and fall back on other evidence rather than trying to disentangle the records.

Can I use device identifiers to recover a stolen phone?

Through the proper channels, yes to a degree. Report the theft to police with the identifier, which allows it to be recorded and, in participating markets, barred through the equipment identity register so it cannot attach to networks there. Notify the carrier and the manufacturer's device location service if enabled. What you cannot do is track the handset yourself, buy location data on it, or use a service claiming to locate it, which is unlawful in many jurisdictions. Blacklists are national, so a device exported after theft often continues to work, which is exactly why cross-border handset theft is profitable.

How should a device belonging to a journalist or activist be examined?

With explicit informed consent and a clear scope, because the device holds far more than the surveillance evidence being sought, including sources, contacts and private material. Explain what the examination will access, what will be retained, who will see it and what happens to the copy afterwards, and get that agreement in writing. Use published methodologies designed for this work, preserve the acquisition with hashes, and have findings independently reviewed before publication, since indicators of compromise are frequently ambiguous. Store the acquisition encrypted and separately from identifying information, and delete it when the agreed purpose ends.

Standards, frameworks and further reading

Work that references a recognised framework is easier to defend, easier to hand over, and easier for a partner to consume:

• 3GPP TS 23.003 defines the international mobile equipment identity structure, the software version variant and check digit rules.
• The GSMA IMEI allocation and approval process governs assignment of type allocation codes to device models.
• GSMA TS.06 sets the industry requirements for IMEI security and the integrity of the identifier within the device.
• ISO 17025 accreditation applies to forensic laboratories producing device examination evidence in many jurisdictions.
• The ACPO and successor guidance on digital evidence, and the SWGDE best practices, define handling and continuity expectations for mobile devices.
• NIST guidelines on mobile device forensics define acquisition methods, tool validation and reporting expectations.
• The Budapest Convention on Cybercrime frames international cooperation for obtaining subscriber and traffic data.
• The EU General Data Protection Regulation treats device identifiers linked to a user as personal data requiring lawful basis and minimisation.

References

Primary sources and authoritative references for this entry. Publishers revise and retire material, so treat the retrieval date as part of the citation and re-check before relying on any of it in a formal product.

1. IMEI allocation, Device Check and device services — GSMA. Industry administration of type allocation codes and equipment identity registers.
2. TS 23.003 numbering, addressing and identification — 3rd Generation Partnership Project. The specification defining device identifier structure and validation.
3. Guidelines on mobile device forensics — United States National Institute of Standards and Technology. Acquisition methods, tool validation and reporting standards for handset examination.
4. Best practices for mobile device evidence — Scientific Working Group on Digital Evidence. Handling, continuity and examination guidance for digital devices.
5. Security Lab forensic methodology — Amnesty International. Published methodology for detecting targeted surveillance on mobile devices.
6. Targeted surveillance research and device forensics — Citizen Lab, University of Toronto. Technical investigations of commercial spyware targeting civil society devices.
7. Convention on Cybercrime — Council of Europe. International framework for obtaining subscriber and traffic data across borders.
8. Central equipment identity register guidance — International Telecommunication Union. International guidance on national device registries and counterfeit device controls.

Link integrity: every reference above was verified with a live request when this page was generated. Where a publisher had moved or withdrawn a document, the link was repointed at a preserved copy in the Internet Archive and marked as archived. Anything with no reachable copy anywhere had its link removed rather than left to rot — the source is still credited, it simply cannot be linked.

Put it into practice

The Quantus Intel threat intelligence platform operationalises this entry: decodes device identifiers to hardware profiles and separates equipment identity from subscriber identity. Explore the platform, or browse the rest of the library by following any tag above.