Transsion telemetry shows how mobile SDKs become device-wide risk

At a glance

What this is: NowSecure’s Transsion research shows that first-party mobile telemetry can be decrypted to reveal app activity, location, and device-level identifiers collected through embedded SDKs.

Why it matters: It matters because mobile security, IAM, and privacy teams need visibility into hidden data collection paths that can bind sensitive behaviour to persistent identifiers outside user or enterprise control.

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.

👉 Read NowSecure's analysis of Transsion telemetry and mobile SDK collection

Context

Mobile telemetry is often treated as a benign background function, but the control problem is access, not intent. When an SDK can collect device events, bind them to persistent identifiers, and transmit them through encrypted channels, security teams lose the visibility needed to judge what is actually being shared. In this case, the primary issue is not just mobile privacy; it is unmanaged data collection and governance drift inside software users and enterprises rarely inspect at runtime.

That matters for identity security because the telemetry path behaves like a non-human identity in practice: it is a software actor with permissions, network access, and a repeatable execution pattern. Where an SDK is system-signed or embedded in third-party apps, traditional app approval and source review will not reveal the full collection surface. The starting position here is atypical in the amount of detail recovered, but the underlying governance gap is common across mobile ecosystems.

Key questions

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. Once the SDK is system-signed, permissions and visibility expand beyond the host app’s expected scope. That makes telemetry governance a privileged software identity problem, not a simple app consent problem.

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. That turns routine telemetry into a durable profile that can reveal behaviour patterns, location history, and app inventory. The risk is not one data point in isolation, but the ability to correlate many low-sensitivity events into high-sensitivity identity insight.

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. Standardisation helps teams share and move data, but it does not replace enrichment, entity resolution, or behavioural detection. If the schema becomes the ceiling, the platform becomes easier to integrate but harder to investigate.

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.

Technical breakdown

Encrypted telemetry does not equal protected telemetry

The research shows a common mobile security misconception: encryption in transit can hide collection from observers, but it does not provide confidentiality if the client carries the key material. Here the payload was encrypted with AES-CBC, yet the key table and IV were recoverable from the application itself. That means anyone with the binary, memory access, or runtime instrumentation can reconstruct the traffic. For security teams, the architectural lesson is that client-side secrecy is fragile when the collecting component must also decrypt its own transmissions.

Practical implication: treat embedded telemetry as inspectable software behaviour, not as a trustworthy encrypted channel.

System-signed SDKs expand the telemetry trust boundary

The same telemetry SDK behaves very differently depending on where it runs. In an ordinary app context it is constrained by the sandbox, but as a system component it inherits privileged access and can observe device-wide state such as foreground apps, location, and hardware-linked identifiers. That changes the trust boundary from an app-level analytics feature to a fleet-wide collection service. In identity terms, this is a privileged software principal with access beyond the user-installed app’s expected scope.

Practical implication: inventory system-signed components separately from ordinary apps and review their permissions as privileged identities.

Persistent identifiers turn telemetry into joinable identity data

The most material risk is not a single data point, but the way telemetry records are bound to durable identifiers. Once app usage, location, device metadata, and package inventory are correlated to stable IDs, the result is a long-lived profile that can be linked across sessions and applications. This is a governance problem because it creates an externalised identity graph outside enterprise controls. Mobile security review therefore needs to assess not only what is collected, but whether the collection can be re-identified and joined over time.

Practical implication: classify telemetry outputs by re-identification risk and block collection paths that create persistent cross-app linkage.

Threat narrative

Attacker objective: The objective is to collect high-fidelity behavioural and identity-linked telemetry from mobile devices without meaningful user or enterprise visibility.

1. Entry occurs through preinstalled or embedded mobile SDKs that ship inside system apps and third-party applications, giving the telemetry framework direct runtime presence on the device.
2. Credential access happens when the client contains the decryption materials, allowing observers to recover the AES key table and IV from the binary or memory.
3. Escalation follows when system-signed placement expands the SDK from app-local reporting to device-wide collection across privileged components and installed apps.
4. Impact is the creation of a persistent telemetry feed that exposes app activity, location, camera usage, and device-linked identifiers at scale.

NHI Mgmt Group analysis

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.

Client-side encryption cannot be treated as a control when the client owns the keys. The research shows that encrypted telemetry can still be recoverable if key material is embedded in the application or derivable at runtime. That is a governance assumption failure, because the organisation assumes encryption implies limited visibility. In reality, the telemetry path remains fully inspectable by anyone who can analyse the app or intercept its runtime behaviour.

Privilege turns telemetry into a platform-level control plane. Once a telemetry SDK runs with system privileges, it stops being a narrow analytics component and becomes a device-wide sensor. That is the named concept here: telemetry trust boundary expansion, meaning ordinary collection features gain privileged reach without corresponding governance review. Security teams should treat this as a privileged software identity and evaluate it accordingly.

Mobile AppSec needs runtime evidence, not just documentation. Source code review and vendor statements will not fully reveal what a mobile component collects, how it encrypts traffic, or how it joins records across apps. Runtime analysis exposes the real behaviour, which is the only basis for judging risk in systems that can be preinstalled, system-signed, or hidden inside third-party software. The practitioner takeaway is that runtime inspection must become part of mobile governance.

Third-party mobile SDK distribution is an NHI-style supply chain risk. An embedded telemetry framework behaves like a non-human identity because it has credentials, network endpoints, repeatable actions, and access boundaries that matter more than the app label. That makes lifecycle control, provenance review, and endpoint governance relevant in a mobile context. Teams should apply software identity thinking to mobile SDKs that can act beyond the host app’s intended scope.

What this signals

The operational signal for mobile and identity teams is that telemetry governance now needs the same discipline applied to high-risk non-human identities. If a software component can see, join, and export user behaviour across applications, then ownership, scope, and revocation questions become unavoidable. The relevant benchmark is not whether the app is popular, but whether the organisation can explain what the component can do at runtime and under which privilege boundary.

Telemetry trust boundary expansion: this is the pattern practitioners should watch for as mobile platforms, SDKs, and embedded analytics increasingly cross the line from app-local measurement into device-wide observation. That boundary shift complicates app approval, privacy review, and enterprise allowlisting because the visible application is no longer the full security subject. Teams should align mobile review with the NIST Cybersecurity Framework 2.0 and, where device access is privileged, treat the component as a software identity with lifecycle controls.

For practitioners

• Map privileged mobile SDKs as software identities Inventory preinstalled services, embedded analytics libraries, and system-signed components separately from consumer apps. Record permissions, network destinations, and whether the component can observe device-wide state such as installed apps, location, or camera events.
• 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. Static review alone will miss client-owned decryption paths and hidden data joins.
• 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. Apply stronger retention, access, and transfer controls when telemetry can be correlated across apps or sessions.
• Block untrusted mobile data paths at the network edge Where enterprise policy requires it, enforce DNS or egress controls against known telemetry domains and monitor for wildcard or GSLB-backed endpoints that can shift hosts dynamically. The point is to cut off the collection path, not just the visible leaf host.
• Separate user consent from system privilege Do not assume a user-installed app permission model explains what a system component can see. Review privileged mobile software under the same scrutiny you would apply to a high-value service account in enterprise infrastructure.

Key takeaways

• Encrypted mobile telemetry can still be fully inspectable when the client carries the keys or configuration needed to decrypt it.
• System-signed or embedded SDKs can turn ordinary app analytics into device-wide identity-linked data collection.
• Mobile security teams need runtime analysis, privilege review, and identity-style lifecycle controls to govern hidden telemetry paths.

Key terms

• Mobile Telemetry: Mobile telemetry is data a device or app sends back about behaviour, usage, or state. In security terms, it can include location, app inventory, identifiers, and interaction events, which makes governance about collection scope, retention, and re-identification risk as important as transport security.
• 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.
• Persistent Identifier: A durable signal used to recognise a device or browser over time, even when some session attributes change. In practice, it helps teams connect repeated behaviour to the same source and distinguish ordinary reuse from coordinated abuse or automation.
• Runtime Analysis: Runtime analysis is the inspection of software while it is executing, not just by reading code or documentation. It reveals actual network behaviour, decrypted payloads, and privilege use, which is essential when embedded SDKs hide collection logic behind obfuscation or client-side encryption.

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

👉 The full NowSecure post covers the decryption workflow, payload fields, and mobile supply-chain exposure in detail.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It is designed for practitioners who need to apply identity controls consistently across software identities and privileged access paths.