California Cybersecurity Law: Scope, Requirements, and Penalties

The California IoT security law, codified at Civil Code Sections 1798.91.04 through 1798.91.06, requires manufacturers of internet-connected devices sold in California to equip those products with reasonable security features. It took effect on January 1, 2020, and reaches any manufacturer whose products are sold or offered for sale in California, no matter where the company itself sits.¹

Who Has to Comply and Which Devices Are Covered

The statute covers any physical object that can connect to the internet, directly or indirectly, and that has an IP address or Bluetooth address.² Smart thermostats, voice assistants, fitness trackers, connected appliances, smart doorbells — if it talks to a network and carries one of those addresses, it counts.

A “manufacturer” is the person or company that makes the device or contracts with someone else to make it for sale in California. Buying a finished device and reselling it, or rebranding a device someone else built, does not make you a manufacturer under this law.² The trigger is selling or offering the connected device for sale in California. A company headquartered in another state or another country must still comply if its products reach California buyers.

What “Reasonable Security Features” Means

Every covered device must ship with reasonable security features that are appropriate to the device’s function, appropriate to the information it might collect or transmit, and designed to protect the device and its data from unauthorized access, destruction, use, modification, or disclosure.¹ A camera-equipped doorbell that streams video to the cloud is held to a higher bar than a connected light bulb with no sensors.

For devices that authenticate users over a network outside a local connection, the law provides a safe harbor. A manufacturer meets the reasonable-security standard if either of the following is true:

The device ships with a preprogrammed password that is unique to each individual unit, or
The device requires the user to generate new authentication credentials before it can be accessed for the first time.¹

The point of the password provisions is ending the industry practice of shipping devices with identical defaults like “admin” or “1234,” which made large fleets of IoT devices easy to compromise at scale. The statute otherwise avoids prescribing specific technical controls, which lets the standard evolve with technology but leaves manufacturers guessing about what a court would find reasonable for their particular product. The safest approach is to treat the password rules as a floor rather than a ceiling and build security that actually matches the risks the device creates.

The NIST Labeling Alternative

A later amendment added a second compliance path. A manufacturer can satisfy the security requirement by ensuring the device meets the baseline product criteria of a NIST-conforming labeling scheme, passes a conformity assessment under that scheme (including a third-party test, inspection, or certification), and carries the scheme’s label.³ For manufacturers who want a concrete, verifiable benchmark instead of a good-faith reading of “reasonable,” this is the closest thing the law offers. The federal NISTIR 8259 series sets out core cybersecurity capabilities (device identification, configuration, data protection, logical access control, software updates, and cybersecurity state awareness) that underpin those labeling schemes.⁴

What the Law Does Not Require

Several obligations you might expect are not in the statute, and manufacturers should understand those limits before scoping a compliance program.

Manufacturers have no duty under this law to secure third-party software or apps that a user independently installs on the device after purchase.⁵
Providers of electronic stores, app marketplaces, and download platforms have no obligation to review devices or police compliance.⁵
The law cannot be used as a reason to prevent a user from modifying the software or firmware on their own device.⁵

The statute also does not require formal risk assessments, security audit filings, or any particular ongoing update schedule. It says nothing about encrypting data in transit or at rest, and it sets no minimum period for how long a manufacturer must keep supporting a device’s security after sale.⁶ Those practices are good engineering, but they are not statutory duties.

Exemptions

Two categories of devices sit outside the law entirely.

Connected devices whose functionality is already governed by federal security requirements are exempt. If a federal agency has issued security regulations or guidance for a particular device type under its enforcement authority, this statute does not apply on top of that federal regime.⁵

Entities already subject to HIPAA or California’s Confidentiality of Medical Information Act are exempt for activity regulated by those statutes.⁵ The exemption is activity-specific. A hospital using HIPAA-regulated connected medical devices does not need to layer this IoT statute on top for those devices, but the same organization selling a consumer fitness tracker outside HIPAA’s scope would still have to comply for that product.

Being exempt from this statute does not relieve a manufacturer of security duties imposed by other state or federal laws. Obligations under different regimes are cumulative.

Enforcement and Penalties

Consumers cannot sue manufacturers directly for violating this law. Enforcement authority sits exclusively with the California Attorney General, city attorneys, county counsels, and district attorneys.¹ Because there is no private right of action, enforcement depends on how aggressively public officials pursue violations.

The statute does not set specific fine amounts, penalty tiers, or a formula for damages. Courts have discretion to fashion relief in enforcement actions, but no schedule of fines appears in the law itself. That distinguishes it from the CCPA, which spells out per-consumer damage ranges. The ambiguity can cut two ways: it lowers a manufacturer’s ability to price the risk of noncompliance, and it also means a public enforcement action’s ultimate cost, including reputational fallout, can be hard to bound in advance.

How the CCPA Turns Insecure Devices Into Class-Action Risk

The IoT statute has no private right of action, but California’s Consumer Privacy Act fills much of that gap for devices that handle personal information. Under Civil Code Section 1798.150, any consumer whose unencrypted personal information is exposed in a breach caused by a business’s failure to maintain reasonable security procedures can sue for statutory damages between $100 and $750 per consumer per incident, or actual damages, whichever is greater.⁷ Courts weigh the seriousness of the misconduct, the number of violations, how long the failure lasted, and whether the business acted willfully.

Before filing a statutory-damages claim, a consumer must give the business 30 days’ written notice identifying the specific violation. If the business cures the problem within that window and provides a written statement that the violation has been fixed, the statutory-damages claim is blocked. Implementing reasonable security after a breach does not count as a cure for that breach.⁷ For an IoT manufacturer, an insecure connected device that leads to a consumer data breach can produce class-action exposure under the CCPA even though the IoT security statute itself offers no private lawsuit path.

Breach Notification Runs in Parallel

Any individual or business that owns or licenses computerized data containing personal information about a California resident must notify affected residents when a breach occurs. Notification must go out within 30 calendar days of discovering or being notified of the breach, though the deadline can be extended if law enforcement determines that notification would interfere with a criminal investigation.⁸

A “breach” here means the unauthorized acquisition of computerized data that compromises the security, confidentiality, or integrity of personal information. An employee accessing data in good faith for legitimate business purposes does not trigger notification, provided the information is not further misused or disclosed.⁸ A device vulnerability that leads to unauthorized data access can trigger this obligation at the same time it creates CCPA liability.

The Law’s Practical Weaknesses

The statute was groundbreaking when it passed, but its shortcomings matter for anyone counting on it either as a compliance ceiling or as consumer protection. The central phrase, “reasonable security features,” is flexible by design, and some commentators have read the safe harbor to mean that unique passwords alone might technically satisfy the law, which would leave most of the IoT security picture untouched.⁶

The absence of any encryption mandate, update obligation, or minimum support period is a real gap. A device shipped with a unique password but no mechanism to receive security patches becomes vulnerable the moment a new exploit surfaces. The NIST labeling alternative helps close some of that ground, but only for manufacturers who voluntarily pursue certification rather than resting on the password safe harbor.

The enforcement-only-by-public-officials model has drawn its own criticism. Widely reported enforcement actions under this statute have not materialized, which may reflect either broad compliance or limited enforcement bandwidth. Either way, manufacturers who treat this statute as one layer inside a broader compliance picture — CCPA breach liability, breach notification duties, federal sector rules, and NIST guidance — are better positioned than those who read the password safe harbor as a finish line.

1
California Legislative Information. California SB 327 – Information Privacy: Connected Devices
2
California Legislative Information. California Civil Code 1798.91.05 – Definitions
3
California Legislative Information. California Civil Code 1798.91.04 – Connected Device Security
4
National Institute of Standards and Technology. NISTIR 8259A – IoT Device Cybersecurity Capability Core Baseline
5
California Legislative Information. California Civil Code 1798.91.06 – Scope and Limitations
6
Help Net Security. California’s IoT Cybersecurity Bill: What It Gets Right and Wrong
7
California Legislative Information. California Civil Code 1798.150 – Personal Information Security Breaches
8
California Legislative Information. California Civil Code 1798.82 – Breach Notification