CLS Blue Sky Blog

Arnold & Porter Discusses New California Law on Security for Internet-Connected Devices

California has passed the first state law imposing security requirements on devices in the Internet of Things (IoT). On September 28, 2018, California Governor Jerry Brown signed into law the nearly identical Senate Bill 327 and Assembly Bill 1906,[1] which require manufacturers of Internet-connected devices that are sold or offered for sale in California to equip them with “reasonable security features.”[2] Manufacturers of IoT devices are now on the clock to make the necessary changes to comply with the law before it becomes effective on January 1, 2020. While the law does provide some specific guidance for manufacturers—including new rules regarding default passwords and user authentication—it also imposes open-ended requirements that will require manufacturers to grapple with its interpretation when designing product security features.

What Products Does the Law Cover and to Whom Does It Apply?

The new law covers “connected devices,” which it defines as any device or “other physical object” that is “capable of connecting to the Internet, directly or indirectly, and that is assigned an Internet Protocol (IP) address or Bluetooth address.”[3] As such the law is broad in scope, and appears likely to cover practically any conceivable IoT product, including computers, tablets, smartphones, smart watches, thermostats, cars, televisions, security cameras, toys, digital storage devices, kitchen appliances (such as refrigerators), and more. If such a device is capable of connecting to the Internet via an IP or Bluetooth address, it will probably be subject to the law, although the statute leaves open the possibility that certain devices that are never actually assigned IP or Bluetooth addresses may be excluded in some circumstances.

What’s not a “connected device”? The term is defined as a device or physical object, which, on its face, would seemingly exclude software or applications that are not distributed as part of a device. The law further specifically excludes “unaffiliated third-party software or applications that a user chooses to add to a connected device.”[4]

It is also notable that the law applies only to “manufacturers,” which the law defines as businesses (and other legal “persons”) that manufacture products that are sold or offered for sale in California, or contract with another business to manufacture such products on their behalf.[5] By contrast, the law excludes a business that contracts with another business “only to purchase and brand a connected device.”[6] Thus, if a business purchases a white-label device from a manufacturer and re-brands it, it may not be subject to the law, although answering that question may require a close examination of the nature of the purchasing relationship.

What Reasonable Security Features Are Required?

The core requirement of the new law is that manufacturers of “connected devices” must equip each device with a “reasonable security feature or features.”[7] A reasonable security feature is broadly defined as one that is:

  1. Appropriate to the nature and function of the device,
  2. Appropriate to the information it may collect, contain or transmit, and
  3. Designed to protect the device and any information contained therein from unauthorized access, destruction, use, modification, or disclosure.[8]

The law goes on to describe two specific approaches that are a starting point from which manufacturers may work toward meeting this “reasonable security feature” requirement. The title states that if a connected device is equipped with a means for authentication outside a local area network, it “shall be deemed a reasonable security feature” if either of two requirements is met:

  1. The connected device is equipped with a preprogrammed password unique to each device manufactured.[9]
  2. The device contains a security feature that requires a user to generate a new means of authentication before access is granted to the device for the first time.[10]

The law does not specify particular methods of preprogramming passwords or generating means of authentication, nor does it specify robustness, such as minimum complexity requirements, for passwords.

While the exact requirements are not clear under the statutory language, this section appears to require manufacturers to meet the three broad standards defining a “reasonable security feature” generally. If a manufacturer implements either of the listed two specific requirements regarding preprogrammed passwords and authentication, that may be sufficient in some cases to demonstrate that the device has “reasonable security features.” That said, compliance with either of the two requirements does not, in of itself, necessarily mean that a manufacturer has met the three broader standards under the first part of the “reasonable security features” requirement, and they should not be viewed as a “safe harbor.”

For example, if the preprogrammed unique passwords provided by a manufacturer under the first approach are inappropriate to the nature and function of the device or the type of information the device may collect, or otherwise not reasonably designed to protect the device and any information it contains, then that manufacturer might still fail to meet the standards of a “reasonable security feature.” To illustrate one possible scenario, consider a manufacturer of a smart coffee makers that are designed to have access to credit card information for purchasing refill coffee pods. If the manufacturer assigned each device a “unique” preprogrammed password but the passwords were too obvious and predictable (e.g., “password” or “house”), the manufacturer might not be deemed to have included reasonable security features.

Retroactivity and Exemptions

The title goes into effect on January 1, 2020,[11] but its retroactive scope is unclear. While there can be no doubt that the law applies to devices that are manufactured on or after the effective date, it does not specify whether it applies to devices that have been manufactured and are already in inventory or in the distribution chain as of that date. However, nothing in the law suggests that it would go so far as to require devices that have already been sold to consumers as of the effective date to be recalled.

The law contains two limited exemptions to its broad application, applying to federally regulated devices and devices related to health care. First, the title has an exemption for connected devices “the functionality of which is subject to security requirements under federal law, regulations, or guidance promulgated by a federal agency pursuant to its regulatory enforcement authority.”[12] Second, the title also has an even more specific exemption for a “covered entity, provider of health care, business associate, health care service plan, contractor, employer, or any other person subject to the federal Health Insurance Portability and Accountability Act of 1996 (HIPAA) . . . or the Confidentiality of Medical Information Act” that is not “subject to this title with respect to any activity regulated by those acts.”[13] While the federal exemption seems to exempt all devices that have their own security requirements promulgated by a federal agency, the health/medical exemption indicates certain types of entities are exempt from these requirements insofar as their activities are regulated by the enumerated Acts.

Implications and Questions Going Forward

As the first state bill expressly regulating and imposing specific requirements relating to IoT devices, the only certainty when it comes to its enforcement is its uncertainty. Additionally, the law does not create a private right of action for consumers and further exclusively limits the right to enforce it to the “Attorney General, a city attorney, a county counsel, or a district attorney,” so it remains to be seen how the government will seek to enforce the law. Manufacturers may be left to develop their own practices to comply with the law without the benefit of regulatory interpretation or guidance.

Also uncertain is the interplay between this bill and existing California laws already providing similar or related security protections for its citizens. For example, California already requires that businesses employ ‘‘reasonable security procedures and practices” to protect the personal information of California residents that the businesses own, license or maintain from “unauthorized access, destruction, use, modification, or disclosure.”[14] Additionally, the recent California Consumer Privacy Act (see our October 3, 2018 Advisory detailing the CCPA) provides for a private right of action in connection with the unauthorized access and exfiltration, theft, or disclosure of a consumer’s nonencrypted or nonredacted personal information that results from a business’s failure to implement reasonable security procedures and practices to safeguard that data.[15] This new law may intersect with, and in some ways piggy-back off. these other laws, and manufacturers should consider how their compliance efforts may also overlap.

ENDNOTES

[1] See Senate Bill 327 and Assembly Bill 1906. These bills will be codified at Title 1.81.26 of Part 4 of Division 3 of the California Civil Code.

[2] See 1798.91.05(b); 1798.91.04(a).

[3] 1798.91.05(b).

[4] 1798.91.06(a).

[5] 1798.91.05(c).

[6] Id.

[7] 1798.91.04(a).

[8] 1798.91.04(a). “[U]nauthorized access, destruction, use, modification, or disclosure” is defined as actions that are “not authorized by the consumer.” 1798.91.05(e). “Consumer” is not defined in the title.

[9] 1798.91.04(b)(1).

[10] 1798.91.04(b)(2). The bill defines authentication as “a method of verifying the authority of a user, process, or device to access resources in an information system.”

[11] 1798.91.06(i).

[12] 1798.91.06(d).

[13] 1798.91.06(h).

[14] 1798.81.5(b).

[15] 1798.150(a).

This post comes to us from Arnold & Porter Kaye Scholer LLP. It is based on the firm’s memorandum, “California Governor Signs into Law Bill Requiring Internet-Connected Devices to Have Reasonable Security Features,” dated October 4, 2018, and available here

Exit mobile version