A manufacturer that has assessed its devices under California or Oregon security law may already have useful records of authentication design, information protection and security decisions. Those records can support parts of an EU Cyber Resilience Act (CRA) assessment. The next step is to establish which requirements and product versions the records actually cover.
This guide compares the current codified provisions. California’s law is often searched for as SB 327; the code also includes provisions enacted through AB 1906, and AB 2392 (2022) added the labeling option described below. Oregon’s provisions are in ORS 646A.813. The comparison is intended for manufacturers considering EU sales, and does not attempt to catalog every applicable US state law.
Start with the different scopes
| Question | California | Oregon | CRA |
|---|---|---|---|
| Which product? | A physical device capable of connecting to the internet directly or indirectly, assigned an IP or Bluetooth address | A physical device connecting directly or indirectly to the internet, used primarily for personal, family or household purposes, with an IP address or another identifier for a short-range wireless connection | Products with digital elements, including software, meeting Article 2’s connection test and subject to its exclusions |
| Which manufacturer? | A person manufacturing, or contracting for manufacture, of devices sold or offered for sale in California, with the qualifications in section 1798.91.05(c) | A person making a connected device and selling or offering it for sale in Oregon | The manufacturer defined in Article 3(13), for a product made available on the EU market |
| Main security approach? | Features appropriate to the device’s nature, function and information, designed to protect against the listed unauthorized actions | Reasonable security features appropriate to the device and its information | Product risk assessment, applicable Annex I product-security requirements and vulnerability handling |
Sources: California sections 1798.91.04(a) and 1798.91.05(b)–(c), Oregon section 646A.813(1)–(2), and CRA Article 2 and Article 3.
California’s definition does not contain Oregon’s household-use restriction. Do not exclude an industrial device from the California assessment just because Oregon uses that restriction. Conversely, the CRA can reach standalone software that falls outside these state definitions of a physical connected device.
The laws also have different exclusions and limits. California excludes devices whose functionality is subject to security requirements under federal law, regulations or federal agency guidance (section 1798.91.06(d)) and activity regulated by HIPAA or California’s Confidentiality of Medical Information Act (section 1798.91.06(h)). It also limits duties for unaffiliated software that a user adds (section 1798.91.06(a)). Oregon excludes devices whose functions are subject to and comply with FDA medical-device requirements, regulations and guidance (section 646A.813(4)(c)), actions regulated under HIPAA (section 646A.813(4)(b)) and devices to which a consumer adds software or devices that the manufacturer does not approve, or that damage, evade, disable or otherwise modify its security features (section 646A.813(4)(a)). Section 646A.813(3) sets further limits on the duties it imposes. In Oregon, compliance with applicable federal security law is instead one way to provide a reasonable security feature under subsection (2)(b). Apply CRA Article 2 separately. For example, Article 2(2) excludes products to which the EU Medical Devices or In Vitro Diagnostic Medical Devices Regulation applies. A US exemption does not determine the product’s EU status.
What the password provisions actually say
California: section 1798.91.04(b) concerns devices equipped with authentication from outside a local area network. It recognizes either a unique preprogrammed password for each device or a feature requiring the user to create a new means of authentication before first access. The subdivision expressly remains subject to all the requirements in subdivision (a). Unique passwords therefore do not dispose of the broader reasonable-security assessment.
Oregon: section 646A.813(2) says a reasonable security feature may consist of the described external authentication arrangements, including a unique preprogrammed password or new authentication before first access, or compliance with applicable federal device-security law or regulations. Read that wording with the definition in subsection (1)(c). The two statutes should not be presented as having identical text or legal mechanisms.
CRA: Annex I Part I(2)(b) and (d) address secure defaults and protection against unauthorized access. They do not declare that either state password option is sufficient for CRA conformity. The manufacturer’s assessment must address the product’s risks and the applicability of each Part I(2) requirement under Article 13(3)–(4).
How to reuse the engineering evidence
The table is Meroi Security’s analytical comparison. A document is reusable only to the extent it covers the EU product and the claim being assessed. State-law compliance creates no automatic CRA presumption of conformity; see Article 27.
| Existing work | Potential CRA contribution | Additional product check |
|---|---|---|
| Review of device function, stored data and threats used to select reasonable security features | Article 13(2)–(4): input to the documented cybersecurity risk assessment | Add intended and reasonably foreseeable use, operational environment, assets and expected use time. Address each applicable Annex I requirement and justify exclusions. |
| Password uniqueness and first-use authentication tests | Annex I Part I(2)(b) and (d): evidence for defaults and access protection | Test all relevant interfaces and credentials, recovery and reset behavior, and authorization after login. |
| Tests against unauthorized reading or modification of device data | Annex I Part I(2)(e) and (f): evidence for confidentiality and integrity | Cover relevant stored and transmitted data across the product boundary, including required remote processing. |
| Design decisions and security test reports retained from the state-law assessment | Annex VII(2), (3) and (6): inputs to technical documentation | Confirm the reports match the version sold in the EU and include the vulnerability-handling processes that Annex VII(6) also covers. |
A checklist showing that every device has a unique password may be supported by excellent manufacturing tests. It still provides limited information about data deletion, software updates, availability, attack-surface reduction or vulnerability handling. Examine those subjects against Annex I without assuming that compliance with the state law already assessed them.
California’s labeling option is a separate legal provision
Section 1798.91.04(c), added by AB 2392 with effect from January 1, 2023, allows a manufacturer to satisfy subdivision (a) through specified conditions involving a NIST conforming labeling scheme. The device must meet or exceed its baseline product criteria, satisfy a conformity assessment including third-party testing, inspection or certification, and bear the scheme’s binary label. Section 1798.91.05(d) defines the scheme by reference to NIST’s February 4, 2022 white paper and revisions or successor publications.
Check those statutory conditions and the actual scheme evidence before relying on this option. A claim that a product is “NIST aligned” does not establish them. Any effect under California law also leaves the EU conformity assessment to be addressed. Our Cyber Trust Mark and CRA guide examines the evidence potentially available from that US program.
Cyber Resilience Act work that needs its own evidence
For a product in CRA scope, assess at least these additional subjects:
- Vulnerability handling and components: Annex I Part II includes the SBOM, remediation, regular security testing, coordinated disclosure, a reporting contact and secure update distribution. Article 13(5)–(6) covers due diligence for integrated third-party components and communication with their maintainers.
- Support: Article 13(8) ties the support period to expected use and sets a five-year minimum unless expected use is shorter. Article 13(19) requires the end date to be clearly available at purchase. Existing product support terms need to be checked against those requirements.
- Regulatory reporting: Article 14 applies from September 11, 2026. Its actively exploited vulnerability and severe incident notifications use the Single Reporting Platform, including the 24-hour early warning and 72-hour notification stages and the separate final-report deadlines. Article 14(8) also requires informing impacted users, and where appropriate all users, including where necessary about mitigation and corrective measures. A state-law security assessment does not establish this reporting capability.
- EU conformity: determine classification and the applicable Article 32 procedure, assemble Annex VII documentation and meet the declaration and CE-marking duties in Article 13(12). The main application date is December 11, 2027, under Article 71.
Read Article 13, Article 14, Article 32 and Article 71 for the legal requirements.
A practical first-use review
For a home camera, trace the first-use setup, local and remote interfaces, account recovery, factory reset and transfer to another owner. Compare the existing authentication tests with the actual EU firmware and companion app. Then check update delivery and the security of data retained on the device.
This is an implementation example based on the state authentication provisions and CRA Annex I. The CRA does not mandate this particular test sequence.
In the regulation
Related guides
- From the US Cyber Trust Mark to EU Cyber Resilience Act Compliance Reuse Cyber Trust Mark testing and product-security evidence for the EU Cyber Resilience Act. Check scope, support periods, reporting and conformity obligations.
- US Federal Software and IoT Procurement Evidence for the EU Cyber Resilience Act Use evidence from US federal software and IoT contracts for the EU Cyber Resilience Act, with current OMB policy, NIST guidance and product gap checks.