Internet-of-things devices — smart locks, cameras, medical wearables, connected vehicles, industrial sensors — sit at the intersection of physical product liability and cybersecurity negligence, since a security failure in a connected device can cause purely digital harm (data exposure), purely physical harm (a compromised lock or vehicle system), or both at once. Plaintiffs pursuing these claims draw on negligent-cybersecurity and product-defect theories together, arguing the device's connectivity created a foreseeable attack surface the manufacturer had a duty to secure reasonably, whether through the traditional product-liability lens or an ordinary negligence lens.

A recurring, genuinely unresolved complication is the device's post-sale software lifecycle: many IoT products depend on ongoing firmware updates and cloud services to remain secure, and manufacturers frequently stop supporting older devices well before consumers stop using them, raising the same open questions found in the broader duty-to-patch debate but with the added dimension that a security failure here can translate directly into physical-world harm rather than purely data exposure. Multiple parties can be implicated in a single incident — the device manufacturer, a third-party component or chipset supplier, and a cloud-service provider — each potentially bearing a different share of responsibility for the failure.

Juricratic models an IoT security matter with dials for whether the harm was primarily physical or data-based (which shapes which liability theory fits best), how long the device went without security support before the incident, and how the responsibility is likely to be allocated across manufacturer, component supplier, and service-provider defendants.

Plaintiffs map the incident to whichever theory the specific harm fits — product defect if a physical safety failure resulted, negligent-cybersecurity if the harm was primarily data exposure — and investigate the device's support and update history to establish how long a known vulnerability went unaddressed. Manufacturers defending these claims document their security update practices and clearly disclosed end-of-support timelines, and typically look to allocate responsibility among component suppliers and cloud-service providers where the actual point of failure originated outside their own code.