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.
Editorial analysis by NHI Mgmt Group, based on content published by Guardsquare: “You Shipped the Fix, but Your Old App Is Still Out There, Now What?”.
Key questions
Q: What fails when mobile app version deprecation relies on client-side checks?
A: Client-side deprecation fails because the attacker controls the binary and can skip the update path, remove the check, or replay requests from a repackaged build.
Q: Why do version numbers and manifest changes not prove a mobile app is current?
A: Version numbers are just request data unless the backend can verify their origin.
Q: How should teams detect when version deprecation controls are failing?
A: Teams should look for deprecated builds that still reach protected APIs, repeated acceptance of spoofed version identifiers, or successful requests from repackaged clients after a release cutoff.
Practitioner guidance
- Move version enforcement to the backend Reject API calls from builds that are outside the approved release window, rather than relying on a local update prompt to do the blocking.
- Bind access to a verifiable build identity Use a server-validated identifier that cannot be changed by editing a manifest field or spoofed through a simple request parameter.
- Protect challenge material with runtime controls Combine challenge-response logic with obfuscation, string protection, and anti-tamper controls so the proof values are harder to extract from the binary.
Bottom line: Old mobile app builds do not disappear just because a patched version exists, because attackers can keep the old one functional through repackaging and spoofing.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
14/09/2026 10:10 am
Version deprecation is really a trust problem, not an update problem. If the backend accepts a client’s claim that it is current, the attacker only needs to alter that claim once the app leaves the developer’s control. This is why mobile app governance has to treat the runtime as adversarial, not cooperative. Practitioners should move the enforcement decision to a place the attacker cannot trivially edit.
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