Topic starter
24/10/2026 8:52 pm
TL;DR: Embedded API keys and tokens can be extracted from mobile apps running on hostile devices, according to Approov. Mobile API governance has to shift toward runtime attestation and short-lived credential delivery before a request reaches sensitive services.
Editorial analysis by NHI Mgmt Group, based on content published by Approov: “How to Build a Mobile Application Risk Management (MARM) Framework”.
Key questions
Q: Why do embedded mobile credentials increase backend risk even when user login is protected?
A: User login only authenticates the person, not the app instance or device state that sends the request.
Q: What signs show that mobile runtime protection is failing?
A: Common warning signs include successful debugging on protected builds, altered integrity results, repeated abuse of login or approval flows, and suspicious activity that appears after the app is launched but before a backend control sees it.
Q: What breaks when mobile apps still store reusable API keys or tokens on the client?
A: The control fails because the client no longer owns a trustworthy execution environment.
Practitioner guidance
- Eliminate client-side long-lived secrets Remove API keys, LLM tokens, and other reusable credentials from mobile binaries and shift them to cloud-managed runtime secret services.
- Bind credential release to runtime attestation Require attestation from the app and device before issuing any secret or token, and keep the credential valid only for the current request or session.
- Fail closed at the API gateway Drop requests that lack a valid, current attestation token before application logic executes, rather than allowing the backend to decide later.
Bottom line: Mobile checklists miss the core issue because apps run in hostile environments where embedded secrets and static pinning can be extracted or bypassed.
Glossary terms: Zero-Secrets Architecture, Runtime Attestation, Certificate Pinning, Just-in-Time Secret Delivery
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 6 days ago by NHI Mgmt Group
25/10/2026 11:13 am
Zero Secrets Architecture is the correct response to client-side trust collapse. Mobile apps that carry long-lived credentials are not protected by obfuscation in any meaningful governance sense, because the control boundary sits inside an attacker-controlled environment. The article's central point is that the secret itself has become the liability, not merely the code that contains it. Practitioners should treat this as a machine-identity problem, not a packaging problem.
A few things that frame the scale:
- DeepSeek alone generated 113,000 new exposed API keys in 2025, illustrating how new AI providers create credential exposure before security guardrails catch up, according to the State of Secrets Sprawl 2026.
- 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.
A question worth separating out:
Q: How should teams govern mobile API access when a token broker or proxy is involved?
A: Treat the broker as an enforcement point, not a trust shortcut. If the broker cannot verify the app, device, and runtime state before releasing credentials, it simply relocates the exposure. The governance model should require attestation-bound issuance, fail-closed API validation, and short-lived credentials that cannot be reused broadly.
👉 Read our full editorial: Zero secrets architecture is becoming essential for mobile API security
This post was modified 6 days ago by NHI Mgmt Group