CRA Checklist 2026
The definitive CRA checklist for assessing your organization’s readiness for the Cyber Resilience Act.
Last updated 22 October 2026 · Based on Regulation (EU) 2024/2847 and Implementing Regulation (EU) 2025/2392
The Cyber Resilience Act establishes new cybersecurity obligations for any product with digital elements sold in the EU. Our CRA Readiness Checklist helps you quickly assess whether your organization is prepared to meet the requirements coming into force between 2025 and 2027.
By submitting this form, you accept our Terms and acknowledge that Regulus will process your data to send the checklist. For more details, see our Privacy Policy.
Key Facts About the CRA’s Impact
The Cyber Resilience Act introduces cybersecurity obligations with an unprecedented scope across the digital product landscape. These figures show what it asks of manufacturers.
24 h
to send an early warning to the CSIRT and ENISA when a vulnerability in your product is actively exploited. In force since 11 September 2026, also for products already on the market.
5 years
minimum support period for security updates, unless the product is expected to be in use for less time. The end date has to be shown at the time of purchase.
EUR 15M
or 2.5% of worldwide annual turnover, whichever is higher: the maximum fine for breaching the essential requirements or the manufacturer's obligations.
- Product is in scopeArt. 2
- Class: important, Class IAnnex III
- Risk assessment documentedArt. 13
- Secure by defaultAnnex I
- SBOM, machine-readableAnnex I · II
- Disclosure policy publishedAnnex I · II
- Technical documentationAnnex VII
- EU declaration of conformityAnnex V
What the CRA Checklist Includes
This checklist brings together the essential criteria you need to determine how the Cyber Resilience Act affects your product and your organization. It distills the regulation into clear, actionable checkpoints so you can validate scope, risk class, obligations and required documentation without navigating the full legal text.
👉🏻 Inside you will find:
🔸 Core guidance for understanding CRA scope
🔸 Quick-reference guides on key CRA requirements:
▪️ Determining whether your product qualifies as a product with digital elements.
▪️ Validating your product’s risk class (default, important Class I, important Class II or critical).
▪️ Understanding mandatory security requirements and lifecycle obligations.
▪️ Listing all required documentation for CRA conformity.
Updated for 2026
This CRA Checklist is maintained according to the latest updates from the European Commission and evolving CRA guidance.
How the CRA Checklist Helps You
The Cyber Resilience Act introduces cybersecurity obligations with an unprecedented scope across the digital product landscape. These figures show what it asks of manufacturers.
1️⃣ Quickly identify whether the CRA applies to you and to what extent.
2️⃣ Detect compliance gaps well ahead of regulatory deadlines.
3️⃣ Facilitate alignment between product, engineering, security, and compliance teams.
4️⃣ Reduce time spent interpreting the regulation and focus on actionable steps.
Other Free CRA Templates
Access a set of complementary resources designed to accelerate your Cyber Resilience Act readiness. These templates help you structure documentation, standardize internal processes and ensure consistency across product, security and compliance workflows while preparing for CRA requirements. Available soon:
- 📝 CRA Product Classification Template
- 📚 Coordinated Vulnerability Disclosure Policy
- 📄 Technical Documentation Structure
- 🔐 Security Requirements Checklist for Manufacturers
- 🔧 Post-Market Cybersecurity Obligations Guide
- 📑 EU Declaration of Conformity (DoC) Outline
- 🧭 CRA Scope Assessment Worksheet
- 🛠️ Secure Development Lifecycle (SDL) Starter Framework
- 📊 CRA Compliance Roadmap Template
How to Use This CRA Checklist
Use this checklist to evaluate your current readiness, detect compliance gaps, guide internal conversations between engineering and compliance teams, and plan your preparation for CRA enforcement. It can be used as a standalone tool or as part of a broader CRA compliance workflow. If you need a broader strategic view, our Cyber Resilience Act compliance roadmap shows how this checklist fits into a complete CRA programme.
- Step 1: Determine CRA applicability
- Step 2: Identify compliance gaps
- Step 3: Align engineering and compliance teams
- Step 4: Plan your CRA roadmap
Not sure whether the CRA applies to your product?
Read our full applicability guide → “Does the CRA Apply to Your Product?”
Who Should Use This CRA Checklist
This CRA checklist is designed for:
- Manufacturers of products with digital elements
- IoT and connected-device vendors
- Embedded and firmware engineering teams
- Importers and distributors operating in the EU
- Product security and compliance teams preparing for CRA obligations
CRA Timeline (2025–2027)
The CRA’s main application date is 11 December 2027, but key obligations already apply: reporting obligations since 11 September 2026 and the conformity assessment framework since 11 June 2026.
Use 2025–2027 as your preparation window: scope, secure development practices, documentation, vulnerability handling and update support must be operational before deadlines.
Get 20% off your first year of Regulus.
Preview of the CRA Checklist
Below is a short extract of the technical checkpoints included in the full CRA Readiness Checklist. These items reflect the real structure of the PDF you will receive:
Scope & Product Determination
• Product qualifies as a “product with digital elements”
• Connectivity and data-processing analysis completed
• Sector-specific exemptions reviewed
• EU market placement validated
Economic Operator Role
• Manufacturer responsibilities assessed
• Importer/distributor obligations mapped
• Authorized Representative requirements verified
Risk Classification (Default, Important or Critical)
• Annex III and Annex IV criteria evaluated
• Critical functionalities identified
• Classification documented for conformity assessment
Security & Lifecycle Requirements
• Annex I, Section 1 security controls reviewed
• Annex I, Section 2 vulnerability handling requirements validated
• Update mechanisms and support lifetime defined
Technical Documentation & Evidence
• Architecture and design documentation available
• SBOM and third-party components recorded
• Test results, logs and evidence prepared for conformity
Vulnerability Reporting (Article 14)
• Process to detect actively exploited vulnerabilities and severe incidents
• 24-hour early warning and 72-hour notification prepared
• Final report deadlines tracked (14 days after a fix, one month for incidents)
• Notifications sent through ENISA’s single reporting platform
Coordinated Vulnerability Disclosure
• Disclosure policy published and enforced
• Contact address for vulnerability reports available
• Advisories published for fixed vulnerabilities
• Vulnerabilities in third-party components reported upstream
Support Period & Security Updates
• Support period set: at least five years unless the product is used for less
• End date (month and year) shown at the time of purchase
• Security updates free of charge, separate from feature updates where feasible
• Each security update kept available for 10 years or the rest of the support period, whichever is longer
User Information (Annex II)
• Manufacturer contact and vulnerability contact point
• Intended purpose and foreseeable cybersecurity risks
• Support end date and secure use and update instructions
• Where the EU declaration of conformity can be found
Conformity & CE Marking
• Conformity assessment route chosen for the product class
• EU declaration of conformity (Annex V) drawn up
• CE marking affixed
• Technical documentation and declaration kept for 10 years or the support period, whichever is longer
Free CRA Checklist (2026)
Download the CRA Checklist to assess applicability, product classification, security requirements and documentation.
Prefer to read it online, without the form? See all 22 essential requirements explained or classification by product type.
Annex I requirements at a glance
Every product in scope has to meet the same 22 essential requirements of Annex I, whatever its class: 14 about the product (Part I) and 8 about vulnerability handling (Part II). The evidence column is common practice, not wording from the Regulation.
| Annex I | Requirement | Typical evidence |
|---|---|---|
| I.1 | Appropriate level of cybersecurity based on the risks | Risk assessment and the design decisions it led to |
| I.2(a) | No known exploitable vulnerabilities when made available | Release scan against the SBOM, findings triaged |
| I.2(b) | Secure by default configuration, with reset to original state | Default settings list, no shared default passwords |
| I.2(c) | Vulnerabilities fixable through security updates | Update mechanism, automatic updates by default where applicable |
| I.2(d) | Protection from unauthorised access | Authentication and access control design and tests |
| I.2(e) | Confidentiality of stored, transmitted and processed data | Encryption at rest and in transit, key management |
| I.2(f) | Integrity of data, commands, programs and configuration | Signed firmware and updates, integrity checks |
| I.2(g) | Data minimisation | Data inventory mapped to product functions |
| I.2(h) | Availability of essential functions, also after an incident | Resilience and denial-of-service tests |
| I.2(i) | Minimal impact on other devices and networks | Network behaviour analysis, traffic limits |
| I.2(j) | Limited attack surfaces, including external interfaces | Interface inventory, unused ports and debug access closed |
| I.2(k) | Exploitation mitigation mechanisms | Compiler hardening, memory protection, privilege separation |
| I.2(l) | Recording and monitoring of relevant internal activity | Security event logging, with user opt-out |
| I.2(m) | Secure, permanent removal of data and settings | Factory reset that erases user data |
| II.1 | Identify components, with a machine-readable SBOM | SBOM covering at least top-level dependencies |
| II.2 | Remediate vulnerabilities without delay | Vulnerability handling process and security updates |
| II.3 | Effective and regular security tests and reviews | Test reports per release |
| II.4 | Public information on fixed vulnerabilities | Security advisories |
| II.5 | Coordinated vulnerability disclosure policy | Published CVD policy |
| II.6 | Sharing of vulnerability information, with a contact address | Security contact, reports to component maintainers |
| II.7 | Secure distribution of updates | Signed, authenticated update channel |
| II.8 | Security updates without delay, free of charge, with advisories | Release notes and advisory messages for users |
Each requirement in detail, with links to the guides: CRA requirements.
Article 14 reporting deadlines
In force since 11 September 2026, also for products placed on the market before that date. Notifications go through ENISA’s single reporting platform, which reaches the CSIRT designated as coordinator and ENISA at the same time.
| Stage | Actively exploited vulnerability | Severe incident |
|---|---|---|
| Early warning | Within 24 hours of becoming aware | Within 24 hours of becoming aware |
| Notification | Within 72 hours of becoming aware | Within 72 hours of becoming aware |
| Final report | No later than 14 days after a corrective or mitigating measure is available | Within one month of the incident notification |
Impacted users also have to be informed of the vulnerability or incident and of the measures they can take. More in Article 14 reporting.
Common CRA checklist mistakes
- There is no “Class III”. The classes are default, important Class I and Class II (Annex III) and critical (Annex IV).
- Annex I has 22 requirements, not 12, 19 or 21. Part I has 14 (one general plus 13 specific) and Part II has 8.
- Class I does not always need a notified body. Self-assessment is possible when harmonised standards, common specifications or a European cybersecurity certification scheme are applied in full.
- The class does not change the requirements. It changes the conformity assessment route. The essential requirements are the same for every class.
- Late reporting is not a minor breach. The obligations of Articles 13 and 14 sit in the highest fine tier, up to EUR 15 million or 2.5% of worldwide annual turnover.
- Sector exclusions cover the regulated product, not the supplier. A component sold to car or aircraft makers, or aftermarket telematics, can still be in scope.
- Pure SaaS is not a CRA product. Remote data processing is covered only when a product needs it to perform one of its functions.
- The 2022 proposal is not the law. In the adopted text every firewall, IDS and IPS is Class II, industrial or not.
Sources
- Regulation (EU) 2024/2847 (Cyber Resilience Act), Official Journal of the EU.
- Commission Implementing Regulation (EU) 2025/2392, technical descriptions of the important and critical product categories.
- European Commission, Cyber Resilience Act, policy page and guidance.
- ENISA, the EU Agency for Cybersecurity, which runs the single reporting platform.
Frequently Asked Questions About the Cyber Resilience Act
This section addresses the most common questions organizations face when preparing for CRA compliance. It provides clear, practical answers to help you understand scope, obligations, timelines and the concrete steps required to bring your digital products in line with the Cyber Resilience Act.
Who must comply with the Cyber Resilience Act?
Any organization that manufactures, imports, distributes, or places products with digital elements on the EU market must comply with the CRA. This includes hardware vendors, IoT companies, embedded software teams, and digital product manufacturers.
Does the CRA apply to software-only products?
Yes. Software-only products fall under the CRA if they have direct or indirect connectivity or are necessary for a product to operate securely. Cloud-only SaaS platforms are generally excluded unless they ship an installable or connectable component.
How do I know if my product is in scope?
A product is in scope if it meets the definition of a “product with digital elements,” which includes embedded software, connected devices, firmware-driven systems, and software components placed on the EU market. You can follow the CRA applicability criteria or use your applicability article here: CRA Applicability Guide.
What is the difference between Default Class and Critical Class products?
All classes follow the same essential requirements; the class changes how conformity is assessed. Default products can be self-assessed. Important products (Class I and Class II, listed in Annex III) and critical products (listed in Annex IV) require stricter assessment, through a notified body or a European cybersecurity certificate depending on the class. Classification determines conformity procedures and documentation obligations.
What documentation is required under the CRA?
Manufacturers must prepare technical documentation, a cybersecurity risk assessment, vulnerability handling procedures, SBOM, update policies, testing evidence, and the EU Declaration of Conformity. Distributors and importers also have documentation responsibilities.
What happens if an organization fails to comply?
Non-compliance can result in products being banned from the EU market, mandatory withdrawals, or administrative fines. Manufacturers also risk liability if cybersecurity incidents arise from missing requirements.
What is the timeline for CRA enforcement?
The CRA entered into force on 10 December 2024. Reporting obligations apply from 11 September 2026 and the remaining obligations from 11 December 2027. Companies must use this transition period to assess applicability, classify products, build technical documentation, and implement vulnerability management processes.
How does this CRA checklist help my organization?
The checklist provides a structured, step-by-step review of CRA obligations covering scope, classification, technical documentation, security requirements, and lifecycle processes. It helps teams identify gaps and accelerate compliance preparation.
CRA Free Tools
CRA Scope Wizard
Check if the Cyber Resilience Act applies to your product. Answer a few questions to determine CRA applicability and classification.
CRA Cost Calculator
What will Cyber Resilience Act compliance cost you? This calculator estimates that internal effort, block by block, from seven questions about your portfolio.
CRA DoC Generator
This generator asks for those fields and composes the declaration for you, ready to copy, download and put in front of whoever signs it.
