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.
At a glance
What this is: NowSecure’s analysis shows that Transsion’s mobile SDK telemetry is encrypted in transit but still readable because the client holds the keys, exposing device-wide collection across apps and system components.
Why it matters: This matters because mobile telemetry can become an ungoverned collection layer that bypasses app sandbox assumptions, complicating third-party risk, privacy review and mobile app governance.
Context
Mobile telemetry is data sent from a device or app about user, app, and system activity. In this case, the security gap is not simply that the telemetry exists, but that it is collected by components outside the user's direct control and can span the whole device rather than a single app.
The governance problem is that encrypted transport does not equal controlled visibility. When SDKs sit in preinstalled apps, system-signed components, or widely distributed consumer apps, normal app review and sandbox assumptions do not show what is being collected or how broadly it is shared across the device ecosystem.
Key questions
Q: How should security teams govern mobile SDK telemetry that reaches beyond a single app?
A: Treat mobile telemetry as a collection-scope problem, not just an app-security problem. If an SDK can observe foreground activity, installed apps or device identifiers, governance has to include runtime validation, data-minimisation review, and explicit approval for privileged components that can operate across the handset.
Q: Why is encrypted mobile telemetry still a governance risk if the traffic is protected in transit?
A: Because transport encryption only helps if the keys stay out of the client and out of runtime memory. When the app ships the IV, key table or other decryption material, the telemetry remains recoverable and reviewable by anyone who can inspect the binary or hook the process.
Q: Where do mobile SDK controls fail when telemetry is embedded in privileged system apps?
A: They fail at the boundary between app-level trust and device-level privilege. A system-signed component can collect data from across the handset, so controls designed for a sandboxed app do not limit what the SDK can observe or transmit.
Q: What should organisations check before allowing apps with embedded analytics or telemetry SDKs?
A: Check what the SDK collects at runtime, where the keys live, which system permissions it inherits, and whether the same telemetry plane exists in other apps or firmware builds. That is the practical test for whether the collection is app-scoped or device-wide.
Technical breakdown
Why encrypted telemetry still leaks data
The traffic uses AES-CBC with a fixed IV and per-message keys chosen from a client-side key table. That means the payload is encrypted for transport, but the protection depends on secrets embedded in the application and retrievable from firmware or runtime memory. Once the key table and IV are recovered, the ciphertext becomes readable and the telemetry corpus can be inspected across versions and devices. This is not strong confidentiality; it is obscurity anchored in the client build.
Practical implication: Treat client-held telemetry keys as recoverable and validate mobile data flows by decrypting actual runtime traffic, not by trusting transport encryption.
How system-signed Android SDKs become device-wide collectors
Android SDKs normally inherit the sandbox of the host app, but a system-signed build running in privileged partitions can access far more than the app that embeds it. In this case, privileged components can observe foreground app state, camera use, location, clipboard and installed-app inventory, then ship that data through central telemetry services. The control boundary has moved from app scope to device scope, which is why the same SDK behaves very differently once it is granted system privileges.
Practical implication: Review any telemetry or analytics component that ships with privileged permissions as a device-wide data collector, not as an ordinary app library.
Why runtime analysis is essential for mobile SDK governance
Static review of code, manifests and vendor claims misses what the device actually emits at runtime. The research shows that one SDK instance can report every installed app, current foreground activity and OS-level signals that are invisible to the user and often invisible to app-level governance. That creates a supply-chain visibility gap: the organisation may approve the app while never seeing the telemetry plane behind it. Runtime instrumentation closes that gap by exposing the real collection surface.
Practical implication: Add runtime traffic inspection and firmware-level review to mobile risk assessments whenever SDK-driven telemetry is part of the app or device stack.
Threat narrative
Attacker objective: The objective is persistent, device-wide telemetry collection that can be read by anyone able to recover the client-side keys, turning mobile analytics into broad surveillance data.
- Entry occurs through preinstalled system apps and widely distributed third-party apps that embed the telemetry SDK, giving the collector a foothold on both Transsion and non-Transsion devices.
- Credential and key access are effectively built into the client because the AES keys and IV can be recovered from the app bundle and runtime memory, allowing the traffic to be decrypted.
- Collection and impact follow at device scope because the telemetry records app inventory, foreground activity, location, camera use and permanent identifiers across the whole handset.
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.
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
Device-wide telemetry is the real governance boundary: once a mobile SDK runs inside privileged system components, the question is no longer which app it belongs to, but what the device can now observe and transmit. That shifts oversight from app approval to collection-scope governance, especially where a single framework sees installed apps, foreground state, location and hardware identifiers. Practitioners should treat system-signed telemetry as a separate control domain.
Client-held encryption keys create a false sense of protection: transport encryption does not protect telemetry when the decryption material ships in the same binary or can be recovered from runtime state. The field should name this failure mode as recovered-key telemetry, because the data remains collectible even when network traffic looks opaque. Security teams should assume that obscured telemetry is still discoverable unless the key lifecycle is externalised.
Mobile app risk is increasingly supply-chain risk: the same SDK logic can appear in preinstalled device software and in popular third-party apps, which means app-store trust does not equal collection governance. That makes mobile telemetry a third-party access problem as much as a privacy problem, with the control gap sitting between vendor assurances and actual device behaviour. Practitioners should expand mobile due diligence beyond static app review.
Runtime observation is the only reliable truth source for mobile data flows: code review, manifest inspection and policy documents do not reveal what a handset actually emits once it is live. The research demonstrates why mobile governance needs behavioural validation, not just procurement checklists. Security teams should verify what the device sends before they decide whether the app or SDK is acceptable.
What this signals
Recovered-key telemetry is the key concept here: when decryption material lives inside the client, the organisation is not managing a protected channel so much as a discoverable data pipe. That means mobile governance has to shift from “is it encrypted?” to “can the telemetry be recovered, decoded and scoped in practice?”
For mobile programmes, the next control question is whether privileged SDKs are being treated as device-side data processors. If a preinstalled or widely embedded component can see installed apps, camera use or location, then app approval alone is not a sufficient boundary; the device itself becomes part of the trust model.
For practitioners
- Validate telemetry at runtime Instrument representative devices and confirm what SDKs actually send, including app inventory, location, camera events and identifiers, rather than relying on code review alone.
- Classify system-signed SDKs as device-wide collectors Require extra governance for any telemetry component embedded in privileged apps or system partitions, because its collection scope exceeds the host app boundary.
- Review mobile SDK key management Check whether telemetry encryption keys, IVs or config bundles are recoverable from the client, firmware or memory, then treat those flows as exposed if they are.
- Map third-party apps that share telemetry planes Inventory consumer apps and preinstalled software that connect to the same telemetry hosts so you can assess collection scope across the fleet, not just one device family.
Key takeaways
- Mobile telemetry can become device-wide when a privileged SDK collects across apps, not just inside the host app.
- Encrypted mobile traffic is not a reliable control if the keys, IV or key table are recoverable from the client.
- Governance has to move from static app review to runtime verification, because that is where the real data collection surface appears.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP API Security Top 10 | API8 — Security Misconfiguration | The telemetry plane relies on opaque client and transport design that obscures data handling. |
| Recommendation — Review telemetry endpoints and client configurations for misconfigured access paths that expose device data. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | Privileged system components have access to device-wide data beyond the host app boundary. |
| Recommendation — Limit telemetry components to the minimum permissions needed for their collection scope. | ||
| CIS Controls v8 | CIS-5 — Account Management | The article shows a central service managing broad device data flows and privileged access paths. |
| Recommendation — Inventory and review privileged service accounts and embedded components that can collect device-wide data. | ||
| MITRE ATT&CK | TA0006;TA0007 — Credential Access; Discovery | Recovered client keys and device inventory exposure map to key access and discovery activity. |
| Recommendation — Map exposed telemetry and recovered keys to TA0006 and TA0007 to prioritise detection and containment. | ||
Key terms
- Telemetry SDK: A telemetry SDK is a software component that collects and transmits device or app activity to a backend service. In mobile environments, it can observe usage, identifiers and system state, and its real governance risk depends on where it runs and what permissions it inherits.
- System-signed App: A system-signed app is signed with the platform or device vendor certificate and may run with elevated trust or privileges. That can allow device-wide observation or control that ordinary user-installed apps cannot perform, so its security review must be closer to privileged infrastructure than consumer software.
- Client-side Key Material: Client-side key material is encryption data embedded in the application or recoverable from its runtime state. It weakens confidentiality when the same binary that encrypts traffic also contains the means to decrypt it, making encrypted transport easy to reverse during analysis.
- Device-wide Collection: Device-wide collection is the practice of gathering telemetry from across the whole handset rather than from one isolated app. It becomes a governance problem when system components, shared SDKs or privileged services can aggregate data that users and app owners do not expect to be combined.
Deepen your knowledge
The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, workload identity and secrets management in a way that helps practitioners reason about hidden access paths. It is suitable for teams that need a stronger control model for identity-linked data flows across modern environments.
Published by the NHIMG editorial team on August 1, 2026.
Updated on October 13, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org