The EU Cyber Resilience Act Is Coming for Your Product in 2026-2027

The EU Cyber Resilience Act (CRA) — Regulation (EU) 2024/2847 — entered into force in December 2024, and the countdown has started. Most of its substantive requirements apply from December 2027, with earlier deadlines for vulnerability reporting kicking in from September 2026. If you sell any "product with digital elements" in the EU, this regulation applies to you, and it's one of the most significant changes to European product law in decades.

That phrase — "product with digital elements" — is doing a lot of work. It covers software, firmware, and connected hardware. It covers your web app if you distribute it. It covers the light bulb with a WiFi chip. It covers the industrial controller. It covers the smart watch, the home router, the developer library, and probably the thing you're building right now.

Here's what you actually need to understand.

The Core Idea

The CRA takes the CE marking model that has worked for physical product safety in the EU for decades and extends it to cybersecurity. Today, if you want to sell a piece of electronic equipment in Europe, you show it meets essential safety and EMC requirements, you affix the CE mark, and you issue a Declaration of Conformity.

From December 2027, that same process will include cybersecurity. Your product must meet essential cybersecurity requirements across its lifecycle. You document how. You put the CE mark on it. And you are legally accountable for keeping it secure — not just at ship time, but throughout the product's expected lifetime.

This is a fundamental shift. Historically, if you shipped an insecure IoT device, the consequences were reputational and maybe commercial. Under the CRA, shipping an insecure product into the EU market becomes a regulatory violation with real penalties.

What "Product with Digital Elements" Means

The CRA's scope is intentionally broad. It covers any software or hardware product that can "directly or indirectly" connect to a device or network. That includes:

• Consumer IoT (smart home devices, wearables, connected appliances)
• Industrial IoT and operational technology
• Embedded devices and firmware
• Standalone software, including desktop apps, mobile apps, and server software
• Developer libraries and SDKs
• Operating systems and middleware
• Network equipment (routers, switches, access points)

And it applies regardless of whether you charge money for the product, distribute it for free, or make it open source (with significant carveouts for non-commercial open source, covered below).

What's excluded:

• Cloud services (those fall under NIS2 and sector-specific rules)
• Software-as-a-service specifically (though software that runs on customer premises is in scope)
• Products already covered by specific regulations — medical devices (EU MDR), cars (type approval), aviation, certain military equipment, marine
• Non-commercial open source software (maintained by individuals or non-profits outside commercial activity)

The commercial open source question is nuanced. If you're a company monetizing open source — running a commercial offering, selling support, selling a managed version — your contributions to that open source project are likely in scope. The CRA introduced the concept of "open source software stewards" with lighter obligations, specifically to address the concern that the CRA would chill open source. It helped but didn't fully solve it.

The Three Risk Categories

The CRA classifies products into three categories based on cybersecurity risk:

Default category (majority of products). Self-assessment. You evaluate your product against the essential requirements, document compliance in technical files, and declare conformity. Most software and consumer IoT falls here.

Important products (Class I and Class II). Enumerated lists in Annex III. Class I includes things like password managers, VPN clients, firewalls, antivirus, routers, smart home systems, connected toys with interactive features, and wearables with health monitoring. Class II adds higher-risk products like hypervisors, container runtimes, boot managers, certificates issuers, and hardware security modules. Class I can self-assess if harmonized standards are followed; Class II requires a notified body assessment.

Critical products. Smart meter gateways, smart cards with secure elements, and similar. These require EU-level certification under the Cybersecurity Act's European cybersecurity certification schemes.

Get your product categorization wrong and you could be doing self-assessment when you needed a notified body, which is a compliance violation. The categorization lists in Annex III are worth reading in full.

What the Essential Requirements Actually Say

Annex I of the CRA lists the essential cybersecurity requirements. I'm going to paraphrase heavily to make it readable:

Design requirements (before shipment):

• Products must be designed so that they have an appropriate level of cybersecurity based on the risks
• Products must be placed on the market without known exploitable vulnerabilities
• Products must have a secure-by-default configuration
• Products must ensure the confidentiality of stored, transmitted, and processed data through encryption and other means
• Products must be resilient against denial-of-service attacks
• Products must protect the integrity of data they process
• Products must limit what data they process to what's necessary
• Products must facilitate the removal of personal data

Lifecycle requirements (after shipment):

• Vulnerabilities must be handled effectively, including free security updates
• Security updates must be provided for a period reflecting the product's expected use (with a minimum guidance of five years for many products)
• Documentation must clearly describe the support period
• A coordinated vulnerability disclosure policy must exist
• Vulnerability reports from third parties must be acceptable

Vulnerability reporting requirements:

• Manufacturers must report actively exploited vulnerabilities to ENISA within 24 hours of awareness
• Manufacturers must report severe incidents affecting product security within 72 hours
• Final reports are due within 14 days for vulnerabilities and one month for incidents

These reporting timelines begin applying in September 2026 — earlier than most other CRA requirements — and they're a big deal. This means if you discover active exploitation of a vulnerability in your product, you have 24 hours to notify ENISA. That's an aggressive operational requirement.

What's Changed Since the Drafts

The CRA went through major changes during legislative review, particularly to address concerns from the open source community and small-to-medium enterprises:

• Open source stewards were added as a lighter-obligation category for commercial-adjacent open source projects
• Support periods were relaxed from "the entire expected product lifetime" to a more reasonable "period reflecting expected use, not less than five years for many products"
• SME accommodations were included — lighter documentation requirements and phased enforcement for small companies
• Regulatory sandboxes were introduced to allow innovative products to be tested under regulatory supervision

The final text is more workable than the original proposal, but it's still a significant compliance regime.

How This Interacts with Other Security Laws

The CRA doesn't operate in isolation. It overlaps with and complements several other EU cybersecurity regulations:

• NIS2: Applies to operators of essential services. If you're a network operator, cloud provider, or digital infrastructure company, NIS2 covers your operations while the CRA covers your products.
• DORA: Applies specifically to financial services. For fintechs selling financial services software, DORA and NIS2 interact and the CRA adds another layer on top.
• EU AI Act: If your product is an AI system, the AI Act's requirements sit on top of the CRA's cybersecurity requirements.
• Radio Equipment Directive cybersecurity requirements (effective August 2025): These pre-existed the CRA and will eventually be subsumed under it.
• GDPR: Personal data protection obligations remain separate but related.

The practical answer: mature security programs built around ISO 27001 and established secure development practices will largely meet the CRA's essential requirements. The gap is typically in vulnerability handling processes, documented support periods, and coordinated disclosure programs. For industrial products specifically, IEC 62443 is highly aligned with CRA requirements.

The Timeline

• December 2024: CRA entered into force
• June 2026: Open source stewards rules begin applying
• September 2026: Vulnerability and incident reporting requirements apply
• December 2027: Full substantive requirements apply to all products

For products placed on the market after December 11, 2027, the full CRA applies. Products already on the market on that date generally have transitional provisions, but new product releases after that date must comply from day one.

Non-compliance penalties scale to global turnover: up to €15 million or 2.5% for breaching essential requirements, €10 million or 2% for most other violations, and €5 million or 1% for providing incorrect or misleading information.

What You Should Be Doing in 2026

If the CRA applies to your product (and it probably does), start now:

Inventory your products. Which ones fall into the default category, Class I, Class II, or critical? Get the classifications right.

Establish a Secure Software Development Lifecycle. If you don't have one, build it. The CRA effectively mandates secure-by-design principles. NIST SSDF and ISO/IEC 27034 are good references.

Set up a vulnerability disclosure program. If you don't have a security.txt file, a way for external researchers to report issues, and a documented process to triage and remediate, start there.

Define your support period. How long will you provide security updates for each product? Document it, communicate it to customers, and actually do it.

Build your incident response pipeline. Within 24 hours of learning about active exploitation, you need to be able to file an initial report with ENISA. That's not an ad-hoc capability — that's an operational process with defined roles and runbooks.

Document your technical file. The CRA's conformity assessment is based on technical documentation. Components, architecture, risk assessment, threat model, implementation of essential requirements, testing evidence. Start the file now even if you're self-assessing.

Watch the harmonized standards. Cenelec and ETSI are developing harmonized European standards mapped to the CRA's essential requirements. Using them gives you a presumption of conformity. For consumer IoT, ETSI EN 303 645 is already widely cited.

The Bottom Line

The CRA is not a future problem. The vulnerability reporting requirements hit in 18 months. The full regime hits in about three years. The work to be genuinely ready — product architecture changes, SSDLC improvements, vulnerability handling capabilities, documented technical files — takes time.

Companies that have mature security practices will find the CRA largely formalizes what they already do. Companies that have been shipping insecure products and patching reactively are going to discover their costs went up meaningfully. Either way, the EU is no longer the regulator-of-last-resort for product cybersecurity. It's the regulator setting the baseline that's going to influence US and global approaches for years.

For a broader look at how this fits into product compliance across markets, think of the CRA as the cybersecurity layer added to the existing CE marking regime — the same model, applied to a new risk dimension.

References

1. Regulation (EU) 2024/2847 (CRA) — Official Journal of the EU
2. EU Cyber Resilience Act Overview — European Commission Digital Strategy
3. ENISA CRA Guidance — European Union Agency for Cybersecurity
4. ETSI EN 303 645 — Cybersecurity for Consumer IoT — European Telecommunications Standards Institute