Device / Advertising ID: Data Point Intelligence Guide

An advertising identifier was designed to be a resettable, privacy-preserving marketing token. In practice it became one of the most precise commercial tracking artifacts ever created.

Understanding the Device / Advertising ID as an intelligence artifact

A device or advertising identifier is a platform-issued string used to attribute advertising and analytics to a device: the Google Advertising ID on Android and the Identifier for Advertisers on iOS, both typically UUID formatted. They are device-scoped rather than app-scoped, resettable by the user, and increasingly gated behind explicit consent. Alongside them sit vendor identifiers scoped to one developer, and platform hardware identifiers such as IMEI and serial numbers that are not resettable and are restricted to privileged use.

Analytically, distinguish resettable advertising identifiers from persistent hardware identifiers, and both from probabilistic fingerprints assembled from device attributes when identifiers are unavailable. Apple's App Tracking Transparency zeroed the IDFA for non-consenting users, pushing the adtech industry toward fingerprinting and first-party identifiers. Bid stream data historically paired these identifiers with precise coordinates, which is what made them a surveillance concern rather than a marketing detail.

Why it matters

Where lawfully accessible, a device identifier connects app usage, in-app purchases and, in some datasets, location history to a single handset. In fraud and abuse work it detects one device operating many accounts, which is the core signal behind bonus abuse, fake reviews and account farming. In corporate investigations it supports device inventory correlation. The identifier's value is precisely proportional to its intrusiveness, which is why access should be tightly constrained and purpose-bound.

What analysts actually look for

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

• Platform and identifier type, distinguishing Android advertising identifiers, iOS identifiers, vendor-scoped identifiers and restricted hardware identifiers.
• Multiple accounts sharing one identifier, the primary detection signal for account farming, referral abuse and coordinated fake engagement.
• One account presenting many identifiers in a short window, indicating identifier resets, emulators or device spoofing frameworks.
• Consistency between the identifier and other device attributes such as model, operating system version, locale and timezone.
• App inventory and SDK presence associated with the device in first-party telemetry, indicating usage patterns and installed tooling.
• Emulator and rooted device indicators, since automated abuse commonly runs on virtualised or modified handsets.
• Reset frequency, where an identifier that changes far more often than normal user behaviour suggests deliberate evasion.
• Correlation with first-party account identifiers in your own systems, which is the only linkage most organisations can lawfully make.

Where the data comes from

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

• Your own first-party mobile analytics and telemetry — The lawful primary source: identifiers your app collected under your own consent notice and privacy policy.
• Google Play Services and Apple developer documentation — Authoritative specification of identifier scope, reset behaviour, consent gating and permitted uses.
• Mobile device management platforms — Enrolled corporate device inventory mapping hardware and platform identifiers to assigned users and assets.
• Mobile forensic tooling such as Cellebrite or open alternatives like ALEAPP and iLEAPP — Identifier extraction from a lawfully seized device under proper authority.
• Fraud and device intelligence platforms — Emulator, root and reset detection with device reputation scoring for abuse prevention.
• App store listings and privacy nutrition labels — Declared data collection and tracking behaviour for apps observed on a device.
• Regulator guidance and enforcement decisions on adtech identifiers — Current legal constraints on collecting, buying or combining advertising identifier data.

A working method

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

1. Verify lawful access — Confirm you hold the identifier through first-party collection, device management, or lawful seizure, and reject commercially purchased location or bid stream data.
2. Classify the identifier — Determine platform, scope and resettability, since a vendor-scoped identifier and a hardware serial support very different conclusions.
3. Correlate inside your own systems — Join against first-party account and session records to detect shared devices and multi-account patterns within your data only.
4. Check device integrity — Assess emulator, root and spoofing indicators, and treat identifiers from modified environments as untrusted assertions.
5. Analyse temporal behaviour — Examine identifier lifetime, reset cadence and session overlap to distinguish family device sharing from deliberate abuse.
6. Corroborate before acting — Require a second independent signal before enforcement, because a shared household or reissued device produces the same pattern as fraud.
7. Apply retention and minimisation — Hash or truncate where full identifiers are unnecessary, and expire records on a defined schedule with documented justification.

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

• Identity Intelligence — Resolving and Verifying Who Someone Is
• Attack Surface Intelligence — Your Own Exposed Attack Surface
• Cyber Intelligence — Adversary Activity in Networks and Systems
• Breach Intelligence — Exposed Credentials and Compromised Data
• Certificate Intelligence — TLS Certificates and Certificate Transparency
• Domain Intelligence — Domains, DNS, and Registration Intelligence

Investigated in these domains

• Operational Security
• Transnational Repression

Pivots to these data points

• Person / Name — A named individual — the subject of identity resolution and profiling.
• Email Address — Electronic mail address tied to an individual or organization.
• Username / Handle — Screen name or handle used across online platforms and services.
• Phone Number — Telephone number for voice, SMS, or messaging identification.
• Physical Address — A physical or mailing address tied to a person, company, or registered entity.
• Social Profile — A social media profile or online account page tied to a persona or identity.

Inside the platform: where Device / Advertising ID 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_device_id — Data point hub
• domain.php?d=opsec — Operational Security dashboard
• domain.php?d=repression — Transnational Repression 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. Verify lawful access 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. Correlate inside your own systems 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. Apply retention and minimisation 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 Device / Advertising ID

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 primarily as an exposure problem. Personnel devices generate advertising and analytics identifiers that historically flowed into commercial datasets, and the resulting operational security risk to bases, deployments and personnel movement is a documented and serious one. The legitimate analytical uses are internal: correlating enrolled devices in an estate, detecting unmanaged or non compliant equipment, and supporting policy on application use and consent settings. Acquiring commercial location or bid stream datasets keyed to identifiers, whether about adversaries or personnel, is not a lawful or acceptable collection method and creates precisely the exposure it purports to study.

🕵 National intelligence

Where identifiers arise lawfully, from device examinations conducted under proper authority or from an organisation's own telemetry, they support correlation of activity to a handset and detection of one device operating many accounts. The controlling principle is provenance: an identifier is usable only if it was obtained through lawful authority, from assets under your control, or with valid consent. Purchasing commercial location or advertising datasets about individuals is not a substitute for legal process and is prohibited or heavily restricted in a growing number of jurisdictions. Handling is at the most sensitive end because these identifiers are explicitly regulated as personal data.

👮 Law enforcement

For law enforcement identifiers are strong correlative evidence when obtained properly: from a device examined under warrant, from a service provider under production order, or from an organisation's own logs. They demonstrate that one device operated multiple accounts, which underpins fraud, abuse and account farming cases. Resettable identifiers complicate persistence, so record the extraction time and note that a reset creates a discontinuity rather than a new device. Commercially purchased location data keyed to identifiers has been the subject of significant legal challenge and should not be relied on as a substitute for judicial authorisation.

🔍 Private investigation and corporate security

Corporate security uses first party identifiers within the client's own applications and managed devices for fraud detection, multi account abuse, device inventory and licence compliance. That is defensible because the client is the controller and users were informed. What is not defensible is purchasing commercial location or advertising data about individuals, obtaining identifiers from devices without informed consent, or attempting to link a client's identifiers to external datasets to profile individuals. Deliverables should describe device correlation within the client estate and route anything requiring external data to lawful process.

📰 Journalism and OSINT media

The story here is usually the data market itself: how identifiers designed as privacy preserving marketing tokens became a commercial surveillance capability, and who buys the resulting datasets. That reporting is important and is best done through documents, contracts, procurement records, regulatory enforcement actions and consenting participants using their own devices. Do not purchase datasets about individuals to demonstrate the risk, and do not publish identifiers or derived location traces for real people. Regulatory enforcement records and platform policy changes provide a documented, citable evidence base without creating new harm.

🌍 NGO, humanitarian and human rights

Digital rights and human rights organisations have led the documentation of harms from identifier based tracking, including exposure of military sites, places of worship and clinics through commercially available datasets. Victim centred practice means working with consenting participants on their own devices, and never acquiring datasets that contain non consenting individuals. Advisory work is high value: helping at risk users understand consent settings, identifier resets, application permissions and the limits of those controls. Advocacy documentation should rest on regulatory findings, vendor documentation and controlled experiments rather than on purchased data.

🎓 University and research

Research on identifier ecosystems, consent frameworks and tracking prevalence is well established and ethically demanding. Institutional review will normally require that no non consenting individual's identifier is processed, which effectively rules out purchased datasets and mandates controlled experiments with instrumented devices and consenting participants. Method must state the platform versions, consent states tested and identifier reset behaviour, since platform policy changes altered availability dramatically and results are not comparable across those boundaries. Publish aggregate findings and instrumentation code, and never publish identifier values even in hashed form, since hashed identifiers are reversible.

Playbook: working Device / Advertising ID 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 — Establish provenance before anything else

Determine exactly how the identifier came into your possession: your own application with valid consent, a managed device you administer, a lawful device examination, or a service provider under process. If the answer is a commercial dataset about individuals, stop. A good output is a written provenance statement for every identifier source. Stop and escalate if provenance cannot be established, because unlawfully sourced identifiers taint everything downstream.

Phase 2 — Record lawful basis, purpose and consent state

Document the lawful basis, the specific purpose, and where consent applies, the consent state at the time of collection and how it was obtained. Identifiers are explicitly regulated as online identifiers in most privacy regimes and consent requirements are strict. A good output is an authorisation with the consent evidence referenced. Stop if the purpose is profiling an individual outside a defined and authorised investigation.

Phase 3 — Classify the identifier type

Distinguish a resettable advertising identifier, a vendor scoped identifier limited to one developer, an installation identifier unique per application install, and a persistent hardware identifier which is restricted to privileged use in most platforms. Each has entirely different persistence, scope and legal treatment. A good output is a classified identifier with its scope. Stop when the type is established, since inferences about persistence depend on it.

Phase 4 — Minimise at the point of collection

Where the purpose permits, hash or truncate identifiers with a per purpose salt so the working dataset cannot be joined against external data. Retain the raw value only where the purpose genuinely requires it and with additional controls. A good output is a minimised dataset with the transformation documented. Stop when the analysis can be performed on the minimised form, which is usually the case for abuse detection.

Phase 5 — Correlate within your own estate only

Use the identifier to link activity within the systems you control: multiple accounts on one device, installation and usage patterns, and device inventory reconciliation. Do not attempt to join it against external datasets to enrich a person. A good output is an intra estate correlation with the systems named. Stop at your own boundary; crossing it is where this artifact becomes a surveillance capability.

Phase 6 — Detect multi account abuse

Where the purpose is fraud or abuse, identify devices operating numbers of accounts inconsistent with legitimate use, accounting for shared and family devices, device resale and test devices. This is the highest value defensible use of the artifact. A good output is a ranked device list with account counts and the exclusion logic applied. Stop when legitimate shared use has been excluded rather than swept in.

Phase 7 — Handle resets and discontinuities

Record the extraction or observation time and treat a reset as a discontinuity in the identifier rather than as evidence of a new device or of evasion. Users reset identifiers routinely and platforms encourage it. A good output is a timeline noting discontinuities. Stop before treating a reset as suspicious behaviour, since it is an exercise of a documented user control.

Phase 8 — Extract from devices only under authority

Where a device examination is in scope, follow established mobile forensic procedure under warrant or documented informed consent, recording the tool, version, extraction method and hashes. Identifiers extracted this way are defensible; identifiers obtained any other way from someone else's device are not. A good output is an extraction record meeting forensic standards. Stop if the authority or consent is not documented.

Phase 9 — Assess re identification risk in any sharing

Before sharing or publishing anything derived from identifiers, assess whether individuals could be re identified, including from hashed values which are reversible by brute force given the small identifier space. A good output is a re identification assessment with the mitigation applied. Stop before sharing raw or hashed identifiers outside the controlled environment.

Phase 10 — Review platform and regulatory position

Check the current platform policy and regulatory position for the jurisdictions involved, since availability, consent requirements and permitted uses have changed substantially and continue to. A finding based on a superseded policy state may be both wrong and unlawful. A good output is a dated note of the applicable platform and regulatory position. Stop when the current position is confirmed rather than assumed.

Phase 11 — Document the exposure, not the individuals

Where the work is about the risk of identifier based tracking, report at the level of capability, dataset availability, vendor practice and regulatory action rather than by demonstrating tracking of real people. A good output is an evidenced capability assessment using documents and controlled tests. Stop before any collection that would create the harm you are describing.

Phase 12 — Retain minimally and delete

Apply short retention, restrict access to the specific team and purpose, log access, and delete on schedule. Identifiers accumulate value as a tracking capability the longer they are held, which is the opposite of what you want. A good output is a controlled dataset with an enforced deletion date. Stop when deletion is scheduled and access logging is confirmed.

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
Android advertising identifier documentation	Open	Platform documentation describing identifier availability, permission requirements, reset behaviour and developer policy obligations.	Authoritative reference for what the identifier is, when it is available, and what a reset means for persistence.
Apple App Tracking Transparency documentation	Open	Platform documentation on tracking authorisation, the identifier for advertisers, vendor identifiers and consent requirements.	Defines when identifiers are available at all, which changed the entire ecosystem and any analysis predating it.
GSMA device and identifier resources	Registration	Industry reference on device type allocation, equipment identity structure and the databases used for stolen device blocking.	Explains hardware identifier structure and the legitimate operator and regulator processes that use it.
NIST SP 800-101 guidelines on mobile device forensics	Open	Federal guidance on acquisition, examination and reporting for mobile devices including identifier and configuration artifacts.	Procedural standard for extracting identifiers under authority so the result withstands evidential challenge.
Cellebrite documentation and validation material	Licensed	Vendor documentation for mobile extraction tooling covering supported devices, extraction methods and artifact interpretation.	Reference for what a given extraction method can recover and how identifiers are represented in the output.
Magnet Forensics documentation	Licensed	Vendor material on mobile and computer artifact parsing including application level identifiers and installation records.	Artifact interpretation reference when identifiers appear in application databases rather than system configuration.
European Data Protection Board guidance and decisions	Open	Regulatory guidance and enforcement decisions treating advertising and device identifiers as personal data subject to consent requirements.	Defines the lawful basis and consent conditions that govern any processing of identifiers in scope of EU law.
Information Commissioner's Office guidance on adtech	Open	United Kingdom regulatory analysis of real time bidding, identifier use and the lawful basis problems in programmatic advertising.	Documented regulatory assessment of the data flows that made identifiers a surveillance concern.
Federal Trade Commission enforcement actions on location data	Open	United States enforcement decisions and orders concerning sale and use of precise location data tied to device identifiers.	Citable documentary evidence of the market, its practices and the legal consequences of participating in it.
Norwegian Consumer Council Out of Control report	Open	Documented technical study of how mobile applications transmit identifiers and personal data to advertising and analytics companies.	Evidenced description of the data flows, methodology reproducible with instrumented devices and consenting users.
Electronic Frontier Foundation research and technical analysis	Open	Published analysis of tracking technologies, identifier ecosystems, and technical countermeasures available to users.	Reference for advisory work with at risk users and for understanding the limits of platform provided controls.
OWASP Mobile Application Security project	Open	Testing guide and verification standard covering mobile application data handling including identifier collection and transmission.	Methodology for assessing what identifiers an application collects and transmits during authorised security testing.
MITRE ATT&CK for Mobile	Open	Structured technique taxonomy for mobile platform adversary behaviour including device identifier collection by malicious applications.	Maps identifier harvesting behaviour to shared technique identifiers for detection and reporting.
Platform transparency and policy change records	Open	Published developer policy documentation and change histories governing identifier availability, consent and permitted use.	Establishes the applicable policy state at a given date, which determines whether historic analysis remains valid.
ISO/IEC 27701 privacy information management	Licensed	Management system standard extending information security controls to processing of personally identifiable information.	Control framework for the minimisation, retention and access governance that identifier processing requires.

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 Device / Advertising ID. None of these replace judgement, and each carries its own failure modes — know what a tool infers versus what it observes.

• Mobile device management platforms — Provide authoritative identifier and configuration inventory for enrolled devices in an estate. Limitation: covers only managed devices, which excludes the highest risk population.
• Mobile forensic extraction suites — Recover identifiers and application artifacts from devices under warrant or consent. Limitation: support varies by platform version and encryption state, and extraction requires authority.
• First party analytics and fraud platforms — Correlate device level activity across accounts within an organisation's own applications. Limitation: only sees the organisation's own applications, so cross service behaviour is invisible.
• Salted hashing pipelines — Transform identifiers at ingestion so working datasets cannot be joined externally. Limitation: the identifier space is small enough that unsalted hashes are trivially reversible.
• Instrumented test devices with proxy interception — Observe what identifiers an application transmits and to whom during authorised testing. Limitation: certificate pinning and native networking defeat naive interception setups.
• OWASP mobile testing tooling — Structured assessment of application data handling including identifier collection during security review. Limitation: requires authorisation from the application owner.
• Consent management platforms — Record and enforce consent state for identifier collection across an organisation's applications. Limitation: configuration errors routinely allow collection before consent is captured.
• Data loss prevention and egress monitoring — Detect identifier bearing data leaving a controlled environment. Limitation: identifier formats are generic enough to produce substantial false positives.

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:

• Provenance is the first question and frequently the last. An identifier obtained from a commercial dataset about individuals is not usable evidence in any serious context, and its presence in a case file is a liability rather than a lead.
• Hash at ingestion with a per purpose salt. The identifier space is small enough that an unsalted hash is reversible by exhaustive search, so hashing without salting provides the appearance of protection and none of the substance.
• A reset is a user exercising a documented control, not evasion. Treating identifier discontinuity as suspicious behaviour penalises privacy conscious users and produces a fraud signal that correlates with the wrong thing.
• Distinguish device scope from application scope carefully. Vendor and installation identifiers do not correlate across developers, so a linkage claim that assumes they do is simply wrong about how the platform works.
• The most defensible use is entirely internal: one device, many accounts, within your own service. Every step outward from that boundary increases both the legal exposure and the probability that you are building surveillance rather than detection.
• Platform policy changes invalidate historic analysis. Consent gating substantially reduced identifier availability, so prevalence figures and correlation rates from before that change do not describe the current environment.
• Shared and resold devices break the one device one person assumption. Family tablets, refurbished handsets and shared work devices all produce multi account patterns that look like abuse and are not.
• When the subject of the work is the tracking risk itself, document the capability rather than demonstrating it. Regulatory findings, vendor documentation and controlled tests on consenting devices evidence the harm without creating another instance of it.

Measuring whether it is working

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

• Proportion of identifier records with a documented provenance and lawful basis at the point of ingestion, audited rather than assumed.
• Share of working datasets holding only salted hashed identifiers rather than raw values, tracked as a minimisation measure.
• Number of external datasets containing identifiers about individuals acquired, which should be zero and should be actively monitored for.
• Detection rate for multi account abuse within the first party estate, with the false positive rate on shared and family devices measured separately.
• Retention compliance for identifier datasets, measured as the proportion deleted on schedule rather than persisting in analytics stores.
• Consent capture accuracy, measured as the proportion of collection events occurring after a valid consent record rather than before.
• Coverage of the managed device inventory, since unmanaged devices are the population where identifier based correlation has no visibility.

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

• Advertising identifiers are user-resettable, so continuity breaks whenever a user resets and the same device appears as a new one.
• Devices are shared within households and resold second hand, so an identifier maps to a device rather than a person.
• Emulators and spoofing frameworks fabricate identifiers at scale, making the value an assertion rather than a measurement.
• iOS tracking consent means most identifiers are now zeroed, so coverage is heavily biased toward Android and consenting users.
• Commercial location datasets keyed to advertising identifiers are legally hazardous and, in several jurisdictions, unlawful to acquire.
• Corporate devices map to employees, so identifier analysis in the workplace triggers employee monitoring obligations.

Legal and ethical considerations

Advertising and device identifiers are personal data under GDPR and are explicitly regulated as online identifiers, with regulators having taken repeated enforcement action against adtech data flows. Process only identifiers you collected lawfully with valid consent, obtained through device management of assets you own, or extracted under proper legal authority. Do not purchase bid stream or commercial location data keyed to these identifiers for investigative purposes. Minimise, hash where possible, define retention, restrict access and document the lawful basis and necessity for every use.

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 Device / Advertising ID, 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, 2 mission domains, 6 closely related entries — every one of them a tag you can follow, and a dashboard you can open.

Questions analysts actually ask

Can I buy commercial location data to support an investigation?

No, and treat any suggestion of it as a serious risk to the case and the organisation. Regulators and legislatures in multiple jurisdictions have restricted or prohibited the sale and government purchase of location data derived from advertising identifiers, enforcement actions have been brought against brokers and buyers, and courts have questioned whether purchase can substitute for judicial authorisation. Practically, the data is of unverified provenance, the subjects gave no meaningful consent, and its presence in a file invites challenge to everything else. Use legal process instead.

Is a hashed identifier safe to share?

Not without salting, and often not even then. These identifiers occupy a small, well defined value space, so an unsalted hash can be reversed by generating hashes for all plausible values, which is computationally trivial. Salting with a per purpose secret prevents joining against external datasets but also means the hash is only useful inside your own environment, which is usually the point. Before sharing anything derived from identifiers, run a re identification assessment and assume a determined recipient will attempt reversal.

What is the difference between the identifier types?

Scope and persistence. Advertising identifiers are device scoped, resettable by the user and increasingly gated behind explicit consent, so they correlate activity across applications only while consent holds and the user has not reset. Vendor identifiers are scoped to a single developer and do not correlate across companies. Installation identifiers are unique per application install and vanish on reinstall. Hardware identifiers are persistent and unresettable but restricted to privileged use in modern platforms and regulated separately. Getting these confused produces linkage claims the platform cannot support.

How should we handle identifiers in our own product?

Collect only if you have a defined purpose, capture consent before collection where required rather than after, hash with a per purpose salt at ingestion, retain for the shortest period that serves the purpose, restrict access to the team that needs it, and delete on schedule. Document the necessity for each purpose separately rather than collecting broadly and finding uses later. Test the consent implementation, because collection occurring before consent is captured is one of the most common and most heavily penalised failures.

A device shows fifty accounts. Is that fraud?

It is a signal requiring exclusion logic before it becomes a finding. Shared family devices, refurbished and resold handsets, internal test devices, device emulators used for legitimate quality assurance, and public or workplace shared devices all produce high account counts innocently. Build the exclusions explicitly: check account creation timing, behavioural similarity, payment instrument overlap and content patterns. A device with fifty accounts created within an hour with sequential naming is a different finding from fifty accounts accumulated over four years.

Can I use an identifier to track a suspect?

Only through data you lawfully hold or obtain through process, and only within its actual scope. If a suspect used your service, your first party records showing that device identifier across accounts are legitimate evidence. If you want their activity elsewhere, that requires production orders to the relevant service providers. What you cannot do is acquire a commercial dataset keyed to their identifier to reconstruct their movements, which several jurisdictions now expressly restrict and which no competent prosecutor will want in the file.

What should I tell an at risk user about identifiers?

Cover the practical controls and be honest about their limits. Explain how to reset the advertising identifier and how to decline tracking authorisation where the platform offers it, and note that declining substantially reduces but does not eliminate cross application correlation because fingerprinting and first party identifiers persist. Review application permissions, particularly location, and remove applications that are not needed. For a high risk individual, a compartmentalised device with minimal applications is more effective than any configuration change on a general use handset.

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:

• GDPR Article 4 online identifiers and Articles 5, 6 and 7, governing lawful basis, minimisation and the conditions for valid consent.
• ePrivacy Directive provisions on access to information stored in terminal equipment, which govern identifier access independently of general data protection law.
• Platform developer policies on advertising identifiers and tracking authorisation, which define availability and permitted use.
• United States federal and state restrictions on sale and government purchase of location data derived from device identifiers.
• NIST SP 800-101 guidelines on mobile device forensics, defining acquisition and documentation practice for device derived identifiers.
• ISO/IEC 27701 privacy information management, providing controls for processing personally identifiable information including identifiers.
• OWASP Mobile Application Security Verification Standard, defining expectations for identifier handling in application security testing.
• MITRE ATT&CK for Mobile, providing shared technique identifiers for adversary collection of device identifiers.

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. Advertising ID documentation — Google. Platform documentation on identifier availability, reset behaviour and developer policy obligations.
2. App Tracking Transparency documentation — Apple. Platform documentation on tracking authorisation and identifier availability under consent.
3. Guidelines on Mobile Device Forensics — NIST. Federal guidance on acquisition and examination of mobile devices and their artifacts.
4. European Data Protection Board guidance — EDPB. Regulatory guidance treating device and advertising identifiers as personal data requiring consent.
5. Adtech and real time bidding analysis — Information Commissioner's Office. Regulatory assessment of identifier flows in programmatic advertising and their lawful basis problems.
6. Enforcement actions on location data brokers — Federal Trade Commission. Documented enforcement concerning sale and use of precise location data tied to device identifiers.
7. Out of Control report on mobile data sharing — Norwegian Consumer Council. Technical study documenting identifier transmission from mobile applications to advertising companies.
8. Mobile Application Security Verification Standard — OWASP Foundation. Standard covering identifier handling and data protection expectations in mobile applications.
9. MITRE ATT&CK for Mobile — MITRE. Technique taxonomy covering adversary collection of device identifiers on mobile platforms.
10. Technical analysis of tracking technologies — Electronic Frontier Foundation. Published research on identifier ecosystems and the limits of user facing privacy 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: correlates first-party device identifiers for abuse detection with minimisation, hashing and strict lawful-basis gating. Explore the platform, or browse the rest of the library by following any tag above.