IoT hacking: how devices get breached and how to stop it

What is IoT hacking?

IoT hacking is the unauthorized takeover or manipulation of a connected device, such as a camera, meter, tracker, gateway, or sensor, or of the traffic that device sends.

Most of it is not clever. The device answers on the public internet, runs a service such as Telnet or a web admin page, and accepts a default or hardcoded password. The attacker just logs in. The pattern repeats across almost every category of IoT devices.

Why IoT devices are easier to hack than laptops

Internet of things hacking works because your devices are weaker than a laptop in four ways:

• Limited compute: A module with a few megabytes of memory has no room for endpoint protection.
• Too many transports: Wi-Fi, Bluetooth, cellular, and MQTT each bring their own security model, and no single standard covers them all.
• Shared components: The same low-cost chipset and firmware ship in millions of units, so one flaw opens all of them.
• Nobody watching: Once installed, a device often runs for years without a patch or anyone looking at its traffic.

What an IoT hacker is actually after

An IoT hacker usually wants one of four things, and each maps to a real internet of things hack:

• A botnet node: Mirai enlisted cameras and DVRs to flood targets with traffic.
• A foothold: Attackers reached a casino's network through a connected fish tank thermometer.
• The data: A TRENDnet camera flaw exposed live video from inside people's homes.
• Destruction: BrickerBot wiped devices so they had to be replaced.

The first thing to know about any device in your fleet is whether it has a public IP address. A device without one is invisible to internet-wide scans. Telnyx IoT SIM lets you assign public or private IP addresses per SIM, and the Private Wireless Gateway and IoT VPN keep device traffic off the public internet

Keep your devices off scan lists

Devices on Telnyx IoT SIMs can get a private IP from day one, so an internet-wide scan never finds them.

Get IoT SIMs

How are attackers hacking IoT devices?

Hacking IoT devices follows a four-step sequence, and every step depends on a condition you can remove.

Step 1: find devices with exposed services and default logins

Attackers scan the internet for devices answering on Telnet, SSH, HTTP admin pages, and vendor cloud ports, then try lists of default credentials. The industry ranks this failure first: item one on the OWASP IoT Top 10 is "Weak, Guessable, or Hardcoded Passwords."

This needs a public IP and a factory password. A device on a private IP with unique credentials gives the scan nothing to find.

Step 2: pull the firmware and find the IoT exploit

An attacker downloads your firmware from the vendor's site or dumps it from flash memory, then searches it for hardcoded secrets. On the board, UART and JTAG debug ports left enabled open a console into the operating system.

The IoT exploit that matters most here is an unsigned update path. A device that accepts an unsigned update will run whatever it is handed. Signed over-the-air updates, plus debug ports disabled before shipping, remove this step.

Your build pipeline counts too. Unpinned installs were the exposure when malicious Telnyx Python SDK versions briefly reached PyPI, as our supply chain security notice explains. Pin every package.

Step 3: intercept device traffic on Wi-Fi, Bluetooth and MQTT

IoT security hacks here target the link to your backend. Traffic is readable or writable when:

• Open or WPA-weak Wi-Fi: no usable encryption on the link.
• Bluetooth Low Energy pairing with no authentication: any nearby phone can bond.
• An MQTT broker with no TLS or no credentials: every message is readable and writable.
• A cloud connection without certificate checks: a man-in-the-middle can impersonate your server.

TLS everywhere, authenticated MQTT, and certificate checks on the device make each condition false.

Step 4: pivot into the network or enlist the device

Once inside, the attacker takes one of two paths. Lateral movement uses the device as a doorway to the network behind it. Botnet enrollment turns it into a node that takes orders from a command-and-control server.

Newer peer-to-peer botnets have no central server to take down. Both paths need flat network access and outbound reach. Segmentation removes the first, and a per-SIM data limit caps the second.

What risk is posed by IoT devices once one is hacked?

A hacked device is a network foothold, a botnet node, a data leak, and on a cellular plan a running cost, all at once.

Botnets, DDoS and permanent bricking

The most visible risk posed by IoT devices is that yours become the weapon. A hijacked fleet sends distributed denial-of-service (DDoS) traffic at someone else. Permanent denial of service, which BrickerBot made famous, wipes a device so it has to be physically replaced with a truck roll. Plan for four outcomes:

• DDoS from your devices at a third party
• Blocklisted IP ranges
• Ransom during downtime
• Bricked hardware

Data theft and the consequences of poor privacy practices

Your devices see video, location, health readings, and payment data. The potential consequences of poor privacy practices in IoT devices arrive in order: a regulator opens a case, a fine or settlement follows, then customers leave or a recall begins. The FTC's 2013 settlement with TRENDnet, over camera feeds exposed online, set that pattern. Patient data raises the stakes, which is why healthcare solutions start at the connectivity layer.

Why a hacked device shows up on your data bill first

On a cellular fleet, the first sign of a hijacked device is usually data consumption. A botnet node or an exfiltrating device moves traffic it never used to move. Telnyx bills US Zone 1 data in five tiers: $0.0780 per MB up to 100MB, $0.0390 per MB to 500MB, $0.0195 per MB to 2GB, $0.0150 per MB to 5GB, and $0.0125 per MB above 5GB.

A tracker that normally sends 20MB a month sits low on that ladder. A hijacked unit moving 5GB is moving 250 times its normal volume, which makes it both a cost and the clearest signal you will get. The portal and API let you group SIMs and set data limits, so that device is cut off at the cap. It is not the only signal of compromise, but it is often the first.

Which IoT hacking incidents matter most?

Three IoT hacking incidents explain most of what came after.

Mirai and the Dyn outage: default passwords at internet scale

In October 2016, the Mirai botnet hijacked cameras and DVRs by scanning for Telnet and logging in with default usernames and passwords. It then flooded DNS provider Dyn and knocked major websites offline, as the CISA Mirai alert describes.

The failure was public IP addresses plus factory credentials.

The lesson: Mirai's scanner could only find devices with public addresses.

Jeep Cherokee: one infotainment flaw, 1.4 million recalled vehicles

In 2015, researchers Charlie Miller and Chris Valasek took remote control of a Jeep Cherokee through its cellular-connected Uconnect infotainment unit. Fiat Chrysler recalled about 1.4 million US vehicles to patch the software, and the carrier blocked the exposed port.

The failure was a head unit reachable over the cellular network with nothing separating it from steering and brakes.

The lesson for any fleet of telematics devices: a patch fixed this flaw, but segmentation between the connectivity unit and the control bus contains the next one. In logistics and transportation, the connectivity layer is part of the product.

BrickerBot: when the goal is to destroy the device

In 2017, BrickerBot brute-forced Telnet logins on BusyBox devices and overwrote their storage. Its author claimed more than 2 million devices bricked, a figure researchers could not verify.

The failure was the one Mirai used: exposed Telnet and default credentials.

The lesson: a hijacked device is not always recoverable, so you need to spot misbehavior before it spreads.

The other well-known incidents fit the same pattern:

Seven IoT incidents and the control that would have stopped each

Across all seven, four failures repeat: public reachability, default credentials, no signed updates, and no segmentation. For medical devices, secure healthcare communications start with authenticated transport.

How to protect IoT devices from hackers at fleet scale

On Telnyx, you can take a cellular fleet off the public internet, update it over the air, cap each SIM's data, and watch usage for anomalies from one portal and API, at published prices. Here is how to protect IoT devices from hackers in five steps.

Which fix does my IoT fleet need first?

• Devices answer on a public IP today: move each Telnyx IoT SIM to a private IP. Scans like the ones Mirai used to find cameras and DVRs never see it.
• Backend traffic crosses the open internet: route it through a Telnyx Private Wireless Gateway or IoT VPN. Intercepted traffic is one of the attacker's steps, and this removes it.
• Units ship with a shared default password: set a unique credential per unit before shipping. Default logins let Mirai and BrickerBot in without any exploit at all.
• Firmware updates go out unsigned: sign every OTA image and reject anything unsigned. One flaw in shared firmware can open millions of identical units.
• Nobody looks at device traffic for years: set per-SIM data limits and alerts on Telnyx IoT SIM. A sudden jump in data use is how a botnet node shows itself.

Keep devices off the public internet

Assign each SIM a private IP and route its traffic through the Private Wireless Gateway or the IoT VPN. The Private Wireless Gateway costs $100 per gateway per month, with $0 per attached SIM up to 100 SIMs and $0.60 per SIM from 101 to 1,000. The docs on public and private IPs cover the setup.

A private IP removes Step 1 of the attack entirely. If a device only sends data to your backend, the gateway is all it needs. If your backend must reach the device, use the IoT VPN. Use a public IP only when a third party must connect, with every admin port closed.

Sign firmware and ship it over the air

Sign every firmware image and reject anything unsigned, which removes the Step 2 implant. On the SIM side, Telnyx eUICC technology switches SIM profiles over the air with no physical access and is GSMA SGP.02 and SGP.22 compliant. See the guide to OTA updates, and consider embedded MFF2 chips, which are soldered in and hard to pull from a device.

Set data limits and alert on unusual usage

Group SIMs by product line and set one data limit per group in the portal or API. The monitor-iot-data-usage-python example is a Flask app that pulls per-SIM usage from the Telnyx IoT API and flags any SIM that crosses a threshold you set. Run it on a schedule, set the threshold just above each model's normal monthly volume, and suspend the SIM when it fires.

This function from the app reads a SIM's usage and raises the flag:

Our guide to monitoring IoT traffic covers patterns beyond volume.

Suspend, replace and retire SIMs you no longer trust

Disable a SIM the moment its device misbehaves, inspect the unit, and replace the profile over the air once it is clean. Retire SIMs from decommissioned devices too, because a forgotten unit with an active SIM is an unwatched way in. The SIM lifecycle doc covers each state, and bulk SIM actions apply a change across many SIMs at once.

Private Wireless Gateway

$100 per gateway per month. Keeps device traffic off the public internet. See IoT pricing

IoT VPN

A private route from your devices to your VPC.

Per-SIM data limits

Set in the portal or API and applied by SIM group.

OTA and eUICC

GSMA SGP.02 and SGP.22. Switch profiles with no site visit.

Which standards and laws now apply to your devices

Five frameworks now set the baseline:

• NIST's Cybersecurity for IoT Program defines baseline device capabilities for US manufacturers and federal buyers.
• ETSI EN 303 645 is the European baseline for consumer IoT security.
• The UK's Product Security and Telecommunications Infrastructure (PSTI) regime has banned universal default passwords on consumer connectable products since April 2024.
• The EU Cyber Resilience Act has required manufacturers to report actively exploited vulnerabilities since September 11, 2026, with full requirements from December 11, 2027.
• The US Cyber Trust Mark is a voluntary FCC label for consumer IoT products, now administered by the ioXt Alliance.

For a single home device, the FAQ below covers the basics. For a fleet, these five steps tell you which devices are reachable, and you hear about it as soon as one starts behaving like a botnet node.

IoT hacking FAQ

Can IoT devices be hacked?

Yes. Any networked device can be hacked, and IoT devices are easier targets than laptops because they have little memory for security software, often ship with default passwords, and rarely get patched.

How do IoT devices get hacked?

Most attacks start with an internet-wide scan for devices answering on Telnet, SSH, or a web admin page, then a login attempt with default credentials. From there, attackers replace firmware, intercept unencrypted traffic, or use the device to reach your network or join a botnet.

What makes IoT devices vulnerable?

Limited compute leaves no room for endpoint protection, a mix of radios and protocols has no single security standard, shared components spread one flaw across millions of units, and nobody monitors the device after installation.

What are the top IoT vulnerabilities?

The OWASP IoT Top 10 ranks weak, guessable, or hardcoded passwords first, followed by insecure network services, insecure ecosystem interfaces, and the lack of a secure update mechanism.

How do IoT device vulnerabilities affect users?

Users lose privacy when camera, location, or health data leaks, lose service when a device is bricked or held for ransom, and lose money when a hijacked cellular device runs up data charges. At home, changing default passwords and turning on automatic updates closes the most common gaps.