California’s IoT Security Law – Everyone Needs Cybersecurity Now

In September of this year, with SB 327, California stepped into the vanguard of information age law by passing a cybersecurity regulation on the Internet of Things. SB 327 has added new sections to Cal. Civil Code §1798. Specifically, §1798.91 et seq. While this seems to be a good thing, the larger question is what does it do, and how far does it reach?

What does it Do?

In a nutshell, the law requires the manufacturer of a “connected device” to 1) equip it with reasonable security feature(s) appropriate to a) the nature and function of the device; b) the information it may collect, contain, or transmit; and 2) ensure those security features are designed to protect the device and any information within from unauthorized access, destruction, use, modification, or disclosure.

Recognizing the inherent ambiguity “reasonable security feature(s)” may cause, fortunately the drafters of the law provided some clarification: If the device is subject to authentication outside a local area network, should it contain either a unique pre-programmed password; or the device requires a user to generate a new means of authentication prior to initial access being granted; then such security feature is reasonable.

Note that this is a “reasonableness test” just for the authentication aspect of the device. The rest of the requirements in Cal. Civil Code §1798.91.04(a) will still mandate reasonable security beyond just the authentication aspects of the device.

How Far does it Reach?

“Connected device” is defined quite broadly. Under the definition, all the IoT devices we have discussed in previous posts should be covered by the law. Additionally, the law makes it apparent that manufacturers are the primary party subject to the requirements. Additionally, it applies to manufacturers located anywhere, even outside of California, if they sell or offer devices for sale in California.

Why does this Matter?

This law will have far reaching effects because the world we live in is a connected world. The Internet of Things is technology that increasingly influences everyone’s life and any business that manufactures devices are increasingly making those devices “connected”.

Until now, no such cybersecurity law existed. The legal landscape for around when OEMs had to incorporate cybersecurity was a veritable wild west. Adoption of this measure now mandates security measures be “baked” into the device before human user intervention. “Reasonable security” is now “table stakes” for anyone selling a smart device in California – which is nearly everyone.

Of course, there is much debate about what “reasonable security” might be. Under SB 327 there is some guidance, but it is still limited. Section 1798.91.04 does provide a floor for authentication requirements with the mandate that either a unique preprogrammed password will be provided OR the user won’t be able to use the device until the password is changed. However, there is still some question as to what the rest of the requirements will need to be to “protect the device and any information within from unauthorized access, destruction, use, modification, or disclosure.” Still, California has taken the vanguard position in regulating IoT devices specifically. The Federal government and other states have not looked at this question from a “connected device” perspective. Most other laws imposing cybersecurity requirements talk about a “system”, which can include devices, but can also include other controls (e.g. network security, physical security, etc.).

So is this a problem?

Just a few observations to keep in mind:

First, this is a California state specific law. There is no federal law on this issue. This can create preemption and constitutionality questions – adding to the uncertainty of compliance.

Second, “reasonable security” outside the authentication protocols of the device are still ambiguous. This leaves businesses with looking at standards like NIST guidelines, which can be overwhelming, or taking the risk they their security is deemed inadequate “after the fact”.

Third, SB 327 expressly carves out third-party software from being subject to this title. However, the interconnectivity of such third-party software may well be the source of a security breach – the NIST guidelines recognize this. As such, is it reasonable security to not consider how a device interacts with third-party software? This approach seems to fail to consider how devices (and software) are built today.

Fortunately, SB 327 does not include a private right of action – so the plaintiff’s bar will be limited in what they can do. Unfortunately, city and county attorney’s do have authority to enforce the law. This means that an activist city attorney may well force a device manufacturer into court.

In any event, SB 327 can be seen as the beginning of a trend which sees OEMs responsibilities expand beyond merely making sure their devices are safe, but also making sure the software inside the device is safe.