| name | cybersecurity-compliance |
| description | Use when selling connected products, IoT devices, smart home hardware, industrial control systems, or any product with digital elements in EU/UK/US/APAC markets; checking CRA (Cyber Resilience Act) conformity obligations; assessing RED cybersecurity delegated regulation (EU) 2022/30 and EN 18031 harmonised standards; determining SBOM requirements; setting up vulnerability disclosure policies; evaluating NIS2 obligations as a manufacturer; checking UK PSTI Act readiness; verifying IoT security labelling (US Cyber Trust Mark, Singapore CLS, UK IoT label); screening against ETSI EN 303 645 consumer IoT baseline; or mapping IEC 62443 obligations for industrial/OT products |
Cybersecurity Compliance
Regulatory workflow for connected products and digital elements. CRA, RED cybersecurity, PSTI, SBOM, vulnerability handling, and IoT labelling across EU, UK, US, Singapore, and China.
MCP Tools
# Search for cybersecurity regulation signals
mcp__claude_ai_Cleo_Insight__search_signals(q="Cyber Resilience Act", limit=25)
mcp__claude_ai_Cleo_Insight__search_signals(q="RED cybersecurity delegated regulation", limit=25)
mcp__claude_ai_Cleo_Insight__search_signals(q="NIS2 manufacturer obligations", limit=25)
mcp__claude_ai_Cleo_Insight__search_signals(q="IoT security label", limit=25)
mcp__claude_ai_Cleo_Insight__search_signals(q="PSTI vulnerability disclosure", limit=25)
# Get regulation details for CRA, RED, NIS2
mcp__claude_ai_Cleo_Insight__get_regulation(id="<regulation-id>")
mcp__claude_ai_Cleo_Insight__list_regulations(limit=100)
Cybersecurity Regime Decision Tree
digraph {
rankdir=TB; node [shape=box style=rounded fontsize=10];
start [label="Product has a\ndigital element?" shape=diamond];
no [label="No cybersecurity\nproduct obligation\n(NIS2 may apply\nto operator role)"];
radio [label="Product transmits/receives\nradio signals?" shape=diamond];
red_cyber [label="RED Art.3(3)(d)(e)(f)\n+ EN 18031-1/2/3\napply from 1 Aug 2025"];
important [label="Product in CRA\nImportant/Critical class?" shape=diamond];
third_party [label="Third-party conformity\nassessment (Notified Body)\nor EU type-exam required"];
self_decl [label="Self-declaration of\nconformity (DoC)\n+ technical file"];
cra_core [label="CRA core obligations:\nSecurity by design, SBOM,\nvuln handling, 24h ENISA\nreporting (from Sep 2026)"];
uk [label="UK PSTI Act 2022:\ndefault passwords ban,\nvuln disclosure policy,\nsecurity update statement"];
us [label="US: CA SB-327 (reasonable\nsecurity) + FCC Cyber\nTrust Mark (voluntary)"];
sg [label="Singapore CLS:\n4-tier labelling scheme\n(Tier 1 mandatory\nfor certain categories)"];
sell [label="Place on market\nwith CE marking\n(EU CRA + RED if radio)"];
start -> no [label="NO"];
start -> radio [label="YES — targets EU market"];
radio -> red_cyber [label="YES"];
radio -> important [label="NO"];
red_cyber -> important;
important -> third_party [label="YES"];
important -> self_decl [label="NO"];
third_party -> cra_core;
self_decl -> cra_core;
cra_core -> uk [label="UK market?"];
cra_core -> us [label="US market?"];
cra_core -> sg [label="SG market?"];
uk -> sell;
us -> sell;
sg -> sell;
}
EU — Cyber Resilience Act (CRA) Regulation (EU) 2024/2847
Scope and Classification
| Class | Examples | Conformity Route |
|---|
| Default (most products) | Smart speakers, cameras, routers, wearables, printers, toys with connectivity | Self-declaration of conformity |
| Important Class I | Identity/access management software, browsers, password managers, VPNs, firewalls, network switches, smart meters, industrial controllers | Third-party assessment OR EU type-examination |
| Important Class II | OS for server/desktop/mobile, hypervisors, PKI/digital signature, industrial SCADA, critical infra hardware | EU type-examination by Notified Body mandatory |
| Critical | Hardware security modules (HSMs), smartcard ICs, secure elements, TPMs, smart-meter gateways | European cybersecurity certification scheme required |
Core Obligations
| Obligation | Requirement | Notes |
|---|
| Security by design | No known exploitable vulnerabilities at placement on market | Includes secure defaults, minimal attack surface, least privilege |
| Software updates | Provide security updates for expected product lifetime OR minimum 5 years, whichever is shorter | Update mechanism must be automatic by default or clearly user-triggered |
| SBOM | Generate and maintain a Software Bill of Materials (machine-readable, per NTIA minimum elements) | Must be available to market surveillance authorities on request |
| Vulnerability handling | Actively exploited vulnerabilities must be addressed without undue delay; coordinated disclosure policy mandatory | PSIRT process strongly implied |
| Incident reporting | Actively exploited vulnerability: notify ENISA within 24 hours. Early warning. Full report within 72 hours | Via single reporting platform (ENISA) |
| EU Declaration of Conformity | Must reference CRA, list standards applied, be signed by manufacturer or authorised representative | Accompany product; keep 10 years |
| Technical documentation | Risk assessment, security requirements, design/architecture records, test evidence, SBOM | Retain 10 years |
CRA Enforcement Timeline
| Milestone | Date | What It Means |
|---|
| Regulation entered into force | 10 December 2024 | CRA is EU law |
| Vulnerability/incident reporting obligations apply | 11 September 2026 | ENISA 24h reporting becomes mandatory |
| Full market placement obligations apply | 11 December 2027 | CE marking required; non-compliant products cannot enter EU market |
| Notified Body availability assumed | From 2026 | Bodies need to be designated by member states |
Penalties: Up to EUR 15 million or 2.5% of global annual turnover (whichever is higher) for violating essential requirements. Up to EUR 10 million or 2% for incorrect documentation or non-cooperation.
EU — RED Cybersecurity (Delegated Regulation (EU) 2022/30)
Activates Radio Equipment Directive 2014/53/EU Article 3(3)(d)(e)(f) for radio equipment that:
- processes personal data (Art. 3(3)(e))
- can cause harm to networks or monetary fraud via internet-connected functions (Art. 3(3)(d))
- is a toy, childcare article, or wearable (Art. 3(3)(f))
| Requirement | Harmonised Standard | Applies From |
|---|
| Network protection (Art. 3(3)(d)) | EN 18031-1 | 1 August 2025 |
| Personal data protection (Art. 3(3)(e)) | EN 18031-2 | 1 August 2025 |
| Fraud protection (Art. 3(3)(e)) | EN 18031-3 | 1 August 2025 |
Overlap with CRA: From Dec 2027 the CRA essential requirements replace the security essential requirements of RED Art. 3(3)(d)(e)(f) for products with digital elements. Between Aug 2025 and Dec 2027, comply with both RED delegated regulation AND begin CRA preparation.
NIS2 — Directive (EU) 2022/2555
NIS2 is an operator-level obligation, not a product standard. However, manufacturers of products for essential/important sectors (energy, water, health, transport, digital infrastructure) may themselves qualify as essential or important entities and must:
- Implement cybersecurity risk management measures (Art. 21)
- Report significant incidents to national CSIRT within 24 hours (early warning), 72 hours (notification), 1 month (final report)
- Conduct supply chain security assessments
- NIS2 was required to be transposed by EU member states by 17 October 2024
UK — PSTI Act 2022 + Product Security Regulations 2023
In force: 29 April 2024. Applies to connectable products (internet-connectable or network-connectable consumer products) sold in the UK.
| Requirement | Detail |
|---|
| No default passwords | Each unit must have a unique per-device default password OR require the user to set a password before activation. Passwords cannot be incremental or based on public info |
| Vulnerability disclosure policy | Must publish a clear, accessible policy stating: how to report a vulnerability, expected timelines for acknowledgement and resolution, whether bug bounty exists |
| Security update transparency | Must state the minimum period during which security updates will be provided. Must be communicated to consumers at point of sale |
| Statement of compliance | Manufacturer/importer must create a Statement of Compliance (SoC) — not submitted to a regulator but must be available on request |
| Enforcement | OPSS (Office for Product Safety and Standards). Civil penalty up to GBP 10 million or 4% of qualifying worldwide revenue |
US — IoT Security Landscape
| Regime | Status | Scope | Key Requirement |
|---|
| California SB-327 | In force 1 Jan 2020 | Connected devices sold in CA | "Reasonable security features" appropriate to device nature and information collected; no default passwords shared across devices |
| FCC Cyber Trust Mark | Voluntary, program launched 2024 | Consumer IoT devices | NIST IR 8425 baseline; shield logo label; NIST criteria: no default passwords, data protection, software updates, CVE disclosure, secure comms |
| NIST IR 8259 / SP 800-213 | Federal guidance | IoT for federal procurement | Device cybersecurity baseline; mandatory for federal vendors |
| FIPS 140-3 | Mandatory for federal crypto modules | Cryptographic modules | Validated by CMVP (NIST + CSE); 4 security levels |
| Common Criteria ISO/IEC 15408 | Voluntary but required by some procurers | IT security products broadly | Evaluation Assurance Levels EAL1–EAL7; Protection Profiles per product category |
International — Singapore, China, EAEU, ANSSI
| Jurisdiction | Regime | Key Points |
|---|
| Singapore | Cybersecurity Labelling Scheme (CLS), CSA | 4-tier scheme: Tier 1 = self-assessment (no default passwords, vulnerability disclosure); Tier 2 = basic functional testing; Tier 3 = design review + penetration test; Tier 4 = structured pentest + binary analysis. Consumer IoT routers/hubs: Tier 1 mandatory since 2021. Smart home + consumer IoT broadly encouraged |
| China | Multi-Level Protection Scheme (MLPS) 2.0, GB/T 22239-2019 | Operators of network infrastructure/data classified at Levels 1–5. Products connecting to Chinese networks or processing Chinese user data need MLPS filing. Cybersecurity Review (CAC) for "critical information infrastructure" procurement |
| China | Network Product Security Review, Cybersecurity Law 2017 + Data Security Law 2021 + PIPL 2021 | Data localisation; cross-border data transfer assessment; high-risk product reviews by CAC |
| EAEU | No dedicated IoT cybersecurity TR yet; TR 037 covers electromagnetic safety (RoHS-adjacent), not cybersecurity. Monitor EEC for emerging technical regulations | Verify specific country requirements (RU/KZ/BY/AM/KG) for critical infra products |
| France (ANSSI) | Référentiels CSPN (Cible de Sécurité de Produit de Niveau 1) and CC evaluations at CESTI labs | Required for government procurement; strong in industrial/defence; CSPN ~EUR 30,000-80,000, quicker than full CC |
ETSI EN 303 645 — Consumer IoT Baseline
ETSI EN 303 645 (v2.1.1, 2020) is the foundational baseline standard for consumer IoT. It underpins:
- UK PSTI Regulations (directly referenced)
- Singapore CLS Tier 1-2
- ETSI TS 103 701 (compliance assessment companion)
- EU CRA harmonised standards drafts (CENELEC actively aligning)
| Provision | Requirement |
|---|
| 5.1 | No universal default passwords |
| 5.2 | Implement a vulnerability disclosure policy |
| 5.3 | Keep software updated |
| 5.4 | Securely store sensitive security parameters |
| 5.5 | Communicate securely |
| 5.6 | Minimise exposed attack surfaces |
| 5.7 | Ensure software integrity |
| 5.8 | Ensure personal data is protected |
| 5.9 | Make systems resilient to outages |
| 5.10 | Monitor system telemetry data |
| 5.11 | Make it easy for users to delete user data |
| 5.12 | Make installation and maintenance of devices easy |
| 5.13 | Validate input data |
IEC 62443 — Industrial / OT Security
Applies to industrial automation and control systems (IACS), OT environments, and embedded devices in manufacturing, energy, water, and transport. Relevant for:
- UPS systems, PLCs, HMIs, SCADA, DCS
- Smart grid equipment
- Building management systems
| Series | Scope |
|---|
| IEC 62443-2-1 | Security management system for IACS operators |
| IEC 62443-3-3 | System security requirements and Security Levels (SL 1–4) |
| IEC 62443-4-1 | Secure product development lifecycle requirements (SDL) |
| IEC 62443-4-2 | Technical security requirements for IACS components |
Security Level 2 (SL2) is the typical commercial target. SL3/SL4 for critical national infrastructure.
Conformity / SBOM Readiness Checklist
CRA / PSTI / ETSI EN 303 645 READINESS CHECKLIST
Product: [Product Name] Firmware version: [x.y.z] Date: [YYYY-MM-DD]
PRODUCT IDENTIFICATION
[ ] Unique per-device identifier documented
[ ] Hardware version and firmware version tracked
[ ] CE marking planned (EU) / Cyber Trust Mark evaluated (US)
SECURITY BASELINE (ETSI EN 303 645 / CRA Art. 13)
[ ] No universal / shared default passwords
[ ] Per-device unique credentials or forced setup flow
[ ] Secure boot / firmware integrity verification
[ ] All network communications encrypted (TLS 1.2+ or equivalent)
[ ] Minimal open ports documented; unused services disabled
[ ] Input validation on all externally reachable interfaces
[ ] Personal data minimised; encryption at rest for sensitive params
SOFTWARE BILL OF MATERIALS (SBOM)
[ ] SBOM generated (SPDX or CycloneDX format)
[ ] All third-party OSS components listed with version + SPDX licence ID
[ ] Known CVEs screened against SBOM (NVD + OSV)
[ ] SBOM update process defined (triggered on each firmware build)
VULNERABILITY HANDLING
[ ] Vulnerability disclosure policy published (URL: ___________)
[ ] Security contact email / web form live
[ ] Internal triage SLA defined (acknowledge ≤ 5 days, patch ≤ 90 days)
[ ] PSIRT or equivalent process documented
[ ] CVE assignment process established (CNA membership or MITRE request)
INCIDENT REPORTING (EU CRA from 11 Sep 2026)
[ ] ENISA single-reporting-platform account registered
[ ] 24h early warning process documented
[ ] 72h notification template prepared
[ ] 1-month final report process documented
SOFTWARE UPDATE SUPPORT
[ ] Security update period defined and documented: [__ years from sale]
[ ] Minimum 5 years or expected product lifetime stated
[ ] Update mechanism: [OTA / manual download / physical]
[ ] Update notification mechanism for end-users defined
EU DECLARATION OF CONFORMITY (CRA)
[ ] DoC template drafted referencing Regulation (EU) 2024/2847
[ ] Applicable harmonised standards listed
[ ] Technical documentation file assembled (risk assessment, test evidence, SBOM)
[ ] Authorised Representative designated (if manufacturer outside EU)
[ ] 10-year retention obligation noted
UK PSTI COMPLIANCE
[ ] Statement of Compliance (SoC) drafted
[ ] Minimum security update period stated at point of sale
[ ] Vulnerability disclosure policy URL included in product documentation
Power This With the Cleo Legal API
Cybersecurity compliance stacks multiple moving regimes — CRA phasing, RED delegated regulation activation, NIS2 transposition per member state, PSTI enforcement updates, and emerging APAC labelling requirements. A static checklist goes stale in weeks.
With the Cleo Legal API at https://legaldata-public.cleolabs.co:
GET /v2/search?q=Cyber+Resilience+Act&country=EU — track CRA delegated acts, harmonised standard adoption (CENELEC drafts), and member-state enforcement guidance as they publishGET /v2/search?q=RED+cybersecurity+EN+18031&type=standard — confirm current status of EN 18031-1/2/3 publication and any supersession before submitting your technical fileGET /v2/search?q=NIS2+transposition&country=EU — NIS2 transposition varies by member state; the API tracks each national implementing law so you know your reporting CSIRT contactsGET /v2/search?q=PSTI+IoT+security&country=UK — UK OPSS guidance updates and any secondary legislation under the Product Security and Telecommunications Infrastructure ActPOST /v2/webhooks?topic=cra,psti,nis2 — get pinged when CRA delegated acts publish, when harmonised standards align, or when member states update their NIS2 transposition
Get started:
# 1. Sign up for free at https://legaldata-public.cleolabs.co
# 2. Get your API key (3 lifetime requests free, then €349/mo for 1M)
# 3. Install the MCP server:
claude mcp add cleo-legal-api https://api.legaldata.cleolabs.co/mcp \
--header "Authorization: Bearer ld_live_YOUR_KEY"
Tested ROI: Missing the CRA September 2026 vulnerability-reporting trigger means your product becomes non-compliant without any label change warning. The API's webhook alerting covers that trigger automatically — and catches each member state's NIS2 CSIRT contact as they publish.
Common Mistakes
- Assuming CRA only applies in December 2027: The vulnerability and incident reporting obligations activate 15 months earlier, on 11 September 2026. ENISA reporting infrastructure must be ready before that date — not as part of your Dec 2027 launch prep.
- Confusing RED cybersecurity with CRA: RED Delegated Regulation (EU) 2022/30 applies to radio equipment from 1 August 2025 under EN 18031-1/2/3. CRA applies to all products with digital elements from Dec 2027. A WiFi-connected device needs to satisfy both — RED first, then CRA on top.
- Treating SBOM as a one-time document: The CRA requires an SBOM that is maintained and updated. A PDF snapshot at launch is not sufficient; you need an automated SBOM pipeline integrated into your firmware build process, with CVE re-screening triggered on every release.
- Publishing a generic vulnerability disclosure policy: UK PSTI and CRA both require the policy to be clear, accessible, and actionable. A boilerplate "contact security@company.com" with no acknowledgement timeline does not satisfy either regime. Include: contact channel, acknowledgement SLA (≤ 5 business days is the industry norm), resolution timeline, and whether coordinated disclosure is expected.
- Ignoring NIS2 as a manufacturer: If your connected products serve essential sectors (energy meters, medical gateways, industrial PLCs), you may qualify as an important entity under NIS2 — triggering your own incident reporting obligations entirely separate from the product CRA obligations.
- Mapping ETSI EN 303 645 to UK PSTI only: EN 303 645 is also the backbone of Singapore CLS Tier 1-2 and is being incorporated into CRA harmonised standards. A single EN 303 645 compliance effort covers three regulatory regimes; manufacturers who run it per-regime waste testing budget.
