TL;DR: Mobile app research across more than 10,000 Android and iOS apps found hundreds of live credentials embedded in production builds, while LLM-assisted analysis identified thousands more hidden secrets that regex-based tools missed, according to Guardsquare and cited academic studies. The control problem is not just detection, but reducing on-device trust assumptions so leaked secrets have limited value.
At a glance
What this is: Guardsquare argues that mobile apps still leak embedded secrets at scale, and that finding them requires both continuous scanning and runtime protection.
Why it matters: IAM and security teams need to treat embedded app secrets as a lifecycle problem, because detection alone does not stop credential abuse once a binary is shipped.
By the numbers:
- Guardsquare's analysis of 5,480 public Android apps found 164 keys flagged as potential secrets.
- Researchers found 13 Git credentials that opened access to 2,440 private repositories.
- LLM-based SecretLoc identified 4,800+ hidden secrets in thousands of APKs, many missed by regex scanners.
Context
Mobile app secrets leakage is a lifecycle and governance problem, not just a code-quality issue. Apps often need API keys, OAuth tokens, and cryptographic material to talk to backend services, but once those values are embedded in a shipped binary they become recoverable by reverse engineering, memory inspection, or automated analysis.
The identity angle matters because embedded secrets are credentials, not just configuration. When a mobile build ships with a valid key or token, the control failure is often poor secret lifecycle management, weak blast-radius design, or an assumption that obfuscation alone will protect the credential after release.
Key questions
Q: What should teams do first when a mobile build may contain secrets or trust assumptions?
A: Start with automated scanning of release artefacts and fail builds that contain credentials, tokens, or high-value endpoint details. Then map where those secrets are consumed in the app so you can remove local trust decisions that should live on the server. Early detection matters because once the app ships, the exposure is public.
Q: Why do hard-coded secrets in native mobile apps create elevated risk during penetration testing?
A: Hard-coded secrets create risk because they can be extracted even when the application code appears clean. If a password, API key, or token is embedded in a native library, an attacker or tester can recover it through reverse engineering and then reuse it outside the app. That turns a hidden implementation detail into a direct authentication and access control weakness.
Q: What are the signs that mobile secret scanning is not working well enough?
A: Repeated findings in compiled release artefacts, secrets hidden in configs or bundled scripts, and credentials that appear after obfuscation all indicate weak coverage. If scanners only check source code, or if the team keeps finding the same token classes after every release, the pipeline is missing the actual exposure point.
Q: How should teams balance scanning and protection for mobile app secrets?
A: Use scanning to prevent unnecessary secrets from shipping, and use protection to slow extraction when a credential must remain on the device. The two controls are not substitutes. The correct test is whether the app can function with less trust on the client, fewer standing credentials, and narrower backend permissions.
Technical breakdown
Why hardcoded mobile app secrets are so hard to eliminate
Mobile apps often need to authenticate to APIs, cloud services, and payment providers, which creates pressure to place credentials in client code. The technical problem is that binaries are distributed to untrusted devices, where attackers can decompile, inspect strings, hook functions, and capture material at runtime. Even when teams use Base64, string splitting, or basic obfuscation, those measures usually slow extraction rather than prevent it. The deeper issue is architectural: if a secret must exist on the device, it is already exposed to a hostile analysis environment.
Practical implication: Minimise on-device secrets by redesigning flows so backend services issue short-lived, narrowly scoped credentials instead of embedding static values.
How scanners and LLMs find secrets that regex misses
Traditional secret scanners rely on patterns, entropy checks, and known token formats. That works for many obvious cases, but mobile apps also contain contextual secrets in config files, scripts, documentation, and SDK artefacts that do not resemble a standard key. LLM-assisted analysis changes the detection model by reasoning about context, code structure, and intent, which is why it can surface secrets hidden behind obfuscation or non-standard formatting. This does not replace scanners, but it does expand discovery coverage across compiled Android and iOS packages.
Practical implication: Run multiple detection methods on compiled release artefacts so pattern-based tools and context-aware tools cover each other's blind spots.
What protection adds after detection has done its job
Protection addresses the reality that some client-side secrets will still exist, even in mature pipelines. Code obfuscation, string encryption, secure storage, runtime self-protection, and backend restrictions all increase the effort required to extract and abuse a key. None of these controls make reverse engineering impossible, but they can slow attackers, reduce automation, and limit what a leaked credential can do. In practice, protection is about shrinking the blast radius of a secret that should never have been public in the first place.
Practical implication: Treat protection as a compensating control for unavoidable client-side secrets, not as a substitute for removing those secrets from the app.
Threat narrative
Attacker objective: Use exposed mobile app secrets to impersonate the application, reach backend systems, and abuse trusted service access at scale.
- Entry occurs when attackers download a public mobile app build and extract embedded credentials from code, config files, or packaged scripts.
- Credential access follows when reverse engineering, static analysis, or AI-assisted discovery reveals API keys, OAuth tokens, or other secrets usable against backend services.
- Impact occurs when those leaked credentials are used to call APIs, access private repositories, or abuse paid services with the identity and privilege of the app.
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.
- Hugging Face Spaces breach 2024: Unauthorised access to Hugging Face Spaces may have exposed secrets users stored for AI apps; tokens were revoked and org tokens removed.
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
Embedded mobile secrets are a credential lifecycle failure, not a packaging mistake. Once a key or token is compiled into a mobile build, the organisation has lost the normal control points for issuance, review, rotation, and revocation. That shifts the problem from source control hygiene to governance of what must never reach the device. The practitioner conclusion is simple: if a secret is visible in a shipped app, the lifecycle design failed upstream.
Scanning and protection solve different parts of the same trust gap. Scanning answers whether secrets slipped into the binary, while protection raises the cost of extraction after release. That distinction matters because security teams often over-trust obfuscation and under-invest in release-time detection. The practical conclusion is that both controls are necessary, but neither is sufficient alone.
Mobile app secret sprawl: embedded credentials create a lasting trust gap between the release pipeline and the live binary. This is not just about individual leaks. It is about a development model that treats some client-side secrets as acceptable even though every copied build can be reverse engineered at scale. The practitioner conclusion is to redesign app flows so the device carries as little standing trust as possible.
Obfuscation is a delay mechanism, not a security boundary. AI-assisted analysis lowers the cost of secret discovery and undermines assumptions that low-skill adversaries will be deterred by encoding or string hiding. That means the real governance question is whether the embedded credential has enough privilege, lifetime, and usage scope to survive inevitable extraction. The practitioner conclusion is to assume compromise and engineer for low blast radius.
The mobile app issue now intersects directly with NHI governance. API keys, tokens, and service credentials embedded in apps are non-human identities in practice, even when they are delivered through a human-facing product. If those credentials are unmanaged, unrevoed, or over-scoped, the app becomes a distribution channel for standing machine access. The practitioner conclusion is to bring mobile build outputs into the same inventory, rotation, and revocation discipline used for other NHIs.
From our research library:
- 69% of organisations still authenticate machine identities with long-lived API keys, according to the 2026 State of AI Agent Identity Security Report.
- Read next: Guide to the Secret Sprawl Challenge
What this signals
Mobile app secret sprawl now behaves like a release-management problem with identity consequences. When a binary ships with embedded credentials, revocation, scope reduction, and usage monitoring all become harder because the secret has already crossed into uncontrolled distribution.
The strongest programme response is to move review earlier in the pipeline and reduce the number of secrets that ever reach the client. That means treating mobile builds as credential carriers, not just software artefacts, and aligning release governance with NHI inventory and revocation discipline.
According to the Ultimate Guide to NHIs, 80% of identity breaches involved compromised non-human identities such as service accounts and API keys. Mobile apps that embed similar secrets deserve the same inventory and lifecycle control as other machine identities.
For practitioners
- Bake secret scanning into every mobile build Run scanners on compiled APKs and IPAs in CI/CD, not just on source code, and treat release artefacts as the authoritative inspection point.
- Reduce or remove client-side credentials Move sensitive logic to backend services wherever possible, and use short-lived, narrowly scoped tokens when a mobile app must authenticate directly.
- Harden any unavoidable embedded secrets Store required secrets in OS-level secure storage, pair them with obfuscation and runtime protection, and restrict their backend permissions aggressively.
- Plan for revocation before release Keep an inventory of secrets per build, define revocation steps for exposed keys, and verify that old versions cannot keep accessing services after a leak.
Key takeaways
- Mobile apps still ship with embedded credentials, and once those secrets are present in a distributed binary they can be extracted by attackers at scale.
- The article shows why scanning alone is incomplete. Detection finds exposed secrets, but protection limits what a leaked key can do after release.
- Mobile app secrets should be governed like non-human identities, with tighter scope, shorter lifetime, and explicit revocation paths.
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 and OWASP API Security Top 10 address the attack and risk surface, while NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | The article centres on secrets embedded in mobile apps and extracted from shipped binaries. |
| NHI-07 — Long-Lived Secrets | The risk increases when embedded app credentials remain valid after release and extraction. | |
| NHI-05 — Overprivileged NHI | Leaked app keys become worse when they have broad service or repository access. | |
| Recommendation — Scan release artefacts for leaked secrets and revoke any exposed credential immediately. Replace long-lived embedded secrets with short-lived credentials and tighter backend enforcement. Constrain embedded credentials to the minimum scope and monitor for over-privileged usage. | ||
| OWASP API Security Top 10 | API2 — Broken Authentication | Leaked API keys and tokens let attackers impersonate the app to backend services. |
| API8 — Security Misconfiguration | Bundled scripts, config files, and weak release hygiene expose secrets in shipped apps. | |
| Recommendation — Harden API authentication so leaked client credentials cannot authenticate broadly or indefinitely. Fix build and deployment misconfigurations that allow secrets to be bundled into release artefacts. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | The article is about managing secret lifecycles, rotation, and revocation for app credentials. |
| Recommendation — Apply authenticator management controls to rotate, revoke, and track embedded mobile secrets. | ||
| CIS Controls v8 | CIS-5 — Account Management | Account and credential inventories are needed to control leaked app secrets and their access paths. |
| Recommendation — Maintain a complete account and credential inventory so exposed mobile secrets can be retired quickly. | ||
Key terms
- Hardcoded Secret: A hardcoded secret is a credential written directly into source code, scripts, configuration files, or build assets. It is convenient for development but dangerous in production because it can be copied, indexed, propagated, and reused outside the intended control boundary.
- Runtime Protection: Runtime protection is a control model that observes application behavior while software is running and blocks unsafe actions as they occur. In Java estates, it helps distinguish active exploit paths from dormant vulnerable code, which is essential when patching is delayed or impossible.
- Secrets Scanning: Automated tooling that scans source code repositories, CI/CD pipelines, and cloud environments to detect exposed secrets such as API keys, tokens, and passwords before they are exploited.
- Blast Radius: The potential scope of damage if a specific credential or identity is compromised. Identities with broad permissions have a larger blast radius and represent a higher priority for least-privilege enforcement and security controls.
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 helps security and IAM practitioners build stronger lifecycle control across human and non-human identity programmes.
Published by the NHIMG editorial team on August 19, 2026.
Updated on October 12, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org