Hello readers!

This week, we’re looking at how a fleet of vacuums became a massive security liability, SGP.32, multi-orbit resilience, and more!

A screwdriver and a few minutes at the UART pins are all it takes to strip the client certificate off a Shark RV2320EDUS robot vacuum. That certificate turns out to be a master key. A researcher going by tokay0 published a method this month showing it can run root commands on other people's Shark vacuums in the same AWS region — pulling camera feeds, reading stored floor plans, driving the robot, and lifting Wi-Fi passwords stored in plaintext. Scanning a single AWS region over 24 hours, the researcher found 1.5 million unique Shark devices, with roughly 673,000 of them responding in a way that confirmed they were exploitable. He reported the flaw to SharkNinja in March. Four months and three vague status updates later, SharkNinja finally shipped a patch on July 20. The defect was a device certificate carrying a policy that was never scoped to the device holding it, and that same mistake shows up constantly in fleets far more consequential than robot vacuums.

The vulnerability isn't exotic. No memory corruption, no password guessing. The certificate's AWS IoT policy grants publish-and-subscribe access to any device's topic instead of pinning access to the connecting device itself, so one certificate can address the whole fleet's message bus. AWS actually flags this exact misconfiguration through Device Defender, its own fleet auditing tool, rating an overly permissive policy shape as critical. The failure wasn't a gap in available tooling. It was a provisioning shortcut that a working audit check was sitting there to catch. Secure identity is the foundation everything else in a connected fleet rests on: a unique, unclonable certificate per device, checked against a trusted signer, with access scoped to that device alone. Skip the scoping step at manufacturing time, and every other security layer you build on top inherits the crack.

The underlying architecture here is ordinary, not smart-home-specific. AWS IoT Core, MQTT topics, device shadows, per-thing certificates run industrial sensor networks, fleet telematics, and connected medical devices on the exact same stack. A 2026 device lifecycle survey found that 71% of the market still manages IoT infrastructure through bespoke, in-house tooling or manual processes, and three in five OEMs expect their current device management setup to become inadequate within three years. Provisioning millions of units correctly, at scale, under a launch deadline, is exactly the kind of unglamorous plumbing that gets shortcuts when a team is racing to ship. SharkNinja's fleet is the visible failure. It's a reasonable bet that it isn't the only one running the same policy shape quietly, undetected, on a product line nobody's poked at yet.

A vendor's incident-response process determines how long a known flaw stays exploitable in an environment, and SharkNinja's timeline is a useful data point on how that process holds up under no real pressure to move fast. A fix requiring zero firmware changes, zero supply chain coordination, and a few AWS API calls still took four months to ship. That's the baseline case: the best-case fix, at a company with no shortage of cloud engineering talent, moving at the pace of an organization that didn't treat the problem as urgent until public disclosure forced its hand. Enterprise buyers evaluating any connected-device vendor should assume that pace, not the technically possible one, and diligence accordingly.

None of this requires exotic new tooling on the buyer's side. If you're running device fleets on AWS IoT Core or an equivalent broker, run the equivalent of Device Defender's overly-permissive-policy check against your own fleet this week, not as an annual audit item. Confirm that certificate scoping was actually enforced at provisioning time, not just designed that way on a whiteboard, since the gap between the two is exactly where SharkNinja's flaw lives. And when evaluating a vendor's connected-device security, ask about disclosure timelines and patch cadence as directly as you'd ask about encryption standards — with the EU Cyber Resilience Act's 24-hour exploited-vulnerability reporting clock starting later this year, a vendor's response speed is about to become a contractual and regulatory question, not just a reputational one.

For years, resilience meant redundancy. Enterprises deployed multiple mobile carriers, added roaming agreements, and built failover into their architecture. If one network went down, another would take over.

Read more

Most eCommerce brands running external traffic aren't scaling — they're just spending.

Wrong channels, no real attribution, and at the end of the month, still no clear answer to the only question that matters: what actually moved your BSR?

The brands getting it right aren't necessarily spending more. They've just stopped guessing. They know which channels pull weight on Amazon listings, which ones look good in a dashboard but bleed budget, and why creator traffic consistently outperforms paid social on ROI when it's set up correctly.

Levanta put together a free playbook breaking down 7 proven external traffic strategies. Inside you'll see how top brands are driving millions in off-Amazon revenue and why most channels underdeliver when brands don't know what to look for before they start spending.

If you're serious about growing outside of PPC, this is worth 5 minutes.

Grab the FREE playbook

In this episode of the IoT For All Podcast, Wienke Giezeman, CEO and co-founder of The Things Industries, joins Ryan Chacon to discuss how IoT is finally delivering what it promised ten years ago. The conversation covers what changed technically and commercially, the ROI of IoT, why deployments failed in the early days, criticism of IoT, what companies still get wrong about LoRaWAN, and The Things Conference 2026.

YouTube • Spotify • Apple • YT Music • Amazon

Interested in becoming an IoT For All Partner? Reach out here!