CRA Compliance Checklist: What You Need Before September 2026
The EU Cyber Resilience Act (CRA) vulnerability reporting obligation begins September 11, 2026. Full compliance is required by December 11, 2027. If you manufacture, import, or distribute products with digital elements in the EU, here is exactly what you need to have in place.
This checklist is organized by priority. Start at the top and work your way down.
Phase 1: Know Your Scope (Start Now)
Inventory Your Products
List every product with digital elements that your organization places on the EU market. This includes standalone software, firmware, IoT devices, connected hardware, and software-as-a-service with on-premise components.
For each product, document:
Product name and version
Target market (EU, global, specific member states)
Whether you are the manufacturer, importer, or distributor
Expected product lifetime and support period
Classify Each Product
The CRA defines three risk categories that determine your conformity assessment path:
Default — self-assessment is sufficient. This covers the majority of products.
Important (Annex III) — Class I products (VPNs, SIEM systems, identity management, network tools) and Class II products (firewalls, hypervisors, container runtimes, intrusion detection systems). These may require third-party assessment.
Critical (Annex IV) — hardware security modules, smart meter gateways, and critical infrastructure components. Third-party certification is required.
If you are unsure about classification, err on the side of the higher category and seek legal guidance.
Identify Your Role in the Supply Chain
Your CRA obligations differ based on your role:
Manufacturers bear the full set of obligations: secure design, SBOM, vulnerability handling, ENISA reporting, CE marking, and documentation.
Importers must verify the manufacturer has fulfilled their obligations before placing the product on the EU market.
Distributors must verify CE marking and documentation are in place.
If you modify a product substantially, you may be reclassified as the manufacturer for that product.
Phase 2: SBOM and Vulnerability Infrastructure (By June 2026)
Generate SBOMs for Every Product
The CRA requires a Software Bill of Materials in a machine-readable format. For a detailed walkthrough, see our guide on generating SBOMs for CRA compliance. For each product:
Choose a format: CycloneDX (recommended for security use cases) or SPDX
Generate the SBOM from your build pipeline, not manually
Include all direct dependencies and as many transitive dependencies as feasible
Record component names, versions, and package URLs (purls)
Automate SBOM generation so it updates with every release
Tools that can generate SBOMs: Syft, CycloneDX CLI, Trivy, SPDX SBOM Generator.
Set Up Vulnerability Monitoring
You need continuous monitoring of your dependencies against known vulnerability databases. At minimum, monitor:
NVD (National Vulnerability Database) — the most comprehensive CVE source
OSV.dev — aggregates vulnerabilities per ecosystem with pre-resolved version ranges
CISA KEV (Known Exploited Vulnerabilities) — critical for the 24-hour ENISA reporting obligation, as these are actively exploited
Your monitoring system should alert you immediately when a component in any of your products has a known vulnerability — especially if it appears on the CISA KEV list.
Implement Version-Aware Matching
Not every CVE that mentions a package name affects your version. Your vulnerability matching must be version-aware:
For npm/Cargo ecosystems: use semver range comparison
For Python packages: use PEP 440 version matching
For NVD lookups: use CPE matching with version ranges
False positives erode trust in your process. False negatives on actively exploited vulnerabilities can trigger regulatory consequences.
Phase 3: ENISA Reporting Readiness (By September 2026)
This is the first hard deadline. By September 11, 2026, you must be able to detect and report actively exploited vulnerabilities within 24 hours.
Define Internal Responsibilities
Document who is responsible for:
Monitoring vulnerability feeds for active exploitation
Making the determination that a vulnerability is actively exploited in your product
Drafting and submitting the ENISA early warning within 24 hours
Preparing the 72-hour detailed notification
Completing the 14-day final report
Communicating with affected users
This cannot be an ad-hoc process. Name specific roles and ensure backup coverage.
Prepare Report Templates
The three ENISA report types have specific information requirements:
24-hour early warning: Indication that an actively exploited vulnerability is suspected and preliminary information about the product affected.
72-hour incident notification: General description of the vulnerability, initial assessment of severity, corrective measures taken or planned, and information about whether the vulnerability affects other manufacturers.
14-day final report: Detailed vulnerability description and root cause, severity and impact assessment, complete list of affected products and versions, corrective measures applied, and information shared with users.
Pre-fill as much as possible so your team can focus on the specifics during an incident.
Run a Drill
Before September 2026, simulate an actively exploited vulnerability scenario:
Pick a real CVE from the CISA KEV list that affects a common dependency
Assume it affects one of your products
Walk through the full reporting process within the 24-hour timeline
Identify bottlenecks: who was hard to reach, what information was missing, what tooling gaps existed
Fix whatever breaks during the drill. Then run it again.
Phase 4: Security Practices and Documentation (By December 2027)
Create a Vulnerability Disclosure Policy
Publish a clear policy that tells security researchers and users how to report vulnerabilities in your products. Include:
A dedicated security contact (email or web form)
Expected response time
Your commitment to coordinated disclosure (ISO 29147)
A SECURITY.md file in your code repositories
Implement Secure Development Practices
The CRA requires products to be designed with security in mind. Document and implement:
Threat modeling for new features and products
Secure coding guidelines for your team
Automated dependency updates (Dependabot, Renovate, or similar)
Regular security testing (SAST, DAST, dependency scanning)
Code review processes that include security considerations
Prepare Technical Documentation
For each product, compile:
Description of the product and its intended use
Design and development documentation showing how essential requirements are met
Risk assessment and how identified risks are addressed
SBOM
EU Declaration of Conformity
Instructions for secure installation, operation, and maintenance
Support period and how security updates will be delivered
Apply CE Marking
Once you have completed conformity assessment and compiled technical documentation, apply the CE marking to your product. For default category products, this follows self-assessment. For Important and Critical products, you may need a notified body to certify conformity.
Quick Reference: Deadline Summary
Now — inventory products, classify by risk category, start generating SBOMs
June 2026 — SBOM generation automated, vulnerability monitoring active, internal processes documented
September 11, 2026 — ENISA reporting capability fully operational, 24-hour response tested
December 11, 2027 — all essential requirements met, CE marking applied, technical documentation complete
Tools That Help
SBOM generation: Syft, CycloneDX CLI, Trivy, SPDX tools
Vulnerability monitoring: OSV.dev, NVD API, CISA KEV feed
CRA readiness assessment: cra-scanner (free, open source)
Automated compliance: Complaro — from SBOM analysis to ENISA reporting
Do Not Wait
The companies that struggle with CRA compliance will be the ones that start six months before the deadline. The companies that succeed will be the ones that started a year early.
September 2026 is close. Start with Phase 1 today: inventory your products, classify them, and generate your first SBOM. Everything else builds on that foundation.
Complaro helps engineering teams automate the technical side of CRA compliance. Join the waitlist to get started.