TL;DR: Mobile app fingerprinting can uniquely identify devices and users by combining analytics, advertising and telemetry signals, even without login, according to NowSecure’s analysis. Persistent identifiers and SDK-driven data flows turn routine app behaviour into privacy, compliance and enterprise liability risk.
At a glance
What this is: NowSecure shows that mobile app fingerprinting can create persistent device and user identity from ordinary telemetry, ad data and SDK traffic even when no login exists.
Why it matters: It matters because AppSec, privacy and mobility teams need to govern how apps collect, combine and transmit signals that can expose identity, behavior and location.
Context
Mobile app fingerprinting is the practice of combining many small data points, such as advertising IDs, device details and network metadata, into a profile that can persist across sessions and sometimes across apps. In this case, the security problem is not a single malicious payload but routine telemetry being assembled into an identity signal.
That creates a direct governance issue for app security and privacy review. When apps gather more data than the user expects, the result can undermine consent, complicate compliance and create enterprise exposure through third-party SDKs and cross-app tracking. For organisations approving mobile software, the boundary between product analytics and identity tracking becomes the control point.
Key questions
Q: What breaks when mobile apps combine analytics and advertising data into a fingerprint?
A: The control that breaks is the assumption that individual data points are harmless in isolation. Once apps combine device attributes, identifiers and SDK traffic, they can reconstruct a persistent profile that outlives login status and sometimes even app reinstallations. That undermines privacy expectations and makes disclosure, consent and vendor oversight much harder to defend.
Q: Why do advertising IDs and SDKs increase tracking risk in mobile apps?
A: Because they create a reusable link between sessions, devices and services. Advertising IDs support attribution, but when apps and SDKs pair them with network metadata, usage events or device details, the result is cross-app correlation. That makes the risk less about a single field and more about how many identifiers are allowed to converge.
Q: What signs show that a mobile app is over-collecting identity signals?
A: Watch for repeated device identifiers, unexpected calls to ad or analytics endpoints, unusual volumes of pre-login network requests, and telemetry that includes network, battery or storage details without a clear product need. Those signals suggest the app is assembling more identity context than the user or enterprise likely intended.
Q: How should privacy and AppSec teams approve mobile apps that use tracking SDKs?
A: They should require runtime evidence of what the app actually transmits, then compare it with the declared privacy model and approved data uses. If the live traffic shows richer identity signals than the notice implies, the app should not pass review until the collection scope is reduced, documented or explicitly accepted.
Technical breakdown
How mobile fingerprinting is assembled from normal app telemetry
Mobile fingerprinting works by correlating signals that are individually ordinary but collectively distinctive. Device attributes, local network information, battery and storage status, SDK outputs, session tokens and advertising identifiers can be combined into a profile that survives normal app use. The key mechanism is correlation, not a single high-risk field. Even if one identifier changes, other stable signals can preserve continuity. That is why fingerprinting often hides inside analytics and monetisation flows rather than standing out as a separate feature. The risk grows when apps share the same identifiers with multiple ad and analytics services, because those services can also correlate behaviour across contexts.
Practical implication: review app telemetry as an identity surface, not just a data inventory.
Why SDKs and advertising IDs create cross-app tracking risk
SDKs are often trusted intermediaries that expand what the app can observe and transmit. Marketing and advertising SDKs may receive device details, usage events and identifiers that are then reused across apps and sessions. Advertising IDs are especially sensitive because they are designed to support attribution and targeting, but they can also become the backbone of persistent tracking. Once an app or SDK links a device signal to a behavioural profile, the result can outlive reinstallations or account changes. The governance issue is not whether tracking is technically possible, but whether it has been constrained to a disclosed and defensible purpose.
Practical implication: classify every third-party SDK by the identity and tracking signals it can expose.
How privacy review should treat fingerprinting as a compliance control problem
Fingerprinting is not only a privacy issue. It also raises compliance questions about consent, purpose limitation, disclosure and downstream sharing. If apps can reconstruct identity from hidden or unexpected signal combinations, privacy notices and user settings may not reflect actual data flows. For enterprise buyers, the same issue becomes a vendor risk problem because mobile apps can expose employee or customer behaviour outside approved boundaries. The control challenge is to test what the app transmits in practice, then compare that behaviour with the declared data collection model. Static policy alone will miss many of these cases.
Practical implication: require dynamic testing and audit-ready evidence before approving mobile apps for release or use.
Threat narrative
Attacker objective: The objective is to build a durable tracking profile that links a device or user across sessions, apps and services without relying on explicit account creation.
- Entry occurs when a mobile app collects ordinary telemetry, advertising data and SDK-derived signals during normal use, even before login.
- Credential-like continuity is created when unique identifiers, advertising IDs or app-assigned IDs are reused to tie sessions and behaviours together across requests.
- Impact occurs when those combined signals reconstruct a persistent profile that exposes identity, behaviour patterns or location and expands privacy and compliance liability.
Breaches seen in the wild
- iOS apps leaking hard-coded secrets: Cybernews found 71% of 156,080 iOS apps leak hard-coded secrets, with open cloud storage and Firebase databases exposing user data.
- Symantec mobile apps AWS keys 2022: Symantec found AWS keys hard-coded in 1,859 mobile apps; 77% were valid, many shared via SDKs, one exposing 300,000 fingerprints. No misuse reported.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Mobile fingerprinting is an identity governance problem, not just a privacy nuisance. When telemetry, advertising IDs and SDK outputs are merged into a stable profile, the app is effectively creating a non-human tracking mechanism that behaves like an identity system. That means AppSec and privacy teams must treat signal combination, not only data disclosure, as the control boundary. The practitioner conclusion is simple: identity risk is being generated inside the app runtime.
SDK concentration creates a hidden governance layer inside mobile applications. The more marketing, analytics and ad SDKs an app carries, the more difficult it becomes to explain which party is collecting which signal and for what purpose. This is where vendor due diligence, data mapping and runtime testing intersect. The practitioner conclusion is to review third-party SDKs as part of access and data governance, not as a separate procurement checklist.
Fingerprinting drift: the gap between what the privacy notice says and what the app actually transmits can become a standing compliance failure. Static disclosures rarely capture the full set of network requests, device attributes and cross-service identifiers that appear in live traffic. That makes runtime verification essential for auditability and defensibility. The practitioner conclusion is to prove actual data behaviour before release, not after a complaint or regulator query.
Enterprise mobility programmes need an evidentiary standard for mobile data collection. If an app can infer identity from non-obvious signals, then approval should depend on observable telemetry, not just declared intent. That changes review from a policy exercise into an evidence exercise. The practitioner conclusion is to require continuous testing where mobile apps are used for customer, employee or partner workflows.
OWASP relevance here is indirect but real: hidden signal reuse is a security design failure. The issue is not a traditional exploit path, but a data handling pattern that expands tracking surface and weakens user expectations. The practitioner conclusion is to align mobile app review with privacy engineering, third-party risk and runtime monitoring together.
From our research library:
- Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap, according to the State of Secrets in AppSec.
- Read next: Biometric Authentication and Verification Guide
What this signals
Fingerprinting drift: the practical problem is not just that mobile apps collect data, but that live traffic often exceeds the declared data model. That gap turns privacy review into a runtime verification problem, because the app can create a persistent identity profile from signals the user never meaningfully saw.
The strongest control point is release-time evidence. If privacy teams cannot show what the app actually transmitted, then they cannot credibly say the app stayed within purpose, disclosure and consent boundaries.
Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap, according to the State of Secrets in AppSec.
For practitioners
- Map mobile app telemetry to identity signals Catalogue advertising IDs, device attributes, session tokens and SDK outputs, then decide which combinations create persistent identity risk.
- Test live network traffic before release Use dynamic analysis to inspect the actual requests, headers and endpoints an app uses in production-like conditions.
- Review every third-party SDK for tracking scope Require owners to document which SDKs receive behavioural, device and location data, and whether each use is disclosed.
- Tie privacy approvals to evidence, not promises Block release until the observed traffic matches the declared data collection model and the exceptions are approved.
Key takeaways
- Mobile fingerprinting turns ordinary telemetry into a persistent identity mechanism that privacy notices may not fully capture.
- The exposure is amplified when ad, analytics and SDK data converge into cross-app tracking signals.
- Runtime traffic review is the practical control that shows whether a mobile app is collecting more identity data than its stated purpose allows.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 addresses the attack and risk surface, while NIST SP 800-63, NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-63 | SP 800-63C — Federation | Cross-app identifiers and shared tracking signals create federation-like linkage concerns. |
| Recommendation — Limit identity assertions shared across apps and services to only what the use case requires. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | Fingerprinting grows when apps overreach in what they can collect and transmit. |
| Recommendation — Restrict mobile app entitlements and the identity data they are authorised to process. | ||
| OWASP Non-Human Identity Top 10 | NHI-10 — Human Use of NHI | Human identity is being reconstructed through machine-driven tracking mechanisms, creating governance overlap with identity systems. |
| Recommendation — Review where human identity is inferred from machine tracking signals and constrain that linkage. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | The article shows persistent identifiers functioning like reusable authenticators across apps. |
| Recommendation — Manage reusable identifiers as authenticators and rotate or revoke them when tracking scope is excessive. | ||
Key terms
- Mobile App Fingerprinting: Mobile app fingerprinting is the practice of combining multiple device, network and behavioural signals to identify or track a user or device over time. The technique becomes more powerful as more data points are collected, even if each individual field looks harmless in isolation.
- Advertiser ID: Advertiser ID is a device-level identifier used for advertising and attribution on mobile platforms. Security and privacy teams treat it as sensitive because it can be combined with other signals to track user activity across apps and sessions, making it a useful marker for profiling even when it is not a credential.
- Runtime Privacy Control: Runtime privacy control is the practice of proving that privacy safeguards operate correctly while systems are live. It focuses on actual access, processing, and disclosure behaviour across APIs, services, and automated workflows, rather than on policies that only describe intended handling.
- SDK Data Sharing: SDK data sharing is the transfer of app-collected information to embedded third-party software development kits for analytics, advertising or other services. The security concern is that SDKs can widen the collection surface and create hidden paths for identity correlation and data disclosure.
Deepen your knowledge
The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, secrets management and identity lifecycle concepts that help security teams frame hidden tracking risk. It gives practitioners a consistent way to connect identity controls to broader security and privacy decisions.
Published by the NHIMG editorial team on August 2, 2026.
Updated on October 12, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org