
AI-ready knowledge base of security & compliance regulations for hardware and connected-device manufacturers - structured, indexed, and machine-readable for LLMs and agents.
A fact-checked, open reference on the EU laws that govern hardware and IoT cybersecurity — CRA, RED, NIS2, and the Cybersecurity Act/EUCC, in one place instead of four.
Prepared by Platanor Technologies (platanor.com) — an embedded security firm for IoT device manufacturers.
Contents: Quick start · What this is · Repository structure · Methodology · Using with an LLM · Claude Skill · Feedback · License · Discussions
cra/faq.md, red/faq.md, nis2/faq.md, or csa/faq.md — each is a practical Q&A for hardware/IoT manufacturers, no legal background required.cra/product-risk-classes.md and red/essential-requirements.md, does a Wi-Fi-connected baby monitor need a notified body, or can we self-assess?"primary-sources/ — full official text, chunked by article.This is NOT legal advice. The materials in this repository are a reference knowledge base on the main pieces of EU law that touch hardware and IoT cybersecurity — the Cyber Resilience Act (Regulation (EU) 2024/2847), the Radio Equipment Directive (Directive 2014/53/EU and its cybersecurity delegated act), the NIS2 Directive (Directive (EU) 2022/2555), and the Cybersecurity Act (Regulation (EU) 2019/881, including the EUCC certification framework) — prepared to help you orient yourself in the topic, not to inform legal or compliance decisions.
Hardware and IoT manufacturers selling into the EU are increasingly subject to more than one regulation at once — the CRA governs the product, RED governs radio equipment specifically (with its own overlapping cybersecurity requirements), NIS2 governs certain organisations in critical sectors (including some manufacturers and their customers), and the Cybersecurity Act provides the voluntary certification framework (EUCC) that sits alongside all of them. This repository exists because treating any one of these in isolation gives an incomplete picture — a manufacturer can be in full CRA compliance and still miss a RED-specific requirement, or misjudge whether NIS2 reaches them indirectly through a customer's supply-chain obligations.
The repository has two layers:
cra/, red/, nis2/, csa/) — shorter, structured reference documents per regulation: overview, definitions/scope, essential requirements or obligations, deadlines, penalties, and a practical FAQ. Easy to use for a quick grasp of a topic, and each one is written to flag how it relates to the other three regulations, not just to stand alone.primary-sources/) — the full official text of each regulation and related act, unmodified. The source of truth for exact quotes, for humans and LLMs alike.The processed guides have been fact-checked against the primary text of each regulation and related sources (M/606, delegated/implementing acts) — methodology described below.
| File | What it covers |
|---|---|
cra/overview.md | Adoption context, scope, structure of the regulation (chapters and annexes) |
cra/definitions.md | Official definitions and terminology (product with digital elements, RDPS, critical/important product, etc.) |
cra/essential-requirements.md | Annex I essential cybersecurity requirements + status of harmonised standards development (mandate M/606); cross-referenced against ENISA's Secure by Design and Default Playbook |
cra/product-risk-classes.md | Product risk classification: Default, Important Class I/II, Critical |
cra/obligations-by-role.md | Manufacturer, importer, and distributor obligations (Chapter II) |
cra/timeline-deadlines.md | Key deadlines and transitional provisions |
cra/vulnerability-reporting.md | Vulnerability and severe-incident reporting (Article 14) |
cra/penalties-enforcement.md | Penalties and market surveillance |
cra/self-assessment-maturity-model.md | ENISA SME Cyber Resilience Maturity Assessment Model |
cra/faq.md | Practical FAQ for hardware/IoT manufacturers |