TL;DR: 35% of tested iOS apps failed to disclose collected data, 97% lacked required third-party SDK privacy manifests, and 18% of 183,000 mobile apps used AI, creating hidden data-flow, consent, and compliance risk across mobile ecosystems, according to NowSecure. The governance gap is not visibility alone but accountability for what apps, SDKs, and AI endpoints actually transmit.
At a glance
What this is: NowSecure argues that mobile privacy exposure is no longer just a compliance issue, because hidden data collection, missing manifests, and unapproved AI flows create a governance gap across apps and third-party components.
Why it matters: IAM, privacy, AppSec, and data governance teams need visibility into what mobile apps collect, who can access it, and whether SDKs, APIs, and AI endpoints are operating within approved control boundaries.
By the numbers:
- 35% of the iOS apps failed to disclose the data they collected.
- 97% were missing required Privacy Manifests for their third-party SDKs.
- 18% (33,396 apps) use artificial intelligence.
- 40% of 10,500 Android apps don’t declare that they can support a way to be forgotten.
Context
Mobile privacy risk is what happens when applications collect, share, and transform personal data in ways users, regulators, and enterprises cannot clearly see or govern. In this article, the primary issue is not just whether data exists on a device, but whether disclosures, SDK dependencies, and AI-driven data flows are controlled as part of a broader governance model.
That matters for identity and access programmes because mobile apps now sit inside the same trust fabric as customer identity, employee access, consent records, and regulated data handling. Once apps, third-party SDKs, and AI endpoints can move data without clear approval or inventory, privacy and access governance stop being separate disciplines and become one operational control problem.
Key questions
Q: What breaks when mobile apps do not disclose data collection properly?
A: Disclosure gaps break the organisation’s ability to prove purpose, necessity, and accountability. Users, regulators, and internal security teams lose the evidence needed to judge whether an app’s behaviour matches its stated privacy posture. In practice, that also weakens incident response because hidden data flows are harder to trace after a complaint, breach, or enforcement action.
Q: Why do embedded advertising SDKs create compliance and privacy risk for mobile apps?
A: Embedded advertising SDKs can collect sensitive data outside the developer’s direct control, then transmit it through networks the team may not fully understand. That creates exposure to GDPR and CCPA violations, unauthorized profiling, legal claims, and loss of customer trust. The risk is highest when teams assume an SDK is only for monetization and do not validate its actual data flows.
Q: How should organisations govern private AI apps used on mobile devices?
A: Treat them as governed data-processing tools, not harmless consumer apps. Allow use only when you can verify where prompts and uploads go, whether sharing is enabled, and how feature access is controlled. The right control set combines app approval, content classification, and access review, especially when documents or images are involved.
Q: When should privacy teams block a mobile app from release?
A: They should block release when the app requests excessive permissions, lacks required disclosures, or sends regulated data to unapproved third parties. The decision should be based on data sensitivity, purpose limitation, and the ability to evidence control over downstream sharing. If those cannot be shown, the app is not ready for production use.
Technical breakdown
Hidden data flows inside mobile apps
Mobile apps can collect data through first-party code, third-party SDKs, embedded APIs, and background telemetry that users never see. Privacy manifests and data-safety declarations are meant to make those flows legible, but the article shows those controls are often missing or incomplete. The real technical issue is that data handling is distributed across components, so a developer may not directly control every endpoint that receives personal data. That creates a control gap between what the app appears to do and what it actually transmits.
Practical implication: inventory every app component that can originate or forward personal data, including SDKs and AI services.
Dangerous permissions, entitlements, and mobile access scope
Android permissions and iOS entitlements define what sensitive resources an app can reach, such as location, microphone, camera, photos, storage, and private files. When an app requests more than it needs, the permission model stops being a narrow access gate and becomes a privacy amplification mechanism. The article’s point is that excessive access scope, combined with tracking domains or external analytics, turns ordinary app functionality into a broad data extraction path. That is a governance failure as much as a technical one, because approval should be tied to necessity and declared use.
Practical implication: review entitlement scope against business need and block apps that request sensitive access without a clear purpose.
AI endpoints as a new mobile data exfiltration path
The article shows that mobile apps using AI can send data to remote endpoints for inference or processing, which introduces a separate privacy plane outside the traditional app store disclosure model. If those transmissions are unencrypted, unauthorised, or not pre-approved, the AI service becomes part of the app’s data-processing chain. This is where mobile privacy intersects with AI governance: the identity of the endpoint, the data shared with it, and the approval status of that exchange all matter. In practical terms, AI use in mobile apps is now a data-governance and third-party-risk issue, not just a product feature.
Practical implication: treat AI endpoints as governed third parties and require approval, monitoring, and data-flow documentation before use.
Threat narrative
Attacker objective: The attacker or unsafe data recipient aims to harvest sensitive mobile data at scale and turn it into profiling, monetisation, coercion, or compliance leverage.
- Entry begins when a mobile app or its embedded component requests broad permissions, integrates third-party SDKs, or sends data to an AI endpoint without clear disclosure.
- Credential and access abuse follow when those permissions expose camera, microphone, location, contacts, messages, files, or tracking-linked telemetry beyond user expectation.
- Impact occurs when personal data is shared, leaked, or repurposed for profiling, tracking, blackmail, consent violations, or regulatory exposure.
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
Mobile privacy has crossed from disclosure management into access governance. Once an app can collect data through SDKs, background services, and AI endpoints, the real question is who approved that flow and whether it remains within declared purpose. Transparency alone does not stop over-collection, so privacy teams need control ownership, not just notices and policies. The practitioner conclusion is that mobile privacy must be governed as an access problem.
Third-party SDKs are now part of the mobile trust boundary. The article shows why treating SDKs as invisible implementation detail is no longer defensible. If the component can observe, enrich, or forward user data, it must be inventoried and constrained like any other high-risk dependency. The governance concept here is mobile data supply chain risk, and the practitioner conclusion is to manage SDKs as controlled data processors.
AI-enabled mobile apps create a new accountability gap for consent and data sharing. Mobile AI use can move sensitive content into remote services that sit outside store-level disclosure and traditional app security reviews. That means model endpoints, prompt content, and transmission paths all need governance, especially where regulated data is involved. The practitioner conclusion is that AI in mobile apps should not be allowed to bypass privacy approval workflows.
Selective disclosure is the symptom, not the problem. Missing privacy manifests and incomplete data disclosures matter because they reveal a deeper failure to align technical behaviour with legal and operational accountability. In the mobile ecosystem, the organisation shipping the app is still accountable for what the app and its dependencies do, even when third-party code creates the exposure. The practitioner conclusion is to assign accountability for hidden data flows before shipment, not after complaint or enforcement.
Mobile privacy risk is now a board-level governance issue because it ties together brand, regulatory, and identity trust. When mobile apps collect more than users expect, the organisation inherits the operational burden of proving necessity, disclosure, and control. That is especially true where mobile apps touch customer identity, employee access, or regulated personal data. The practitioner conclusion is that privacy evidence must be auditable across the full app ecosystem, not assumed from policy text alone.
What this signals
Mobile privacy risk is an inventory problem before it is a legal one. If an organisation cannot name every app, SDK, and AI endpoint that touches personal data, it cannot credibly prove consent, purpose limitation, or sharing boundaries. That is why mobile governance needs the same operational discipline as identity governance: ownership, approval, and evidence.
NowSecure’s findings point to a hidden-data-flow gap that standard app reviews often miss. The practical failure is not only in what an app requests, but in what its dependencies transmit after installation. Teams should expect privacy controls to move closer to runtime inspection and release gating, rather than relying on policy declarations alone.
Mobile app privacy risk is now a cross-functional control issue. AppSec, privacy, IAM, and data governance teams all need to work from the same app and data-flow inventory so that approvals, access scope, and disclosure evidence line up. The organisations that close this gap will be able to defend both user trust and regulatory accountability.
For practitioners
- Define mobile privacy inventory ownership Assign a named owner for every mobile app, SDK, API, and AI endpoint that can collect or transmit personal data.
- Enforce entitlement minimisation Block apps that request camera, microphone, location, storage, or messaging access without a documented business justification.
- Require privacy manifests before release Make disclosure of data collection and third-party sharing a release gate for both first-party code and embedded SDKs.
- Treat mobile AI endpoints as approved processors Document what data each AI service receives, whether transport is encrypted, and which approvals cover the transfer.
- Test for hidden data sharing paths Continuously validate whether apps send regulated data to trackers, analytics services, or third parties beyond declared purpose.
Key takeaways
- Mobile app privacy risk is driven by hidden data collection, third-party components, and AI endpoints that sit outside normal user expectations.
- NowSecure’s analysis shows that disclosure failures and incomplete manifests are widespread enough to make governance and accountability the real problem.
- The control answer is to tie app release to approved data flows, entitlement scope, and auditable privacy evidence.
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 addresses the attack surface, NIST CSF 2.0, OWASP ASVS and NIST SP 800-63 set the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP API Security Top 10 | API10 — Unsafe Consumption of APIs | Mobile apps in the article rely on external APIs and AI endpoints that can move data without proper oversight. |
| Recommendation — Audit mobile app API consumption paths and restrict unsanctioned data transfers to external services. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | Excessive mobile permissions and entitlements are central to the article’s privacy risk pattern. |
| Recommendation — Apply PR.AA-05 to minimise mobile app entitlements and enforce purpose-based approval for sensitive access. | ||
| OWASP ASVS | V14 — Data Protection | The article is about protecting sensitive data handled by apps, SDKs, and AI integrations. |
| Recommendation — Use V14 to validate that mobile apps disclose, limit, and protect personal data end to end. | ||
| ISO/IEC 27001:2022 | A.8.24 — Use of Cryptography | The article notes some AI data transfers may occur unencrypted, creating exposure in transit. |
| Recommendation — Require A.8.24 controls for sensitive mobile data in transit, especially where apps call remote AI services. | ||
| NIST SP 800-63 | SP 800-63C — Federation | Mobile apps commonly sit in federated identity flows where consent and data sharing need strict governance. |
| Recommendation — Review federated mobile identity flows to ensure data sharing is explicit, limited, and auditable. | ||
Key terms
- Mobile Privacy Manifest: A privacy manifest is a structured disclosure that explains what data an app or its embedded components collect, share, or access. In practice, it helps users and organisations compare declared behaviour with observed data handling, especially where third-party SDKs or APIs are involved.
- Dangerous Permission: A dangerous permission is an operating-system entitlement that grants access to sensitive device capabilities or data such as camera, microphone, location, storage, or messages. It becomes a governance issue when the requested access exceeds the app’s approved purpose or continues without adequate oversight.
- Data Flow Governance: Data flow governance is the discipline of controlling where sensitive data can move, who can move it, and how that movement is recorded. It links access policy to runtime evidence so teams can spot policy violations across accounts, regions, and third-party access paths.
- Third-Party SDK: A software development kit supplied by an external party and embedded into a mobile app to add functionality such as analytics, authentication, payments, or AI features. It can also introduce hidden data flows, permission requirements, and update risk that the owning team must actively govern.
Deepen your knowledge
The NHI Foundation Level course covers NHI governance, secrets management, and identity lifecycle principles that help teams control sensitive access paths. It is designed for security and identity practitioners who need a stronger operational model for governed access.
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