IoT penetration testing and firmware analysis services
IoT penetration testing examines a connected product the way an attacker who owns one would: the firmware it runs, the app that controls it, and the cloud service behind the fleet. BERRY9 tests IoT products and analyzes their firmware for device makers and the organizations that deploy them, from Hyderabad for teams across India.
- Layers
- Firmware, apps, cloud
- Firmware
- Secrets, components, update signing, boot
- Office
- Hyderabad, for teams across India
- Starts from
- INR 27,000 + 18% GST
Last reviewed
Pathupdate file → F-01 → firmware image → F-02 → update server → F-03 → device fleet
Also mappedcompanion app · F-04
- F-01The firmware update file can be downloaded by anyone and unpacks without a passwordMedium
- F-02The firmware image contains the credentials the devices use when signing in to the update serverHigh
- F-03Devices install any package the update server offers, without checking a signatureCritical
- F-04The companion app's API lists other customers' devices when a serial number is changedMedium
01 / What it is
What IoT and firmware penetration testing is, and who needs it
A connected device is a small computer that ships to strangers. Anyone can buy one, open it and study it at leisure, and whatever they learn may apply to every other unit in the field.
IoT penetration testing, also called embedded device security testing, is a security test of a connected product as a whole system. The device is only one part of it. A typical product also has firmware that can be unpacked and read, a companion mobile app, and a cloud service that registers devices, stores their data and sends them updates. A weakness in any one of these can expose the others, so the test follows how they fit together instead of stopping at one piece.
Firmware security analysis is the part of the work that looks inside the software image the device runs. Firmware is usually a small operating system, a set of open-source libraries and the maker's own programs packed into a single file. Reading it shows what an attacker who buys one unit can learn about every other unit: passwords and keys written into the code, components with published vulnerabilities, and how the device decides whether an update is genuine.
BERRY9 delivers IoT and firmware penetration testing from its office in Hyderabad. The service covers three layers: the firmware, the companion app and its APIs, and the cloud back end.
Who usually asks for one:
Companies that build devices
Makers of smart home products, wearables, trackers and medical equipment test before launch, because a flaw shipped in firmware lives on in every unit sold until an update reaches it. Finding it on a prototype costs far less than a recall or an emergency release.
Hospitals and clinics
Infusion pumps, patient monitors and imaging systems join clinical networks. Hospitals ask vendors for evidence that the product was examined, and some test the units already on their wards.
Utilities and smart meters
Smart meters and the head-end systems that read them carry billing data and, in some designs, can switch supply on or off. A weakness copied into every meter of a rollout is a weakness across the network.
CCTV, access control and building systems
Cameras, video recorders, door controllers and building management panels often sit on corporate networks with factory settings, and they watch or control physical spaces. Indian rules on CCTV security add a further reason to check them.
Factories and warehouses
Sensors, gateways and controllers on a shop floor connect machines to dashboards and to the vendor's cloud. A test shows whether a compromised gateway could reach production systems or the office network next to them.
02 / Attack surface
The three layers an IoT test covers
An IoT test covers more than the box on the shelf. It examines three layers, from the firmware to the cloud, and the trust that joins them.
Firmware
The software image on the device: its operating system, libraries, start-up scripts, configuration and the maker's own programs. What the image contains, how it is protected in storage and whether secure boot refuses a modified copy decide how much a single stolen unit gives away.
Companion apps and device APIs
The mobile app that sets up and controls the device, and the APIs both of them call. Flaws here are often the easiest to reach, because they need no hardware at all. The app itself is covered in depth by mobile application penetration testing, and the server interfaces by API security testing.
Cloud back end
The service that registers devices, issues their credentials, stores their readings, relays messages (often over MQTT) and pushes firmware updates. One flaw here can reach every device in the field at once, and the accounts it runs in can be examined with a cloud security assessment.
Board-level hardware work and radio-protocol testing are not part of this service, which covers the firmware, the companion app and its APIs, and the cloud back end.
The layers are joined by trust. The cloud trusts a device because it presents a key; the device trusts an update because it carries a signature; the app trusts the device because setup succeeded. Most serious IoT findings are a broken link in that chain, which is why the test follows it from end to end.
03 / Firmware
What firmware security analysis looks for
The firmware image is where a device keeps its secrets and its rules. Reading it shows what every unit has in common and which protections exist only on paper.
Show details for What firmware security analysis looks for
Firmware analysis starts with getting the image. It may come from the maker's own build or from an update file the device downloads. Once it is unpacked, the work is a careful read of what the maker actually shipped.
- Hard-coded credentials. Root or service passwords, API tokens and private keys written into the image. Every unit runs the same image, so a secret found once is the same secret on every device.
- Outdated components. Kernels, libraries and embedded web servers bundled long before release and never upgraded, matched by name and version against published vulnerabilities.
- Update integrity. Whether update files are signed, whether the device verifies the signature before it installs anything, whether the image is encrypted, and whether an older, weaker version can be loaded over a newer one.
- Boot chain. Whether secure boot is switched on and enforced, so that a tampered image is refused at start-up instead of running.
- Key and data storage. Where the device keeps its own keys, Wi-Fi passwords and user data, and whether a secure element or encrypted storage protects them or they sit in plain files.
- Leftover debug features. Developer back doors, test accounts, verbose logs and network services that helped in the lab and were never turned off for production.
- Local web and network services. The code behind the device's own admin page or local API, read for the same injection and login flaws a web application is tested for.
Reading the image shows what could go wrong; the services it talks to show what does. A password found in the image is tried against the app and cloud services in scope, and what the firmware sends to them is checked for what it gives away. Where you can share the source of the firmware or its back end, a source code review finds flaws that are hard to see in compiled code.
04 / IoT or network
How IoT testing differs from a network penetration test
Both look for ways in, but they examine different things, need different inputs and lead to different fixes. Most connected estates end up needing a little of each.
Show details for How IoT testing differs from a network penetration test
| Question | Network penetration test | IoT penetration test |
|---|---|---|
| What is examined | Hosts, services and the routes between them across your network | One product in depth: firmware, app and cloud |
| Where the work happens | Over the network, remotely or from a laptop plugged in on site | Remotely: the firmware you supply is analyzed, and the app and cloud parts are tested live |
| What you hand over | Address ranges, and an account or a network port for an internal test | Firmware, design documents and test accounts |
| Who fixes the findings | IT and infrastructure teams, by changing settings or patching servers | Product, firmware and cloud engineers, usually in a new release |
| How a fix reaches the field | Applied once, on systems you run | Shipped as an update to every unit |
Makers and buyers come to the test with different aims. A device maker tests its product before it ships and after major firmware changes. An organization that deploys devices made by someone else cannot change the firmware itself; its test shows which weaknesses the vendor has to fix, which settings it can harden on its own, and how tightly the devices must be fenced off.
That fencing is where a network test still matters in an IoT estate. Where devices are installed in your offices, plants or hospitals, a network penetration test shows what the device segment can reach and whether a compromised camera or controller could step into the systems around it.
05 / Method
How an IoT and firmware test runs
Five steps carry the test from the signed scope to a ranked list of fixes. The threat model in step two keeps the effort on the layers that matter for your product.
Show details for How an IoT and firmware test runs
Step 1
Scope and authorization
Agree the product, the firmware version, the app and the cloud environment in scope, and who owns each part. Where a vendor runs the cloud service, its written permission is part of the paperwork.
OutputSigned scope
Step 2
Documents and threat model
Read the architecture, data flows and update process, and map where the product keeps its secrets and which parts trust which. The threat model decides where the test spends its time.
OutputThreat model and test plan
Step 3
Firmware examination
Unpack the firmware and review what it holds: credentials, components, update checks and leftover debug features.
OutputFirmware findings
Step 4
App, API and cloud testing
Test the companion app, and the APIs and cloud service behind it, using what the firmware revealed to follow chains from one layer into the next.
OutputConfirmed findings with proof
Step 5
Reporting
Write findings up for product owners and engineers, ranked by risk to the whole fleet.
OutputExecutive and engineering reports
The test examines the product versions supplied, at one point in time. A later firmware release or a move to another cloud provider is new scope, and the parts of the product it touches need examining again.
06 / Common findings
IoT and firmware weaknesses that keep turning up
Device makers work under tight cost and launch pressure, and the same shortcuts appear across very different products. Each is easy to miss in development and expensive to fix once units have shipped.
Show details for IoT and firmware weaknesses that keep turning up
| Finding | What it allows | Severity | How it is fixed |
|---|---|---|---|
| Default or hard-coded passwords | The same factory password on every unit, or a service account written into the firmware that the owner cannot change. Whoever learns it once can sign in to every device that ships with it. | VariesOften the first thing an attacker tries. | A unique credential for each device, set at manufacture or first setup, and no fixed accounts in the image. |
| Unsigned or unencrypted updates | Devices install any update file they are offered, or fetch updates over an unprotected connection. Whoever can supply a file can replace the device's firmware with their own. | VariesCan turn one weakness into control of a fleet. | Releases signed by the maker, verified on the device before install, delivered over an authenticated channel, with downgrades blocked. |
| Weak or missing secure boot | The device starts whatever image is in its storage, so a modified firmware survives a reboot and keeps its foothold. | VariesMakes every other compromise permanent. | A verified boot chain, enabled and locked before devices leave the factory. |
| Keys stored where they can be read | Private keys, certificates and Wi-Fi credentials kept in plain files on flash memory instead of a secure element or encrypted store, ready to copy from one unit. | VariesOne unit's key may open its cloud account. | Keys generated per device and held in protected or encrypted storage. |
| Outdated open-source components | Kernels, libraries and embedded web servers with published vulnerabilities, still shipping long after fixes were released. | VariesRating follows the component and how it is exposed. | Components upgraded, tracked in an inventory, and watched for new advisories between releases. |
| Cloud APIs that trust the wrong thing | Device or app APIs that accept a serial number as proof of identity, let one account read another's devices, or let any device publish to any message topic. | VariesReachable from anywhere, with no hardware needed. | Per-device credentials checked on every call, and each device and account limited to its own data and topics. |
How serious each of these is depends on how the product is used and who can get to it. A hard-coded key in a camera any visitor can reach is a different risk from the same key in a sensor behind a firewall, so each class is rated Varies here and rated for your product in the report.
07 / What you receive
What you receive from an IoT test
An IoT report has to serve people who decide whether to delay a launch and engineers who change firmware, apps and servers. Each audience gets a report written for it.
Show details for What you receive from an IoT test
- An executive report for product owners and leadership: the risks that matter for the fleet and for your customers, and what closing them involves, including whether a firmware release is enough.
- An engineering report for the firmware, app and cloud engineers, naming each weakness, the layer and component it sits in, and the change that removes it.
- A proof of concept for each finding, showing what was achieved against the test build, so your engineers can reproduce it on their own bench.
- CVSS 3.1 scores for every finding, whose attack vector shows how the flaw can be reached.
- A remediation matrix that orders the fixes by risk, so the change that protects the most devices is made first.
Firmware, app and cloud findings all use one format, which you can preview in our sample VAPT report. How each phase of a device test runs is explained in the VAPT methodology.
Finding F-03 · IoT and firmware test
Firmware updates are installed without a signature check
- Severity
- Critical
- Component
- Update routine, firmware 2.4.1
- Test setup
- A test build on an isolated test network
How it was confirmed
- The update routine in the firmware image checks a package's size and version number, and nothing else.
- A harmless test build with only its version string changed was offered to the device software from a test update server.
- The test setup installed the build and restarted into it, so any package the update server offers would run on every device.
Fix
Sign every release with a key kept offline, verify the signature in both the updater and the bootloader before anything is installed, and refuse versions older than the one already running.
Example layout, not client dataUpdate integrity · Firmware
08 / Your inputs
What you provide for an IoT and firmware test
An IoT test needs more from you than most tests: firmware, documents, accounts and a place to test the cloud side safely. The more you share, the less time goes into rediscovering what your engineers already know.
Show details for What you provide for an IoT and firmware test
What we need from you
- The firmware image for the version in scope, or the update channel it arrives through, plus release notes for recent versions.
- Documentation: an architecture sketch, data flows and the update process.
- Apps and accounts: test builds or store versions of the companion app, and user accounts at each permission level.
- A test cloud environment or a separate tenant, so device registration and updates can be exercised without touching customers' devices.
- Written authorization for the firmware, the app and every cloud service in scope, including any run by a vendor or partner.
Firmware and accounts. A test starts from the firmware image or update files you supply, with the app and cloud accounts the product uses.
Devices you did not make. If you deploy a product built by someone else, read its terms and speak to the vendor before testing: its cloud service needs its owner's permission, and many vendors run disclosure programs that want to hear about what is found.
Firmware and design notes you share stay under the confidentiality terms of the engagement agreement; the privacy notice on this website covers only messages sent through its forms.
The app, API and cloud layers are tested remotely from BERRY9's office in Hyderabad, the same way other BERRY9 tests are delivered.
09 / Standards
Device security standards and rules makers meet
Device security is moving from good practice to written rules in several markets. These are some that IoT makers in India run into, either at home or when selling abroad.
Show details for Device security standards and rules makers meet
| Standard or rule | Who it concerns | What it covers |
|---|---|---|
| OWASP IoT Top 10 | Anyone building or buying connected products | A widely cited list of the most common weaknesses in IoT products, from weak passwords to insecure update mechanisms. A shared vocabulary, not a certification. |
| ETSI EN 303 645 | Makers of consumer IoT products, especially those selling in Europe | A baseline of provisions for consumer devices, among them no universal default passwords, a way to report vulnerabilities, and keeping software updated. |
| IEC 62443 | Makers, integrators and operators of industrial automation and control systems | A series of standards for securing industrial systems, with requirements for components such as controllers and gateways as well as for the plants that run them. |
| Section 524B, US Federal Food, Drug, and Cosmetic Act | Makers of medical devices that can connect to the internet, sold in the United States | Premarket submissions to the FDA for these cyber devices include a plan to monitor and fix vulnerabilities and a software bill of materials. |
| EU Cyber Resilience Act | Makers of products with digital elements sold in the European Union | Security requirements across a product's life, including vulnerability handling and security updates, with most obligations applying from December 2027. |
| Essential Requirements for Security of CCTV | Makers and importers of CCTV cameras registered for sale in India | Security requirements added to MeitY's compulsory registration scheme for CCTV cameras, with testing at government-recognized laboratories. |
BERRY9 tests devices and reports what it finds; it is not a certification body or a recognized test laboratory for any of these schemes. A penetration test report can support the evidence a maker prepares, and each scheme's own assessor decides what counts.
Devices can also fall inside a company's own audit boundary: a smart lock in an ISMS scope, or a payment terminal on a network that handles card data. For how a test report serves as evidence in those cases, see ISO 27001 penetration testing and PCI DSS penetration testing.
10 / Related tests
IoT testing alongside mobile, API, wireless, cloud, network and code review
An IoT test touches every layer of a product, but some layers deserve a full test of their own. These are the services an IoT engagement most often sits next to.
Show details for IoT testing alongside mobile, API, wireless, cloud, network and code review
Mobile application testing
Anyone can download the companion app, which makes it a common way into a connected product. A full mobile test goes further than an IoT test into how the app stores data, handles keys and sends its traffic.
API security testing
Devices and apps both call the product's APIs. An API test checks every endpoint for authorization flaws, such as one customer reaching another's devices, across the whole interface rather than the calls a device makes.
Wireless penetration testing
Where devices join a Wi-Fi network, the security of that network decides who else can reach them. A wireless test looks at the access points, their encryption and any unauthorized devices on the air.
Cloud security assessment
Fleet back ends often run on AWS, Azure or Google Cloud. A cloud review checks the accounts behind the service: who can change device credentials, publish firmware or read telemetry.
Network penetration testing
Installed devices live on someone's network. A network test shows whether the device segment is kept apart from servers and office systems, and what a compromised unit could reach.
Source code review
With access to the firmware or back-end source, a review finds flaws that compiled code hides, such as a signature check that can be skipped or a buffer copied without checking its length.
Every other test BERRY9 offers, from thick-client to red teaming, is listed in the offensive security services hub.
11 / Price
What IoT penetration testing costs
An IoT and firmware test starts from INR 27,000 + 18% GST; the final price is set in a written proposal after scoping. Products differ so much in firmware, apps and back ends that the scoping call, not a price list, decides the number.
IoT and firmware test
Starts fromINR 27,000 + 18% GST
Firmware size, apps and cloud scope move the figure, and the written proposal sets your price.
Request a scoping call- How many devices and versions. One product on one firmware version is a smaller job than a family of models or several firmware branches.
- How large the firmware is. A compact image with few services is quicker to review than a large one with many bundled components.
- Apps and cloud in scope. Adding the companion app, the device APIs and the back end turns a device test into a test of the whole product.
Duration: The written proposal fixes the schedule, which grows with each added device model and cloud service.
Prices for web, mobile, API, network and other tests are set out in our guide to VAPT costs in India.
The starting price for small scopes includes one free retest. For larger scopes, the retest terms are written into the proposal before work starts.
IoT testing by city
12 / Inquiry
Tell us about your device
Tell us what the device does, how many models and firmware versions are in scope, whether an app and cloud service come with it, and when you need results. That is enough to propose a scope.
To talk it through first, call +91 86868 92922 or email contact@berry9.com.
13 / FAQ
Frequently asked questions
Short answers about scope, price and how testing works. For anything else, call +91 86868 92922.
What is IoT penetration testing?
It is a security test of a connected product as a whole: the firmware it runs, the companion app and APIs, and the cloud service that manages the fleet. The tester works as an attacker who owns one unit would, looking for weaknesses that reach other units, customer data or the back end. The result is a set of findings with proof and the changes that fix them. See the section on What IoT and firmware penetration testing is, and who needs it above.
What is firmware security analysis?
Firmware security analysis examines the software image a device runs, usually a small operating system, open-source libraries and the maker's programs in one file. It looks for passwords and keys written into the image, outdated components with published vulnerabilities, missing signature checks on updates, disabled secure boot, unprotected key storage and leftover debug features. Findings in the image are then confirmed on a running device. See the section on What firmware security analysis looks for above.
How is IoT penetration testing different from a network penetration test?
A network penetration test looks across many hosts and services on your network and is fixed by IT teams changing settings or patching servers. An IoT test looks deep into one product, from its firmware to its cloud service, needs the firmware and design documents, and is fixed by product engineers in a new firmware release. Organizations that install connected devices often need both: the IoT test for the product, the network test for how well the devices are kept apart from everything else. See the section on How IoT testing differs from a network penetration test above.
What do you need from us for an IoT security test?
The firmware image or the update channel it comes from; architecture notes and data flows; the companion app and test accounts; a test cloud environment; and written authorization covering every part in scope, including services a vendor runs for you. See the section on What you provide for an IoT and firmware test above.
Do we need to send physical devices, or can IoT testing be done remotely?
Yes. The firmware you supply, the companion app, the device APIs and the cloud back end are all tested remotely from Hyderabad, so no device has to be shipped or handled. Board-level hardware work and radio-protocol testing are not part of this service. See the section on What you provide for an IoT and firmware test above.
How much does IoT penetration testing cost in India?
Pricing for an IoT and firmware test from BERRY9 starts from INR 27,000 + 18% GST; the final price is set in a written proposal after scoping. What moves the figure is how many devices, models and firmware versions are in scope, how large the firmware is, and whether the app, APIs and cloud back end are included. See the section on What IoT penetration testing costs above.
Can IoT testing damage our devices or customers' data?
It is unlikely, because the work does not touch devices in customers' hands. Firmware is analyzed from the image you supply, and testing of the app, APIs and cloud is pointed at test accounts and a test environment. Any step that could affect a live system is listed in the written scope before testing starts. See the section on How an IoT and firmware test runs above.
Can the firmware of medical devices, smart meters and CCTV cameras be tested?
The firmware, app and cloud layers of such products can be tested, and the test is shaped around what matters for that device: patient safety and health data for medical equipment, billing data and remote switching for smart meters, video feeds and the recorder's place on the network for CCTV. Makers of these products also face sector rules, such as security requirements for CCTV cameras sold in India. See the section on What IoT and firmware penetration testing is, and who needs it above.
Which standards does an IoT penetration test refer to?
Common references are the OWASP IoT Top 10 for weakness categories, ETSI EN 303 645 for consumer devices and IEC 62443 for industrial systems, with sector rules for medical devices and CCTV on top. A penetration test report is evidence that a product was examined against such weaknesses; it is not a certificate under any of these schemes. See the section on Device security standards and rules makers meet above.
How often should a connected product be tested?
Test before the first release, and again whenever firmware changes how the device signs in, receives updates or talks to the cloud, or when the back end moves. Buyers who install devices made by others often test at purchase and after major vendor updates.
Which devices and firmware versions should we test first?
Start with the model that is most widely deployed, or the one that handles the most sensitive data or controls something physical, running the firmware version your customers actually have. If an update is about to ship, testing the release candidate finds problems before they reach the field. Older versions still in service deserve a line in the scope too, since devices that never update keep running them. The written scope names each model and version.