Notifications
Clear all
Topic starter
14/09/2026 10:09 am
TL;DR: Old mobile app versions rarely disappear after a patch, because bots can scrape, repackage, and replay them unless the server-side trust model shuts them out, according to Guardsquare. The practical lesson is that version deprecation only works when update checks, tamper resistance, and challenge-response controls are enforced together, not left to client-side cooperation.
NHIMG editorial — based on content published by Guardsquare: You Shipped the Fix, but Your Old App Is Still Out There, Now What?
By the numbers:
- 72% of organisations have experienced or suspect they have experienced a breach of non-human identities.
Questions worth separating out
Q: How should security teams stop deprecated mobile app versions from keeping access to APIs?
A: Make the server, not the app, the authority that decides whether a build is still allowed.
Q: Why do client-side version checks fail in repackaged mobile apps?
A: Because the attacker controls the code that performs the check.
Q: What do security teams get wrong about mobile app deprecation controls?
A: They often confuse update delivery with enforcement.
Practitioner guidance
- Enforce server-side version gating Reject requests from deprecated builds at the API layer, not just through client update prompts, so disabling local update logic does not preserve access.
- Bind legitimacy to a challenge-response proof Require a one-time server challenge and verify a signed response so copied identifiers and replayed values do not authenticate a repackaged app.
- Protect release identifiers with obfuscation and RASP Use code obfuscation, string encryption, and runtime self-protection to make version keys and verification paths harder to extract after release.
What's in the full article
Guardsquare's full article covers the operational detail this post intentionally leaves for the source:
- Code-level examples for implementing version checks in Android and iOS clients
- How the challenge-response flow is structured around one-time server challenges and signed responses
- Why obfuscation, string encryption, and RASP change the reverse-engineering effort required
- How application attestation is positioned alongside tamper protection and server-side monitoring
👉 Read Guardsquare's analysis of mobile app version deprecation and tamper resistance →
App version deprecation: what actually keeps old builds out?
Explore further
14/09/2026 10:10 am
Client-side version enforcement is a trust failure, not just a usability problem. If the app itself decides whether it should be updated, the attacker controls the decision point. That makes update prompts, local version checks, and embedded allowlists inherently weak as deprecation controls. The issue is analogous to granting a service account the power to approve its own revocation. Practitioners should treat any enforcement logic that lives inside the controlled binary as advisory only.
A question worth separating out:
Q: What should teams do when an old mobile build is still in the wild after remediation?
A: Assume the build remains operational until the server explicitly refuses it. That means revoking trust in the old version, validating requests with stronger proof than a visible version number, and monitoring for repackaged clients that continue calling the API.
👉 Read our full editorial: Mobile app version deprecation needs layered runtime enforcement
