As manufacturers of connected products, IoT devices, and software-enabled hardware race toward critical compliance deadlines, the European Union’s Cyber Resilience Act (CRA) is about to fundamentally transform cybersecurity requirements for products with digital elements. With actively exploited vulnerability reporting required from June 2026 and security incident reporting beginning in September 2026, manufacturers face an unprecedented mandate to integrate security throughout the product lifecycle—from design and development through post-market monitoring and incident response.

Executive Summary

The Cyber Resilience Act (Regulation (EU) 2024/2847), adopted by the European Parliament on March 12, 2024 and entering into force in phases through 2027, establishes binding cybersecurity requirements for hardware and software products with digital elements placed on the EU market. Unlike voluntary frameworks or sector-specific regulations, the CRA creates horizontal cybersecurity obligations affecting virtually every industry that manufactures or distributes products with connectivity, software, or digital functionality.

Key aspects include:

  • Universal scope: Applies to all products with digital elements unless specifically exempted- “Security by design” mandate: Cybersecurity must be integrated from initial product conception- Ongoing obligations: Post-market monitoring, vulnerability management, incident reporting throughout product support lifecycle- Critical deadlines:June 2026: Manufacturers must report actively exploited vulnerabilities- September 2026: Security incident reporting obligations begin- December 2027: Full CRA compliance required for new products placed on market Substantial penalties: Up to €15 million or 2.5% of global annual turnover for serious violationsSupply chain implications: Obligations extend to distributors, importers, and economic operators The CRA represents the EU’s most ambitious effort to address the cybersecurity of consumer and industrial products, aiming to reduce the prevalence of vulnerable devices in the marketplace and create accountability throughout the product supply chain.

What is the Cyber Resilience Act?

Legislative Context

The CRA forms part of the EU’s comprehensive strategy to enhance cybersecurity resilience:

Related EU Regulations:

  • NIS2 Directive: Network and information security requirements for entities- AI Act: Regulation of artificial intelligence systems- Data Act: Access and use of data from connected products- General Data Protection Regulation (GDPR): Personal data protection- Radio Equipment Directive (RED): Radio equipment and telecommunications terminal equipment

Together, these create a layered regulatory framework addressing cybersecurity from multiple angles: entity-level security (NIS2), product security (CRA), data governance (GDPR, Data Act), and sector-specific requirements.

Core Objectives

The CRA aims to:

1. Improve Security of Products with Digital Elements

  • Reduce cybersecurity vulnerabilities in hardware and software- Mandate security-by-design and security-by-default principles- Create accountability for product security throughout lifecycle

2. Enable Users to Make Secure Choices

  • Require clear information about product security features- Mandate disclosure of support duration- Create transparency about security update availability

3. Facilitate Vulnerability Disclosure and Coordination

  • Establish vulnerability handling requirements for manufacturers- Create coordinated vulnerability disclosure framework- Enable security researchers to report vulnerabilities without legal risk

4. Strengthen Market Surveillance

  • Empower authorities to monitor product security compliance- Enable testing and assessment of products- Create enforcement mechanisms for non-compliant products

What Products Are Covered?

Definition: “Product with Digital Elements” Any hardware or software product where:

  • The product or any of its components has data processing capability- Connectivity enables communication with other devices or networks (directly or indirectly)

Practical Examples:

Consumer Electronics:

  • Smartphones and tablets- Smart home devices (thermostats, cameras, doorbells)- Wearables (smartwatches, fitness trackers)- Connected appliances (refrigerators, washing machines)- Gaming consoles- Smart TVs

Industrial Equipment:

  • Industrial IoT sensors- Building management systems- Connected machinery- Logistics tracking devices- Medical devices with connectivity

Software:

  • Operating systems- Browsers- VPN software- Antivirus and security software- Password managers- Enterprise software applications- Mobile applications

Biotech Risk Calculator - Digital Twin Security Assessment

Important Exemptions:

Medical Devices: Covered by Medical Device Regulation (MDR) and In Vitro Diagnostic Regulation (IVDR); CRA does not apply to avoid regulatory duplication.

Automotive: Vehicles and their components covered by UN Regulation No. 155 on cybersecurity and software update management systems; CRA exemption to avoid conflict.

Aviation: Aircraft components regulated under aviation safety framework; exempt from CRA.

Exclusively National Security/Defense: Products used solely for national security or defense purposes.

Open-Source Software (Specific Conditions): Non-commercial open-source software developed and supplied outside the course of a commercial activity.

Custom/Bespoke Products: Products manufactured for own use or under specific customer contract not intended for market placement.

Key Requirements of the Cyber Resilience Act

1. Essential Cybersecurity Requirements (Annex I)

Security by Design and Security by Default:

What it Means:

  • Security must be integrated from initial product design, not retrofitted- Products must be configured securely “out of the box”- Default credentials, insecure default settings, and unnecessary open ports prohibited- Security features enabled by default

Practical Implications:

  • No more default passwords like “admin/admin”- Automatic security updates enabled by default- Least privilege access controls from initial configuration- Secure boot and firmware integrity verification

Risk-Based Security Measures:

Requirement: Manufacturers must implement security measures appropriate to the risks posed by the product, considering:

  • Nature and sensitivity of data processed- Connectivity and exposure to attacks- Product’s role in broader systems (e.g., critical infrastructure)- Foreseeable misuse scenarios

Examples:

  • Authentication mechanisms (passwords, biometrics, multi-factor)- Encryption of data at rest and in transit- Access controls and user permission management- Audit logging for security-relevant events- Protection against unauthorized modification (firmware integrity)

Vulnerability Handling:

Obligation:

  • Identify, document, and remediate vulnerabilities throughout product lifecycle- Provide security updates in timely manner- Communicate vulnerabilities and patches to users- Maintain vulnerability disclosure policy

Timeline:

  • Critical vulnerabilities: Patches within days to weeks (risk-dependent)- Less severe vulnerabilities: Coordinated disclosure and patch release- End-of-support planning to address vulnerabilities when updates cease

Resilience Against Cyber Attacks:

Requirement: Products must withstand common attack techniques:

  • Input validation to prevent injection attacks (SQL, command injection, etc.)- Protection against buffer overflows and memory corruption- Denial-of-service attack mitigation- Protection of cryptographic keys and credentials

Secure Development:

Process Requirements:

  • Use of secure coding practices- Automated security testing (SAST, DAST)- Third-party component security assessment (software composition analysis)- Security review and testing before product release

2. Documentation and Transparency Requirements

CE Marking:

Requirement: Products meeting CRA essential cybersecurity requirements bear CE marking indicating compliance.

Significance:

  • Only compliant products can be placed on EU market- Manufacturers self-declare conformity (for most products)- Market surveillance authorities can verify and challenge CE marking

EU Declaration of Conformity:

Contents:

  • Manufacturer identification- Product description- Standards or specifications used for compliance assessment- Statement that product meets essential requirements

Instructions for Users:

Required Information:

  • Security features and how to use them- Supported security update period- How to receive and install security updates- Contact point for vulnerability reporting- Recommendations for secure use and configuration

Format:

  • Clear, understandable language- Available in official language(s) of member state where product sold- Accessible to users (packaging, documentation, digital platforms)

3. Conformity Assessment

Three Categories of Products:

Default (Unclassified) Products:

  • Manufacturer self-assessment of conformity- No third-party involvement required- Manufacturer assumes responsibility for compliance

Important Products (Class I):

  • Moderate criticality- Internal controls by manufacturer- Enhanced documentation requirements- Potential for spot checks by authorities

Critical Products (Class II):

  • High criticality (e.g., security products, authentication systems, critical infrastructure components)- Third-party conformity assessment required- Notified body must verify compliance before CE marking- Ongoing surveillance by notified body

Examples of Critical Products:

  • Password managers- Smart cards for authentication- VPNs and secure communication products- Firewalls and intrusion detection systems- Network management systems for critical infrastructure

4. Vulnerability Reporting and Incident Notification

June 2026 Deadline: Actively Exploited Vulnerabilities

Obligation: Manufacturers must report to ENISA (European Union Agency for Cybersecurity) and the relevant national CSIRT (Computer Security Incident Response Team):

When:

  • Vulnerability in product is actively exploited in the wild- Manufacturer becomes aware of active exploitation

Timeline:

  • 24 hours: Initial notification of actively exploited vulnerability- 72 hours: Detailed report including:Vulnerability description and CVE identifier (if available)- Affected product versions- Evidence of active exploitation- Potential impact- Mitigation or remediation measures (if available)- Timeline for security update/patch

Purpose:

  • Enable rapid awareness of zero-day or emergent threats- Coordinate response across EU member states- Inform users and other stakeholders of urgent risks

September 2026 Deadline: Security Incidents

Obligation: Manufacturers must report significant cybersecurity incidents affecting their products or infrastructure.

What Constitutes a Reportable Incident:

  • Compromise of product security (unauthorized access, malware, data breach)- Incident affecting manufacturer’s systems that could impact product security- Large-scale or severe incidents affecting multiple users

Timeline:

  • 24 hours: Early warning notification- 72 hours: Incident report with details- Monthly updates: Significant incidents require ongoing reporting until resolved

Required Information:

  • Nature of incident (breach type, attack vector)- Affected products and user base- Assessment of impact- Response measures taken- User recommendations

Coordination:

  • Reports to national CSIRT and ENISA- ENISA may coordinate cross-border response- Market surveillance authorities notified

5. Support Duration and End-of-Life

Obligation: Manufacturers must provide security updates for a defined support period.

Minimum Requirements:

  • Support period must be clearly communicated to users before purchase- Duration must be “reasonable” considering:Product type and expected lifespan- Industry norms for similar products- User expectations

Examples:

  • Consumer IoT devices: Minimum 5 years from product placement- Enterprise software: Throughout license/subscription period- Critical infrastructure components: 10+ years

End-of-Support:

  • Manufacturers must inform users of approaching end-of-support at least 3 months in advance- Recommendations for secure product disposal or replacement- If severe vulnerability discovered after end-of-support, manufacturer must inform users even if patch not provided

6. Supply Chain Obligations

Distributors:

  • Verify manufacturer compliance (CE marking, documentation)- Ensure product accompanied by required information- Cooperate with market surveillance authorities- Report known non-compliance

Importers:

  • Ensure manufacturer has met obligations before importing to EU- Verify documentation and CE marking- Maintain records for market surveillance- Affix importer identification on product or packaging

Economic Operators: Any entity in supply chain can become liable if they:

  • Modify product in way affecting compliance- Place product on market under their own name/brand- Fail to cooperate with authorities

The June 2026 and September 2026 Deadlines

Why These Deadlines Matter

Phased Implementation:

The CRA enters into force in stages:

  • December 2024: CRA adopted and published- June 2026: Actively exploited vulnerability reporting begins- September 2026: Security incident reporting begins- December 2027: Full CRA essential requirements apply to new products

Strategic Significance:

June & September 2026 Deadlines: These are the first enforceable obligations under the CRA. They apply to:

  • Products already on the market- Manufacturers currently selling in EU- Immediate operational requirements (not just product design)

Implication: Manufacturers cannot wait until December 2027 to address CRA. They must have:

  • Vulnerability monitoring and disclosure processes (by June 2026)- Incident detection and reporting procedures (by September 2026)- Coordination with legal, security, and product teams

June 2026: Actively Exploited Vulnerability Reporting

Operational Requirements:

1. Threat Intelligence Integration

  • Monitor security research, CVE databases, exploit databases- Analyze threat actor TTPs (tactics, techniques, procedures)- Track vulnerability exploitation in products- Integrate threat feeds (commercial and open-source)

2. Rapid Assessment Capability

  • Determine if reported vulnerability affects your products- Assess which product versions vulnerable- Evaluate severity and exploitability- Identify if active exploitation occurring

3. Reporting Infrastructure

  • Establish contact with national CSIRT- Prepare reporting templates and processes- Designate responsible personnel (24/7 availability)- Test reporting mechanisms

4. Coordination with Development and Security Teams

  • Processes for emergency patch development- Communication workflows for vulnerability disclosure- Customer notification procedures- Media/public relations coordination

Challenges:

Identifying “Active Exploitation”:

  • No bright-line rule for what constitutes “active” exploitation- Isolated proof-of-concept vs. widespread attacks?- Targeted attacks vs. opportunistic scanning?- Evidence threshold for triggering reporting?

Vendor Dependency:

  • Many products use third-party components (open-source libraries, commercial SDKs)- If vulnerability is in third-party component, does manufacturer still report?- Coordination with upstream vendors

September 2026: Security Incident Reporting

Operational Requirements:

1. Incident Detection

  • Security Information and Event Management (SIEM)- Intrusion detection/prevention systems- Log analysis and monitoring- User and customer incident reports

2. Incident Classification

  • Criteria for “significant” incidents requiring reporting- Impact assessment procedures- Data breach evaluation- User/customer impact analysis

3. Reporting Procedures

  • Incident response playbooks- Internal escalation paths- Authority notification processes- User communication protocols

4. Post-Incident Activities

  • Root cause analysis- Remediation and patch development- Lessons learned documentation- Ongoing reporting for prolonged incidents

Challenges:

Defining “Significant”:

  • No prescriptive threshold in CRA- Risk-based determination required- Varies by product type and user base

Internal vs. External Incidents:

  • Must report manufacturer system compromises if they could affect product security- Development environment breaches, source code theft, supply chain compromises potentially reportable

Penalties and Enforcement

Financial Penalties

Tiered Penalty Structure:

Serious Non-Compliance: Up to €15 million or 2.5% of global annual turnover (whichever is higher) for:

  • Placing non-compliant products on market- Failing to meet essential cybersecurity requirements- Providing false or misleading information to authorities

Moderate Non-Compliance: Up to €10 million or 2% of global annual turnover for:

  • Failure to cooperate with market surveillance authorities- Inadequate documentation or CE marking violations

Administrative Violations: Up to €5 million or 1% of global annual turnover for:

  • Failure to provide required information to users- Delayed or incomplete vulnerability/incident reporting

Comparison to Other EU Regulations:

  • GDPR: Up to €20M or 4% of global turnover- Digital Markets Act (DMA): Up to 10% of global turnover- AI Act: Up to €35M or 7% of global turnover

Non-Financial Enforcement

Market Surveillance Actions:

Product Recall:

  • Authorities can order recall of non-compliant products- Manufacturer bears costs of recall, replacement, or correction

Sales Prohibition:

  • Ban on placing non-compliant products on EU market- Existing products may need to be withdrawn

Public Disclosure:

  • Enforcement actions may be publicly announced- Reputational damage from non-compliance findings

Import Restrictions:

  • Customs authorities can block importation of non-compliant products- Border surveillance for products without proper CE marking or documentation

Industry-Specific Implications

Consumer Electronics and IoT

Affected Products:

  • Smart home devices (thermostats, cameras, locks, doorbells)- Wearables and fitness trackers- Connected appliances- Consumer routers and network equipment

Key Challenges:

  • High volume, low margin business models- Rapid product iteration and short lifecycles- Expectation of low prices conflicting with security investment- User experience vs. security trade-offs (complex security measures may deter consumers)

Compliance Priorities:

  1. Eliminate default passwords; require user-set strong passwords2. Automatic security update mechanisms3. Clear communication of support duration (minimum 5 years recommended)4. Vulnerability disclosure policy and security contact5. Supply chain security for third-party components

Industrial IoT and Critical Infrastructure

Affected Products:

  • Industrial sensors and controllers- Building management systems- SCADA systems and industrial control systems- Energy management platforms

Key Challenges:

  • Long product lifecycles (10-20+ years)- Legacy systems with limited update mechanisms- Safety-critical applications requiring careful change management- Air-gapped or isolated networks complicating update delivery

Compliance Priorities:

  1. Extended support commitments (10+ years for critical infrastructure)2. Secure over-the-air (OTA) or isolated update mechanisms3. Rigorous third-party conformity assessment (likely Class II products)4. Incident reporting coordination with critical infrastructure protection authorities5. Resilience and fail-safe design

Software and Cloud Services

Affected Products:

  • Operating systems- Enterprise applications- Security software (antivirus, firewalls, VPNs)- SaaS platforms with desktop/mobile clients

Key Challenges:

  • Continuous deployment models vs. conformity assessment cycles- Open-source component management- Cloud vs. on-premises deployment differences- Software-as-a-service vs. licensed software distinction

Compliance Priorities:

  1. Secure software development lifecycle (SSDLC)2. Automated security testing (SAST, DAST, SCA)3. Comprehensive vulnerability disclosure program4. Rapid patch deployment capabilities5. Clear support and end-of-life policies for software versions

Supply Chain and Third-Party Components

Challenge: Modern products incorporate numerous third-party components:

  • Open-source libraries and frameworks- Commercial SDKs- Hardware components with embedded software/firmware- Cloud services and APIs

CRA Implications:

Manufacturer Responsibility: Even when vulnerability originates in third-party component, product manufacturer remains responsible for:

  • Monitoring third-party component vulnerabilities- Assessing impact on their products- Developing and deploying patches or mitigations- Reporting if third-party vulnerability actively exploited in their product

Mitigation Strategies:

  1. Software Bill of Materials (SBOM): Comprehensive inventory of all components2. Vendor assessment: Evaluate third-party vendor security practices3. Contractual provisions: Require vendors to notify of vulnerabilities, provide timely patches4. Redundancy: Avoid single point of failure; ability to replace components if vendor unresponsive5. Continuous monitoring: Automated tracking of third-party component vulnerabilities (e.g., Snyk, Dependabot)

Preparing for June and September 2026

Phase 1: Gap Assessment (January-March 2026)

Product Inventory:

  • Identify all products with digital elements- Determine CRA applicability for each product- Classify products (Default, Class I, Class II)- Map products to essential cybersecurity requirements

Vulnerability Management Assessment:

  • Current vulnerability disclosure processes- Threat intelligence capabilities- Patch development and deployment timelines- Third-party component tracking

Incident Response Assessment:

  • Incident detection capabilities- Classification and escalation procedures- Reporting infrastructure- Authority relationships (CSIRT, ENISA, market surveillance)

Organizational Readiness:

  • Roles and responsibilities for CRA compliance- Cross-functional coordination (legal, security, product, customer support)- Budget and resource allocation

Phase 2: Process Development (March-May 2026)

Vulnerability Reporting Procedures:

  • Define “actively exploited vulnerability” criteria- Establish threat intelligence feeds and monitoring- Create reporting templates for CSIRT/ENISA- Designate 24/7 responsible personnel- Test reporting mechanisms with authorities

Incident Reporting Procedures:

  • Define “significant security incident” thresholds- Incident classification decision trees- Reporting workflows and templates- Communication plans (internal, authorities, users)

Technical Infrastructure:

  • Deploy or enhance SIEM, logging, monitoring- Vulnerability scanning for products and infrastructure- Patch management systems- Secure software development pipeline

Documentation:

  • Vulnerability disclosure policy- Security contact information (security.txt, etc.)- EU Declaration of Conformity templates- User instructions for security features

Phase 3: Testing and Training (May-June 2026)

Tabletop Exercises:

  • Simulate actively exploited vulnerability scenario- Practice 24-hour reporting timeline- Test coordination between teams- Identify gaps in procedures

Authority Engagement:

  • Establish relationships with national CSIRT- Clarify reporting expectations and procedures- Understand authority response processes- Participate in industry working groups

Personnel Training:

  • CRA awareness for all relevant staff- Detailed training for incident response team- Legal and compliance training- Customer support training on security inquiries

System Testing:

  • Validate incident detection capabilities- Test reporting portal access and functionality- Confirm 24/7 availability of key personnel- Dry-run reporting process

Phase 4: Operational Readiness (June 2026 Onward)

Continuous Monitoring:

  • Threat intelligence for product vulnerabilities- Security research and CVE monitoring- Customer and security researcher reports- Automated vulnerability scanning

Incident Response:

  • 24/7 incident detection and assessment- Rapid classification and escalation- Timely reporting to authorities- User communication and support

Documentation and Compliance:

  • Maintain records of vulnerability reports and incidents- Document conformity assessment processes- Prepare for market surveillance inquiries- Continuous improvement based on lessons learned

Phase 5: Full CRA Compliance (Toward December 2027)

Product Design and Development:

  • Integrate security-by-design from concept phase- Secure coding practices and developer training- Automated security testing in CI/CD pipeline- Third-party component security assessment

Conformity Assessment:

  • Self-assessment or third-party assessment as appropriate- Documentation of compliance with essential requirements- CE marking application- EU Declaration of Conformity

Market Readiness:

  • Updated product documentation and user instructions- Clear communication of support duration- Security feature transparency- Post-market monitoring processes

Strategic Considerations

Build vs. Buy: Security Infrastructure

Options:

1. In-House Development

  • Custom vulnerability management platform- Bespoke incident response systems- Internal security operations center (SOC)

Pros:

  • Tailored to specific products and business- Full control and customization- No third-party dependencies

Cons:

  • High upfront investment- Ongoing maintenance burden- Difficulty attracting/retaining security talent

2. Commercial Solutions

  • SIEM platforms (Splunk, Elastic, Microsoft Sentinel)- Vulnerability management (Tenable, Qualys, Rapid7)- Incident response platforms (PagerDuty, ServiceNow)- Threat intelligence feeds (Recorded Future, Anomali)

Pros:

  • Faster deployment- Proven capabilities- Vendor support and updates- Integration ecosystems

Cons:

  • Subscription costs- Vendor lock-in- Customization limitations- Third-party dependency

3. Managed Services

  • Managed SOC (Security Operations Center)- Managed Detection and Response (MDR)- Vulnerability management as a service- Incident response retainer

Pros:

  • Expert staffing without hiring- 24/7 coverage- Scalability- Focus internal resources on core business

Cons:

  • Ongoing costs- Less direct control- Knowledge retention challenges- Vendor dependency

Recommendation: Hybrid approach combining commercial tools for broad capabilities with internal expertise for product-specific knowledge and authority relationships.

Insurance and Risk Transfer

Cyber Insurance Considerations:

Coverage for CRA Compliance:

  • Product recall costs- Regulatory fines and penalties- Incident response expenses- Legal defense costs- Customer notification and remediation

Policy Requirements: Insurers may mandate:

  • Specific security controls and practices- Vulnerability management processes- Incident response plans- Regular security assessments

Impact of CRA:

  • Expect increased scrutiny from insurers- Premiums may reflect CRA compliance posture- Non-compliance could void coverage- Claims related to CRA violations may be excluded

Competitive Advantage

Beyond Compliance:

Security as Differentiator:

  • Customers increasingly value security- B2B procurement often requires security evidence- Proactive security communication builds trust- Certifications and compliance demonstrate commitment

Market Positioning:

  • “CRA compliant” as marketing message- Transparency about security practices- Longer support commitments than competitors- Vulnerability disclosure program as trust signal

Innovation Opportunities:

  • Secure-by-design as innovation driver- New product features addressing security needs- Partnerships with security vendors- Thought leadership in product security

Conclusion: Security is No Longer Optional

The Cyber Resilience Act marks a fundamental shift in how the EU regulates product security. For the first time, cybersecurity is a mandatory, enforceable product requirement comparable to safety standards for electrical equipment or toys.

The June 2026 actively exploited vulnerability reporting and September 2026 security incident reporting deadlines represent the first enforceable milestones, requiring immediate operational readiness from manufacturers currently selling products in the EU.

Key takeaways:

1. June and September 2026 Deadlines Are Imminent Just months away, these reporting obligations require processes, personnel, and infrastructure to be in place immediately.

2. CRA Applies Broadly Virtually all products with connectivity, software, or digital functionality are covered unless specifically exempted.

3. Lifecycle Obligations CRA is not a one-time certification but ongoing responsibility throughout product support period.

4. Supply Chain Accountability Manufacturers remain responsible even when vulnerabilities originate in third-party components.

5. Substantial Penalties Up to €15M or 2.5% of global turnover for serious violations creates significant financial risk.

6. Cultural Shift Required Security-by-design demands organizational change across product, engineering, legal, and business functions.

Manufacturers who embrace the CRA as opportunity rather than burden—investing in security infrastructure, transparent communication, and user trust—will differentiate themselves in an increasingly security-conscious market. Those who view it as mere compliance obligation risk enforcement action, reputational damage, and competitive disadvantage.

The message is clear: in the EU market, security is no longer optional. The question is whether manufacturers will be ready.

About This Analysis This report is published by Compliance Hub and CISO Marketplace, providing product security and EU regulatory compliance professionals with analysis and strategic guidance on emerging cybersecurity requirements.

Sources:

  • Regulation (EU) 2024/2847 (Cyber Resilience Act)- European Union Agency for Cybersecurity (ENISA)- European Commission CRA Guidance- EU Market Surveillance Authorities- Industry compliance analysis and surveys