Your 6-Step Path to
CRA Compliance

Start by creating a complete inventory of every product you place on the EU market that contains software or connects to a network. For each product, determine its category: default (most products), important (Annex III, Class I or II), or critical (Annex IV, such as hardware security modules or smart meter gateways). The category determines which conformity assessment route you must follow. Default products can self-assess, Important Class I products can use harmonised standards, and Important Class II and Critical products require third-party assessment.

• Create a full inventory of products with digital elements
• Classify each product as default, important (Class I/II), or critical
• Identify which products are already on the market vs. in development
• Map existing security measures for each product
• Determine the conformity assessment route per product category
• Identify gaps between current state and CRA requirements

Annex I Part I of the CRA lists the essential cybersecurity requirements your product must meet. These include: delivering products without known exploitable vulnerabilities, securing default configurations, protecting against unauthorised access, ensuring confidentiality and integrity of data, and minimising the attack surface. You must implement security by design throughout your development process, not bolt it on afterwards. This means integrating threat modelling, secure coding practices, and security testing into every stage of your product lifecycle.

• Implement a secure development lifecycle (SDL)
• Conduct threat modelling for each product
• Ensure products ship without known exploitable vulnerabilities
• Implement secure-by-default configurations
• Protect stored, transmitted, and processed data
• Minimise attack surface and limit interfaces to necessary functions
• Design for confidentiality, integrity, and availability

The CRA requires two critical processes. First, per Annex I Part II, you must establish a coordinated vulnerability disclosure policy, identify and document vulnerabilities (including in third-party components), provide security updates without delay, and share information about fixed vulnerabilities publicly. Second, per Art. 14, from September 2026 you must report actively exploited vulnerabilities to ENISA within 24 hours of becoming aware, with a full notification within 72 hours. You must also notify users without undue delay and inform them about corrective measures they can take.

• Establish a coordinated vulnerability disclosure policy
• Set up internal vulnerability handling procedures
• Build a system to track vulnerabilities in your own code and third-party components
• Create an incident response plan with 24h/72h notification capability
• Implement automated security update distribution mechanisms
• Set up a process to notify affected users of vulnerabilities
• Create a contact point for vulnerability reporters

The CRA requires extensive documentation. Per Annex VII, your technical documentation must include: a general product description, design and manufacturing information, a cybersecurity risk assessment, how essential requirements from Annex I are met, and the applied harmonised standards or other technical specifications. You must also generate a Software Bill of Materials (SBOM) per Annex V covering at minimum the top-level dependencies. Finally, you need an EU declaration of conformity per Art. 28 and user information per Annex II (including instructions for secure installation, a contact address, and details of the support period).

• Prepare technical documentation per Annex VII requirements
• Create a cybersecurity risk assessment for each product
• Generate a Software Bill of Materials (SBOM) per Annex V
• Draft the EU declaration of conformity per Art. 28
• Write user-facing security instructions per Annex II
• Document the planned security support period for each product
• Ensure all documentation is kept up to date for 10 years after product release

The conformity assessment route depends on your product category. Default-category products can use internal control (Module A per Annex VIII), where you self-assess against the essential requirements. Important Class I products can also self-assess if you apply harmonised standards that cover all requirements — otherwise, third-party assessment is needed. Important Class II and critical products always require a third-party assessment by a notified body (EU-type examination per Module B, or full quality assurance per Module H). If you applied harmonised standards, Art. 32 provides a presumption of conformity for the requirements they cover.

• Determine your conformity assessment route based on product category
• Conduct internal security testing (penetration testing, fuzzing, code review)
• Verify all Annex I essential requirements are met with documented evidence
• Apply for third-party assessment by a notified body if required
• Ensure applied harmonised standards are up to date
• Document test results and assessment outcomes
• Prepare for market surveillance authority audits

CRA compliance does not end at product launch. Per Art. 13(8), manufacturers must ensure vulnerabilities are handled effectively throughout the support period, which must be at minimum 5 years (Art. 16) unless the product's expected lifetime is shorter. You must continuously monitor for new vulnerabilities affecting your product and its components, provide security updates free of charge without undue delay, and report actively exploited vulnerabilities to ENISA within 24 hours. If you become aware that your product no longer meets the essential requirements, you must immediately take corrective action or withdraw it from the market.

• Define and publicly communicate the support period for each product (proportionate to expected product lifetime, minimum 5 years unless expected lifetime is shorter)
• Set up continuous vulnerability monitoring for your codebase and dependencies
• Implement an automated pipeline for distributing security updates
• Maintain your reporting capability (24h early warning, 72h notification)
• Periodically reassess whether your product still meets essential requirements
• Keep technical documentation and SBOM up to date with each release
• Establish procedures for product withdrawal or recall if necessary