Yes, a device companion app should have a minimum supported version check, because a vulnerable app release cannot be recalled from phones. Let the backend or device refuse old versions in stages: warn first, then block the sensitive actions, and last of all block everything. Always give users a clear way to update.
Why you need this lever
You can push a fixed app to the store, but people keep running old ones. If an old release has a flaw in pairing or in how it talks to your cloud, it stays in use until you do something about it. Phone updates are outside your control, so the control you do have is server side: what the backend and the device will accept.
Three levels of response
| Level | Behaviour | Use when |
|---|---|---|
| Soft | Banner prompting an update | Minor fixes, no security impact |
| Firm | Block sensitive actions such as new pairing or firmware update | A known weakness exists |
| Hard | Block the app entirely until updated | A serious flaw is being exploited |
Start soft by default and escalate by evidence, not by habit. A hard block locks customers out of their own device, which is a support cost and a reputational one.
What to build
- Send the app version on every request. Use a header your backend can read.
- Keep a server-side minimum version per platform. Android and iOS releases land at different times.
- Return a clear error code and message. The app should show a human sentence and a store link, not a spinner.
- Let the device enforce it too. For pairing and firmware commands, the device can check the app version in the handshake, so a modified client cannot skip the backend.
- Test the block. Ship a build marked old in staging and confirm the user path.
Related facts about Android signing
If you distribute through Google Play with Play App Signing, the app signing key never changes during the app's life, and an upload key can be reset if lost or compromised, according to Android's documentation. That means your users keep receiving updates as updates to the same app, which is exactly what a minimum version policy relies on.
Do not forget the offline case
Some devices pair on a local network with no cloud. If your hard block depends on the cloud, an offline device is exempt. Decide whether the device itself should reject old app versions for sensitive operations.
Communicating the block
Tell users why. A message such as "this version of the app has a security problem, please update to continue" is clear and honest. Avoid blaming the user or hiding the reason behind a generic error. Record how many users hit each level, so you can see whether the policy is working and whether an old version is still widely used. Support teams should have a short script for the call that follows.
Where Safeguard fits
Safeguard's SBOM and dependency scanning can tell you which library versions are in each app release, which helps you decide what the minimum version should be after an advisory. See Safeguard's free scan to look at a repository.
Quick check
Will a forced update annoy users?
It can. That is why the soft and firm levels exist. Reserve hard blocks for serious issues.
Can we do this without a server?
Partly. The device can check the app version during pairing, but a server gives you faster control.
Sources
Last reviewed: 19 October 2026.
