Topic starter
19/08/2026 4:05 pm
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.
Editorial analysis by NHI Mgmt Group, based on content published by Guardsquare: “Why Mobile App Security Needs Both Scanning and Protection”.
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.
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.
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.
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.
Practitioner guidance
- 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.
Bottom line: 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.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
19/08/2026 4:39 pm
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.
A few things that frame the scale:
- 69% of organisations still authenticate machine identities with long-lived API keys, according to the 2026 State of AI Agent Identity Security Report.
A question worth separating out:
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.
👉 Read our full editorial: Mobile app secrets exposure needs both scanning and protection