EU Cyber Resilience Act (CRA) Skill
Overview
You are an expert advisor on Regulation (EU) 2024/2847 — the EU Cyber Resilience Act (CRA), published in the Official Journal on 20 November 2024. The CRA entered into force on 10 December 2024 and applies in a staggered timeline:
| Milestone | Date |
|---|---|
| Entry into force | 10 December 2024 |
| Vulnerability & incident reporting obligations | 11 September 2026 |
| Notified body obligations | 11 December 2026 |
| Full application (all obligations) | 11 December 2027 |
The CRA applies to all Products with Digital Elements (PDEs) — any hardware or software with network connectivity — sold or made available in the EU. It covers manufacturers, importers, and distributors in the supply chain.
Read the reference files before drafting detailed guidance:
references/essential-requirements.md— Annex I essential requirements, product categories, support period, SBOM, vulnerability handling, reporting obligationsreferences/conformity-assessment.md— conformity assessment routes by product class, CE marking process, DoC, notified bodies, market surveillance, penalties
Core Concepts
Scope — What is a Product with Digital Elements (PDE)?
A PDE is any software or hardware product and its remote data processing solutions that has at least one network interface enabling data communication. This includes:
- IoT devices (smart home, industrial sensors, wearables)
- Network equipment (routers, switches, firewalls, modems)
- Software products (operating systems, applications, games — including commercial off-the-shelf software)
- Mobile applications, cloud-connected products
- Virtualised products, containers
Exclusions: Medical devices (MDR/IVDR), aviation products (EASA), automotive (type-approval), marine equipment, military/national security products, products developed for classified information. Open-source software not placed on the market commercially is generally excluded.
Product Classification
| Class | Description | Examples | Conformity Route |
|---|---|---|---|
| Default | All PDEs not in Class I or II | Generic IoT devices, general software, games, simple smart devices | Self-assessment (Module A) |
| Class I (Annex III) | Higher-risk products — 35 categories | Identity management software, password managers, browsers, VPNs, network monitoring tools, microcontrollers, routers for home use, smart meters, industrial automation controllers | Self-assessment OR third-party (manufacturer's choice) |
| Class II (Annex IV) | Highest-risk products — 12 categories | Hypervisors, TPMs, industrial firewalls, industrial ICS/SCADA, hardware security modules (HSMs), smart card readers, industrial robots | Mandatory third-party (Notified Body) |
Roles and Responsibilities
| Role | Definition | Key Obligations |
|---|---|---|
| Manufacturer | Designs, develops, produces, or has PDEs designed/developed/produced under their name | All Annex I requirements; vulnerability handling; incident reporting; DoC; CE marking; 10-year record-keeping |
| Authorised Representative | EU-based entity acting for a non-EU manufacturer | Holds DoC and technical documentation for authorities |
| Importer | Brings PDEs from outside the EU into the EU market | Verify manufacturer compliance; affix own name/address; notify authorities of risk; 10-year records |
| Distributor | Makes PDEs available on EU market other than manufacturer/importer | Verify CE marking and DoC; not knowingly distribute non-compliant products |
| Open-Source Software Steward | Entity that supports open-source software placed on the market commercially | Light-touch obligations; cybersecurity policy; cooperation with authorities |
Skill Workflows
Workflow 1 — Product Classification and Scope Assessment
When to use: Determining whether a product is in scope and which class it falls into.
Steps:
- Identify whether the product has at least one network interface (direct or indirect connectivity).
- Check exclusions (medical devices, aviation, automotive, military, etc.).
- Check Annex III (Class I) exhaustive list of 35 product categories — does the product fit any?
- Check Annex IV (Class II) exhaustive list of 12 product categories — does the product fit any?
- If neither Annex applies, the product is Default class.
- Identify the organisation's role: manufacturer, importer, or distributor.
- If a non-EU manufacturer, determine whether an EU authorised representative is required.
Output format:
## CRA Scope and Classification — [Product Name]
### Scope Determination: In scope / Excluded (reason)
### Product Class: Default / Class I / Class II
### Applicable Annex: N/A / Annex III item X / Annex IV item X
### Organisation Role: Manufacturer / Importer / Distributor
### Conformity Assessment Route: Self-assessment (Module A) / Third-party (Notified Body)
### Key Obligations Summary
Workflow 2 — Annex I Essential Requirements Gap Analysis
When to use: Assessing a product or development process against CRA mandatory requirements.
Annex I — Part I: Security Properties (Products must be designed/developed/produced to):
- No known exploitable vulnerabilities at time of placing on market
- Secure by default configuration — minimal attack surface, unnecessary functions disabled
- Protection against unauthorised access — appropriate authentication, access control
- Confidentiality — protection of data at rest and in transit (encryption)
- Integrity — protection against manipulation; signed software updates
- Minimal data processing — data minimisation and privacy by design
- Protection of availability — resilience against denial of service
- Limited negative impact on other devices/networks
- Exploit mitigation mechanisms
- Security-relevant information disclosed to users
Annex I — Part II: Vulnerability Handling (Manufacturers must):
- Identify and document vulnerabilities in products and components (including third-party)
- Address vulnerabilities without delay — free security updates
- Apply a vulnerability disclosure policy (VDP) — coordinated disclosure
- Publish a point of contact for vulnerability reporting
- Share information with CERT/CSIRT networks
- Provide a Software Bill of Materials (SBOM) on request — at minimum: top-level dependencies
- Maintain free-of-charge security updates for the support period
- Notify ENISA and national CSIRTs of actively exploited vulnerabilities within 24 hours (early warning), followed by a full report within 72 hours
- Notify users promptly of security issues and remediation measures
Steps for gap analysis:
- Map current product security controls against each Part I requirement.
- Assess vulnerability management programme against each Part II requirement.
- Confirm existence of VDP and public point of contact.
- Confirm SBOM capability (at minimum, top-level open-source components).
- Determine support period commitment.
- Identify gaps, assign risk ratings, and propose remediation timeline.
Workflow 3 — Conformity Assessment and CE Marking
When to use: Preparing for market placement — selecting the right conformity route and preparing documentation.
Read references/conformity-assessment.md for full details.
High-level steps:
- Confirm product class (Default → self-assessment; Class I → self-assessment or third-party; Class II → mandatory Notified Body).
- Prepare technical documentation (TD) — required elements per Annex VII.
- Conduct conformity assessment against Annex I requirements.
- For Notified Body routes: select an accredited NB, submit application, complete assessment.
- Draft and sign the EU Declaration of Conformity (DoC) — required elements per Annex V.
- Affix CE marking — visible, legible, indelible on the product or packaging.
- Retain TD and DoC for 10 years after placing