Notifications
Clear all
Topic starter
01/08/2026 8:56 pm
TL;DR: An encrypted first-party framework can collect app activity, location, device identifiers, and camera usage, with keys embedded in the client and traffic decryptable from firmware and runtime hooks, according to NowSecure’s analysis of Transsion telemetry. The finding illustrates how mobile telemetry can become a device-wide collection layer that escapes normal app visibility and governance.
NHIMG editorial — based on content published by NowSecure: What the Transsion Telemetry Research Means for Mobile Security
By the numbers:
- Only 5.7% of organisations have full visibility into their service accounts.
- 92% of organisations expose NHIs to third parties, raising concerns about supply chain security.
- 79% of organisations have experienced secrets leaks, with 77% of these incidents resulting in tangible damage.
Questions worth separating out
Q: What breaks when mobile telemetry SDKs are hidden inside system apps?
A: App-level review breaks down because the SDK can observe and transmit device-wide behaviour from components the user did not install or meaningfully approve.
Q: Why do persistent mobile identifiers increase security and privacy risk?
A: Persistent identifiers make separate events joinable over time, across apps, and often across sessions.
Q: What do teams get wrong about standardising security telemetry?
A: The most common mistake is assuming that a single canonical schema can replace analytic design.
Practitioner guidance
- Map privileged mobile SDKs as software identities Inventory preinstalled services, embedded analytics libraries, and system-signed components separately from consumer apps.
- Inspect runtime telemetry, not just app manifests Use dynamic analysis to confirm what is actually transmitted, how payloads are protected, and whether keys or control-plane configuration are recoverable from the client.
- Classify persistent identifiers as re-identifiable telemetry Treat any event stream that combines durable identifiers with app inventory, location, or device metadata as identity-linked data.
What's in the full report
NowSecure's full analysis covers the operational detail this post intentionally leaves for the source:
- The step-by-step decryption method used to recover Athena traffic from firmware and live device instrumentation
- The recovered telemetry fields showing app inventory, location, foreground activity, and camera access data
- The host and control-plane mapping for shalltry.com endpoints and how the telemetry flow is routed at runtime
- The app and device package examples that demonstrate how the SDK appears in both system and third-party software
👉 Read NowSecure's analysis of Transsion telemetry and mobile SDK collection →
Transsion telemetry and mobile SDKs: what security teams need to know?
Explore further
01/08/2026 9:04 pm
Mobile telemetry is increasingly an identity problem, not just a privacy problem. When software can bind app usage, location, and device state to stable identifiers, it creates a cross-app identity graph that sits outside conventional enterprise controls. That is especially relevant when the telemetry component is system-signed or embedded in widely distributed apps. The practical conclusion is that mobile governance must account for identity linkage, not merely data volume.
A question worth separating out:
Q: How should organisations govern mobile SDKs that collect app and device data?
A: They should review them as software identities with permissions, network reach, and lifecycle risk. That means inventorying embedded SDKs, validating runtime behaviour, limiting collection of persistent identifiers, and applying network controls where the telemetry path cannot be fully trusted. Documentation alone is not enough for approval.
👉 Read our full editorial: Transsion telemetry shows how mobile SDKs become device-wide risk
