Skip to main content

Cyber Security Testing

IoT Security Testing

Device, mobile companion, cloud backend and radio protocol testing across the full IoT chain.

Every engagement includes manual validation, a two audience report and free re-testing.

Get a scoped quote+91 96682 00222

What this actually is

An IoT product is four attack surfaces pretending to be one. The device, the firmware, the app that controls it, and the cloud backend tying them together. Testing one of them tells you very little.

We test the whole chain. It is common to find a well-built device sitting behind a cloud API that will happily accept commands for somebody else's device if you change a number in the request.

Where the product uses radio, we look at that too. Pairing and provisioning flows are a reliable source of serious findings.

What we go after

  • Device firmware extraction and analysis
  • Hardware interfaces and physical attack surface
  • Companion mobile and web application testing
  • Cloud backend and device management API testing
  • Device identity, provisioning and pairing flows
  • Radio protocol analysis including BLE, Zigbee and Wi-Fi
  • Update mechanism and secure boot
  • Cross-tenant device access

How we run it

  1. 01

    Scope and authorise

    Targets, testing windows, escalation contacts and safety limits, all agreed in writing before anyone touches anything.

  2. 02

    Map the surface

    We enumerate what is actually exposed, which is usually more than the asset register says.

  3. 03

    Test by hand

    Tooling gives coverage, our engineers give proof. Every finding is reproduced before it is written down.

  4. 04

    Report

    An executive narrative your board can act on, and a technical annexe with the exact request, payload and fix.

  5. 05

    Re-test and sign off

    Once you have fixed it we verify each one at no extra cost, then close the engagement properly.

What you receive

  • Findings across device, app, cloud and radio
  • Attack narrative across the full product chain
  • Firmware and backend remediation guidance
  • Free re-test after fixes

Who needs this

Manufacturers and operators of connected products, from consumer devices to industrial sensors and smart metering.

How long it takes

Two to four weeks for a full product chain.

Standards this satisfies

  • OWASP IoT Top 10
  • ETSI EN 303 645
  • IEC 62443
  • CERT-In

Why it matters

A connected device is hardware an attacker can hold. Debug ports, extractable firmware and keys shared across an entire product line are all in play, and none of them can be patched away after the units ship.

The exposure is rarely one device. It is the fleet, and the cloud service every unit trusts.

Choose the depth you actually need

Most of the price difference between quotes comes down to this one choice, and it is rarely explained. Pick one to see what it covers, what it suits and what it costs you.

You give us working accounts at each privilege level and a short walkthrough. We then test what a real attacker reaches after the first stolen password, which is where the findings that matter almost always live. This is what we recommend for most engagements.

Choose this when

  • Any application with authenticated functionality
  • Multi-tenant products, where tenant isolation is the real risk
  • Getting the most findings for the money

Effort and cost

Moderate effort and by far the best coverage per rupee. Most of the serious findings we report come out of authenticated testing rather than unauthenticated.

Assessed against IEC 62443

Industrial testing is scoped to the zone and conduit model in IEC 62443, with findings mapped to a target security level per zone. That lets you prioritise by consequence rather than by CVSS score, which means very little on a plant floor.

Scope it yourself, before you call anyone

Answer a few questions and you get an indicative number, the working behind it and what your answers tell us. It runs in your browser, so nothing you type reaches us.

1/5

What needs testing?

Pick everything in scope. Effort is driven by unique functionality, not by how many IP addresses you own.

What we look for, and keep finding

These are the classes of problem this work exists to surface. Not every engagement finds all of them, but these are the ones that turn up often enough to be worth naming.

  • IT to OT boundary failure

    The route every published industrial attack has used. We map every path from the corporate network into the control environment, including the ones created for projects and left in place.

  • Unauthenticated industrial protocols

    Modbus, DNP3 and their relatives assume a trusted network. Anyone who reaches the segment can often issue commands, which makes segmentation the primary control rather than a secondary one.

  • Vendor remote access

    Permanent tunnels with shared credentials and no logging, established so a supplier can maintain their equipment. The supplier's security posture silently becomes yours.

  • Unpatchable legacy assets

    Devices that cannot be updated without invalidating certification. The finding is not the missing patch, it is whether the compensating isolation actually holds when tested.

  • Firmware and physical interfaces

    Debug ports, unsigned firmware and extractable secrets on devices sitting in places no one supervises. We assess these in a lab rather than on a live line.

Who runs your engagement

A senior tester, named before you sign

Testing is led by an engineer holding OSCP, CREST or equivalent, and you are told who it is before the engagement starts. They write the report themselves rather than handing notes to someone else, and they are on the call when findings are walked through. If the person changes, we tell you why.

Questions we get asked

Where do IoT products usually fail?

The cloud API, almost every time. The device gets the attention and the backend gets built quickly, so authorisation between tenants is the weak point far more often than the firmware.

Ready to scope your iot security testing?

Thirty minutes with a senior engineer, and you leave with a written scope and indicative effort.