Overview

California’s Bold First Step in IoT Security

You probably don’t think twice about the security of your smart thermostat, Wi-Fi camera, or even that sleek fitness tracker you wear daily. But behind the convenience of these everyday devices lies a less obvious concern , one that California decided to tackle head-on.

Enter the California Internet of Things (IoT) Security Law, officially known as SB-327 and AB-1906. It’s not just another tech regulation; it’s the first law in the U.S. that lays down ground rules for IoT device security. Passed in 2018 and enforced since January 1, 2020, this law was California’s way of saying, “Enough with default passwords and open doors to hackers.”

The aim? Pretty straightforward: make sure that any IoT device , whether it’s streaming your doorbell footage or tracking your heart rate , comes with built-in, reasonable security features. That means no more devices with “admin/admin” as a login, and no more excuses for failing to patch known vulnerabilities.

Who’s Behind the Law?

Oversight of this legislation falls under the watchful eye of the California Attorney General. While it might sound like a niche initiative limited to the Golden State, its reach is broader than most people realize. If your device lands in California stores , or on a California doorstep via an online order , you’re in scope. Whether you’re building smart toasters in Boston or connected fitness gear in Finland, if you sell in California, you play by California’s rules.

Why It Matters Now More Than Ever

The truth is, the world of IoT exploded faster than the security around it. Manufacturers raced to connect devices without fully considering how vulnerable those connections made consumers. This law flips the script, putting the onus on creators , not users , to bake security into their devices from the ground up.

And sure, it’s not perfect. Some say the law leaves room for interpretation when it comes to what counts as “reasonable security.” But it’s a starting point , a legal floor that ensures no device slips through with gaping security holes just because no one thought to ask the hard questions.

Coming up next: we’ll get into who this law affects and why even businesses outside California should be paying close attention.

 

 

Applicability

Who’s Actually on the Hook for Compliance?

Let’s clear something up right away: this law isn’t just for Silicon Valley giants or gadget startups in San Diego. It has a far broader reach. If you’re selling an IoT device that ends up in California , even if your company operates out of New York, Berlin, or a warehouse in Shenzhen , you’re within the crosshairs of this legislation.

That’s because the law targets the sale or use of IoT devices in California. Not the manufacturing location, not the shipping origin , it’s all about where the device ends up. So whether you’re a software developer embedding smart features into home automation gear or a hardware brand shipping connected cameras via Amazon, this law touches your business.

Which Businesses Need to Pay Attention?

Here’s the thing: it’s not just traditional “tech” companies. The lines have blurred. Today, you’ve got everything from lightbulbs to dog collars running on embedded software and connected to the cloud. If your product can talk to the internet , or even just whisper over Bluetooth , it’s considered an IoT device under this law.

So who needs to take this seriously?

  • Consumer Electronics Brands: Think smart speakers, doorbell cams, TVs that connect to Netflix , all fair game.

  • Healthcare Tech Companies: If you’re building remote monitoring devices, smart inhalers, or wearable ECGs, this law sees you.

  • Industrial and Enterprise IoT Players: Using networked sensors to manage utilities, monitor traffic, or optimize warehouse operations? Yep, you’re included too.

  • Smart Home Startups: Thermostats, locks, fridges that text you when the milk’s gone bad , all fall under this law.

It doesn’t matter if your device is in a cozy bungalow in Santa Cruz or a power plant in Bakersfield. If it’s connected and in California, it needs to be secure.

Industry Quirks and Edge Cases

Some industries have extra wrinkles. In healthcare, for example, you might also be dealing with HIPAA , so now you’re juggling multiple compliance mandates. Industrial IoT often means legacy systems are connected to the internet, making them ripe for exploits unless secured properly.

The real kicker? Even if you’re using someone else’s hardware but developing software for it , say, a fitness app that pairs with third-party wearables , you may still be responsible for compliance if you control how that device communicates or stores data.

So don’t assume you’re out of scope because you “just write code” or “don’t sell in California directly.” Compliance might still come knocking.

 

 

What the California IoT Security Law Governs

So… What Counts as an IoT Device, Anyway?

That’s the million-dollar question, isn’t it? According to California’s law, an IoT device is any device that connects directly or indirectly to the internet and has an IP or Bluetooth address. Which, frankly, includes way more gadgets than most people realize.

We’re not just talking about obvious tech like smartphones and smartwatches. Think broader:

  • A fridge that messages your phone when you’re low on eggs

  • A kid’s toy that connects to a parent’s app via Bluetooth

  • Security cameras, routers, connected light bulbs

  • Medical devices that send vitals to a healthcare dashboard

  • Industrial sensors monitoring factory machinery

  • Even “dumb” devices with embedded connectivity modules

Basically, if it talks to the internet , even in a whisper , it’s in scope.

The Security Must-Haves: Not Just “Nice-to-Haves” Anymore

The heart of the law is pretty straightforward. It says IoT devices must have reasonable security features. That sounds vague, right? Here’s what that boils down to in practice:

1. Ban on Default Passwords
No more out-of-the-box logins like “admin/admin” or “1234.” Devices must either:

  • Come with a unique password per unit, or

  • Force users to change the default on setup.

This might sound basic, but you’d be shocked how many massive breaches happened because someone never changed the default password.

2. Secure Authentication
Devices need secure login processes , think multi-factor authentication, biometric options, or cryptographic login mechanisms. If someone can guess their way into your product, you’re not compliant.

3. Reasonable Security Features
A bit of a catch-all. It includes anything that protects against:

  • Unauthorized access

  • Device hijacking

  • Data theft or manipulation

The law doesn’t list every possible safeguard, but if it’s a basic security expectation in your industry, assume it’s required.

4. Automatic Security Updates
This one’s big. If a vulnerability is discovered, you can’t sit on it. Devices must support firmware updates , ideally automatic ones , so you can patch flaws before bad actors exploit them.

Why It Matters (and How It’s Different)

A lot of companies ask, “Can’t we just follow standard security practices and be fine?” Maybe , but here’s the catch: this law gives legal weight to what were once just ‘recommendations’. Failing to follow them isn’t just sloppy anymore , it’s potentially illegal.

And unlike voluntary frameworks (like NIST’s), California’s law requires action. You’re not scoring brownie points with regulators by being secure , you’re avoiding penalties by meeting the bare minimum.

 

 

Compliance Requirements

Let’s be honest , “reasonable security features” is vague enough to give legal teams heartburn. But California’s law gets more specific when it comes to what manufacturers are actually obligated to implement. This isn’t about guesswork; it’s about laying down real, auditable actions.

Here’s the short list that really isn’t all that short:

1. Kill the Default Passwords
If your device ships with a universal login, you’re already out of compliance. Each unit needs:

  • A unique password, or

  • A forced password change during initial setup

It’s the most common-sense rule here, yet it’s the one that’s been ignored the most historically. Think about how many routers or nanny cams have been hijacked just because someone never changed “admin123.”

2. Use Real Authentication
Multi-factor authentication (MFA) isn’t just for banks anymore. If your device lets someone log in to a dashboard or app, it needs robust verification. That could mean:

  • SMS/email code verification

  • Biometric login (fingerprint, facial recognition)

  • Cryptographic keys or certificates

Whatever you do, don’t rely on usernames and passwords alone. That ship sailed long ago.

3. Patch, Patch, Patch
Security flaws happen , but failing to fix them quickly is where real damage begins. Devices need:

  • Firmware update capabilities

  • Secure channels for update delivery

  • User notification (or ideally, background auto-updates)

If your product can’t update without a tech support call, that’s a design flaw. And potentially, a legal liability.

4. Block Unauthorized Access
It’s not just about who can log in , it’s about who can do things once they’re in. You’ll need:

  • Network security layers (like firewalls or isolation zones)

  • Session timeouts and account lockouts

  • Detection of brute force login attempts

This is especially crucial for industrial and medical IoT, where unauthorized control isn’t just annoying , it’s dangerous.

5. Encrypt Data
Any user data stored on the device or sent over a network must be encrypted. That includes:

  • Passwords and credentials

  • Sensor readings (especially health or biometric data)

  • Video/audio streams

  • Device usage logs

Plaintext anything? That’s a lawsuit waiting to happen.

Digging Deeper: Technical & Operational Expectations

Basic compliance is a start, but regulators and cybersecurity professionals are expecting more. Here’s what you should be building into your development and release cycle:

Secure Boot & Code Signing
Devices should boot only trusted firmware. Use digital signatures to verify authenticity before allowing updates or startup.

Access Control & RBAC
Not every user should have admin privileges. Implement Role-Based Access Control (RBAC) to assign permissions based on function, not convenience.

Logging & Monitoring
Devices should log:

  • Login attempts

  • Firmware updates

  • Critical operations (like factory resets or security setting changes)

And yes, you should be reviewing these logs regularly , ideally with an intrusion detection system (IDS) watching the backend.

Third-Party Testing Isn’t Optional
Before launch, conduct:

  • Penetration tests

  • Code audits

  • Device-level security assessments

Use ethical hackers or certified security firms. It’s not about checking a box, it’s about catching what your engineers missed.

 

 

Consequences of Non-Compliance

The Financial Sting: Penalties and Fines

Here’s the part that usually makes legal departments sit up a little straighter. While the California IoT Security Law doesn’t list specific fine amounts in the statute, non-compliance doesn’t just fade quietly into the night. Violations fall under California’s Unfair Competition Law (UCL) , and that’s where the money talk begins.

Let’s break it down:

  • **Up to 2,500perdevice,perviolation.∗∗ Yes,perdevice.Ifyoushipped10,000unitswithflawedsecurity?That′spotentially2,500 per device, per violation.**\ Yes, per device. If you shipped 10,000 units with flawed security? That's potentially 25 million in civil penalties.

  • Multiple violations add up fast.
    Every insecure firmware version, every unpatched vulnerability, every batch of default-password devices , each one could be counted separately.

  • No upper limit on class-action damages.
    If a security failure leads to personal data exposure, consumers can sue. Multiply that by thousands of affected users, and you’re staring down some serious legal costs.

And no, “we didn’t know” isn’t a defense. California regulators expect manufacturers to be proactive , not reactive , when it comes to device security.

It’s not just about the money. The California Attorney General has the authority to investigate violations, demand internal records, and bring public enforcement actions. That’s the kind of scrutiny that can tank a product launch or freeze investor confidence overnight.

Here’s what’s at stake:

  • Formal investigations into your security practices

  • Injunctions forcing you to halt device sales

  • Public disclosure of your violations (nothing tanks brand trust like a state-backed press release about your insecure smart device)

It’s not just the regulators either , consumers can sue too. If a device’s flaw results in actual damage , identity theft, data loss, or physical risk , you may face lawsuits from individuals or groups. And yes, class-actions are fair game.

Long-Term Fallout: Business and Brand Risk

If you think this is just a legal headache, think again. Compliance failures have serious consequences that ripple through your business:

  • Reputation Damage
    Once your company name is associated with a data breach, it sticks. Ask any brand that’s been through it , consumer trust is hard to rebuild once it’s broken.

  • Sales Bans
    Retailers, platforms, and even distributors may refuse to carry or list your devices if you’re flagged as non-compliant. Especially in California, where consumer rights are tightly enforced.

  • Product Recalls
    Devices with security flaws might need to be pulled from shelves , costing you not just in logistics and refunds, but in PR and customer loyalty.

 

 

Why the California IoT Security Law Exists

The Breach That Woke Everyone Up

Let’s rewind to 2016 , the year the internet, quite literally, broke for millions of people. The culprit? A ragtag army of hijacked IoT devices. Cheap webcams and routers, mass-produced with the same factory-set credentials, were scooped up by the Mirai botnet and used to flood internet infrastructure with junk traffic. Netflix, Twitter, Spotify, Reddit , all went dark in parts of the U.S. and Europe.

It was a wake-up call. These weren’t advanced cyberweapons. They were your aunt’s baby monitor and your neighbor’s security cam , weaponized because no one bothered to change the default password.

That was the moment policymakers finally asked, “Why are these things even allowed to ship this way?”

California didn’t wait around for the next crisis. In 2018, the state passed SB-327 and AB-1906 , the first U.S. laws requiring manufacturers to build in basic security for any internet-connected device sold in the state. The law took effect in 2020 and instantly changed the baseline for what’s considered “acceptable” in product design.

California Leads, But It’s Not Alone

While California was first out of the gate, it didn’t stay alone for long. The law set off a global ripple effect , a kind of cybersecurity domino chain.

Here’s how it spread:

  • European Union: The EU Cybersecurity Act introduced similar standards, with even stricter mandates around certification and lifecycle security.

  • United Kingdom: The UK passed its own IoT Security Law, banning universal passwords and requiring transparency around support timelines and vulnerability reporting.

  • U.S. Federal Level: NIST (National Institute of Standards and Technology) began rolling out its own voluntary framework for IoT cybersecurity, heavily influenced by California’s move.

Suddenly, what started as a “California-only” thing became a global compliance trend. Device makers can no longer think in silos. If you’re building for any major market, secure-by-design is your new baseline.

A Glimpse at the Road Ahead

The California law isn’t static, and neither is the threat landscape. Lawmakers and regulators are already eyeing potential expansions, including:

  • Formal certification programs for IoT devices, similar to EnergyStar or UL marks

  • Broader definitions of what counts as “reasonable security”

  • Higher penalties for egregious or repeated violations

  • Mandated support timelines , where devices must receive updates for a minimum number of years

Cybersecurity isn’t a checkbox anymore, it’s a living process. And laws like California’s are evolving to reflect that reality.

 

 

Implementation & Best Practices

Where to Start: Building Compliance into Your Workflow

First things first , compliance doesn’t have to be a bureaucratic slog. Yes, it’s a legal requirement, but smart teams treat it like a product feature. Why? Because secure devices don’t just meet regulations , they win trust, protect users, and save you from future firefights.

So, how do you get your house in order?

1. Audit Your Current IoT Security Posture
Before you fix anything, you need to know what’s broken. Conduct a full audit of your device ecosystem:

  • Are passwords hardcoded or dynamic?

  • How are firmware updates delivered?

  • What data is stored, and how is it protected?

  • Who has admin access , and should they?

This isn’t just a checklist exercise. It’s your map. You can’t navigate compliance blindfolded.

2. Kill Default Credentials. For Real.
If your product still ships with a single hardcoded password, you’re out of compliance. Period. Replace that with:

  • Device-specific passwords generated during manufacturing

  • Setup flows that force a password change on first use

  • Password complexity requirements built into UI/UX

3. Upgrade Authentication Standards
Single-layer authentication doesn’t cut it anymore. Depending on the sensitivity of your device:

  • Integrate MFA (multi-factor authentication)

  • Add biometric options where feasible

  • Use client-side certificate authentication for high-security use cases

Your goal isn’t just to keep hackers out , it’s to make it painful for them to even try.

4. Patch Management Is Not Optional
You need a formal process for pushing updates:

  • Establish a secure update mechanism (signed, encrypted, and verified)

  • Enable over-the-air (OTA) delivery when possible

  • Notify users about critical security patches , or better yet, install them automatically

And yes, this should be in place before launch.

5. Educate Your Development Team
Security isn’t just the CISO’s problem. Your engineers, designers, even QA testers , everyone should understand the basics of secure IoT design. Hold internal workshops. Use threat modeling exercises. Introduce tools like:

  • OWASP IoT Top Ten

  • NIST Secure Software Development Framework (SSDF)

Security by design means security by everyone.

Keeping It Compliant: Long-Term Habits That Stick

Getting compliant is half the battle , staying compliant is a whole different game. Here’s how to avoid backsliding:

Annual Security Audits
Make them routine. Schedule external or internal audits that assess:

  • Firmware vulnerabilities

  • Network communications

  • Authentication flow integrity

  • Physical tamper resistance

Create Clear Disclosure Channels
Make it easy for researchers and users to report issues. A public-facing security contact (like security@yourcompany.com) isn’t just nice , it’s a best practice that builds goodwill and buys time if something does go wrong.

Have an Incident Response Plan
If a breach happens , and let’s face it, no system is bulletproof , your response needs to be fast, honest, and effective. Outline:

  • Who’s on the internal response team

  • How you’ll notify users

  • What remediation steps follow

  • Your timeline for patching and communication

Build Support Timelines Into Product Planning
Consumers are tired of buying connected devices that stop getting updates a year later. Be transparent:

  • Publish your update policy

  • Support products for a reasonable duration (ideally 3—5 years)

  • Retire products responsibly, with clear communication and security wind-down plans

 

 

Additional Resources

Where to Turn When You Need Guidance (and Tools That Actually Help)

Compliance doesn’t happen in a vacuum. Whether you’re a startup navigating your first product release or an enterprise scaling a global line of connected devices, having the right resources at your fingertips makes all the difference.

Let’s break it down into what you should be reading, using, and learning from.

Official Documentation & Guidelines

Start with the source. These aren’t dusty legal texts , they’re surprisingly clear, actionable references.

Practical Tools for Getting (and Staying) Compliant

Need help assessing devices, running tests, or implementing secure firmware updates? These tools are widely used in the industry , not just in theory, but in real product security pipelines.

IoT Vulnerability Scanners

  • Tenable — Offers comprehensive scans and visibility across large device fleets.

  • Rapid7 — Known for its user-friendly dashboards and policy management tools.

  • IoT Inspector — Great for analyzing firmware and identifying vulnerabilities during development.

Secure Firmware Update Solutions

  • ARM TrustZone — Hardware-backed security for secure boot and runtime integrity.

  • Intel Secure Boot — A solid choice for embedded devices running on Intel architecture.

IoT Penetration Testing Frameworks

  • OWASP IoT Project — Offers open-source tools, vulnerability checklists, and firmware security checklists.

  • Shodan — A search engine for internet-connected devices. Use it to see if your devices are unintentionally exposed to the world.

Case Studies: The Good, the Bad, and the Hackable

Real-world examples aren’t just useful , they’re sobering reminders of what’s at stake.

The Bad: Mirai Botnet (2016)
Tens of thousands of insecure IoT devices , mostly cameras and routers , were hijacked to launch a record-breaking DDoS attack. The fallout? Millions in damages and global internet outages. The cause? Default credentials.

The Good: Google Nest’s Compliance Pivot
Initially criticized for weak account security, Nest turned things around by enforcing two-factor authentication, improving patch infrastructure, and proactively educating users. It wasn’t just a compliance move , it rebuilt trust in a crowded smart home market.

FAQ , Quick Answers to the Questions You Didn’t Want to Ask Out Loud

Q: Does this law apply if I’m not based in California?
Yes. If your device is sold or used in California, you’re covered , no matter where your headquarters sit.

Q: What’s the worst-case scenario for non-compliance?
Fines, legal investigations, class-action lawsuits, lost retail partnerships, product recalls, public embarrassment. Shall we go on?

Q: What if I’m a small startup?
There’s no exemption for company size. The law applies to anyone who manufactures, sells, or offers connected devices for sale in California.

 

 

Conclusion

A New Era of Accountability for Smart Devices

Let’s call it like it is: the age of “ship now, secure later” is over. The California IoT Security Law didn’t just raise the bar , it rewired how the industry thinks about connected devices. It turned what used to be a loose collection of security “shoulds” into legal “musts.”

Manufacturers can’t afford to treat cybersecurity as an afterthought. And honestly? Neither can consumers. From baby monitors to smart traffic systems, these devices are part of everyday life now. They’re woven into our homes, hospitals, cities , even our pockets. One weak link can compromise thousands of users, leak sensitive data, or cripple infrastructure.

So, what’s the takeaway here?

If you’re designing, building, or selling connected devices , you’re also in the business of protecting them. That means rethinking your development pipeline, investing in secure boot, enforcing better passwords, educating your team, and planning for what happens after launch. It’s not just about staying legal , it’s about staying credible.

And the good news? Getting compliant doesn’t have to derail your product vision. With the right tools, smart design habits, and a clear strategy, you can meet the requirements of SB-327 and AB-1906 and deliver a product your users trust.

Next Steps: What You Should Do Right Now

If you’ve read this far, you’re already ahead of the curve. Here’s what to tackle next:

Security compliance isn’t a finish line. It’s an ongoing commitment. But with the right foundation, it becomes less of a chore , and more of a competitive edge.

And who doesn’t want to build something people can trust?

 

 

Compliance Checklist

Use This as a Starting Point for Your Team’s IoT Security Strategy

Here’s a practical, at-a-glance checklist you can plug into your product or compliance roadmap. Print it, pin it, paste it in Jira , whatever works. It’s not exhaustive, but it covers the critical action points from California’s IoT Security Law.

✅ IoT Device Security Compliance Checklist

Password & Authentication

  • Remove all factory-default, hardcoded passwords

  • Assign a unique password per device, or require password change at setup

  • Implement secure authentication (MFA, biometrics, cryptographic keys)

  • Enforce password complexity standards (length, characters, expiration)

  • Prevent brute-force login with lockouts or rate-limiting

Data Protection & Encryption

  • Encrypt all sensitive data stored on the device

  • Encrypt all data in transit (TLS, HTTPS, etc.)

  • Store credentials securely (e.g., hardware-backed keystores)

  • Regularly test encryption implementations for vulnerabilities

Update & Patch Management

  • Enable over-the-air (OTA) firmware updates

  • Use signed and verified update packages

  • Create a clear update schedule for security patches

  • Provide users with update notifications or automate updates

Access Control & System Hardening

  • Apply least-privilege access across user roles (RBAC)

  • Limit admin functions to authenticated users only

  • Disable unused ports, protocols, and features by default

  • Implement secure boot and code integrity verification

Monitoring & Incident Readiness

  • Enable device-level logging of login attempts and critical events

  • Regularly audit logs for unusual activity

  • Develop and document an incident response plan

  • Publish a responsible disclosure contact and process

Third-Party & Lifecycle Management

  • Conduct penetration testing before product launch

  • Review third-party components and firmware for vulnerabilities

  • Define a minimum support period for security updates (e.g., 3—5 years)

  • Provide end-of-life update plans or mitigations