Kortave
Back to Blog
CRA10 May 20258 min read

The Cyber Resilience Act: What Product Companies Must Do Before December 2027

The CRA makes cybersecurity a legal obligation for any hardware or software product sold in the EU. Here is what manufacturers and developers need to know — and do.

The Cyber Resilience Act (Regulation (EU) 2024/2847) entered into force on 10 December 2024. Most of its substantive obligations apply from December 2027 — but the timeline is shorter than it looks. Building conformity assessment-ready technical documentation for a complex software or hardware product takes months. Companies that wait until late 2026 will not be compliant in time.

This article covers the essential CRA obligations, who is in scope, and what you should be doing now.

What is the CRA?

The Cyber Resilience Act is the EU's first regulation specifically targeting the cybersecurity of products with digital elements — hardware, software, and connected devices. It addresses a gap that GDPR and NIS2 left open: those regulations cover data protection and network security, but neither imposes baseline cybersecurity requirements on the products themselves.

Under the CRA, manufacturers and developers must design, develop, and maintain products that meet EU cybersecurity requirements — and demonstrate this through conformity assessment. The CE marking system is extended to cover cyber-secure products.

Who is in scope?

The CRA applies to any manufacturer, importer, or distributor that places products with digital elements on the EU market. This is deliberately broad:

  • Consumer IoT devices: routers, cameras, smart speakers, connected appliances
  • Industrial connected equipment and operational technology
  • Software products: desktop and mobile apps, operating systems, enterprise software
  • Cloud-connected components and remote data processing systems
  • Professional hardware with network interfaces

Open source software developed on a not-for-profit basis is generally excluded — but commercial deployments of open source components are not. If your product has a digital interface, processes data, or connects to a network, and you sell it in the EU, you are almost certainly in scope.

The risk-based classification system

The CRA uses a tiered classification system based on cybersecurity risk:

  • Default category: Products that are not critical cybersecurity components. The vast majority of products fall here. Self-assessment conformity procedure applies — no third-party auditor required.
  • Important products — Class I: Products in sectors where a compromise could have significant societal or economic consequences. Examples: identity management software, password managers, VPNs, network management tools, SIEM systems. Third-party conformity assessment is required unless the manufacturer applies harmonised standards.
  • Important products — Class II: Higher-risk product categories with stricter requirements. Examples: industrial control systems, operating systems for servers and industrial equipment, firewalls, hardware security modules. Mandatory third-party assessment regardless of standard adherence.

The Annexes to the Regulation define which product categories fall into each class. Manufacturers must classify their products before beginning conformity assessment.

Essential security requirements

All in-scope products must meet the essential requirements in Annex I of the CRA across two areas:

Security by design requirements:

  • No default passwords — each unit must have unique credentials or require credential creation on first use
  • Protection against known exploitation techniques: input validation, output encoding, authentication controls
  • Minimal attack surface configuration — unnecessary ports, protocols, and services disabled by default
  • Confidentiality of data: encryption in transit and at rest where technically feasible
  • Data minimisation in product functionality
  • Physical resilience against tampering where relevant to the use case

Vulnerability handling requirements:

  • Documented coordinated vulnerability disclosure (CVD) policy, publicly accessible
  • Security update availability for at least 5 years (or the expected product lifetime if shorter)
  • Security updates must be free of charge and clearly distinguishable from functionality updates
  • Timely deployment of security updates — critical updates as soon as possible, other updates within a defined timeframe
  • Software Bill of Materials (SBOM) maintained for the duration of the support period

Incident and vulnerability reporting

The CRA introduces mandatory incident reporting, operative from September 2026:

  • Within 24 hours of becoming aware of an actively exploited vulnerability or a severe security incident: early warning to ENISA (European Union Agency for Cybersecurity)
  • Within 72 hours: A notification with initial assessment of the vulnerability or incident and its severity
  • Within 14 days: A final report, including technical details, mitigations applied, and whether the vulnerability has been disclosed

ENISA operates a European vulnerability database. Manufacturers must use this system for disclosure — not just their own advisory channels.

Technical documentation and CE marking

Before placing a product on the EU market, manufacturers must prepare technical documentation (Annex VII) including:

  • Product description, intended purpose, and reasonably foreseeable misuse scenarios
  • EU Declaration of Conformity
  • Design and architecture documentation demonstrating how essential requirements are met
  • Risk assessment under the CRA framework
  • Software Bill of Materials (SBOM) — a machine-readable inventory of all software components
  • Cybersecurity testing methodology and results
  • Instructions for secure installation, configuration, and maintenance (user documentation)

Products satisfying the essential requirements may carry the CE mark. For Class I and Class II products, the CE mark can only be affixed after a notified body assessment (where required) or completion of the appropriate conformity procedure.

Enforcement timeline and penalties

  • June 2026: Notified body and market surveillance authority frameworks established.
  • September 2026: Vulnerability and incident reporting obligations become enforceable.
  • December 2027: All essential requirements and conformity assessment obligations fully apply. Products placed on the market that do not comply may be withdrawn.

Penalties for non-compliance can reach €15 million or 2.5% of global annual turnover, whichever is higher — for violations of essential requirements. Market surveillance authorities can order recall or market withdrawal of non-compliant products.

What you should do now

December 2027 is close enough that companies selling digital products in the EU should already be acting:

  1. Classify each of your products against the CRA Annex categories to determine your risk tier
  2. Conduct an initial gap analysis against Annex I essential requirements
  3. Establish or update your coordinated vulnerability disclosure policy
  4. Start building your Software Bill of Materials (SBOM) for each product
  5. Identify which products require third-party conformity assessment and engage a notified body early (demand is expected to exceed capacity)
  6. Implement the 24-hour ENISA notification workflow before the September 2026 deadline

The CRA marks a shift in EU regulatory philosophy: compliance is no longer limited to data protection and network security. The products themselves must be secure by design, with documented evidence of that security maintained throughout the product lifecycle. For product companies operating in the EU, this is not optional — it is the new baseline.

Handle compliance automatically

Kortave automates GDPR, AI Act, NIS2 & DORA compliance for EU businesses.

See plans →

— More from Kortave —

AI Act

Eight Weeks to the EU AI Act High-Risk Deadline: What Is Still Missing in Most Compliance Files

10 min read
GDPR

Every AI Tool Your Company Uses Is a GDPR Liability — Most Legal Teams Have Not Noticed Yet

9 min read
NIS2

NIS2 in Practice: What a Compliant Incident Response Actually Looks Like

9 min read