Skip to content

Collection of Device Identifier

Description

Collection of Device Identifiers

A device identifier is any value—hardware-based, platform-provided, or application-generated—that remains stable over time and can be used to uniquely identify a device or user across sessions. These identifiers enable device recognition and long-term correlation of activity, but also introduce significant privacy considerations.

There are typically three families:

Hardware-Based Identifiers

Hardware identifiers come from the device’s physical components or firmware and usually remain constant for the lifetime of the device.

  • IMEI / MEID: Unique modem identifiers historically used to identify mobile devices. Access is highly restricted on modern operating systems.
  • Serial Number: A unique hardware identifier assigned by the manufacturer. Generally not accessible to normal applications.

Platform-Provided Identifiers

Operating systems expose identifiers with limited scope or permissions.

  • Android ID: A stable, app-scoped identifier that persists across reinstalls for the same app and signing key on modern Android versions.
  • IDFV (Identifier for Vendor): An iOS identifier shared across apps belonging to the same vendor, reset only if all of the vendor’s apps are uninstalled.
  • IDFA (Advertising Identifier): A user-resettable identifier used for advertising and analytics, available only with user consent under modern privacy frameworks.

Application-Generated Identifiers

Applications may generate their own identifiers and store them persistently.

  • Custom UUIDs: Random identifiers stored in local storage or secure system keychains, potentially surviving app reinstalls.
  • Derived or hashed identifiers: Values created by combining device attributes.

These identifiers function as device identifiers if they can be used to correlate user activity over time.

Privacy & Regulatory Considerations

Under major privacy regulations such as GDPR, CCPA, and similar frameworks, persistent device identifiers are classified as personal data because they allow the identification or tracking of a user or device. Improper handling may violate:

  • Data minimization
  • Purpose limitation
  • Transparency requirements
  • Consent obligations

Platform policies (e.g., Apple App Store, Google Play) further restrict the use of persistent identifiers for analytics, advertising, or cross-app tracking without explicit user authorization.

Security & Compliance Implications

Persistent identifiers can be misused for:

  • Device fingerprinting
  • Cross-app or cross-service tracking
  • Behavioral profiling

Because of this, they require careful handling and justification for collection.

Recommendation

Recommendation

For secure and privacy-respecting handling of persistent device identifiers, it is crucial to follow best practices that minimize tracking risks and comply with privacy regulations. Two general strategies are recommended:

  • Limit Collection and Prefer Safer Identifiers: Only collect persistent device identifiers when strictly necessary for core application functionality. Avoid hardware-based identifiers like IMEI or serial numbers unless there is a compelling operational need. When collection is required, prefer safer alternatives such as platform-approved app-scoped identifiers (e.g., Android’s App Set ID, iOS’s IDFV) or ephemeral/custom-generated UUIDs stored securely for the duration of the app lifecycle.

  • Transparency and Consent: Clearly document the purpose of collecting any persistent identifier. Disclose collection practices in the privacy policy and obtain user consent where legally required.

  • Secure Storage: Store any persistent identifiers securely using platform-provided secure storage mechanisms (e.g., Android Keystore, iOS Keychain). Avoid storing identifiers in plain text or in locations accessible to other apps.

  • Avoid Cross-App Tracking: Do not use persistent identifiers for advertising, analytics, or tracking across multiple apps unless explicitly allowed by platform policies and user consent.

By following these best practices, applications can reduce privacy risks, comply with regulatory requirements, and maintain user trust.