Topic starter
19/08/2026 4:05 pm
TL;DR: 10,000 apps helped Guardsquare and cited studies show that mobile app research still found hundreds of live credentials in production builds, while LLM-assisted analysis surfaced thousands more hidden secrets that regex tools missed. Mobile secrets need tighter scope, shorter lifetime, and explicit revocation paths once they ship.
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: 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.
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.
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.
Glossary terms: Hardcoded Secret, Runtime Protection, Secrets Scanning, Blast Radius
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 1 day ago by NHI Mgmt Group
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: Scanning alone cannot contain leaked mobile app secrets
This post was modified 1 day ago by NHI Mgmt Group