Concept renderCalifornia Civil Code 1798.91.04 is binding law: a connected device needs reasonable security features, and a device with authentication outside a LAN is deemed reasonable with a unique preprogrammed password or new user-created authentication before first access. NIST IR 8259A is guidance. The FCC Cyber Trust Mark is voluntary. Status as of October 31, 2026.
Teams often mix up three different things: a state law, a federal guidance document and a voluntary label. The first binds you if it applies to your device. The other two do not. This guide separates them using the words of the sources, then turns them into a gap checklist that shows the stage where each decision has to be made.
This is an engineering summary and does not constitute legal advice. We quote the sources and link to the originals. Have counsel review your plan. For wearables, this summary covers general wellness products. It does not cover medical devices.
Which rules are law and which are voluntary?
The table lists each source, its status as the source describes it, and a quoted line. Each row was read on October 31, 2026. Program status can change, so re-read the pages before you decide.
| Source | Status | Quoted line | Link |
|---|---|---|---|
| California Civil Code 1798.91.04 | Binding California law for connected devices | "A manufacturer of a connected device shall equip the device with a reasonable security feature or features that are all of the following" | California Civil Code 1798.91.04 (public-law mirror), as of October 31, 2026 |
| NIST IR 8259A, final May 2020 | Guidance. A core baseline of device capabilities | "a starting point to use in identifying the device cybersecurity capabilities for new IoT devices they will manufacture, integrate, or acquire" | NIST CSRC publication page, as of October 31, 2026 |
| FCC Report and Order 24-26 (PS Docket 23-239) | Voluntary labeling program for wireless consumer IoT products (Cyber Trust Mark). The label includes a QR code to a registry | "adopting a voluntary cybersecurity labeling program for wireless Internet of Things products" | FCC 24-26, as of October 31, 2026 |
| FCC DA 26-354, released April 2026 | Program administration notice. Still described as voluntary. The ioXt Alliance is the new Lead Administrator, replacing the previous administrator, and the previous administrator's recommended standards are still under staff review before public comment | "announces the selection of ioXt Alliance (ioXt) to serve as the Lead Administrator of the Federal Communications Commission's" | FCC DA 26-354, as of October 31, 2026 |
We read the California text on a public-law mirror because the official legislature site did not load when we checked. Read the official text before you rely on it. We also could not load the FCC program status page, so the program status here rests on the administrator notice above.
What does the California statute require?
Subdivision (a) says the manufacturer shall equip the device with reasonable security features, appropriate to the device's nature and function and the information it handles, and designed to protect against unauthorized access, destruction, use, modification or disclosure. Subdivision (b) treats a device as reasonable when, if it has authentication outside a local area network, the preprogrammed password is unique to each device manufactured, or the user must create new authentication before first access. Subdivision (c) lets a manufacturer instead satisfy (a) through a labeling scheme that conforms to NIST, with third-party assessment (source, as of October 31, 2026).
This article does not state who counts as a manufacturer, which devices count as connected, or what penalties apply. Those answers are in the statute, and a lawyer should apply them to your product.
What are the six IR 8259A capabilities, and where are they decided?
NIST positions the baseline as a starting point for new devices. The right-hand columns map each capability to a design decision and a stage. That mapping is our engineering reading. NIST does not assign stages. Source: NIST IR 8259A, as of October 31, 2026.
| Capability | Design decision to make | Stage where it must be decided |
|---|---|---|
| Device Identification | Give each unit a unique identity at the factory line, and decide where that identity is stored. | Schematic, factory line |
| Device Configuration | Decide which settings a user or administrator can change, and how a factory reset behaves. | Firmware, app |
| Data Protection | Decide what data sits on the device, what leaves it, and how each is protected. | Schematic, firmware, app |
| Logical Access to Interfaces | Decide which debug, service and radio interfaces stay reachable after production, and what each requires. | Schematic, firmware, factory line |
| Software Update | Design the update path before the first unit ships: how a new image arrives, how it is checked and what happens on failure. | Schematic (flash layout), firmware, backend |
| Cybersecurity State Awareness | Decide what the device reports about its own security state, and where those logs go. | Firmware, app, backend |
What is the gap checklist?
Use this table to find what you have not yet decided. It is a decision map, and a completed table does not show compliance with anything.
| Requirement | Status | Design decision | Stage | Source |
|---|---|---|---|---|
| California Civil Code 1798.91.04(a): reasonable security features suited to the device and the information it handles, designed to protect against unauthorized access, destruction, use, modification or disclosure | Binding law | Write down which features you chose and why they fit this device and its data. | Schematic and firmware | California Civil Code 1798.91.04, as of October 31, 2026 |
| Subdivision (b), preprogrammed password: for a device with authentication outside a LAN, the preprogrammed password is unique to each device manufactured | Binding law (a deemed-reasonable path) | Per-device credential provisioning on the factory line, with the credential printed or retrievable only by the owner. | Factory line, firmware | California Civil Code 1798.91.04, as of October 31, 2026 |
| Subdivision (b), alternative: the user must create new authentication before first access | Binding law (a deemed-reasonable path) | A forced first-use setup step in the app or device, with no shared default. | Firmware, app | California Civil Code 1798.91.04, as of October 31, 2026 |
| Subdivision (c): satisfy (a) through a NIST-conforming labeling scheme with third-party assessment | Binding law (an alternative path) | Decide early whether you pursue a labeling scheme, because it adds an assessment step to the schedule. | Program plan | California Civil Code 1798.91.04, as of October 31, 2026 |
| Six IR 8259A capabilities (table below) | Guidance | Use as the design checklist for a new device. | All stages | NIST IR 8259A, as of October 31, 2026 |
| Cyber Trust Mark label and registry | Voluntary | Decide whether the label fits your product and market. Check scope and program status first. | Program plan | FCC 24-26, as of October 31, 2026 |
What is the status of the Cyber Trust Mark?
The FCC adopted the program in its 2024 Report and Order, FCC 24-26 in PS Docket 23-239, as a voluntary labeling program for wireless Internet of Things products. The label includes a QR code to a registry (source). In an order released in April 2026, the Public Safety bureau selected the ioXt Alliance as the new Lead Administrator, replacing the previous administrator. The notice also says the previous administrator's recommended standards are still under staff review before public comment (source). Both as of October 31, 2026.
The scope wording is about wireless consumer IoT products. We have not confirmed whether a business-to-business device falls inside it. Check the order text and the current FCC program page before you plan around the label.
What are the common traps?
These follow from the quoted sources. They are engineering reasoning, and none describes an incident at any company.
- Treating the voluntary label as the legal floor. The FCC order and the April 2026 notice both call the program voluntary. The California statute is the one that is binding. A team that plans around the label alone has not addressed the statute.
- Deciding the credential scheme after the PCB is done. Subdivision (b) turns on a per-device password or a first-use step. A per-device credential has to be written at the factory line, so the choice reaches the line and the firmware layout. A late change means reworking the production flow. This is engineering inference from the statute text.
- Reading a mirror as the official text. The statute text in this article was read from a public-law mirror because the official legislature site was not reachable when we checked. Read the official text before you rely on any wording.
- Assuming national reach for the California rule. The statute covers connected devices as the California code defines them. Do not describe it as a national requirement to your team or your customers.
- Treating the status of the label as settled. The administrator changed in April 2026 and the earlier recommended standards were still under staff review in that notice. Any plan that depends on the label should date-stamp what it assumes.
- Assuming a business-to-business device is inside the label scope. The order describes wireless consumer IoT products. Check the order text and the current program page to see whether your device falls inside that wording.
What should you test on your own board?
The sources set requirements and do not give test methods. We have not run these tests for you and report no results. The pass line is set by you per product requirement, and you record the basis for it.
| What to test | How to instrument or capture it | Raw data to record |
|---|---|---|
| Credential uniqueness across units | Read the credential or credential-derived value from a set of finished units on the factory line. | Unit identifier, the value read, the tool and station used, and the comparison method. Record how you set the pass line and why. |
| First-use flow | Walk a fresh unit through first power-on and first access with a log of every screen and every network call. | Screen recording, request log, and whether any step reaches the device with a shared default value. |
| Factory reset behavior | Reset a configured unit and repeat the first-use flow. | Which credentials and settings survived the reset, and which returned to a state that needs new authentication. |
| Exposed interfaces after production | List every physical and radio interface on a production-programmed unit and try to reach each one. | The interface list, what each one allowed without credentials, and the firmware build tested. |
| Update path | Deliver a new image over the air to a unit, then deliver a damaged image and an interrupted transfer. | Image version before and after, result of each attempt, and the device state after each failure. |
| State reporting | Trigger the events you chose to report (failed sign-in, update result, reset) and trace each one to its log destination. | Event list, timestamp at the device, timestamp at the destination, and any events that did not arrive. |
Set every pass line before you run the test, and write down why you chose it.
What should you think through before you choose?
Take this list to your team, your counsel and any supplier who proposes a security design.
- Does our device have authentication outside a local network, and which path under subdivision (b) do we take?
- If we use per-device credentials, who writes them on the factory line, who holds the record, and how does an owner learn the value?
- If we use a first-use step, can any sign-in happen before it, on any interface?
- Which of the six IR 8259A capabilities do we cover, and who owns each one?
- Where will each capability be decided: schematic, firmware, factory line or app?
- Is a labeling scheme under subdivision (c) worth the extra assessment step for our product?
- Does our device fall inside the wording on wireless consumer IoT products in the FCC order?
- Which status assumptions about the Cyber Trust Mark program are we making, and on what date did we check them?
- Have we read the California text on the official site, and has counsel reviewed our plan?
- Which items here are measured on our own units, and which are still assumptions?
Questions about US IoT security rules
Is the Cyber Trust Mark required?
The FCC order describes it as a voluntary program for wireless consumer IoT products, and the April 2026 administrator notice calls it voluntary as well. As of October 31, 2026. FCC 24-26, FCC DA 26-354.
Is the California rule voluntary?
No. Civil Code section 1798.91.04 says a manufacturer of a connected device shall equip it with reasonable security features. Subdivision (b) describes the unique-password and first-use paths that count as reasonable. Read the text and have counsel advise on your product. California Civil Code 1798.91.04.
Is NIST IR 8259A a legal requirement?
It is guidance. NIST describes the baseline as a starting point for identifying device cybersecurity capabilities for new IoT devices. It names six capabilities: Device Identification, Device Configuration, Data Protection, Logical Access to Interfaces, Software Update and Cybersecurity State Awareness. NIST IR 8259A.
Does this apply to a health wearable?
The sources above deal with device security. Whether each one covers your health wearable depends on its own scope wording, so check the text and ask counsel. This article is an engineering summary for general wellness products. It does not cover medical devices.
Can Duobay confirm my product meets these rules?
We do not give legal opinions. Security requirements are best settled at Gate 0, before the schematic is frozen. Tell us about your device and we will explain how that works.
If you want these decisions mapped onto a schematic, firmware plan and factory line for your device, tell us about your device. You can also read how the gated process places them.
Sources
All pages accessed 2026-10-31. Program status changes, so confirm on the live pages.
- California Civil Code section 1798.91.04 (public-law mirror): https://california.public.law/codes/civil_code_section_1798.91.04 (accessed 2026-10-31)
- NIST, IR 8259A final: https://csrc.nist.gov/pubs/ir/8259/a/final (accessed 2026-10-31)
- FCC, Report and Order FCC 24-26: https://docs.fcc.gov/public/attachments/FCC-24-26A1.txt (accessed 2026-10-31)
- FCC, DA 26-354: https://docs.fcc.gov/public/attachments/DA-26-354A1.txt (accessed 2026-10-31)
Planning a device like this? Tell us what it needs to do. A Duobay engineer replies within 1 business day. Send a project brief →