Supported frameworks

EU Cyber Resilience Act (CRA)

The EU Cyber Resilience Act (CRA) is upcoming EU legislation that establishes mandatory cybersecurity requirements for products with digital elements (hardware and software) placed on the EU market. Expected to take full effect in 2027, the CRA aims to ensure products are secure by design, vendors maintain security throughout the product lifecycle, and consumers have transparency about product security.

The CRA is not yet fully in force. Enforcement timelines vary by requirement type, with full compliance expected by late 2027. Monitor official EU publications for final text and implementation deadlines.

Who Needs CRA Compliance?

The CRA applies to:

  • Manufacturers: Entities designing, developing, or manufacturing products with digital elements for EU market placement

  • Importers: Businesses bringing products with digital elements into the EU

  • Distributors: Entities making products available on the EU market

  • Open-source stewards: Organizations providing commercial support for open-source products (under certain conditions)

Products with digital elements include:

  • Software (applications, operating systems, firmware)

  • Hardware with embedded software (IoT devices, routers, smart appliances)

  • Connected products (wearables, industrial control systems)

Scope and Exemptions

In scope: Commercial products with digital elements placed on the EU market, including SaaS and cloud services if they contain downloadable software components.

Exempted:

  • Medical devices, aviation systems, and automotive components already covered by sector-specific regulations

  • Purely non-commercial open-source software developed or supplied outside commercial activity

  • Products exclusively for national security or defense

If you distribute open-source software without monetization or commercial support, you're likely exempt. If you provide paid support, SLAs, or enterprise features, CRA may apply.

Product Classification

The CRA categorizes products based on cybersecurity risk:

  • Default (Class I): Standard cybersecurity requirements, self-assessment allowed

  • Important (Class II): Higher-risk products (identity management, VPNs, network management) requiring third-party conformity assessment

  • Critical: Highest-risk products (secure elements, smart cards, PKI systems) requiring rigorous third-party certification

Most commercial software products fall into the default category.

Core Requirements

Manufacturers must ensure products meet essential cybersecurity requirements across the lifecycle:

Secure by Design:

  • No known exploitable vulnerabilities at time of placement on market

  • Security built into product architecture and development process

  • Minimized attack surface and secure default configurations

  • Data protection and encryption where appropriate

  • Security updates delivered automatically or with user notification

Vulnerability Management:

  • Identify, document, and remediate vulnerabilities throughout support period

  • Report actively exploited vulnerabilities to ENISA within 24 hours of awareness

  • Provide security updates for the expected product lifetime (minimum 5 years for many products)

  • Maintain a public vulnerability disclosure policy

Documentation and Transparency:

  • Provide clear security documentation to users

  • Publish EU Declaration of Conformity

  • Affix CE marking to compliant products

  • Maintain technical documentation for 10 years

Incident Reporting:

  • Report actively exploited vulnerabilities and severe incidents to ENISA

  • Notify affected users of security issues and available mitigations

Conformity Assessment

Depending on product class, manufacturers must demonstrate conformity through:

  • Self-assessment (Class I): Manufacturer conducts internal testing and documentation

  • Third-party assessment (Class II/Critical): Notified body evaluates compliance before market placement

All manufacturers must maintain technical documentation proving conformity, including risk assessments, security testing results, and development process records.

Support Obligations

Manufacturers must provide security support for:

  • The expected product lifetime, OR

  • Minimum 5 years from market placement (for most products)

This includes vulnerability patching, security updates, and incident response. Products without ongoing support cannot legally remain on the EU market.

Penalties

The CRA establishes significant financial penalties:

  • Serious violations (non-compliant products, missing CE marking): Up to €15 million or 2.5% of global annual turnover

  • Other violations (incomplete documentation, non-cooperation): Up to €10 million or 2% of global annual turnover

  • False information: Up to €5 million or 1% of global annual turnover

Implementation Timeline

Expected enforcement phases (subject to final regulation publication):

  1. 2024-2025: Regulation published, grace period begins

  2. 2026: Vulnerability reporting obligations take effect

  3. 2027: Full compliance required for new products placed on market

  4. Post-2027: Existing products must maintain support obligations

Start preparing now by implementing secure development practices, establishing vulnerability management processes, and documenting your security architecture.

How ISMS Copilot Helps

ISMS Copilot can support CRA compliance preparation:

  • General cybersecurity guidance: Ask about secure development practices, vulnerability management, and lifecycle security

  • Policy development: Create secure development lifecycle (SDLC) policies and vulnerability disclosure policies

  • Risk assessments: Generate product security risk assessments aligned with essential requirements

  • Documentation templates: Develop security documentation frameworks for conformity assessment

  • Gap analysis: Upload existing development policies to identify gaps against CRA principles

While ISMS Copilot doesn't have dedicated CRA knowledge (regulation is still finalizing), you can ask about ISO 27001 secure development controls and general product security best practices that align with CRA objectives.

Try asking: "Generate a vulnerability disclosure policy for a software product" or "What are secure-by-design principles for product development?"

Getting Started

To prepare for CRA compliance:

  1. Assess whether your products fall under CRA scope and determine classification

  2. Implement secure development lifecycle practices (threat modeling, security testing, code review)

  3. Establish vulnerability management and disclosure processes

  4. Plan for long-term security support (5+ years)

  5. Document security architecture and risk assessments

  6. Monitor ENISA and EU official publications for final requirements and guidance

  • European Commission CRA proposal and updates

  • ENISA cybersecurity certification frameworks and guidance

  • National market surveillance authorities in EU member states

Was this helpful?