Claude Skills Meet EU Hardware Law: A First Look at an Agent-Readable CRA/RED/NIS2 Knowledge Base

On 11 September 2026 — this week — the Cyber Resilience Act's first hard obligation becomes enforceable. Manufacturers who become aware of an actively exploited vulnerability in a product with digital elements now have to file an early-warning notification within 24 hours, a fuller report within 72 hours, and a final report within 14 days of a fix becoming available. This isn't a paperwork footnote: under Article 64 of Regulation (EU) 2024/2847, failing the Article 14 reporting duty sits in the same top penalty tier as failing the core security-by-design obligations of Article 13 — up to €15,000,000 or 2.5% of worldwide annual turnover, whichever is higher.

Timed almost exactly with that deadline, a small, unofficial project quietly shipped something worth a closer look: a Claude Skill that packages the Cyber Resilience Act, the Radio Equipment Directive's cybersecurity rules, NIS2, and the Cybersecurity Act/EUCC certification framework as structured, agent-readable reference material. It's called hardware-compliance-handbook, maintained by Platanor Technologies, an embedded-security firm. We spent an afternoon with it: reading the source, checking its load-bearing legal claims against EUR-Lex ourselves, and thinking through whether "package a fast-moving regulation as an agent skill" is a pattern worth copying for problems outside IoT hardware.

What a Claude Skill actually is

Before judging the content, it's worth being precise about the mechanism, because it's not "upload a PDF and hope." Anthropic's own documentation describes Agent Skills as filesystem-based, progressively disclosed capability packages with three loading tiers:

Only the frontmatter sits in context by default. When a user's question matches the description, Claude reads SKILL.md off disk with a shell command, and only then does it pull in more files — a database schema, a reference doc, another regulation's FAQ — as the task actually needs them. The practical upshot: you can bundle dozens of long reference documents into a skill and pay essentially zero context cost until one of them is actually relevant. That's the mechanical reason a "compliance knowledge base as a skill" is a meaningfully different proposition from just pasting a regulation into a system prompt.

First look: hardware-compliance-handbook

The repository (verified via the GitHub API: created 12 August 2026, 26 stars, still being actively pushed as of 2 September 2026) organizes its content into three layers, and which one you reach for matters:

• Layer 1 — processed guides (cra/, red/, nis2/, csa/): topic-organized summaries for engineers and compliance leads. Each regulation's folder follows the same shape — overview.md, one or two files on the substantive obligations, a faq.md. CRA alone has ten files, from product-risk-classes.md (Default / Important Class I & II / Critical) to vulnerability-reporting.md (the Article 14 duty this post opened with).
• Layer 2 — technical reference (technical/): engineering-depth material on implementing what the law asks for — SBOM generation for embedded firmware (CycloneDX vs. SPDX, Yocto/Zephyr/Buildroot), secure boot chains across UEFI/ARM TBBR/NXP HAB/AHAB, device identity (IEEE 802.1AR, DICE), OTA update architecture (MCUboot, TUF/Uptane), and continuous CVE triage (CVSS/EPSS/KEV/VEX). This is the layer most compliance-focused resources skip entirely.
• Layer 3 — primary sources (primary-sources/): unmodified mirrors of the EU legal texts themselves, chunked by article, each with a provenance header (source URL, CELEX number, retrieval date).

The SKILL.md at the repo root is what makes it installable directly. Its description field — the only thing loaded into every conversation by default — is a dense, purpose-built trigger list ("use this skill whenever the user asks anything about CRA compliance... CRA/RED/NIS2 penalties and fines... whether NIS2 applies to a hardware manufacturer or its customers... EUCC/CSA certification... 'what happens if I don't comply'"). Installing it in Claude Code is a one-line clone into the skills directory:

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

Claude Code discovers SKILL.md automatically from there — no restart, no config file. For claude.ai or the API, the README documents the zip-upload and Skills-API paths separately, since (per Anthropic's docs above) skills don't sync across surfaces — you install once per product.

Verify, don't trust: checking the load-bearing claims ourselves

A knowledge base that will get quoted by an AI agent in front of an engineer making a real compliance decision is exactly the kind of artifact that deserves independent verification before you rely on it — the repo's own README says as much ("this is NOT legal advice... we give no guarantee of completeness or currency"). So we didn't take its claims at face value; we pulled the two regulations it leans on hardest directly from EUR-Lex and checked them line by line.

Claim 1 — CRA Article 14's deadlines and applicability. The full operative text of Regulation (EU) 2024/2847, Article 14(2), reads: an early warning notification "without undue delay and in any event within 24 hours" of the manufacturer becoming aware of an actively exploited vulnerability; a fuller vulnerability notification "within 72 hours"; and a final report "no later than 14 days after a corrective or mitigating measure is available." Article 71(2) confirms the phased rollout: the Regulation applies in full from 11 December 2027, "however, Article 14 shall apply from 11 September 2026." Both match the repo's cra/vulnerability-reporting.md and cra/timeline-deadlines.md descriptions exactly.

Claim 2 — RED's cybersecurity delegated act. The repo's red/essential-requirements.md is described as covering "Art. 3(3)(d)(e)(f) cybersecurity requirements." Pulling Commission Delegated Regulation (EU) 2022/30 directly: Article 1(1) confirms point (d) — network-harm protection — applies to "any radio equipment that can communicate itself over the internet, whether it communicates directly or via any other equipment." Article 3 of the delegated regulation confirms it "shall apply from 1 August 2024." Both check out.

Neither check surfaced an error — which is itself worth saying plainly, because "we fact-checked it and it held up" is a real, useful finding, not a non-result. It also doesn't mean you get to skip your own verification the first time this skill answers a question that actually matters for your product: the repo covers four regulations across dozens of files, we spot-checked two claims in the two we could verify fastest against a primary source, and its own README flags that several referenced items — the CRA's harmonised standards under mandate M/606, the EUCC scheme's implementing act, national NIS2 transposition details — are still moving targets. Spot-checking two facts tells you the authors are careful, not that everything downstream is current.

Why this matters beyond IoT firmware

sota.io's audience skews toward web and SaaS teams, not embedded engineers — so is a hardware-focused skill actually relevant here? Two reasons it is.

First, CRA's scope is broader than "physical device." Article 2 covers any "product with digital elements... the intended purpose of which includes a direct or indirect logical or physical data connection to a device or network" — standalone commercial software qualifies, and the regulation's recitals extend coverage to "remote data processing solutions" where the software is built by or for the manufacturer and the product can't perform one of its functions without that remote processing. Generic SaaS that isn't tied to shipping a specific product is generally outside CRA's scope, but the boundary is narrower than "hardware only," and it's worth checking against your own product before assuming you're exempt.

Second, and more durably: the actual pattern here — take a body of law that changes every few months, structure it as layered markdown with a primary-source layer underneath, and expose it to an agent through progressive disclosure instead of stuffing it into a system prompt — generalizes to any regulatory domain, not just CRA/RED/NIS2. If your team fields the same "does GDPR Article 33's 72-hour breach clock start at detection or at confirmation" question every quarter (the answer, per Article 33(1) GDPR, is "without undue delay and, where feasible, not later than 72 hours after having become aware of it" — awareness, not confirmation), a minimal internal skill costs almost nothing to build:

---
name: gdpr-breach-notification
description: Internal reference on GDPR Article 33/34 breach notification deadlines and templates. Use whenever anyone asks about breach reporting timelines, DPA notification content, or when data subjects must be informed directly.
---

# GDPR Breach Notification

## The 72-hour clock (Article 33)
Starts at *awareness*, not confirmation. See `notification-template.md`
for the required content (Art. 33(3)(a)-(d)).

## When to notify data subjects directly (Article 34)
Only if the breach is "likely to result in a high risk" to their rights.
See `high-risk-criteria.md`.

The metadata costs you ~100 tokens whether or not it ever fires. The moment someone asks a matching question, SKILL.md loads and the agent answers from your team's actual, current interpretation instead of whatever it half-remembers from training data — the same failure mode that makes an unverified skill risky is exactly the failure mode a verified one is meant to fix.

A practical tool: the Article 14 reporting clock

If you do fall under CRA and need to track the three deadlines internally, the clock math is simple enough to script rather than track in a spreadsheet:

from datetime import datetime, timedelta

def cra_article14_deadlines(awareness_time: datetime, fix_available_time: datetime | None = None):
    """CRA Art.14(2): three sequential deadlines from manufacturer awareness
    of an actively exploited vulnerability. Source: Regulation (EU) 2024/2847,
    Art.14(2)(a)-(c) -- verified against eur-lex.europa.eu/eli/reg/2024/2847/oj.
    """
    deadlines = {
        "early_warning_24h": awareness_time + timedelta(hours=24),
        "vulnerability_notification_72h": awareness_time + timedelta(hours=72),
    }
    if fix_available_time:
        # Final report: no later than 14 days after a corrective/mitigating
        # measure becomes available (not 14 days from awareness).
        deadlines["final_report_14d_post_fix"] = fix_available_time + timedelta(days=14)
    return deadlines


now = datetime.now()
clock = cra_article14_deadlines(now)
for stage, dt in clock.items():
    print(f"{stage}: {dt.isoformat()} ({'OK' if dt > datetime.now() else 'OVERDUE'})")

Note the detail that's easy to get wrong and that the code above deliberately encodes: the 14-day final-report clock for vulnerabilities runs from when a fix becomes available, not from the original awareness timestamp. Collapsing the three CRA deadlines into a single countdown — a mistake we've seen in more than one internal tracker — will make you think you're compliant on day 15 when the real clock hasn't even started yet.

What we'd actually recommend

If you're a hardware or IoT manufacturer shipping into the EU: hardware-compliance-handbook is a genuinely useful orientation tool, and its layered structure (summary → engineering detail → primary source) is a better design than most compliance content we've reviewed. Install it, use it to get oriented fast, and treat every article citation the way the repo's own README tells you to — as a pointer to check against EUR-Lex before it informs an actual decision, not as the decision itself.

If you're not in hardware: the transferable lesson is the architecture, not the content. An agent-readable knowledge base beats an agent's parametric memory of law precisely because you can update the markdown the day a deadline changes, cite the exact file a claim came from, and — as we did above — independently verify the two or three facts your business actually depends on before you let an agent repeat them to a customer or an auditor. One more thing worth a moment's thought if you build one yourself: Claude Skills execute inside Anthropic's hosted environment, so check your own data-processing agreement and region settings before piping anything regulator-sensitive through it — the skill's content can be EU-sourced and EUR-Lex-verified while the conversation still leaves the EU, and those are two separate questions worth answering separately.