Product Liability in the Internet of Things
When California enacted SB 327 last year, it became the first state to regulate Internet of Things (IoT) devices, which refer to physical devices that are connected to the internet. Beginning next January, the new law will require manufacturers of IoT devices sold in California to implement reasonable security features that protect the software, data, and information contained within them. While the law regulates only the minimum security standards for IoT devices, its definition of a “connected device” (i.e., an IoT device) may impact product liability claims because “connected devices” are physical objects and not technology. SB 327’s definition suggests that manufacturers of the software in IoT devices may not be held strictly liable for software defects, because the law aligns with and reinforces the view of most courts that software is not a product, but a service.
A broad concept, the IoT comprises billions of devices worldwide. It includes everything from cell phones and tablets to smart speakers that respond to voice commands, smart refrigerators that help keep track of the food inside them, and even smart collars that track a dog’s fitness levels. There are wearable health monitors that send a patient’s real-time medical information directly to a health care professional, and smart pills that help keep track of the time when a patient last took one. If a product can be connected to the internet, it can become an IoT device.
Among other things, SB 327 requires manufacturers of “connected devices” to equip them with “reasonable security features.” The law defines a “connected device” to include only “physical objects,” which is significant because IoT devices combine a physical object with technology that changes the nature of the device. For example, a regular lamp is not part of the IoT. But when a manufacturer installs technology that connects the lamp to the internet and allows it to be turned on or off or dimmed by a tablet or smart phone, then the lamp becomes an IoT device. As written, SB 327 may exclude manufacturers of the intangible technology – such as software – from its requirements.
Combining a physical object and an intangible technology also creates a novel issue when it comes to strict product liability principles, which typically hold that a product manufacturer may be strictly liable for a product’s defect. The first task in a strict product liability case is to identify the product. In the context of a device that has no internet connectivity, the answer is straightforward. If a ladder is defective and causes an injury, the ladder’s manufacturer may be held strictly liable because a ladder is the product. But when it comes to IoT devices, the line may be blurred. Almost always, the software part of the IoT device is “manufactured” by a separate entity from the entity that manufactures the physical object. If the IoT device proves to be defective, the question becomes which entity may be held strictly liable.
A real-world example illustrates the issue. Medical professionals today are beginning to use implantable cardiac devices that transmit data directly from the device to the health care provider, which allow the medical professional to directly monitor the patient and device (For more information on these medical devices and other issues that surround them, see our previous blog post here). The benefits of this technology are obvious. It allows for real-time observation by medical professionals, which makes patients safer and reduces the need for long visits to the doctor’s office. But internet-based monitoring also may come with some risks that the statute attempts to address. For example, as the device is connected to the internet, it may be vulnerable to unauthorized access. Additionally, a software defect could potentially misread data, corrupt information, or even cause the device to malfunction.
If the defect is in the physical object of the device, then the entity that manufactured the device may risk being held strictly liable. But if the defect is in the software, the answer is less apparent because courts have not clearly indicated whether software is a product for purposes of strict product liability. Most observers expect courts to treat software in IoT devices as a service rather than a product, because for UCC purposes courts typically treat custom-made software (like that in IoT devices) as a service rather than a good. SB 327 aligns with this view and provides additional fuel for the argument that software is not a product.
The California Legislature may have placed the burden on an IoT device’s physical manufacturer to ensure safety when it comes to data stored inside the device. But physical device manufacturers may yet argue that the software was a component product when it comes to strict liability issues. Time will tell how courts will address that argument.