Skip to content
Knowledge base Updated: May 15, 2026

IoT and Embedded Systems Pentesting: How to Test and Protect Smart Devices

Your smart lock, CCTV camera or PLC are essentially small, specialized computers. But are they secure? Security testing of IoT devices and embedded systems is a journey into the depths of electronics, software and radio protocols - an area where traditional pentesting is not enough.

We live in the era of the Internet of Things (IoT). We are surrounded by billions of “smart” devices that collect data and communicate with the network - from smartwatches and home appliances in our homes, to surveillance cameras and access control systems in offices, to critical sensors and controllers in factories and critical infrastructure (Industrial IoT). Each of these devices is in fact an embedded system - a specialized computer, enclosed in a small form factor and designed for one specific task. This ubiquity of connected devices, while bringing tremendous convenience and efficiency, has simultaneously created a new, gigantic and extremely heterogeneous attack surface.

The security of these devices is a fundamentally different challenge than protecting traditional servers or web applications. Here we are dealing with a unique combination of hardware, firmware, radio protocols and cloud backend. Traditional penetration testing methods, focused on networks and applications, fall far short here. IoT security testing is a specialized, interdisciplinary field that requires the pentester to be skilled not only as a hacker, but also as an electronics and software engineer. It’s a journey into the depths of the device itself in search of its deepest hidden secrets.

Shortcuts

What are embedded systems and why has their security become such a critical issue?

An embedded system is a special-purpose computer system that is an integral part of the larger device it controls. Unlike a general-purpose computer (like a laptop), an embedded system is optimized to perform a limited set of tasks. Its “operating system” is most often specially prepared firmware, running on specialized hardware.

The security issue has become so critical because these previously isolated systems have been massively connected to the Internet, creating the Internet of Things (IoT). For years, their manufacturers, often coming from the world of traditional electronics rather than IT, did not make cyber security a priority. They focused on functionality, low cost and getting the product to market quickly.

As a result, the market has been flooded with millions of devices that have fundamental security vulnerabilities:

  • They run on outdated, not easy software.

  • They use default, publicly known passwords.

  • They do not encrypt network communications.

  • They have unsecured hardware interfaces that give direct access to their “innards.”

Compromising such devices can lead to the leakage of sensitive data (e.g., home camera images), the creation of huge botnets (like the Mirai botnet) or, in the case of industrial (IIoT) systems, physical sabotage.

📚 Read the complete guide: Cloud Security / AWS: Bezpieczeństwo chmury publicznej - AWS, Azure, best practices

What are the unique challenges and attack vectors in testing IoT devices?

Testing IoT security is much more complex than pentesting a standard web application because the attack surface is multidimensional and covers the entire ecosystem.

  • Device (Hardware & Firmware): An attacker can have physical access to a device. He can attempt to take it apart, connect to interfaces on the motherboard, read the contents of flash memory and reverse engineer the firmware.

  • Radio communication: Most IoT devices communicate wirelessly, using protocols such as Wi-Fi, Bluetooth Low Energy (BLE), Zigbee or LoRaWAN. Each of these protocols has its own unique attack vectors for eavesdropping, disrupting or spoofing communications.

  • Backend in the cloud: Almost every IoT device communicates with a cloud platform that collects its data and allows remote management. Vulnerabilities in this platform or its APIs could allow an entire fleet of devices to be taken over.

  • Mobile/web app: The interface through which the user controls the device (e.g., a smartphone app) is another potential entry point.

An effective IoT penetration test must address all these layers.

What is the IoT security testing methodology and what areas does it cover?

A comprehensive IoT security test is based on a structured methodology that aims to systematically analyze the entire attack surface. A good reference here is the OWASP IoT Top 10 project, which identifies the most common risks. The testing methodology typically covers the following areas:

  • Firmware Analysis: An attempt to obtain and reverse engineer firmware to find “hardwired” passwords, keys, hidden accounts or vulnerabilities in the code.

  • Hardware Interface Analysis (Hardware Hacking): Identifying and attempting to use physical ports and debug interfaces (e.g., UART, JTAG, SPI) to access the system shell or read memory.

  • Analysis of network and radio communications: Intercept and analyze network traffic and wireless communications (Wi-Fi, BLE, etc.) for unencrypted data, weak authentication mechanisms and other vulnerabilities.

  • Penetration testing of the backend (API / Cloud): Conduct a standard penetration test of the APIs with which the device communicates.

  • Penetration testing of a mobile/web application: Testing the client application for the most common mobile or web vulnerabilities.

A multi-layered attack surface in the IoT ecosystem

LayerDescriptionExample attack vectors
Device (hardware and firmware)The physical device, its electronic components and firmware.Reverse engineering of firmware, reading flash memory, attacks on hardware interfaces (JTAG, UART), fault injection attacks.
Communications (network and radio)Protocols by which the device communicates with the network and other devices.Eavesdropping and spoofing of Wi-Fi, Bluetooth, Zigbee traffic. Man-in-the-middle attacks.
Ecosystem (mobile app and cloud)Applications and servers that allow you to manage your device and collect data from it.Vulnerabilities in the mobile app, attacks on backend APIs (according to OWASP API Top 10), configuration errors in the cloud.

How does the firmware analysis (firmware analysis) work?

Firmware analysis is often the first and most important step in IoT testing. The goal is to “unpack” the software that runs on the device and analyze its contents for valuable information and vulnerabilities.

The process is usually as follows:

  • Obtaining firmware: It can be downloaded from the manufacturer’s website (as an update file), captured during the “over-the-air” (OTA) update process or, in the most difficult case, read directly from the flash memory bone on the device’s motherboard.

  • Analysis and unpacking: Using specialized tools (such as Binwalk), the analyst examines the structure of the binary file, attempting to identify and extract its various parts, such as the file system, operating system kernel or bootloader.

  • Static analysis: Once the file system is unpacked, the analyst can browse its contents. It looks for configuration files, startup scripts and, most importantly , “hardcoded” secrets such as passwords, private keys, certificates or API tokens. It also looks for vulnerable, outdated libraries or dangerous code fragments.

Finding such secrets in firmware is one of the most common and critical bugs, as it often allows you to take control of not just one device, but a whole fleet of them.

What are hardware interfaces, such as JTAG and UART, and how are they used in attacks?

Engineers, when designing and debugging electronic devices, leave special interfaces on motherboards that give them low-level access to the processor and memory. In the final, production device, these interfaces should be disabled. Unfortunately, very often they remain active, providing an open “door” for hackers with physical access to the device.

UART (Universal Asynchronous Receiver-Transmitter): This is a simple serial port that often provides direct access to the system console (shell) with root privileges. Finding UART pins on the motherboard and connecting to them with a simple USB-to-serial converter can give an attacker full administrative control over the device’s operating system.

JTAG (Joint Test Action Group): This is a much more powerful debugging interface that allows direct interaction with the processor and memory at a very low level. With JTAG, an attacker can stop the processor, read the contents of the entire RAM, and even read and reprogram the flash memory where the firmware is stored. It’s like connecting directly to the “brain” of the device.

How does nFlo perform advanced penetration testing of IoT devices and embedded systems?

At nFlo, we have one of the few labs and teams in the Polish market specializing in hardware security, embedded systems and IoT. We understand that testing these devices requires a unique combination of software, electronics and radio communications expertise. Our methodology is comprehensive and covers the entire attack surface of the IoT ecosystem.

Our testing is much more than just port scanning. We perform a full, multi-layered analysis that includes:

  • Firmware reverse engineering: We acquire and deeply analyze firmware in search of “buried” credentials, cryptographic weaknesses and hidden backdoors.

  • Attacks on hardware interfaces (hardware hacking): Our experts, with specialized lab equipment, identify and attempt to exploit interfaces such as UART, JTAG and SPI to access the system shell or read memory contents.

  • Security analysis of radio protocols: We intercept and analyze wireless communications**(Wi-Fi, Bluetooth Low Energy, Zigbee, LoRaWAN**), testing their resistance to eavesdropping, forgery and man-in-the-middle attacks.

We understand that the device is only one component. That’s why our tests always also include verification of the security of the mobile app controlling the device, as well as the cloud backend and APIs it communicates with. For manufacturers, as part of our consulting services, we also help implement “security by design” principles from the product design stage to ensure compliance with upcoming regulations such as the Cyber Resilience Act (CRA).

Hardware lab in practice — UART/JTAG/SPI dump + OWASP IoT Top 10 (2024) + ETSI EN 303 645

In practice, the nFlo hardware lab uses several complementary methods to acquire firmware from a physical device. UART dump begins with identifying 4 pins (VCC, GND, TX, RX) using a multimeter and oscilloscope — these are often unsoldered testpoints marked J* or TP*. After connecting a USB-to-TTL converter (such as CP2102, FT232) and establishing the baudrate (115200 is standard, but 9600 and 921600 are also popular), we get the uboot bootlog and frequently a root shell without password authentication. JTAG requires more advanced equipment (Bus Pirate, Segger J-Link, OpenOCD) and identification of TDI/TDO/TCK/TMS — the JTAGulator tool automates brute-force pinout for 24-pin headers. Once a JTAG session is established, we can halt the CPU, dump the entire RAM, and read/program the flash. SPI dump is direct communication with the flash chip (Winbond W25Q*, Macronix MX25L*) using an SOIC-8 clip or by desoldering the chip — flashrom + CH341a yields a binary image of the entire memory in 2-10 minutes.

OWASP IoT Top 10 in its 2024 update retained the V1-V10 numbering but expanded the context: I1 (Weak/Default Passwords) was clarified to include IoT cloud accounts (not just device-level); I3 (Insecure Ecosystem Interfaces) now covers MQTT brokers, CoAP endpoints, and webhooks; I5 (Use of Insecure or Outdated Components) requires SBOM (Software Bill of Materials) and CVE monitoring in embedded Linux distributions (BusyBox, OpenWrt-based). For consumer IoT manufacturers, ETSI EN 303 645 applies (baseline 13 requirements) — the foundation of the UK PSTI Act and the baseline benchmark for the Cyber Resilience Act (CRA) in the EU starting in 2027. Mapping pentest findings to ETSI 5.1 (no default passwords), 5.3 (keep software updated), and 5.4 (secure storage of sensitive parameters) is today a standard in reports for manufacturers.

If you manufacture IoT devices and need ETSI EN 303 645 certification or CRA preparation, contact us about our penetration testing service, which covers a full hardware and firmware audit. Infrastructure operators with IoT devices covered by NIS2 (energy, water, transport, healthcare) should additionally verify supply chain compliance through our NIS2 compliance service — the NIS2 directive explicitly requires supplier risk management, including IoT manufacturers.

Learn key terms related to this article in our cybersecurity glossary:


Learn More

Explore related articles in our knowledge base:


Explore Our Services

Need cybersecurity support? Check out:


Cybersecurity for Your Industry

Learn more about cybersecurity in your industry:

Share:

Talk to an expert

Have questions about this topic? Get in touch with our specialist.

Sales Representative
Grzegorz Gnych

Grzegorz Gnych

Sales Representative

Response within 24 hours
Free consultation
Individual approach

Providing your phone number will speed up contact.

Want to Reduce IT Risk and Costs?

Book a free consultation - we respond within 24h

Response in 24h Free quote No obligations

Or download free guide:

Download NIS2 Checklist