It pairs the device, stores the credentials and sends the commands. If an attacker finds a flaw in the app or its API, they can open doors, watch cameras or change the settings of your users' devices. The same flaw works against every device in the field at once.
App security for connected devices.
Your device is controlled from a mobile app, so that app is the way in: reaching one user's devices through the cloud, pairing with a device that is not theirs, or forging the commands the app sends. We test the app, its link to the device and its cloud API, and give you the report your CRA technical documentation needs.
The app holds the keys to your device.
How attackers turn your app against your devices.
- Taking over devices remotely: reaching and controlling other users' devices through the cloud account.
- Hijacking at pairing: attaching their own phone or account to a device that is not theirs.
- Forging commands: intercepting or faking what the app sends to the device, over Bluetooth, the local network or the cloud.
- Pushing their own firmware: delivering an update the manufacturer never signed.
The weaknesses behind device takeover.
In the apps that control a device, taking over someone's device keeps coming back to the same technical weaknesses. These are what we go after.
- Broken API authorization: one user reading or controlling another user's devices by changing an identifier in a request.
- Keys and secrets in the app: API or encryption keys that work for every device and can be extracted from the app binary.
- Weak pairing: a pairing flow that lets an attacker link their account or phone to a device that is not theirs.
- Unprotected device communication: commands to the device that can be intercepted or forged over Bluetooth, the local network or the cloud.
- Insecure firmware and OTA updates: updates delivered without proper authentication or integrity checks, so an attacker can push their own.
- Insecure data on the phone: credentials, tokens and device data left in plaintext preferences, logs or backups.
You can see several of these worked through end to end on a deliberately vulnerable app in our sample report.
Services for your product.
The standards that apply to you.
A connected product and its app fall under several standards and regulations. We cover the app side of each: some we report on directly, others we get you ready for the lab.
CRA
Security test reports for your Cyber Resilience Act technical documentation.
RED and EN 18031
Security testing of connected radio equipment and its app against EN 18031.
ETSI EN 303 645
Assessment of consumer IoT devices and their companion apps against the baseline.
GDPR
Testing the effectiveness of your security measures under Article 32.
Why vulnit for connected devices.
We have been evaluators
Before vulnit, we worked in security certification laboratories. Throughout our careers we have found vulnerabilities in all kinds of products, both hardware and software.
We have done it with a video intercom
We published how we analyzed the app of a Legrand/BTicino connected video intercom until we could open the door from Home Assistant.
Specialists in mobile security
Our team contributes to OWASP Mobile Application Security, the main reference for testing mobile apps. OWASP recognized this work by naming vulnit an OWASP MAS Advocate.
Our own technology
Chameleon gives us deep visibility into what your app does inside the operating system, which makes the analysis faster and more thorough. The controls that usually slow testing down, such as root, pinning and anti-instrumentation checks, are handled at the OS level by default, so our time goes into finding issues in your app instead of getting past them.
Meet the teamConnected device security frequently asked questions.
What exactly do you test?
The app, its communication with the device over Bluetooth or the local network, and the cloud API. If the firmware or its update mechanism is in scope, we can look at those too.
Who is the report for?
We write reports with their reviewers in mind: your own team and, if it comes to that, a notified body or a market surveillance authority.
Do you test iOS as well as Android?
Yes. We test both, to the same depth. On Android we work with Chameleon; on iOS we test on physical devices. If your app runs on both platforms, we deliver one report per platform.
What do you need from us?
The app builds, test accounts and, if you want us to test the communication with the device, units of the device. The proposal sets out the details.
Do you need source code?
No. By default, testing is black-box: we attack your app with the same information an attacker would have, using the same build you release to your users. If you prefer, we can also review the source code.
Can I combine several services in one project?
Yes. They all start from the same analysis of your app. Tell us what you want to know, for example which vulnerabilities it has, whether your protections stop an attacker or which OWASP MASVS controls it meets, and we combine it into a single project.
How do you handle confidentiality?
We agree confidentiality terms before you share builds, devices or documentation. We have a standard NDA, but if you prefer to use yours, we are happy to review it.
Preparing your product's CE marking?
Tell us about your product and the standards you need to meet. We reply within one business day to arrange a scoping call.
Talk to our team