Back to Blog
CRA Compliance Checklist EU Regulation

CRA Compliance Checklist: 15 Steps to Meet EU Cyber Resilience Act Requirements

The EU Cyber Resilience Act compliance journey can feel overwhelming. This actionable 15-step checklist breaks it down into manageable phases — from product classification through to ongoing vulnerability management — so your team knows exactly what to do and when.

CRATrust Editorial5 December 2025 13 min read
CRA Compliance Checklist: 15 Steps to Meet EU Cyber Resilience Act Requirements

With 11 December 2027 as the full compliance deadline for the EU Cyber Resilience Act, organisations have time — but not unlimited time. The CRA requires deep changes to product development, security operations, and organisational processes. Teams that start now will be compliant; teams that start in 2027 almost certainly will not.

This checklist organises the CRA compliance journey into 15 concrete steps across four phases. Each step includes what to do, why it matters, and where to find official guidance.

Phase 1 — Know Your Obligations (Steps 1–4)

Step 1: Determine if the CRA applies to your products

The CRA applies to any "product with digital elements" placed on the EU market. If you sell, distribute, or import software, firmware, or connected hardware into the EU — or if you are established in the EU and sell globally — you are likely in scope. Check the official text of Regulation (EU) 2024/2847, Article 2 for the precise scope definition and exclusions.

Step 2: Classify all in-scope products

Map your product portfolio against the CRA's three tiers:

  • Default: Most products — self-assessment is sufficient
  • Important (Class I): Products listed in Annex III, Part I (e.g., identity management software, password managers, VPNs, network monitoring tools, remote access software, routers, smart home hubs)
  • Critical (Class II): Products in Annex III, Part II (e.g., HSMs, smart meters, industrial firewalls, microcontrollers with security functions)

Classification determines your conformity assessment route and the rigor of documentation required.

Step 3: Map your supply chain

Identify all third-party software components in your products — commercial and open-source. This includes SDKs, libraries, frameworks, and OS components. You cannot manage what you have not inventoried. This is the prerequisite to Step 5 (SBOM generation).

Step 4: Appoint a CRA compliance lead

CRA compliance spans engineering, legal, product management, and security operations. Designate a named individual (typically CISO, Head of Product Security, or a dedicated compliance role) accountable for the programme. Without clear ownership, compliance tasks fall through the cracks.

Phase 2 — Technical Foundations (Steps 5–9)

Step 5: Generate SBOMs for all products

An SBOM (Software Bill of Materials) is required under CRA Annex I, Part II. Use tools like Syft, cdxgen, or Trivy to generate CycloneDX or SPDX format SBOMs. Integrate generation into your CI/CD pipeline so every build produces an updated SBOM automatically.

Step 6: Establish a vulnerability monitoring programme

Cross-reference your SBOM components against CVE databases (NVD) and open-source vulnerability databases (OSV). Set up automated alerting for new critical vulnerabilities affecting your component inventory. Manual checks are insufficient — the NVD publishes dozens of new CVEs daily.

CRA Compliance Programme — Phase Overview PHASE 1: KNOW Steps 1–4 Scope, classify, map, assign NOW PHASE 2: BUILD Steps 5–9 SBOM, vuln scan, SDL, CVD, updates Q1–Q2 2026 PHASE 3: DOCUMENT Steps 10–12 Tech docs, DoC, CE marking Q3–Q4 2026 PHASE 4: OPERATE Steps 13–15 Monitor, report, update, audit Ongoing

Step 7: Implement a secure development lifecycle (SDL)

The CRA requires products to be developed following security principles. Document your SDL to demonstrate: threat modelling, security design reviews, static analysis (SAST), dependency scanning, penetration testing, and security-focused code review. Frameworks like Microsoft SDL or OWASP SAMM provide good starting points.

Step 8: Establish a Coordinated Vulnerability Disclosure (CVD) policy

CRA Article 13 requires manufacturers to have a CVD policy and a single point of contact for vulnerability reports. Publish a security.txt file at /.well-known/security.txt and a security policy page. Ensure you have a process to acknowledge reports within 72 hours and remediate promptly. The ENISA CVD guidance is the authoritative reference.

Step 9: Define your security update commitment

The CRA requires manufacturers to provide security updates free of charge for the "supported lifecycle" — at least 5 years from market placement (or the product's expected use period if longer). Document your lifecycle policy publicly, specifying end-of-support dates, how security updates are delivered, and your update cadence.

Phase 3 — Documentation and Conformity (Steps 10–12)

Step 10: Prepare Technical Documentation

Annex V of the CRA specifies what technical documentation must be prepared before market placement. This includes: general product description, design and architecture, list of security requirements and how they are met, SBOM, test reports, CVD policy, and risk assessment. This documentation must be kept for 10 years after market placement.

Step 11: Complete the conformity assessment

For default class products, this is a manufacturer's self-assessment against the essential requirements. For Class I products, you may use self-assessment if following a harmonised standard (when published), or opt for third-party audit. Class II products require mandatory third-party certification by a notified body. Plan ahead: notified body capacity will be constrained.

Step 12: Issue the Declaration of Conformity and apply CE marking

The EU Declaration of Conformity (DoC) is a legally binding document in which the manufacturer declares the product meets all applicable CRA requirements. Once the DoC is issued, the CE mark can be affixed. The DoC must reference the applicable regulation and notified body (if used), and be signed by an authorised representative.

Phase 4 — Ongoing Operations (Steps 13–15)

Step 13: Implement continuous vulnerability monitoring

The CRA requires ongoing monitoring of your products' security posture throughout the supported lifecycle. Automate daily checks of your SBOM components against vulnerability databases. When a critical vulnerability is discovered affecting your product, you must notify ENISA within 24 hours of becoming aware (from 11 September 2026) and provide a full report within 72 hours.

Step 14: Establish an incident response procedure

Define how your organisation will respond when a vulnerability is discovered in one of your products — including who is responsible, how severity is assessed, when customers are notified, and how the ENISA report is drafted. The incident response procedure should be tested with a tabletop exercise before the September 2026 reporting deadline.

Step 15: Plan for annual compliance reviews

CRA compliance is not a one-time certification — it is a continuous obligation. Schedule annual reviews of your technical documentation, SBOM currency, CVD policy effectiveness, and SDL maturity. Any "substantial modification" to a product requires the conformity assessment process to be re-evaluated.

The organisations that treat CRA compliance as an operational discipline — rather than a box-ticking exercise — will find it becomes a competitive advantage. Demonstrably secure products command premium prices and win enterprise procurement contracts.

Resources

CRATrust Support

Typically replies in minutes

Hi there!

Ask us anything about CRA compliance. We're here to help.