Free CRA Conformity Self-Assessment (2026) — Annex I, Excel

Free CRA Conformity Self-Assessment (Annex I, Excel)

This free CRA conformity self-assessment is a downloadable Excel workbook (plus PDF field guide and machine-readable Markdown) that walks a manufacturer through the four questions Regulation (EU) 2024/2847 makes decisive: is the product in scope, which class is it (default, important Class I or II, or critical), which Article 32 conformity assessment route is lawful for that class — and does it meet every requirement in Annex I Part I (the 14 product properties) and Part II (the 8 vulnerability-handling processes)? Status dropdowns, evidence columns and a documentation-and-reporting readiness sheet included. Ungated.

The timing matters more than most manufacturers realise. The reporting duties in Article 14 apply from 11 September 2026 — including for products already on the market — and the full essential-requirements regime lands on 11 December 2027. Notified bodies can only be designated from 11 June 2026, so assessment capacity will be scarce exactly when Class I and II manufacturers need it. The self-assessment exists to answer, early and on paper: which route do we need, and how big is the gap?

Key takeaways

1. Classification comes first, and it follows core functionality. Implementing Regulation (EU) 2025/2392, adopted 28 November 2025, gives binding technical descriptions for all 26 important and critical categories — and classifies products by what they primarily are, not what they contain. A router with a built-in firewall is a router; a standalone firewall is Class II. The workbook's first sheet walks all 19 + 4 + 3 categories with that test.
2. Self-assessment is the default route — but a conditional one. Module A internal control is open to every default product. For important Class I products it is available only where harmonised standards, common specifications or EUCC certificates are fully applied — and with CRA harmonised standards still in development in mid-2026 (standardisation request M/606: 41 standards, accepted by CEN, CENELEC and ETSI on 3 April 2025), that condition is hard to meet today. Plan Class I as a notified-body route until standards are cited in the OJEU.
3. Annex I is checkable — so check it. Part I point (2) applies "where applicable" on the basis of the cybersecurity risk assessment (Article 13(2)), which means every "not applicable" needs a documented justification, not a shrug. The checklist sheets enforce exactly that.
4. Reporting readiness is a 2026 problem, not a 2027 one. From 11 September 2026, actively exploited vulnerabilities trigger a 24-hour early warning, 72-hour notification and 14-day final report via ENISA's Single Reporting Platform — severe incidents run 24h/72h/1 month. The readiness sheet tracks the process, the platform access and the Article 14(8) user-information duty.
5. The fines are DORA-scale. Annex I or Article 13/14 breaches reach EUR 15 million or 2.5% of worldwide turnover (Article 64) — and non-compliant products can be withdrawn from the market on top.

What's inside the workbook

Sheet	What it holds	Why it matters
1. Scope & Classification	Product facts, the Article 2 scope test (including the sectoral exclusions and the SaaS boundary), and the full Annex III / Annex IV category checklists with the core-functionality rule	Everything downstream — route, notified body, cost — depends on this answer
2. Conformity Route	The Article 32 decision logic: lawful modules per class, the harmonised-standards condition for Class I, the FOSS exception, notified-body flag, market-entry timing vs 11 Dec 2027	Choosing an unlawful route means redoing the assessment under time pressure
3. Annex I Part I	The 14 product-property requirements — point (1) plus (2)(a)–(m) — each with status, evidence reference, owner and notes	The substance of CRA conformity
4. Annex I Part II	The 8 vulnerability-handling requirements: SBOM, remediation, testing, disclosure, CVD policy, contact, secure updates, free dissemination	Process duties that run for the whole support period
5. Docs & Reporting	Annex VII technical-documentation elements, the Article 13(8) support period (minimum 5 years unless shorter expected use), Article 14 readiness, CE marking, penalty exposure	The file a notified body or market-surveillance authority asks for

Status values are Compliant / Partial / Gap / Not applicable (justified) throughout, with dropdown validations, and a worked example uses a fictional endpoint-monitoring agent to show a completed classification decision. The machine-readable Markdown variant carries the full field definitions, the classification enums, and the route-derivation logic as pseudocode, so an AI agent can classify a product, derive the lawful routes and produce a gap report from the file alone.

How to use it

1. Run the scope test honestly. Software or hardware with a direct or indirect data connection, placed on the EU market commercially, is in — unless a sectoral regime (medical devices, aviation, vehicles, marine equipment) already covers it. Pure SaaS is out of scope unless it is the remote data processing solution of a product.
2. Classify by core functionality. Walk the 19 Class I, 4 Class II and 3 critical categories and check any match against the technical descriptions in CIR (EU) 2025/2392. Record the reasoning — market-surveillance authorities can ask for it, and a wrong class invalidates the route you chose.
3. Derive the route, then sanity-check the standards condition. If you are Class I and counting on self-assessment, verify that harmonised standards covering the relevant requirements are actually cited in the OJEU — not merely drafted — before you rely on Module A.
4. Work the two Annex I checklists. Anchor every status in evidence (architecture docs, test reports, policy documents), and justify every N/A from the risk assessment. Part II is process, not product: an SBOM you generated once is a Partial, not a Compliant.
5. Close the documentation and reporting gaps. Annex VII documentation must exist before placing on the market; the support period must be determined and stated (at least 5 years unless a shorter use time is genuinely expected); the Article 14 process must be live by 11 September 2026.

Legal basis

• Regulation (EU) 2024/2847 (Cyber Resilience Act), Article 32 and Annex VIII — the conformity assessment procedures: internal control (Module A), EU-type examination plus conformity to type (Modules B and C), full quality assurance (Module H), and European cybersecurity certification schemes; with the class-dependent restrictions described above and the public-documentation exception for free and open-source software.
• Annex III and Annex IV, as clarified by Commission Implementing Regulation (EU) 2025/2392 — the important (Class I and II) and critical product categories with binding technical descriptions, and the core-functionality classification principle.
• Annex I — Part I product-property requirements (point (1) and point (2)(a)–(m)) and Part II vulnerability-handling requirements (points (1)–(8)); applicable via Article 6 and Article 13.
• Article 13 — the manufacturer obligation set: the cybersecurity risk assessment (13(2)–(3)) that drives Annex I applicability, the support period of at least 5 years (13(8)), and the documentation duties.
• Article 14 — reporting of actively exploited vulnerabilities and severe incidents from 11 September 2026 via the single reporting platform (Article 16), with the 24h / 72h / 14-day and 24h / 72h / 1-month ladders.
• Article 64 — penalties: up to EUR 15 million or 2.5% of worldwide annual turnover for Annex I / Article 13 / Article 14 breaches.

For the full regulatory picture, see our guides to the Cyber Resilience Act and CRA Articles 13 and 14.

UK and Norway/EEA

UK: there is no UK CRA equivalent yet. The PSTI regime, in force since 29 April 2024, covers consumer connectable products with a much narrower baseline (password rules, vulnerability disclosure policy, update-period transparency) — a PSTI-compliant product is nowhere near CRA-conformant, so UK manufacturers selling into the EU should assess against the CRA directly. Norway/EEA: the CRA is marked EEA-relevant and is expected to be incorporated into the EEA Agreement; Norwegian, Icelandic and Liechtenstein manufacturers placing products on the EU single market are in scope for practical purposes regardless of the incorporation timetable.

From self-assessment to buyer-visible evidence

The workbook tells you where you stand. Increasingly, your buyers ask the same questions — procurement teams now screen hardware and software vendors for CRA readiness well before 2027. Orbiq publishes the evidence this assessment produces — security advisories, SBOM and update policies, support-period statements — in a governed Trust Center, so the same work answers the regulator and the customer once. For the Annex I Part II disclosure duty specifically, pair this workbook with our CRA vulnerability advisory template.

Sources & References

1. Regulation (EU) 2024/2847 (Cyber Resilience Act) — full text — Articles 13, 14, 32, 64; Annexes I, III, IV, VII, VIII.
2. Commission Implementing Regulation (EU) 2025/2392 — technical descriptions of important and critical product categories; adopted 28 November 2025.
3. European Commission — CRA summary of the legislative text — application dates, classification, conformity procedures.
4. European Commission — CRA standardisation — standardisation request M/606 with 41 standards.
5. CEN/CENELEC — CRA standardization request officially accepted — accepted 3 April 2025.
6. ENISA — Single Reporting Platform (SRP) — operational by 11 September 2026 for Article 14 reports.
7. European Commission — CRA reporting obligations — the Article 14 deadlines and platform.
8. UK Product Security and Telecommunications Infrastructure Act 2022 — the UK product-security regime.

Related Reading

• Cyber Resilience Act: Requirements, Scope & Deadlines
• CRA Articles 13 & 14: Manufacturer Obligations and Reporting
• Free Template: CRA Vulnerability Advisory (DOCX + filled sample) — the Annex I Part II disclosure sibling