The RF Side of IoT Security That Most Pentesters Never Touch

Ask ten penetration testers how they would assess the security of an IoT device, and most will describe a familiar workflow. Extract the firmware, reverse engineer the binaries, inspect bootloader protections, identify hardcoded credentials, evaluate update mechanisms, and look for software vulnerabilities. It's a well-established process, and for many devices, it uncovers meaningful security issues.

Yet many IoT products spend surprisingly little time communicating over Ethernet or Wi-Fi.

Instead, they rely on Bluetooth Low Energy, Zigbee, LoRa, Sub-GHz ISM radios, Thread, NFC, or proprietary wireless protocols designed for low power consumption and inexpensive hardware. Those radio links often become the device's primary attack surface, but they're frequently overlooked because RF analysis sits outside the traditional penetration testing toolkit.

Understanding an embedded system without understanding how it communicates is like auditing a web application without looking at its network traffic.

Firmware tells you what the software intends to do.

Radio traffic often reveals what the system actually does.

Firmware Doesn't Show the Entire Attack Surface

Reverse engineering remains one of the most valuable techniques in embedded security. It reveals authentication logic, cryptographic implementations, debug functionality, update mechanisms, and memory protections.

But firmware analysis alone rarely answers questions such as:

• Can an attacker impersonate another device?
• Is radio traffic encrypted or simply obfuscated?
• Are packets replayable?
• Can pairing procedures be abused?
• Does the protocol authenticate messages?
• Are devices distinguishable through RF fingerprints?
• What happens when malformed frames arrive over the air?

These questions only become visible once the wireless protocol itself is investigated.

Many embedded products trust their radio network far more than they should.

That assumption has created some of the most interesting IoT vulnerabilities over the past decade.

Wireless Changes the Threat Model

Traditional software assessments generally assume an attacker already has network access or physical access to the device.

Wireless protocols expand that threat model considerably.

An attacker parked outside a building may never touch the hardware directly. Instead, they observe radio traffic, identify protocol behaviour, replay captured messages, or transmit crafted packets designed to manipulate device state.

The practical attack surface depends on the protocol.

Bluetooth Low Energy emphasises short-range communication but introduces pairing procedures, advertising packets, and GATT services that deserve careful analysis.

Zigbee prioritises low-power mesh networking, creating opportunities to examine key distribution, trust relationships, and network formation.

LoRa enables long-range communication, making geographic assumptions particularly important when evaluating physical security boundaries.

Proprietary ISM protocols often introduce the greatest uncertainty because neither documentation nor mature analysis tools may exist.

The absence of public documentation should never be confused with security.

Capturing Traffic Is Only the Beginning

Many newcomers to RF security assume packet capture represents the difficult part.

In practice, collecting radio traffic is often straightforward.

Interpreting it is where the engineering work begins.

Raw captures rarely explain:

• Field meanings
• Message sequencing
• Session establishment
• Device identities
• State transitions
• Error handling
• Authentication
• Encryption boundaries

Building that understanding requires correlating radio captures with firmware behaviour, hardware observations, and protocol experimentation.

Eventually, the wireless protocol becomes another software interface — one that simply happens to travel through the air.

Unknown Protocols Require Different Thinking

Proprietary wireless implementations often intimidate testers because protocol documentation doesn't exist.

That's usually where the most valuable work begins.

Rather than searching immediately for vulnerabilities, start by answering simpler engineering questions.

How frequently do packets appear?

Which fields change predictably?

Which remain constant?

Do packet lengths vary?

Does communication follow obvious request-response behaviour?

Are counters present?

Do checksums change consistently?

Is entropy concentrated in specific bytes, suggesting encryption or message authentication?

This process resembles reverse engineering a binary.

You're reconstructing system behaviour from observable evidence rather than source code.

RF Security Is Rarely About Breaking Encryption

Security discussions often focus on cryptography.

Wireless assessments frequently reveal different problems.

Devices sometimes authenticate only during pairing and trust every subsequent packet.

Sequence numbers may be predictable.

Replay protection may be absent.

Commands may lack message authentication.

Default network keys may remain unchanged after deployment.

Configuration frames may expose unnecessary operational information.

In many real-world assessments, protocol design proves more interesting than cryptographic implementation.

Strong encryption cannot compensate for weak trust assumptions.

Physical Layer Observations Matter

The radio itself provides information beyond packet contents.

Signal strength.

Channel selection.

Transmission intervals.

Frequency hopping behaviour.

Retry patterns.

Device discovery.

Beacon timing.

Power management.

These characteristics reveal operational behaviour that firmware analysis alone cannot expose.

Engineers investigating battery-powered devices, for example, often learn as much from transmission timing as they do from packet contents.

Similarly, predictable beacon intervals may expose opportunities for traffic analysis even when payloads remain encrypted.

Combining Firmware and RF Produces Better Results

The most productive assessments rarely treat firmware analysis and wireless analysis as separate disciplines.

Instead, they reinforce one another.

Firmware may reveal packet parsing functions whose corresponding messages can be identified over the air.

Radio captures may expose undocumented commands that guide deeper reverse engineering.

Memory analysis may identify cryptographic keys later validated against captured traffic.

Observed protocol behaviour may explain code paths that initially appeared unrelated.

Each technique answers questions that the other cannot.

Together, they provide a much more complete understanding of the device.

RF Security Demands Patience More Than Expensive Equipment

Specialised radio hardware certainly helps, but the limiting factor is rarely equipment.

It's methodology.

Successful wireless investigations depend on careful observation, repeatable experiments, disciplined note-taking, and the willingness to form and revise hypotheses as new evidence appears.

Unlike traditional network protocols, proprietary RF systems often provide few obvious clues. Progress comes from gradually eliminating incorrect assumptions rather than immediately discovering the correct one.

That investigative mindset resembles debugging distributed systems more than running automated vulnerability scanners.

Why Many Pentests Never Reach the Radio Layer

Time is one reason.

Wireless analysis can significantly extend an engagement, particularly when undocumented protocols require reverse engineering before meaningful testing can begin.

Skill specialisation is another.

Many application security professionals have deep expertise in software exploitation but relatively little experience with software-defined radio, spectrum analysis, modulation, or embedded wireless protocols.

Finally, many organisations define IoT assessments around firmware extraction, secure boot validation, and software vulnerabilities because those deliverables fit familiar reporting processes.

None of those reasons reduces the importance of RF security.

They simply explain why it is often omitted.

Embedded Security Doesn't Stop at the Flash Chip

Modern IoT devices rarely exist in isolation. They communicate continuously with sensors, gateways, mobile applications, industrial controllers, and cloud services using radio technologies that shape both their functionality and their security posture.

Evaluating only the firmware answers important questions about how the device was built.

Evaluating its wireless behaviour answers equally important questions about how it behaves in the real world.

The most complete IoT security assessments recognise that these perspectives are inseparable. The firmware defines the logic, the radio exposes the interactions, and meaningful security conclusions emerge only when both are understood together.