Home » Insights » California and Oregon’s IoT Cybersecurity Law: The 7 Key Points Explained

California and Oregon’s IoT Cybersecurity Law: The 7 Key Points Explained

California and Oregon have led the way with the first IoT cybersecurity laws in the country.  California’s SB-327 and Oregon’s HB 2395 went into effect in January of 2020.  The California legislature was the first to pass their law and it is often referred to as the California password law, California IoT law, or Security of Connected Devices Law.  These laws set requirements, some clear and some unclear, for security features for IoT devices sold in those states, no matter where the device is manufactured.  Oregon’s law is based on California’s law, so they are very similar, but there are a couple of significant exceptions that are explained below.  For IoT device manufacturers, the most critical point to take away from this article is: to sell IoT devices into California, they must have unique passwords or use another authentication approach, such as biometrics, to allow access to only authorized users of an IoT device.  

For easy reference, following are the 7 key points from California and Oregon’s IoT security laws that IoT device manufacturers need to be aware of. 

 California & Oregon’s IoT Cybersecurity Law : The 7 Key Points

  1. The California law is clear: all IoT devices need unique passwords
  2. The requirement for “reasonable security” is not clear because it is not defined 
  3. The California law applies to all IoT devices; Oregon’s law only applies to consumer IoT
  4. Stores, marketplaces, or others selling IoT devices are not liable
  5. The law does not apply if a user installs software from other companies 
  6. The law is not a reason to prevent the user from being able to modify the device
  7. It doesn’t apply over federal laws or to businesses subject to HIPAA

Sign up for BG Networks’ newsletter for updates on new IoT cybersecurity laws and what IoT device manufacturers need to know about them.

For information on Congress’s newly passed bill on IoT cybersecurity view: IoT Cybersecurity Act of 2020: The 9 Key Points Explained 

IoT cybersecurity is hard and it’s goal to solve this problem.  One way we are doing this is with BG Networks consulting services for cyber-secure software development for IoT devices.

 The 7 Key Points Explained In Detail

  1.  The California law is clear: all IoT devices need unique passwords

There are multiple terms used to describe a password that is not easy to guess.  They include: no default passwords, unique passwords, and a means for authentication. Despite the various descriptions, the critical point, and it’s compulsory nature is crystal clear in the California law, is each IoT device needs to have a unique password or an alternative approach to authentication. 

The Oregon law, although very similar to the California law, adds the wording, “may consist of” when referring to the requirement for unique passwords.  This is included in a subsection that addresses “reasonable security” which actually makes the requirement for secure passwords unclear.  For more on this see point #2 below.  

The California law describes a couple of options of how the password requirement can be met.  The first is for the manufacturer to install a unique password into every IoT device made.  The second is for the IoT device to have a feature that requires the user to “generate a means of authentication” before first use.  In other words the user sets their own unique password or uses an alternative approach to passwords such as those supported by the FIDO Alliance.  

One of the main motivations behind the creation of these laws and their focus on good password security, is to prevent botnets from compromising IoT devices.  Botnets are malicious internet-based software that attempts to take over an IoT device by breaking into it, often by using an easy to guess password.  The most famous is the Mirai botnet which by 2016 had taken over thousands of consumer IoT devices and instructed them to simultaneously access the Domain Name Servers (DNS) servers of a company called Dyn (now owned by Oracle).  The result was thousands of IoT devices sending so much data to Dyn’s servers that they could not cope.  A large portion of the internet in the U.S. was disabled by this Distributed Denial of Service (DOS) attack.  For more information on the Mirai botnet see the Krebs On Security article titled “Mirai Botnet Authors Avoid Jail Time” 

Wikipedia has a “List of the Most Common Passwords” . These are the ones used by Botnets to break into IoT devices and is really a list of the worst passwords that could be possibly used.  

  1. The requirement for “reasonable security” is not clear because it is not defined  

Both laws use very similar language calling for “reasonable” security but it is not clear what this means.  They only go as far to define “reasonable” as security that is “appropriate to the nature and function of the device” and protect a device and information it stores “from unauthorized access, destruction, use, modification, or disclosure”.  This definition is so ambiguous that it could include security features ranging from secure boot to secure communications to intrusion detection system (IDS) software.  

A definition for “reasonable security” shows up in the California Data Breach Report from 2016 but this is not a law, a regulation, nor is legal advice.  It is simply a report from the California Attorney General, actually Kamala Harris at the time, providing findings on data breaches from 2012 to 2015 and includes recommendations for cybersecurity.  Besides this document not providing a firm legal basis, another problem is what it describes as a “minimum level for security – a floor”.  It’s not a floor at all but a complete and comprehensive cybersecurity program. The “floor” referenced is “CIS Controls” from the Center for Internet Security.   It is unreasonable to expect IoT devices at this point to have such a comprehensive set of cybersecurity controls.  It will probably be 10 years or more  (i.e. 2030) before IoT cybersecurity matures to the level described in the CIS document.  Finally the cybersecurity controls from CIS are for IT security and not written with IoT devices in mind.  IoT security is very different from IT security because the hardware and software used in IoT is resource constrained versus traditional IT equipment such as laptops.  The benefits that come for the trade off of being resource constrained are much better cost, power and size.  IoT devices can cost as little at $10 and run for years on a couple of AA batteries.      

There are a couple of approaches that BG Networks recommends for consideration to meet the “reasonable” requirement.  They are:

a.   Perform a threat analysis of the IoT device and add security features that close significant vulnerabilities and address the threats that have the most risk.  Multiple methodologies for threat analysis have been used for years and are a well-accepted as a “reasonable” way to determine what sort of security is appropriate.  If you need help with a threat analysis for an IoT device, let us know as BG Networks can help. 

b.   The second approach is to watch what NIST defines as “minimum security requirements” in accordance with the IoT Cybersecurity Act of 2020 .  It could be argued that minimum requirements for federal government use of IoT devices is “reasonable” and would apply to California and Oregon.      

  1. The California law applies to all IoT ; Oregon’s law only applies to consumer IoT

The California law applies to all “connected devices” which are defined as having an ability to connect to the internet and are assigned either an Internet Protocol (IP) or Bluetooth address.  Almost every IoT device has either an IP or Bluetooth address including Wifi, Bluetooth, and cellular devices.  These wireless interfaces will be used for the vast majority of IoT.  A much smaller number of IoT devices will use Low Power Wide Area (LPWA) networks, such as LoRa, NB-IoT, or Sigfox.  Some LPWA standards don’t use IP addressing given power constraints.  So the law may not apply to these devices.  For more information on forecasts for the types of network connections IoT devices will use, see IoT Analytics’ report on “The State of IoT 2020: 12 Billion IoT Connections, Surpassing Non-IoT For the First Time” .

The Oregon law has a different definition for a “connected device” as it is limited to cover personal use.  Devices covered are “used primarily for personal, family or household purposes”.  It adds that the device is assigned an IP address or “another address or number” that identifies it for making “short-range wireless connection”.  This certainly will cover Bluetooth based IoT devices and most likely WiFi devices.   LPWA connections used in applications such as electric meters for homes are probably not covered given they are not short range. 

  1. Stores, marketplaces, or others selling IoT devices are not liable

The language in both the California and Oregon laws is almost exactly the same for this provision.  Specifically called out are electronic stores, gateways or market places.  These businesses are not required to verify or enforce compliance.  In other words, it is up to the IoT device manufacturer to make sure the devices comply with these cybersecurity laws and not the companies that distribute.      

  1. The law does not apply if a user installs software from other companies 

If the user of the IoT devices adds software or applications from another company, then the manufacturer is no longer responsible for the security of that device.  The rationale is that 3rd party software could introduce cybersecurity vulnerabilities that the manufacturer of the IoT device would not have any control over.  The Oregon law goes a little further to say the manufacturer of the IoT device is also not responsible if the user adds software that is not approved by the manufacturer. 

  1. The law is not be a reason to prevent the user from being able to modify the device

The language between the two laws is again very similar in this case.  It says the law should not be used as a reason to prevent the user or consumer from “having full control” or from “modifying the software or firmware” on the device. 

  1. It doesn’t apply over federal laws or entities subject to HIPAA

The language again is very similar for both laws.  It says these laws do not apply when there are federal laws or regulations in place.  It also does not apply to health care or other organizations subject to the “Health Insurance Portability and Accountability Act” (HIPPA).  HIPPA already has a number of regulations with respect to cybersecurity of equipment used for medical purposes.  The California bill also calls out it’s state law on the Confidentiality of Medical Information Act (CMIA) in addition to HIPPA.   

Some have argued that these laws do not do enough but BG Networks believes they are a good first step.  Weaknesses cited include that two-factor authentication was not specified as it would have been more secure.  Or a requirement could have been included for the ability to fix cybersecurity vulnerabilities that are found after the IoT devices were sold.  This would have meant including a secure Over the Air (OTA) software update feature which indeed is a very important part of IoT cyber security.  But requiring those features would have put a difficult burden on IoT manufacturers.  If these features were not already supported, it could take over 2 years in some cases to design-in, test, and bring products to volume production with new security capabilities.  A gradual approach is the right one.  But IoT manufacturers should not wait to get started on adding security features such as OTA software updates and IDS software. Legislation based on existing best practices can come fast and may not give time to start embedded engineering designs from scratch.  

The next move will come from NIST and after that, possibly an IoT cybersecurity law in the United Kingdom.  As part of the “IoT Cybersecurity Improvement Act of 2020”, by March 4th 2020, NIST must define minimum cybersecurity requirements for IoT devices.  Let’s see how gradual a step NIST takes with the minimum requirements it defines.  The U.K. currently has a law for consumer IoT devices under review.