Summary
For years, fraud prevention solutions have tried to use Device IDs to bind (or link) a user’s account or session to a specific device to prevent unauthorized access from other devices. However, until recently, Device IDs lacked persistence and the broad threat context needed to stop fraud and ATOs effectively. Now, with IDAnchor™, they can.
The Background of Device IDs & Device Binding (From 2010+)
In the early days of the mobile economy, Apple’s UDID and Google’s Android IMEI provided a durable way to link apps, sessions, and accounts to a physical device. But, starting in 2011, Apple deprecated UDID, replaced it with the resettable IDFA, and began limiting access to its hardware identifiers. Google followed suit, providing its own resettable Advertising ID and restricting access to device-specific attributes.
Third-party vendors entered the market to provide their own Device IDs. These early solutions relied on what remained of OS-level signals to fingerprint a device. Attributes, such as device model, type, network, SIM card and carrier details were used by these systems to generate Device IDs for each device. Vendors like ThreatMetrix and iovation (later acquired by TransUnion) released mobile SDKs that were basically attribute collectors, combining OS-provided attributes into new pseudo-device IDs for mobile devices.
However, these early solutions could not distinguish between two devices of the same type or accommodate the changes each device undergoes during the user’s lifetime. OS-provided device attributes change when the OS is updated. Carriers and SIMs can be swapped on the same device. Once SIM data too became unavailable and the OS manufacturers allowed users to opt out of device tracking for advertising, vendors were stuck. On top of this, user-controlled device resets and optional device wiping added complexity. Attackers began to spoof OS-level signals. All in all, the early attempts to replace hardware-based identifiers failed.
Probabilistic Device IDs & Device Binding (From 2020+)
By 2020, all non-resettable hardware and SIM identifiers were effectively unavailable to third-party apps on both iOS and Android. A handful of vendors turned to probabilistic device fingerprinting (e.g., inAuth, Topaz, and ThreatMetrix). These vendors combined device signals into probabilistic models to determine whether two sessions originated from the same device. These vendors augmented their probabilistic models with:
- Behavioral Biometrics (e.g., Biocatch, Experian Topaz) – typing, swiping, and sensor-driven patterns unique to a user combined with limited threat indicators, such as jailbreak and root detection.
- Feedback Loop from Brands & Enterprises (e.g., ThreatMetrix) – allowing brands and enterprises to flag devices used in fraud to help the vendor create a global database of malicious devices.
At their core, however, these methods still relied on ephemeral OS-provided device attributes. They lacked the immutability of hardware-based device IDs. And, while these techniques added additional context to determine the state of a given device, they lacked the correct or broad enough threat context to combat the rise of sophisticated attack vectors.
AI’s Impact on Mobile Identity (2025+)
By 2025, AI had changed the threat model for mobile identity. Fraudsters no longer needed to compromise the victim’s device. With deepfakes, they can generate convincing biometric data and bypass IDV and Biometric Authentication from entirely separate devices loaded with the tools necessary to carry out each attack. Additionally, social engineering scams don’t rely on device changes. They trick users into downloading a Trojan app onto the user’s real device to steal credentials and hijack sessions.
New methods made it trivial to fake device attributes, manipulate advertiser IDs, spoof location, and mimic user behaviors at scale. In this environment, binding an account to a set of OS-provided device attributes, even when combined with behavioral biometrics and manual feedback loops, no longer guarantees trust in mobile identity. The mobile economy reached its crossroads.
IDAnchor’s Device IDs & Device Binding
In 2025, Appdome launched IDAnchor™ to enable mobile brands and businesses to redefine customer and device identity in an age of AI. The goal of IDAnchor was to allow mobile brands to confidently determine whether an in-app activity, API request, or user action originates from a genuine or trusted app and device, free from compromise or threat.
What makes IDAnchor unique is that each user establishes a customer identity via an immutable chain of trust that includes the mobile app, installation, and device used to engage with the brand. Mobile brands use IDAnchor to bind each customer identity, identity assertion, account, or session to a brand-specific:
- Workspace ID – the root identifier for all customer, device, application, and installation identities within the brand’s business.
- Release ID – a unique identifier bound to the specific mobile app binary released to public app stores.
- Install ID – a persistent identity for each installation of an app on a specific device, surviving across sessions.
- Device ID – an immutable identity anchor tied to each device that is resistant to resets.
As part of IDAnchor, a mobile brand can also receive:
- True Device Attributes – verified device attributes such as manufacturer, model, OS, OS version, as well as detailed information on device state.
- Threat Signals – Each IDAnchor payload can be combined with up to 400+ threat signals to detect location spoofing, geo-fraud, deepfake attempts, malware, spyware, social engineering scams, IT scams, fake devices, and more.
Together, these elements form a multi-layered trust fabric that ties customer identity to trusted apps, installs, and devices. Any break in the chain of trust will signal a threat or compromise to the account, session, or user experience.
The Future of Device Binding in the AI Age
The original Device ID anchors provided by the OS (the UDID, IMEI, SIM data) are gone. The early substitutes were too narrow, easily spoofed, and dependent on signals that OS vendors, users, and attackers could change or remove at will. Today, fraudsters can generate synthetic identities, mimic user biometrics, and disguise malware inside virtual devices. To combat account-based fraud, ATOs, and unauthorized access, the market has learned that looking solely at OS-provided device and user-based biometric signals is insufficient.
IDAnchor expands the context for trusted identity to include application, install, and device identifiers – all anchored to a workspace ID owned by the brand. The Workspace ID acts as the root of trust for all customer, device, application, and installation identities. From this anchor, all other identifiers can be validated, linked, and evolved over time. It elevates device binding from a fragile patchwork of OS-provided “device signals” and “probabilities” into an immutable, threat-aware trust framework that comes from the brand and lives and grows with each user. Combined with OS-independent device attributes and over 400+ threat signals, mobile brands can finally reclaim control over mobile identity at a time when attackers are innovating faster than ever.
