EU Cyber Resilience Act (CRA) for Product Manufacturers

The EU Cyber Resilience Act (CRA) is a regulation requiring manufacturers of products with digital elements to meet cybersecurity requirements throughout the product lifecycle. Adopted in 2024 with enforcement beginning in late 2027, the CRA aims to improve the security of connected devices, software, and hardware sold in the EU by mandating secure design, vulnerability management, and transparency about security properties.

Who Needs to Comply?

The CRA applies to manufacturers placing "products with digital elements" on the EU market:

• Hardware manufacturers: IoT devices, routers, smart home devices, industrial sensors, network equipment

• Software vendors: Operating systems, browsers, security software, productivity applications, mobile apps (if sold as standalone products)

• Embedded system manufacturers: Medical devices, automotive components, smart appliances with firmware

• Open-source software stewards: Organizations providing commercial support or CE marking for open-source products

Products exempt from the CRA include:

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

• Pure SaaS or cloud services (no downloadable software)

• Custom software developed for a single client

• Open-source software developed or supplied outside commercial activity (no CE marking or monetization)

If you manufacture hardware or sell downloadable software in the EU, the CRA likely applies.

CRA Risk Classification

Products are classified into risk tiers determining compliance requirements:

Default (standard cybersecurity) products:

• Most consumer and business products (smart home devices, productivity software, networking gear)

• Self-assessment for conformity

• Manufacturer declares compliance via CE marking

Important (Class I) products:

• Identity management systems, authentication tools, VPNs, firewalls, antivirus, browsers, password managers

• Products integral to critical infrastructure or high-value assets

• Third-party conformity assessment required

• Notified Body reviews design and processes

Critical (Class II) products:

• Operating systems, hypervisors, industrial control systems, smart meters, smart cards for payments

• Highest scrutiny with comprehensive third-party assessment

• Notified Body audits development lifecycle and security controls

Most manufacturers will self-assess as "default" class unless their product is explicitly listed in CRA annexes.

Core Requirements

All products with digital elements must meet essential cybersecurity requirements:

Secure by design and by default:

• Minimize attack surface (disable unnecessary features, services, and ports by default)

• Secure defaults (strong authentication, encryption enabled out-of-the-box)

• Principle of least privilege (limited permissions for processes and users)

• Defense in depth (layered security controls)

Vulnerability handling:

• Publish a vulnerability disclosure policy (VDP) with contact information

• Assess and remediate reported vulnerabilities within timelines (critical: 24-72 hours; high: 14 days; medium: 90 days)

• Notify users and ENISA (EU cybersecurity agency) of actively exploited vulnerabilities

• Provide security updates for the product's expected lifetime or minimum 5 years (whichever is longer)

Secure updates:

• Deliver security patches automatically or with user notification

• Ensure updates are authenticated (signed) and cannot be tampered with

• Allow rollback to previous versions if updates fail

Data protection:

• Protect confidentiality and integrity of stored and transmitted data (encryption at rest and in transit)

• Implement secure credential storage (no hardcoded passwords)

• Process only necessary data (minimization)

Resilience and availability:

• Protect against denial-of-service attacks

• Ensure functionality under abnormal conditions or attacks

• Provide logging and monitoring capabilities for security events

Transparency and documentation:

• Provide users with clear security instructions (how to configure securely, how to update, how to report vulnerabilities)

• Publish a Software Bill of Materials (SBOM) listing components and dependencies

• Declare supported lifetime and end-of-support dates

Conformity Assessment

Manufacturers must demonstrate compliance before placing products on the EU market:

For default (standard) products:

1. Conduct risk assessment and security testing

2. Prepare technical documentation (design specs, SBOM, test results, security measures)

3. Draft EU Declaration of Conformity

4. Affix CE marking

5. Register product with EU database (managed by ENISA)

For Important/Critical (Class I/II) products:

1. Complete steps above

2. Engage a Notified Body (accredited third-party assessor)

3. Undergo design review and/or audit of cybersecurity processes

4. Receive Notified Body certificate

5. Affix CE marking with Notified Body ID

6. Register product with EU database

Notified Body assessments can take 3-12 months and cost €20,000-€100,000+ depending on product complexity.

Lifecycle Obligations

CRA obligations continue after market entry:

• Continuous monitoring: Track vulnerability reports, threat intelligence, and exploits affecting your product

• Incident reporting: Notify ENISA within 24 hours of discovering actively exploited vulnerabilities or severe incidents affecting product security

• Update delivery: Provide timely security updates for the supported lifetime (minimum 5 years)

• Record-keeping: Maintain technical documentation and conformity evidence for 10 years

• Market surveillance cooperation: Respond to inquiries from EU market surveillance authorities

Failure to maintain compliance after market entry can result in product recalls or market bans.

Penalties for Non-Compliance

The CRA includes significant financial penalties:

• Up to €15 million or 2.5% of global annual turnover (whichever is higher) for non-compliance with essential requirements

• Up to €10 million or 2% of turnover for failure to cooperate with authorities or provide documentation

• Up to €5 million or 1% of turnover for providing incorrect or incomplete information

Member states may impose additional penalties, including product recalls, market bans, or criminal liability for serious violations.

Timeline and Transition

The CRA was adopted in 2024 with a phased implementation:

• Late 2027: Full CRA enforcement begins (exact date TBD pending official publication)

• Transition period: Products already on the market before enforcement may remain, but updates must comply with CRA vulnerability handling requirements

• Notified Body accreditation: Member states are designating Notified Bodies throughout 2025-2027

Manufacturers should begin compliance work now, especially for Class I/II products requiring third-party assessment.

Key Documentation

Manufacturers must create and maintain:

• Technical documentation: Product description, design specs, risk assessment, SBOM, security test results, secure development lifecycle evidence

• EU Declaration of Conformity: Formal statement that the product meets CRA requirements

• Vulnerability disclosure policy: Published process for receiving and handling vulnerability reports

• Security instructions: User-facing guidance on secure configuration, updates, and incident reporting

• Conformity certificates: Notified Body certificates for Class I/II products

CRA and Other Regulations

The CRA overlaps and interacts with other EU regulations:

• GDPR: CRA data protection requirements complement GDPR (but don't replace it)

• NIS2: CRA focuses on products; NIS2 focuses on organizational security and incident reporting for service providers

• AI Act: AI-enabled products may need to comply with both CRA (cybersecurity) and AI Act (safety, transparency)

• Radio Equipment Directive (RED): Wireless products must meet both RED and CRA

• Machinery Regulation: Industrial machinery with digital elements must meet both

Coordinate compliance across regulations to avoid duplication or conflicting requirements.

How ISMS Copilot Helps

ISMS Copilot can support CRA compliance preparation:

• Policy creation: Generate vulnerability disclosure policies, secure development policies, incident response procedures

• Risk assessment: Develop product security risk assessment templates

• Process documentation: Create secure SDLC procedures (threat modeling, secure coding, security testing, patch management)

• User-facing content: Draft security instructions for product documentation

• Gap analysis: Upload existing product security documentation to identify gaps

While ISMS Copilot doesn't yet have dedicated CRA knowledge, you can ask general questions about secure product development, vulnerability management, and SBOM best practices.

Getting Started

To prepare for CRA compliance with ISMS Copilot:

1. Classify your products by CRA risk tier (default, Class I, Class II)

2. Create a dedicated workspace for your CRA compliance project

3. Conduct a product security risk assessment (identify threats, vulnerabilities, impacts)

4. Use the AI to generate a vulnerability disclosure policy

5. Develop secure development lifecycle procedures (threat modeling, code review, security testing, update processes)

6. Create a Software Bill of Materials (SBOM) for each product

7. Draft security instructions for users (secure configuration, update procedures, vulnerability reporting)

8. For Class I/II products, identify and engage a Notified Body early

Related Resources

• Official CRA regulation text (EU 2024/XXXX—check EUR-Lex for final publication)

• ENISA CRA guidance and FAQs

• Notified Body directories (member state lists of accredited assessors)

• SBOM standards (SPDX, CycloneDX)