Internet of Things Part II: Security Concerns

With our ever-increasing dependence on technological devices and various sensors that help us park our cars and track our fitness levels, it comes as no surprise that these large collections of electronically stored data could pose a security risk. The Internet of Things, otherwise known as the “IoT”, describes the transmission of data through the Internet, without any human input. Part I of this series looked at what the IoT is and the privacy concerns associated with this mass collection of data. As individuals, we may be most concerned about our own privacy, but the companies that produce these devices are concerned with their systems’ overall security.

For many devices used today, a certain amount of personal information needs to be provided for the device or application to function properly. For example, to get more accurate information from fitness trackers, the user often needs to provide details about their height, weight, gender, activity level, and so forth. We’ve already addressed the possible privacy concerns associated with providing this information – selling data to third parties, data falling into the wrong hands, etc. The security concerns focus on who can gain access to this information, and what can we do to prevent it.

In an article by CMS Wire they reported that 80 percent of these devices failed to require adequate passwords, often resulting in users having no or very weak passwords. The same study reported that 70 percent of devices used unencrypted networks for transferring the data. This means that data is being transferred without any form of protection that would keep it from being picked up by the average computer hacker. Other security concerns the study found included the need for improved user interfaces that weren’t so easy to be hacked and the use of encryption when users download updates for their devices. Without this encryption, hackers can gain access to the user’s profile while an update is being downloaded and installed.

The positive side of this is that with all of these security concerns being raised and brought to the forefront, many companies are taking action now to make changes and protect their users’ private information moving forward. In addition to steps being taken by companies producing these devices, a not-for-profit organization has been established known as the Internet of Things Security Foundation (IoTSF). The IoTSF works to raise awareness and provides resources to companies to help them discover the vulnerabilities and flaws in their devices and correct them.

For more information regarding the IoT and the security concerns stemming from the open flow of data among these devices contact Revision Legal’s Internet attorneys through the contact form or call 855-473-8474.

Image credit to Flickr user reynermedia

The Legal Framework Governing IoT Security

The security vulnerabilities inherent in most IoT devices are not just a technology problem — they are an increasingly well-defined legal liability. In the United States, IoT security obligations arise from multiple overlapping sources: FTC enforcement authority under 15 U.S.C. § 45 (the prohibition on unfair or deceptive trade practices), state-specific IoT security statutes, sector-specific federal regulations, and common law negligence. Understanding which regime applies to a given device or deployment is the first step in managing security-related legal risk.

The FTC’s enforcement record makes clear that inadequate IoT security is an “unfair” practice when the risk of harm is substantial, consumers cannot reasonably avoid the harm, and the countervailing benefit of lax security is low or nonexistent. Landmark cases against ASUS (2016), D-Link (2017), and Ring (2023) established that the FTC will pursue both hardware manufacturers and cloud service providers for IoT security failures. The FTC has secured 20-year consent orders requiring biennial security audits as a baseline remedy.

California and Oregon IoT Security Laws

California’s SB-327, codified at Cal. Civ. Code §§ 1798.91.04–1798.91.06, was the first state IoT security statute in the United States, effective January 1, 2020. It requires manufacturers of connected devices sold in California to equip each device with “reasonable security features” appropriate to the nature of the device and the information it may collect. The law specifically requires that if a device uses a default password, it must either: (a) be a unique password for each device manufactured; or (b) require the user to generate a new authentication credential before accessing the device for the first time. This directly addressed one of the most common vulnerabilities documented in the 2015 HP Fortify study cited in the original post — shared default passwords across an entire product line.

Oregon enacted a nearly identical law (ORS § 646A.810 et seq.) in 2020, and several other states have pending legislation in the same mold. Manufacturers selling nationally should assume the California standard represents the floor, because designing to a lower standard creates both regulatory exposure in California and negligence evidence in other jurisdictions.

Sector-Specific Federal IoT Security Requirements

For IoT devices deployed in regulated industries, sector-specific requirements layer on top of FTC authority. The Health Insurance Portability and Accountability Act (HIPAA), 45 C.F.R. Parts 160 and 164, requires covered entities and their business associates to implement technical safeguards to protect electronic protected health information (ePHI). A connected medical device that transmits patient data — a glucometer, a cardiac monitor, a smart infusion pump — is subject to HIPAA’s Security Rule, and inadequate device security is a Security Rule violation. The OCR has assessed multi-million dollar penalties against healthcare entities for failure to secure connected devices.

Financial services companies using IoT devices for fraud detection or customer authentication face obligations under the Gramm-Leach-Bliley Act, the FTC Safeguards Rule (16 C.F.R. Part 314), and applicable banking regulator guidance. The SEC has also issued guidance making clear that inadequate cybersecurity controls — including those involving IoT infrastructure — may constitute a material weakness that must be disclosed in public company filings.

Contractual Security Obligations in IoT Supply Chains

The security vulnerabilities in IoT systems often arise not from the final product’s hardware but from third-party firmware, software modules, or cloud back-ends licensed from component suppliers. This creates layered contractual risk that manufacturers frequently underestimate. A manufacturer that incorporates an insecure third-party firmware component may face FTC or state regulatory action based on the finished product’s overall security posture — and may not have a contractual right to pass that liability through to the firmware supplier unless the supply agreement expressly allocates security responsibilities.

Best practice IoT supply agreements should include: (1) a representation and warranty that the supplier’s component meets specified security standards; (2) an obligation for the supplier to promptly notify the manufacturer of discovered vulnerabilities; (3) an obligation for the supplier to provide patches and updates for a defined support period; and (4) indemnification for losses arising from security failures in the supplied component. Without these provisions, the manufacturer assumes the supplier’s security risk by default.

Building a Defensible IoT Security Program

Companies can substantially reduce their regulatory and litigation exposure by implementing a security-by-design approach at the product development stage rather than attempting to bolt on security measures after product launch. A defensible security program for an IoT manufacturer includes: threat modeling conducted before finalization of hardware specifications; penetration testing by independent researchers before commercial release; a vulnerability disclosure policy that provides a defined channel for external researchers to report findings; a defined patch release timeline with commitment to support specified for the product’s commercial life; and a breach response plan that satisfies applicable state data breach notification laws.

The FTC’s consent orders in ASUS, D-Link, and Ring provide a concrete benchmark. If your security program would pass a 20-year biennial audit conducted against the standard those orders specify, you are substantially de-risked from federal enforcement. If it would not, you have identified your gap.

If your company develops or deploys IoT devices and needs guidance on security compliance, supply chain contract terms, or response to an FTC inquiry, contact Revision Legal’s technology attorneys through the form on this page or call 855-473-8474.