Internet of Things security failures rarely start with a sophisticated exploit. They start with a camera that shipped with the password "admin" still active, a router nobody patched in three years, or a smart thermostat quietly leaking data over an unencrypted connection. By the end of 2025, an estimated 21.1 billion connected devices were online worldwide, and researchers were tracking roughly 820,000 malicious attempts against them every single day. That volume alone should reframe how builders, IT teams, and everyday device owners think about IoT security: not as an edge case, but as the default battlefield.
This piece looks at why IoT devices remain such an easy target, walks through the technical patterns behind the worst recent breaches, and gives concrete steps — including code — for closing the most common gaps.
Why IoT Devices Are Easier to Hack Than Computers
A laptop or phone gets regular software updates, runs endpoint protection, and usually sits behind a user who notices when something looks wrong. Most IoT devices have none of that. They're built to a price point, run stripped-down firmware, and are often installed once and never looked at again.
Routers and network edge devices illustrate the problem well. They account for the majority of IoT-related attacks and carry a disproportionate share of the most severe vulnerabilities, since compromising the device sitting between a network and the internet gives an attacker a foothold over everything behind it. Forescout's 2026 telemetry found that routers and switches now average around 32 vulnerabilities per device, and that these devices account for roughly a third of the most critical vulnerabilities found across enterprise networks.
Weak or unchanged default credentials remain one of the simplest and most common entry points. Manufacturers ship devices with predictable admin logins to make setup easy, and a large share of those credentials are never rotated. Attackers don't need to break anything sophisticated when the front door is already unlocked.
The Botnet Problem: When Your Toaster Joins an Attack
Individually, a compromised smart plug or IP camera isn't very useful to an attacker. Aggregated into the tens of thousands, it becomes a weapon. IoT botnets recruit exactly this kind of low-value, poorly monitored device, then use the combined bandwidth to launch distributed denial-of-service (DDoS) attacks against much bigger targets.
The scale here has grown sharply. Malicious IoT botnet activity increased roughly fivefold over the past year, with the population of compromised devices climbing from around 200,000 to close to a million, and these botnets now account for more than 40% of observed DDoS traffic. The Aisuru botnet, built substantially from hijacked IoT devices, was tied to a record-setting 29.9 Tbps DDoS attack in late 2025. The BadBox 2.0 botnet separately compromised more than 10 million consumer devices globally through a supply-chain infection baked into firmware before the products even reached buyers.
These numbers matter because they show the shift in the threat model. IoT security isn't only about protecting the device owner's data anymore — a poorly secured smart speaker in a home network can become a small contributor to an attack on infrastructure the owner has never heard of.
Encryption Gaps Are Still Widespread
A large share of IoT traffic still moves without encryption. Palo Alto Networks has reported that around 98% of IoT device traffic is unencrypted, meaning sensor readings, credentials, and command data often travel in plaintext across the network. Combined with tens of billions of active devices, that translates to a huge population of endpoints where a basic packet capture on the local network is enough to expose meaningful data.
This is a solvable problem at the protocol level, and it's where developers building IoT firmware or backend services have the most direct leverage. The following example shows a minimal but realistic pattern for authenticating an MQTT-connected device and encrypting its traffic with TLS, rather than trusting an open, unauthenticated broker connection — a configuration that's still common in production IoT deployments.
import ssl
import paho.mqtt.client as mqtt
BROKER_HOST = "broker.example.com"
BROKER_PORT = 8883 # TLS port, not the unencrypted 1883
DEVICE_ID = "sensor-department-04"
DEVICE_TOKEN = "REPLACE_WITH_SECRET_FROM_ENV"
def on_connect(client, userdata, flags, reason_code, properties=None):
if reason_code == 0:
print(f"{DEVICE_ID} connected securely")
client.subscribe(f"devices/{DEVICE_ID}/commands")
else:
print(f"Connection failed with code {reason_code}")
client = mqtt.Client(client_id=DEVICE_ID, protocol=mqtt.MQTTv5)
client.username_pw_set(DEVICE_ID, DEVICE_TOKEN)
# Enforce TLS instead of allowing a fallback to plaintext
client.tls_set(cert_reqs=ssl.CERT_REQUIRED, tls_version=ssl.PROTOCOL_TLS_CLIENT)
client.tls_insecure_set(False)
client.on_connect = on_connect
client.connect(BROKER_HOST, BROKER_PORT, keepalive=60)
client.loop_forever()
Three details in that snippet do most of the security work: the connection uses port 8883 with tls_set() enforced rather than the plaintext 1883 default, cert_reqs requires a valid certificate instead of accepting any endpoint, and the device authenticates with a per-device token rather than a shared password baked into every unit on the production line. None of this is exotic. It's the difference between a device that's defensible and one that isn't.
Firmware: The Update Problem Nobody Wants to Own
Unlike a phone or laptop, most IoT devices don't have a clear, user-facing update mechanism. Some can't be patched at all after deployment. Others technically support updates, but the process is manual enough that it rarely happens in practice. That gap is a major reason vulnerabilities discovered years ago are still being actively exploited today — CISA's Known Exploited Vulnerabilities catalog has recorded cases where nearly half of newly added entries were vulnerabilities disclosed well before the reporting period, meaning attackers are often exploiting flaws that were already public knowledge.
For teams building connected products, the fix isn't just "ship updates" — it's designing for updates from the start. A device that can verify and apply a signed firmware image over the air is fundamentally more defensible than one that requires physical access or manual flashing. Below is a simplified example of a firmware update handler that checks a cryptographic signature before applying an update, which prevents an attacker from pushing malicious firmware even if they can intercept the update channel.
import hashlib
import hmac
def verify_firmware(firmware_bytes: bytes, signature: str, shared_secret: bytes) -> bool:
"""Verify firmware integrity before flashing using HMAC-SHA256."""
expected_signature = hmac.new(
shared_secret,
firmware_bytes,
hashlib.sha256
).hexdigest()
return hmac.compare_digest(expected_signature, signature)
def apply_update(firmware_bytes: bytes, signature: str, shared_secret: bytes):
if not verify_firmware(firmware_bytes, signature, shared_secret):
raise ValueError("Firmware signature mismatch — update rejected")
# Only reached if the signature check passes
write_to_flash_partition(firmware_bytes)
print("Firmware verified and applied")
The key line is hmac.compare_digest() rather than a plain == comparison — a constant-time comparison prevents timing attacks that could otherwise let an attacker infer the correct signature byte by byte. This kind of detail is easy to skip under deadline pressure, and it's exactly the kind of gap that separates a device that resists tampering from one that doesn't.
Regulation Is Catching Up, Slowly
Governments are starting to close the gap between how fast IoT devices ship and how weak their security baseline has been. The EU's Cyber Resilience Act introduces reporting obligations that take effect in September 2026, requiring manufacturers to report actively exploited vulnerabilities in connected products within a set window after discovery. In the US, the Cyber Trust Mark gives consumers a way to identify products that meet a baseline security standard before they buy.
These frameworks won't fix the installed base of billions of already-deployed devices, but they change the incentive structure for new products. A manufacturer that has to disclose exploited vulnerabilities on a deadline has a much stronger reason to build patchable firmware and secure defaults from day one, rather than treating security as a cost center to minimize.
What Actually Reduces Risk
For organizations managing IoT fleets, the highest-leverage moves are unglamorous. Replacing default credentials before a device goes into production, segmenting IoT traffic onto its own network rather than letting it share a subnet with sensitive systems, and enforcing encrypted connections at the protocol level closes the majority of the attack paths described above. Asset visibility matters just as much — a device that isn't in your inventory can't be patched, monitored, or removed when it's compromised, and unmanaged or forgotten devices are a recurring theme in the incidents researchers have documented over the past year.
For individual device owners, the same logic applies at a smaller scale. Change the default password immediately, keep firmware updated when the manufacturer supports it, and put smart home devices on a separate guest network rather than the same one used for laptops and phones handling sensitive accounts. A compromised smart bulb is a nuisance. A compromised smart bulb sharing a network with your banking session is a much bigger problem.
The Internet of Things isn't going to get less connected. Every year adds more sensors, more cameras, and more devices that quietly assume nobody is watching them closely. The organizations and developers who build in authentication, encryption, and patchability from the start are the ones whose devices stay out of the next botnet headline — and that's a far cheaper investment than cleaning up after one.
Top comments (0)