TL;DR: Mobile apps often embed API keys, certificates and tokens that attackers can recover through reverse engineering or runtime inspection, according to Approov, then use to bypass the app and directly abuse backend services. Hidden secrets do not equal governed secrets: if the credential lives client-side, the control has already failed.
At a glance
What this is: Approov argues that storing secrets inside mobile apps leaves API keys, certificates and tokens recoverable by attackers, creating direct exposure to backend abuse.
Why it matters: This matters because mobile app secrets are effectively distributed to untrusted devices, so IAM, API security and fraud teams need controls that assume client-side compromise is routine.
Context
Mobile applications should never be treated as trusted secret stores. When API keys, certificates, authentication tokens or encryption keys are shipped inside a client app, the organisation loses control the moment that app is downloaded onto a device it does not own.
The governance gap is not just protection strength but placement: a secret that exists on the client can be reverse engineered, inspected in memory, or extracted from traffic. That makes the problem part mobile security, part API governance, and part identity control, because access is being granted to a distributed client rather than a managed principal.
Key questions
Q: How should security teams protect API keys in mobile apps?
A: The safest pattern is to keep the API key off the device entirely and place sensitive API calls behind a backend proxy. If the app must interact directly, use obfuscation, runtime hardening, and strict monitoring, but treat those as delay controls rather than true protection. Server-side authorisation remains the only durable boundary for high-value keys.
Q: Why do static mobile app secrets increase API abuse risk?
A: Because a secret embedded in a client application is a reusable credential that can be recovered through reverse engineering, debugging, or tampering. Once extracted, it can be replayed in scripts, proxies, or modified apps, which means one leaked secret can become a broad backend access path. Short-lived credentials and rotation reduce that exposure.
Q: What are the signs that mobile secret exposure is becoming a governance problem?
A: Look for the same API key or certificate appearing across multiple builds, long-lived credentials with no ownership, and backend traffic that does not align with normal app behaviour. Those signals indicate the organisation is relying on client-side secrecy instead of controlled issuance and revocation. At that point, the issue is no longer just technical exposure.
Q: Should organisations use obfuscation or secret rotation for mobile app credentials?
A: They can help, but neither solves the core problem if the secret is still embedded in the app. Obfuscation only delays extraction, and rotation only reduces the lifetime of a credential that should not have been distributed at all. Use them as supporting controls, but move the design toward runtime release and secretless access.
Technical breakdown
Why client-side secret storage fails
Mobile apps run in environments the publisher cannot trust, which changes the threat model completely. Static analysis can reveal embedded strings, and dynamic analysis can expose secrets during execution or from memory. Once a key, token, or certificate is embedded in the app package, obfuscation only raises the work factor. It does not remove the secret from the attack surface, and it does not create lifecycle control over who can use it or when. In identity terms, the app becomes a credential distribution mechanism rather than a controlled authenticator. Read the Ultimate Guide to NHIs.
Practical implication: Treat embedded client-side secrets as recoverable and remove them from mobile release design.
Why extracted credentials bypass the app boundary
The real risk begins after extraction. A stolen API key or token can let an attacker skip the legitimate app entirely and call backend services directly, which means the service sees apparently valid access without the intended client context. That breaks assumptions around app attestation, rate control, fraud detection, and API authorisation. It also means downstream systems may trust a request that no longer carries the security signals the app was supposed to provide. The issue is not just leakage, but the collapse of the client to service trust boundary. See the API Key Management Guide.
Practical implication: Bind backend access to verified app and device state, not to a reusable credential copied from the app.
Why obfuscation and rotation do not fix embedded secrets
Obfuscation, encryption, hardening, and rotation can slow extraction, but they cannot change the fact that the secret is still present on an untrusted device. If the attacker can obtain the app once, they can often recover the credential once and reuse it until it is revoked. This is why embedded secrets create an ongoing exposure window rather than a one-time release risk. Zero Secrets patterns shift the control point to runtime attestation and conditional release, which is far closer to governed access than static embedding. See the Secrets Management Guide.
Practical implication: Move from concealment to conditional issuance so secrets are never persistently available inside the app.
Threat narrative
Attacker objective: The attacker wants reusable access to backend services without using the legitimate mobile application.
- Entry begins when an attacker downloads the mobile app and subjects it to static analysis, runtime inspection, or traffic examination.
- Credential harvest follows when embedded API keys, certificates, tokens, or encryption keys are recovered from code, memory, or network behaviour.
- Escalation occurs when the stolen credential is reused outside the app to call backend services directly and bypass normal client controls.
- Impact is API abuse, fraud, higher service cost, and compliance exposure because the attacker now operates through a legitimate-looking credential.
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
Embedded client secrets create a trust boundary problem, not just a secret-management problem. Once an API key or token is shipped into a mobile app, the organisation has delegated credential protection to devices it does not control. That is a governance failure because the access decision is now anchored in code distribution rather than controlled issuance. The right question is not how to hide the secret better, but whether the secret should exist on the client at all. The practitioner conclusion is to design mobile access so no persistent credential has to survive app delivery.
Zero Secrets is a governance pattern for client-bound access, not a cosmetic hardening layer. The article points to runtime attestation and conditional release as the real control shift, because the app must prove itself before sensitive material is issued. That changes the security model from storage protection to access governance, which is materially closer to secrets management than to obfuscation. For identity teams, the key lesson is that credential lifecycle only works when the lifecycle starts after trust is established. The practitioner conclusion is to treat release conditions as part of identity governance.
API abuse follows from credential portability. When a credential can be copied out of a mobile app, the backend can no longer distinguish the intended application from a replayed secret. That weakens fraud controls, inflates usage costs, and undermines the assumptions behind API authorisation. This is where mobile app security intersects with IAM: the service is effectively authenticating a secret that has escaped its intended context. The practitioner conclusion is to bind service access to verifiable runtime conditions instead of static client-held credentials.
Mobile app secret leakage fits the broader non-human identity problem. API keys, certificates and tokens embedded in apps are still identities, even when they are packaged as configuration. They need inventory, ownership, issuance rules, and revocation discipline just like any other non-human credential. The point is not that mobile apps are special, but that mobile delivery amplifies the harm when identity material is unmanaged. The practitioner conclusion is to fold mobile-held secrets into the same governance model used for other non-human identities.
From our research library:
- Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them, according to the Ultimate Guide to NHIs.
- Read next: Secrets Management Guide
What this signals
Client-side secret sprawl: mobile apps turn API keys and certificates into recoverable assets when release pipelines treat them as build-time configuration rather than governed identities. That shifts the control point upstream to issuance, attestation and revocation, because once the app is shipped the secret is already outside your trust boundary.
The operational lesson is that mobile app security and identity governance now intersect at the point of secret release. Only 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, according to the Ultimate Guide to NHIs, which is why embedded mobile credentials deserve the same lifecycle scrutiny as other machine identities.
For practitioners
- Remove embedded secrets from mobile release builds Eliminate API keys, certificates, tokens and encryption keys from client packages so the app no longer carries reusable credentials on untrusted devices.
- Use runtime attestation before releasing sensitive material Require the app to prove integrity at runtime before any backend credential or sensitive service token is issued.
- Restrict backend access to app-verified requests Make API and service access depend on verified application state, not on a static secret that can be copied and replayed.
- Treat mobile secrets as governed identities Track ownership, scope, rotation and revocation for every API key or certificate that can reach a mobile app.
- Assume obfuscation will not hold against motivated attackers Use obfuscation as a friction layer only and plan on extraction attempts through reverse engineering, traffic inspection and memory analysis.
Key takeaways
- Mobile apps that embed credentials create a trust gap because attackers can extract the secret and use it outside the app boundary.
- The issue is not only leakage volume but control failure, since the organisation loses governance over a credential once it is distributed to a device it does not own.
- The strongest response is to eliminate persistent client-side secrets and gate any sensitive release on runtime verification and backend enforcement.
Related NHI Mgmt Group resources: Ultimate Guide to NHIs: What are Non-Human Identities · API Key Management Guide · Secrets Management Guide
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 MITRE ATT&CK 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 | Embedded API keys and tokens in mobile apps are exposed through secret leakage. |
| NHI-07 — Long-Lived Secrets | The article centres on secrets that remain usable after app download and reverse engineering. | |
| NHI-10 — Human Use of NHI | Mobile app secrets are distributed through human-operated app installs and can be misused outside intended flows. | |
| Recommendation — Eliminate client-side secret storage and revoke any leaked mobile credentials immediately. Replace long-lived mobile credentials with short-lived or runtime-issued access. Prevent human-accessible distribution of machine credentials inside mobile releases. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | API keys and certificates in apps require lifecycle governance under authenticator management. |
| Recommendation — Apply IA-5 to inventory, rotate and revoke mobile app authenticators. | ||
| CIS Controls v8 | CIS-5 — Account Management | The article describes credentials that should be owned, scoped and offboarded like accounts. |
| Recommendation — Use account management controls to track and revoke app-embedded credentials. | ||
| MITRE ATT&CK | TA0006;TA0010 — Credential Access; Exfiltration | Attackers extract secrets from apps and then use them to access backend services. |
| Recommendation — Map mobile secret extraction to TA0006 and monitor for subsequent credential misuse. | ||
Key terms
- Embedded Secret: An embedded secret is a credential, token, API key, or certificate that has been placed inside an image, file, or configuration bundle. Once exposed, it can outlive the original control that created it, so revocation and rebuilds become necessary even if the underlying system is later patched.
- Runtime Attestation: Runtime attestation is a control that cryptographically proves a request came from the expected system or workload. It adds evidence to machine-to-machine access decisions, which is especially valuable when bearer tokens alone cannot distinguish a real integration from an attacker replaying credentials.
- Zero Secrets: An architecture that avoids placing reusable secrets inside the client application and instead issues access only when the app is verified. The model reduces extraction risk by shifting from stored credentials to conditional, runtime-controlled release, which is more defensible than hiding secrets in shipped code.
- API Abuse: The malicious use of legitimate API functionality for scraping, fraud, bulk extraction, enumeration, or workflow manipulation. Unlike classic exploitation, API abuse relies on valid requests and trusted access paths, which makes it harder to detect unless teams model misuse patterns explicitly.
Deepen your knowledge
The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security and secrets management. It gives practitioners a practical way to connect identity controls to the broader security programmes their environments depend on.
Published by the NHIMG editorial team on October 22, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org