The Mobile App Is the Weakest Part of Your IoT Product

Connected-hardware companies tend to think about security at the device: secure boot, signed firmware, an encrypted channel to the cloud. That work is necessary and it is usually done reasonably well, because the hardware team knows it is being watched.

The companion mobile app is treated as an accessory. It is often the last thing commissioned, sometimes by a different supplier, on the shortest timeline. And it is where the interesting attack surface is, because the app is the thing holding the credentials that command the hardware.

We have built in this space — including for smart-home security and IoT device monitoring — and the same handful of weaknesses recur. None of them are exotic.

Pairing is the moment of maximum exposure

Onboarding a device is the one point in its life when it must accept configuration from something it has no prior relationship with. It has no credentials yet, no network, and frequently no input mechanism.

The common pattern is for the device to raise its own temporary access point, or to accept a Bluetooth connection, and for the app to hand over the home wifi credentials. Which means: for a window of time, an unauthenticated radio interface accepts a network password.

The failure modes are consistent. The device's setup access point has a predictable name and either no password or one derived from something printed on the label. The setup channel is unencrypted, so the wifi password crosses it in the clear. Anybody within radio range during setup — a neighbour, someone in the car park — can collect it or impersonate the device.

The corollary is that setup mode must be short, must require a deliberate physical action to enter, and must not be re-enterable remotely. A device that can be pushed back into pairing mode over the network has handed an attacker a reset button.

Secrets in the app are not secrets

A mobile app is a file on a device the attacker controls. Anything compiled into it can be recovered, and the tooling to do so is a weekend's familiarity.

So: no API keys with real privileges in the binary. No shared secret used by every installation. No cloud credentials, even for a service that "isn't important" — lateral movement is the entire game, and a logging or storage credential is a fine place to start.

What belongs on the device is a per-installation credential obtained after authentication and stored in the platform keystore — Keychain or the Android Keystore, not preferences, not a file, and not a database the app wrote itself. The distinction matters because the platform stores are backed by hardware on modern devices and survive a rooted-device attack far better than anything the app can implement.

Authorisation gets checked in the wrong place

This is the one that produces the worst findings, and it is a backend problem wearing a mobile costume.

The app knows which devices belong to the signed-in account, so it only ever requests those. It is easy — and common — for the API to therefore assume that any device identifier it receives belongs to the caller. Nobody notices, because the only client anyone tests with is the app, and the app never asks for a device it does not own.

An attacker is not using the app. They are talking to the API directly, and they will substitute identifiers. If device IDs are sequential or derived from a serial number, enumeration is trivial, and every call must be independently checked against ownership on the server. "The app wouldn't send that" is not an authorisation model.

The same reasoning kills client-side privilege. If the app hides an administrative action for a household member with limited rights, and the server does not enforce it, the restriction does not exist.

Firmware update is a code-execution channel you built on purpose

Over-the-air update is the mechanism by which you fix everything else, so it deserves more scrutiny than any other feature.

The device must verify a signature over the image before it runs it, and it must check the version to refuse a downgrade — otherwise an attacker rolls the fleet back to a build whose vulnerabilities are published. The update must be fetched over a validated TLS connection, and the app must never be the thing that decides an image is authentic. If the app can be convinced to deliver arbitrary firmware, the entire device-side security story is decorative.

Notifications leak

A security product sends alerts, and alerts arrive on a lock screen where they can be read without unlocking the phone. They also pass through a third-party push service.

"Motion detected in Hallway, 02:14" is a useful notification and also a statement about whether the house is occupied, delivered to anyone who can see the screen. The content of a notification is a privacy decision, not a copywriting one, and the sensitive detail belongs behind the app's own authentication rather than in the payload.

A short list worth running before launch

• Can setup mode be entered remotely, or only by hand at the device?
• Is anything in the app binary a credential? Check it, do not assume it.
• For every API endpoint: is ownership verified server-side, on every call?
• Are device identifiers guessable?
• Does the device verify update signatures and refuse downgrades?
• Does a lock-screen notification reveal something about the premises?
• When a household member is removed, do their tokens actually stop working?

That last one is worth its own paragraph. Access revocation is where long-lived tokens meet real life — a former partner, a departed employee, a previous occupant. A product that cannot promptly and verifiably cut someone off has a safety problem, not just a security one, and it is the single most common gap we find in otherwise well-built connected products.

---

iLeaf's engineering and QA teams work across connected hardware, mobile and cloud. If you have a device product with a companion app, our work shows the range, or get in touch.