What your monitoring should catch during an IoT pentest

Why IoT detection differs from endpoint monitoring

Enterprise SIEM and EDR tools were built for Windows endpoints and Linux servers. They assume an installed agent, a managed operating system and a predictable call pattern to telemetry collection infrastructure. IoT devices run stripped firmware on microcontrollers or real-time operating system variants that accept no agent. Your monitoring coverage sits at the network edge, the cloud API gateway and the firmware update channel, not on the device itself.

The attack surfaces an IoT pentest exercises are distinct from a conventional endpoint test. The device exposes network services, a radio interface, hardware debug ports and the cloud backend it authenticates to. Each surface has a different monitoring layer, and most organisations have coverage on some but not all of them. Knowing which layers are dark before the test starts is the most useful preparation you can make.

Network signals a tester's tools produce

When a tester scans IoT devices, the first signals appear on the network. Port scans and service enumeration against embedded devices generate SYN packets to Telnet (port 23), MQTT (1883 and 8883), CoAP (5683 and 5684), HTTP (80 and 8080) and UPnP SSDP (1900) from a host with no business reason to reach them. A SIEM watching east-west traffic on a dedicated IoT VLAN should alert on any host outside that VLAN initiating connections to device IPs on those ports. The MITRE ATT&CK framework catalogs the network scanning and service discovery techniques testers apply to connected device estates.

ARP scanning and DHCP exhaustion are also common early steps. A tester mapping the network position of a device will send ARP broadcasts that appear as an ARP storm in flow data. DHCP exhaustion, used to understand addressing, appears as a large number of DISCOVER packets from a single source MAC in a short window. Both patterns are detectable from switch-level flow exports even without full packet capture. For infrastructure pentest engagements that include IoT network segments, the same rules apply and your existing signatures likely cover them already.

Cloud API signals when the test moves to the backend

IoT devices authenticate to a cloud backend for telemetry, configuration and provisioning. A tester who extracts an API token from firmware or intercepts the device communication channel will call that API from a non-device IP address. Your cloud API gateway logs should show the source IP alongside the device credential, and an alert on a device token authenticating from an address outside the device's registered subnet is one of the cleaner signals an IoT engagement produces.

Token replay and abnormal call volume are the other signals. A tester trying to understand the provisioning flow will make repeated calls to device registration, certificate provisioning and telemetry endpoints. Rate limits at the API gateway fire visibly here. As described in how an IoT pentest is run, testers who find a misconfigured API endpoint probe it systematically, and the call pattern will diverge from what a real device produces in normal operation.

The cloud side is where your existing SIEM can contribute most. The signals arrive as structured HTTP logs rather than raw packets from an unfamiliar radio protocol. Define a baseline of normal call volume and call pattern per device class, then alert on deviation. A device making ten times its normal call volume in a five-minute window is a signal regardless of whether the source is a tester or a genuine attacker.

Firmware channel signals and update server monitoring

Many IoT devices pull firmware updates over HTTPS from a vendor-hosted server. A tester who attempts to intercept or replace a firmware image generates an unusual request: an outbound connection from a tester host to the update endpoint, or a DNS query resolving the update hostname from an unexpected source. Update server logs showing a device credential authenticating from a new source IP, or a firmware hash that does not match the expected version, are both signals worth surfacing. The OWASP IoT Security Project documents firmware security as a primary IoT attack surface and lists the controls an update channel requires.

Testers also test for unsigned or insufficiently verified firmware by staging a replacement image. The signal appears when the device contacts the staged server rather than the legitimate one: DNS for an unfamiliar update hostname, TLS connections to an IP that does not resolve to the vendor domain, or an outbound connection on a port the device does not normally use. A DNS allowlist for known update endpoints makes interception attempts detectable from resolver logs alone, without requiring full packet capture on the device segment.

Wireless and radio protocol signals

Bluetooth Low Energy and Zigbee scanning tools send probe packets that appear on the radio spectrum before they reach any network log. A red team exercise that includes RF work may also reach for Z-Wave or 433 MHz depending on the target devices. Standard SIEM coverage does not reach this layer: dedicated spectrum monitoring or a managed intrusion detection system for 802.15.4 networks is required to observe BLE beacon floods, out-of-band scan packets and unexpected pairing requests.

A BLE scanner sending LE_SCAN_REQ packets produces a distinctive burst visible to any Bluetooth sniffer attached to the same piconet. A Zigbee active scan floods the 802.15.4 channel with beacon requests visible to any capable receiver on the same channel. Neither signal generates a network log entry unless the device responds and the response reaches an access point that logs at the 802.15.4 layer. For organisations that want to confirm whether their RF detection rules fire correctly, purple teaming exercises that include simulated radio scanning are one way to test them without commissioning a full standalone engagement.

Building a detection coverage map before the engagement starts

The most useful preparation for an IoT pentest is a detection coverage review. Map each phase of the engagement against the monitoring layer that would observe it, and mark the gaps before the tester arrives. The phases follow the attack surface: network enumeration, cloud API access, firmware extraction, wireless scanning and hardware interface probing. A gap at one phase means a tester can operate through it without generating a single alert.

A coverage gap is not a reason to cancel the engagement, and a gap that is hard to close is still worth recording. The point is to have a documented answer to whether you would have detected the activity if it had been a real attacker, before the findings arrive. When the engagement report maps each finding to the monitoring layer that should have caught it, the gap list becomes a prioritised detection backlog rather than a collection of open questions.

Link your coverage map to the scoping call. Agree in advance which monitoring layers are active during the test, which are passive and which are absent. The UAE rules that apply to IoT security testing include requirements from NESA and DESC that bear on monitoring obligations, so knowing your detection gaps before the test is part of satisfying them. The NIST Cybersecurity Framework Detect function provides a cross-sector baseline for what continuous monitoring of networked assets should include, and it is a useful reference point when translating engagement gaps into remediation budget.

IoT monitoring and detection obligations in the UAE

UAE organisations deploying IoT estates face monitoring obligations from multiple regulators. The UAE Information Assurance Standard, published by the National Electronic Security Authority, requires continuous monitoring of networked assets. IoT devices connected to government or critical infrastructure networks fall within that scope, and the expectation covers both network anomalies and access to backend systems. Organisations licensed under DESC in Dubai, including government entities and their technology suppliers, face equivalent requirements under the Dubai Information Security Regulation.

In Abu Dhabi, ADHICS applies to healthcare entities operating connected medical devices. Firmware integrity and cloud API security are directly relevant to patient safety at this scale, and the monitoring requirements under ADHICS cover the device network and the systems it connects to. A pentest finding that reveals a gap in firmware update channel monitoring should be read against those requirements, not treated as a purely technical observation with no regulatory dimension.

Both Abu Dhabi and Dubai have significant concentrations of smart building deployments, connected infrastructure and operational technology that presents a large IoT attack surface. Commissioning an IoT pentest and then reviewing the resulting detection gaps against regulator obligations is the path from test finding to remediation priority. Knowing which of the four monitoring layers are absent before the engagement starts is the starting point for that conversation, and the one that determines whether the report produces a detection backlog or just a list of open questions.

Frequently asked questions