Hardware Compliance Knowledge Base

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 · Technical reference · Methodology · Using with an LLM · Claude Skill · Feedback · License · Discussions

Quick start

• Just want an answer? Open 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.
• Working with an LLM? Drop a processed guide into your prompt and ask, e.g.: "Using 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?"
• Need the exact legal wording? Every processed guide links back to its source in primary-sources/ — full official text, chunked by article.
• Need the engineering, not just the regulation? technical/ covers how to actually build the thing the law asks for — SBOM generation, secure boot, device identity, OTA updates, and CVE monitoring — at the depth an embedded engineer needs, not a compliance summary.

⚠️ Disclaimer — read before use

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.

• We make an effort to keep facts accurate and checked against the primary text of each regulation (EUR-Lex), but we give no guarantee of completeness or currency — this legislation and its supporting standards (M/606, harmonised standards, delegated/implementing acts) are still under development and can change.
• Before making any decision about your product's or organisation's compliance — consult a qualified lawyer or regulatory advisor who can assess your specific case.
• This is a living, growing knowledge base: materials are regularly expanded, corrected, and re-verified. What is accurate today may have changed in a deadline or an interpretation — always check a file's last-verified date against the current state of the regulation.
• Found an error or inaccuracy? We'd appreciate the feedback (see "Feedback" below).

What this is

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 three layers:

1. Processed guides (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.
2. Technical reference (technical/) — engineering-depth pages on how to actually implement what the regulations ask for: SBOM generation for firmware, secure boot across platforms, device identity and provisioning, OTA update architecture, and continuous vulnerability monitoring. Written for the person who has to build the thing, not just document that it exists.
3. Primary sources (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); the technical reference pages have been fact-checked against vendor documentation, RFCs, and other primary technical sources — methodology described below.

Repository structure

CRA — Cyber Resilience Act (Regulation (EU) 2024/2847)

RED — Radio Equipment Directive (2014/53/EU + cybersecurity delegated act)

NIS2 — Directive (EU) 2022/2555

CSA — Cybersecurity Act / EUCC (Regulation (EU) 2019/881)

Technical reference (technical/)

Engineering-depth pages, not regulatory summaries — each one names the CRA requirement it relates to, then goes deeper than any compliance document would on how implementations actually work and where they actually break.

Cross-cutting and primary sources

Methodology and sourcing

Every statement is checked against a source-priority order: primary text of the regulation (EUR-Lex) > official related documents (standardisation mandates, delegated/implementing acts) > secondary sources > our own analysis. Where there is an open question or a not-yet-finalised rule (e.g. the draft amendment to M/606), this is explicitly flagged in the text as pending official confirmation, not stated as settled fact.

How to use this with an LLM

These files are designed to serve as context for language models (ChatGPT, Claude, Gemini, etc.) — for example:

• attach the relevant .md file (or several) as context to your prompt when asking a model about CRA, RED, NIS2 or CSA/EUCC — the processed guides are enough for a quick answer; for an exact article quote, use a file from primary-sources/;
• use the repository as a source for a RAG pipeline or your own hardware-compliance assistant — the primary-source files in primary-sources/ are already split by ### Article N headings, which are natural chunking boundaries;
• the markdown format has no complex layout — easy to parse and chunk;
• the repository root has an llms.txt — a concise, machine-readable index of all files for AI agents.

Since a model's answers will be grounded in these files, the disclaimer above applies to any LLM output built on this base too — those answers are likewise not legal advice.

Installing this as a Claude Skill

This repository has a SKILL.md file at its root, alongside the reference files — so it can be installed as a Claude Skill: a packaged capability that Claude loads automatically whenever a question matches its topic, instead of you having to attach files by hand every time. Installation differs by product, since Skills don't sync across surfaces:

Claude Code (filesystem-based, no upload step):

git clone https://github.com/Platanor/hardware-compliance-handbook.git ~/.claude/skills/hardware-compliance-handbook

Use ~/.claude/skills/ for a personal install available in every project, or clone into a project's own .claude/skills/ folder to scope it to that project. Claude Code discovers SKILL.md automatically — no restart or extra config needed.

claude.ai, Claude Desktop, or Cowork:

1. Clone or download this repository, then zip its contents (e.g. zip -r hardware-compliance-knowledge-base.zip . run from inside the repo folder).
2. In your Claude settings, go to Settings → Features → Skills (requires a Pro, Max, Team, or Enterprise plan with code execution enabled) and upload the zip file.

Skills uploaded this way are tied to your individual account — each teammate who wants it needs to upload it separately.

Claude API / your own application: upload the repository as a Custom Skill through the Skills API (/v1/skills). See Anthropic's Agent Skills documentation for the full reference.

However you install it, this remains a knowledge base, not a certified compliance tool — the disclaimer at the top of this README applies to anything Claude produces using it.

Status

Actively growing. Currently 25 processed documents across four regulations (CRA, RED, NIS2, CSA/EUCC), 5 technical reference documents (technical/), plus 8 primary-source mirrors; more material is planned as the underlying legislation develops (new harmonised standards, delegated/implementing acts, Commission guidance, and the still-unmirrored EUCC scheme implementing act) and as the technical layer expands to more implementation topics.

Feedback

Found an error, an outdated date, or an inaccurate interpretation? Let us know — contact details at platanor.com, or open an issue or pull request directly. See CONTRIBUTING.md for what belongs here and how to submit a change.

Have a question, a use case to share, or want to suggest what should be covered next? Use GitHub Discussions — issues/PRs are for content fixes, Discussions is for everything else.

License

This content is distributed under the Creative Commons Attribution 4.0 International (CC BY 4.0) license.

This means you're free to copy, redistribute, adapt, and even use these materials commercially — provided you give attribution: credit Platanor Technologies (platanor.com) as the source and link to the license.

Full license text: creativecommons.org/licenses/by/4.0. Details in the LICENSE file.

If this saved you from reading four EU regulations back to back, a ⭐ on the repo helps other manufacturers find it too.