What exactly gets tested in an IoT security assessment?

The whole device and the ecosystem around it: the firmware (extracted and analysed for hardcoded credentials, keys and insecure binaries), the exposed hardware interfaces (UART, JTAG, SPI), the wireless protocols it speaks (BLE, Zigbee, MQTT), the companion app and the cloud APIs it talks to. We do not just test the gadget on the bench; we test the entire chain that surrounds it.

Why are default credentials on IoT devices so dangerous?

Plenty of devices ship with factory usernames and passwords that never get changed, or with keys shared across an entire model line. An attacker who knows those credentials walks straight in, and if the firmware is never updated the window of exposure simply never closes. It is one of the most heavily exploited vectors and, at the same time, one of the easiest to overlook across a large device estate.

Can a compromised sensor open the way to critical systems?

Yes, and it is a common pattern. A sensor, a camera or an actuator is rarely isolated: it shares the network with management systems or, in industrial settings, with the OT network that controls physical processes. Compromising the humblest device is often the first hop towards infrastructure that genuinely matters. That pivot is exactly what we assess.

What is the Cyber Resilience Act and how does it affect my connected devices?

The Cyber Resilience Act (CRA) is the European regulation that requires makers of products with digital elements to keep them secure across the whole lifecycle: no insecure default credentials, proper updates and vulnerability handling, and technical documentation that backs it all up. Together with the RED directive for radio equipment, it turns device security into a condition for selling into the EU rather than a nice-to-have. An IoT assessment gives you the technical evidence to stand behind that compliance.

Device security

IoT security testing for businesses

Q: Do you test the device firmware?

Yes, and it tends to be where the nastiest findings surface. We pull the firmware over a debug interface, a flash memory dump or an over-the-air download, unpack it and comb through it for hardcoded credentials and keys, embedded secrets, binaries compiled without protections and boot or update mechanisms that can be tampered with. A single password baked into the image can unlock every unit of the same model.

Every IoT device is a door you forgot.

We test your connected devices the way an attacker would with the board in hand: firmware, hardware interfaces, wireless protocols, companion apps and the APIs behind them.

Request IoT testing View methodology

The blind spot in the attack surface

Servers and endpoints get hardened, but the hundreds of devices chattering across the network usually get on with no one ever checking them.

Forgotten entry points

Every camera, sensor or gateway is a connected computer that no one patches or monitors. Installed once and forgotten, yet it keeps listening on the network for years.

Credentials and firmware left untouched

Default credentials, keys hardcoded into the firmware and no secure over-the-air updates. The device arrives insecure from the factory and no one ever closes that window.

The jump to what is critical

A compromised sensor is rarely the end goal. It is usually the springboard to management systems or, in industrial settings, to the OT network that runs physical processes.

What we test

A connected device is never a single thing: it is firmware, silicon, radios, an app and a cloud backend. We test each layer on its own and, above all, the seams where one layer trusts another without checking.

Firmware

Extraction over debug interfaces, a flash memory dump or an over-the-air download, then static analysis of the binaries: hardcoded credentials and cryptographic keys, embedded secrets and tokens, forgotten debug services, and a check on whether the image is signed and encrypted. This is the layer where critical findings surface fastest.

Hardware

Locating exposed debug interfaces (UART, JTAG, SWD), reaching external memory over SPI or I2C to read or rewrite the firmware, bypassing boot protections and running basic fault injection. The point is to measure what an attacker gets with the board physically in hand.

Wireless protocols

Every radio the device speaks: BLE (pairing, encryption and characteristic authorisation), Zigbee and Z-Wave in smart-building and industrial estates, LoRa for long-range telemetry, and MQTT or CoAP as the transport. We look for missing or weak encryption, reused keys, tamperable messages and node spoofing. When it hangs off a corporate network we cross-reference the WiFi security audit.

Companion app and cloud APIs

The mobile app that drives the device and the cloud APIs behind it: authentication and authorisation, direct object references that leak other users data, secrets baked into the app, and server-side controls that can be sidestepped. Often the weak link is not the gadget but its backend.

Identity, encryption and secure updates

How each unit identifies itself to the cloud, whether keys are unique per device or shared across the whole model, how data is protected in transit and at rest and, crucially, whether the OTA mechanism validates signatures: without secure updates, any flaw we find stays open forever.

Network exposure

Which ports and services the device opens on the local network, whether it answers from the internet, what it leaks when discovered and how well isolated it is from everything else. This is where it meets the infrastructure and network audit, which measures the jump from the device towards systems that matter.

Industrial IoT (IIoT/OT)

On the plant floor a connected device stops being a gadget and becomes embedded IT governing physical processes: gateways, sensors, controllers and cameras that once lived on an isolated network and now sit alongside the corporate one. That IT/OT convergence widens the attack surface exactly where a failure does not take down a service but a production line.

So work in these environments demands operational care: strict rules of engagement, a clear line between what can be tested in production and what belongs on a lab bench, and priority given to the pivot from the device towards the OT network. We match the approach to the real risk of each sector; you can see how we work in security for the industrial sector.

How we test your IoT devices

Ecosystem and surface reconnaissance

Mapping the device and everything around it: physical interfaces, wireless protocols, companion app, cloud APIs, services exposed on the network and the data flows between them all.

Firmware analysis

Extracting the firmware (via interface, memory dump or download), unpacking it and hunting for hardcoded credentials, cryptographic keys, insecure binaries and weak boot or update mechanisms.

Hardware and interface testing

Locating and exploiting exposed debug interfaces (UART, JTAG, SPI), reaching flash memory, bypassing boot protections and validating the physical isolation of the device.

Protocol and app/API testing

Analysing wireless communication (BLE, Zigbee, MQTT) and the companion app and its APIs: weak encryption, authentication, authorisation, message tampering and the absence of secure over-the-air updates.

Report and retest

Risk-prioritised findings with evidence, concrete recommendations per layer (hardware, firmware, protocol, cloud) and a follow-up retest to confirm closure.

What you get at the end

A technical and executive report with each finding, its real business impact and concrete remediation per layer, plus a retest to confirm the critical issues are closed.

Firmware analysis: hardcoded credentials, keys and insecure binaries.
A map of exposed hardware interfaces (UART, JTAG, SPI) and their risk.
Assessment of protocols (BLE, Zigbee, MQTT), companion app and cloud APIs.
Prioritised remediation plan and closure retest.

"The first finding almost always sits inside the firmware: a hardcoded password that opens every unit of the same model. Nobody had looked, because the device was only a sensor."

— Offensive Security Team, Hard2bit

When you need it

You do not have to wait for an incident. These are the moments when an IoT assessment stops being optional.

You are launching a connected product

If you build or integrate a device with connectivity, testing it before it ships spares you recalls, emergency patches and headlines. Far better that you find the hardcoded key than an outside researcher does.

You are rolling out sensors or cameras at scale

Hundreds or thousands of units of the same model multiply any flaw: a weakness in one is a weakness in all. Testing the model before the mass rollout changes the whole risk equation.

You live with legacy devices

Kit installed years ago that no one has touched since, unpatched and running firmware that is out of support. You need to know what it exposes today and how to isolate it while you plan its replacement.

You have compliance to meet

The Cyber Resilience Act and the RED directive make device security a condition for reaching the market. An assessment gives you the technical evidence to stand behind that compliance with customers and regulators.

You have just been through an incident

After a compromise where an IoT device may have been the way in or a pivot point, the assessment reconstructs what was genuinely possible and closes the vector before it happens again. It slots naturally alongside our technical pentesting and Pentesting & Red Team work.

What the report includes

The deliverable is built so the technical team knows exactly what to fix and leadership grasps the real business risk.

Ecosystem inventory

A map of every device tested, its interfaces, protocols, apps and cloud services, with the relationships and data flows between them. The full picture of the surface, not a loose list of gadgets.

Findings per device

Each finding with its severity, the layer it affects (hardware, firmware, protocol, app or cloud) and reproducible evidence: steps, captures and artefacts. No ambiguity about what it is or how it is exploited.

Firmware supply-chain risk

Third-party components and libraries inside the firmware, versions with known vulnerabilities and vendor dependencies. The risk you inherit without having written it yourself.

Remediation and retest

A remediation plan prioritised by impact and effort, with concrete recommendations per layer, and a follow-up retest that confirms in writing that the critical issues are closed.

Frequently asked questions about IoT security

Do I need to send you a physical unit of the device?

For the hardware and firmware work, yes: we operate on real units so we can reach the physical interfaces, extract the firmware and test the boot protections. Ideally several units, because some tests are destructive. The protocol, companion app and API work can run in parallel without sacrificing extra devices.

Do you test the device firmware?

Yes, and it is usually where the most serious findings turn up. We pull the firmware over a debug interface, a flash memory dump or an over-the-air download, unpack it and comb through it for hardcoded credentials and keys, embedded secrets, binaries built without protections and boot or update mechanisms that can be tampered with. A single password baked into the image can unlock every unit of the same model.

Do you test wireless protocols such as BLE and Zigbee?

Yes. We look at every radio the device speaks: BLE (pairing, encryption and characteristic authorisation), Zigbee and Z-Wave in smart-building and industrial deployments, LoRa for long-range telemetry, and MQTT or CoAP as the messaging transport. We hunt for missing or weak encryption, reused keys, tamperable messages and node spoofing. When the device hangs off a corporate wireless network we chain these findings with the WiFi security audit.

Do you cover industrial and OT environments?

Yes. The principles are the same, but in industrial settings the impact is greater: a compromised sensor, gateway or PLC can affect physical processes. We work with particular care under strict rules of engagement so operations are not disrupted, we draw a clear line between tests that are safe in production and those that belong on a lab bench, and we prioritise the pivot from the device towards the OT network.

What is the Cyber Resilience Act and how does it affect me?

The Cyber Resilience Act (CRA) is the European regulation that requires makers of products with digital elements to keep them secure across their whole lifecycle: no insecure default credentials, proper updates and vulnerability handling, and documentation that backs it up. Together with the RED directive for radio equipment, it makes device security a condition for reaching the market. An IoT assessment gives you the technical evidence to stand behind that compliance.

How long does an IoT security assessment take?

It depends on how many layers are in scope and how complex the device is. An assessment focused on a single product (firmware, hardware, a couple of protocols and its companion app) usually runs to around two or three weeks; an ecosystem with several models, a cloud backend and an industrial deployment takes longer. After the initial reconnaissance we agree scope and timeline in writing before any testing starts.

How is testing the IoT different from auditing the WiFi it connects to?

They are complementary. A WiFi audit assesses how an attacker would get in over the air and whether the guest and IoT networks are properly isolated; IoT testing goes down into the device itself: its firmware, its hardware and the protocols it speaks. Findings on one side often explain the other, which is why they are frequently paired with our WiFi security audit.

Where does this fit within the Hard2bit portfolio?

It is part of the Pentesting & Red Team area, alongside technical pentesting, infrastructure and network audits and our WiFi security audit. IoT testing covers the connected device — one of the most overlooked parts of the attack surface.

What is hiding in your device firmware?

Request an IoT security assessment and we will tell you, with evidence, what an attacker would find with your device in hand.

Request IoT testing