Researchers at Black Hat Europe just showed how attackers can compromise IoT devices en masse - no software vulnerability required, no IP address needed, works even on internal networks behind firewalls.

The attack vector? Exploiting the trust relationship between devices and cloud management platforms.

Thanks for reading Tim’s Substack! Subscribe for free to receive new posts and support my work.

The root cause? Devices authenticating with nothing more than serial numbers and MAC addresses.

Predictable. Brute-forceable. Inexcusable in 2025.


Source: Dark Reading coverage of the research

Here’s What Makes This Frustrating

This isn’t a hard problem. The major cloud platforms solved it years ago.

Azure IoT Hub? X.509 certificates are the recommended method for authenticating device identity. They also support symmetric keys and TPM attestation. Microsoft is explicit: X.509 is the most secure authentication type supported in Azure IoT.

AWS IoT Core? Same story. Devices use X.509 certificates with TLS mutual authentication. The platform associates a public key with an identity through proper PKI infrastructure.

You know what neither platform accepts? Serial numbers. MAC addresses. “Trust me, I’m device #12345.”

So where’s the vulnerability?

It’s in the proprietary cloud management platforms that device manufacturers build themselves. The cheaper, faster path is to roll your own backend with weak authentication rather than properly integrate with Azure or AWS certificate-based auth.

The tooling exists. The guidance exists. The excuses don’t.

The Post-It Note Problem

Here’s what’s actually happening in millions of deployments right now:

When your device “proves” its identity to a cloud management platform, it’s often using credentials derived from a serial number printed on its label or a MAC address anyone can sniff.

That’s not device identity. That’s a Post-it note taped to the door that says “I live here.”

The researchers’ recommended fix—generate random UUIDs bound to the management app—is better than nothing. But it’s still a workaround for organizations that won’t implement what the industry already standardized: cryptographically-bound device identity using PKI-based attestation.

A certificate isn’t just a credential. It’s a chain of trust that answers three questions serial numbers never can:

  1. Provenance: Was this device manufactured by who it claims?

  2. Integrity: Has this device been tampered with since provisioning?

  3. Lifecycle: Can we rotate, revoke, or renew this identity without physical access?

Three Questions for Your Next Product Review

If you’re a Chief Product Security Officer—or anyone with influence over device architecture decisions—here’s what I’d bring to your next review:

1. How does this device prove it is what it claims to be—not just at provisioning, but throughout its lifecycle?

First boot is the easy part. What happens at year three when your fleet is scattered across customer sites and you need to verify nothing’s been compromised?

2. What happens when (not if) those credentials need to rotate?

Credentials get compromised. Algorithms get deprecated. Crypto ages. If rotating device identity requires a truck roll or a forklift upgrade, you’ve got a ticking time bomb in your architecture.

3. Who in your supply chain has the ability to create a “twin” of your device?

Contract manufacturers. Component suppliers. Logistics partners. Anyone who touches your serial number database. If any of them can spin up a device that your cloud platform will trust, you don’t control your own fleet.

If your team can’t answer all three with specifics, you have a roadmap problem, not a budget problem.

The Questions Nobody Wants to Ask

Here’s where it gets uncomfortable.

When a secure element gets value-engineered out of the BOM to save $0.40 per unit—who’s accountable for modeling the downstream risk?

What’s the actual cost calculation when that decision leads to a fleet-wide compromise?

  • Incident response

  • Customer notification

  • Regulatory scrutiny

  • Brand rehabilitation that takes years, not quarters

Are we treating security trade-offs with the same rigor we apply to financial decisions? Or are we optimizing for metrics that don’t capture the liabilities we’re creating?

When Azure and AWS have made certificate-based authentication the standard path—and in many ways the easier path—why are teams still building bespoke backends with 1990s-era authentication?

These aren’t gotcha questions. They’re the questions that separate organizations building for resilience from those building for next quarter.

The Uncomfortable Truth

This research didn’t reveal a bug. It revealed a choice.

The choice to roll your own cloud backend instead of using platforms that enforce proper authentication. The choice to ship devices with predictable identifiers instead of cryptographic credentials. The choice to optimize for time-to-market over time-to-breach.

The major cloud providers figured this out. The standards bodies figured this out. The security community has been saying this for a decade.

The question isn’t whether we know better. It’s whether we’ll do better.

What’s your organization doing to verify device identity beyond serial numbers? I’m genuinely curious what’s working in the field—reply or leave a comment.

Thanks for reading Tim’s Substack! Subscribe for free to receive new posts and support my work.