The EU Cyber Resilience Act: What Manufacturers Need to Do Before December 2027

For decades, cybersecurity in connected products was voluntary. Manufacturers made their own decisions about how much security to build in, how long to support their products with patches, and how to disclose vulnerabilities when they found them. The result — documented extensively by ENISA and national cybersecurity agencies across the EU — was a market flooded with products carrying easily exploitable weaknesses and no systematic obligation to fix them.

The EU Cyber Resilience Act (CRA), Regulation (EU) 2024/2847, changes that. It entered into force on 10 December 2024 and introduces the first horizontal, mandatory cybersecurity framework for products with digital elements placed on the European market. For manufacturers, importers, and distributors of hardware and software products, it creates a new compliance landscape that needs to be understood now — because the lead time required to meet it is substantial.

The Three Deadlines That Matter

EU Cyber Resilience Act Timeline (EU CRA Timeline): Key Enforcement Dates

The CRA uses a phased enforcement schedule. Understanding which deadline applies to which obligation is essential for planning:

• 10 December 2024
  CRA enters into force
  Regulation (EU) 2024/2847 published in the Official Journal of the EU. The clock starts.
• 11 September 2026
  Vulnerability and incident reporting obligations apply
  Manufacturers must begin reporting actively exploited vulnerabilities and severe incidents to ENISA via its central EU notification platform. This is the earliest hard deadline with direct operational implications.
• 11 December 2027
  Full CRA obligations apply
  All essential cybersecurity requirements, conformity assessment procedures, CE marking obligations, and technical documentation requirements become enforceable. Products placed on the EU market from this date must be fully compliant.

What the CRA Covers — and What It Doesn't

The CRA applies to products with digital elements (PDEs): any hardware or software product whose intended purpose or reasonably foreseeable use includes a direct or indirect logical or physical data connection to a device or network. That scope is deliberately broad. Connected consumer devices, enterprise software, industrial control components, routers, IoT sensors, operating systems, browsers, password managers — all are within scope if they are placed on the EU market in the course of a commercial activity.

Products that already fall under sector-specific EU regulations with equivalent cybersecurity requirements — such as medical devices under the MDR, machinery under the Machinery Regulation, and vehicles under type-approval frameworks — are excluded from scope. Products not made commercially available (internal-use software not placed on the market) are also excluded.

Free and open-source software receives specific treatment. Software that is developed entirely openly and not monetised falls outside the CRA's scope. However, where open-source components are integrated into a commercial product, the manufacturer of that product bears responsibility for the cybersecurity of the integrated components.

The Four Product Classifications

The CRA divides products into four categories, each triggering a different conformity assessment pathway. Getting the classification right is foundational — it determines whether self-assessment is permitted or whether a third-party notified body must be involved:

The European Commission published draft implementing regulations in March 2025 to clarify the technical descriptions of Important and Critical product categories. Manufacturers in or near these categories should review those descriptions carefully — the boundary between Default and Important Class I has real compliance cost implications.

The Essential Cybersecurity Requirements (Annex I)

Annex I of the CRA sets out the essential cybersecurity requirements that all products within scope must meet. These apply across the full product lifecycle — from design and development through production, delivery, and post-market maintenance. The requirements include:

• Products must be designed and developed without known exploitable vulnerabilities, with a minimal attack surface, and with appropriate protection mechanisms for confidentiality, integrity, and availability
• Products must ship in a secure default configuration, and any security-relevant feature that is enabled by default must be justified
• Products must support the ability to update software securely, including applying security patches throughout the expected product support period
• Sensitive data — including personal data, commands, and configuration data — must be protected against unauthorised access and modification during storage and transmission
• Products must limit the data collected and processed to what is necessary for their intended function (data minimisation)
• Where access credentials are required, products must meet minimum security requirements for those credentials
• Products must be designed to protect the availability of their essential functions against denial-of-service attacks
• Products must minimise their negative impact on the availability of services provided by other devices or networks

Equally important are the vulnerability handling obligations. These are not one-off tasks — they are ongoing operational requirements that survive product launch:

• Manufacturers must identify and document vulnerabilities in their products and the components they contain, including maintaining a software bill of materials (SBOM)
• Vulnerabilities must be addressed without delay and remediated within defined timeframes
• Security updates must be distributed promptly and — where possible — automatically
• A coordinated vulnerability disclosure policy must be in place, including a single point of contact for security researchers and users to report vulnerabilities
• Information about vulnerabilities must be shared with the relevant national CSIRT (Computer Security Incident Response Team)

Vulnerability and Incident Reporting — The September 2026 Obligation

From 11 September 2026, manufacturers must report to ENISA via its central notification platform whenever they identify an actively exploited vulnerability in their product, or a severe incident with a potential impact on the security of that product. The reporting cascade is structured:

• Within 24 hours of becoming aware: an early warning notification covering the affected product, the nature of the vulnerability or incident, and potential impacts
• Within 72 hours: a more detailed technical notification as information becomes available
• Within 14 days: a final report covering root cause analysis, implemented mitigations, and planned security updates

These obligations run in parallel with notification duties under the NIS2 Directive for organisations that are also classified as essential or important entities. A single incident may trigger reporting under multiple frameworks with different timelines and different receiving authorities. Manufacturers need to map these obligations before the September 2026 deadline — not after the first incident occurs. Understanding the full cascade of containment, notification, and recovery costs makes the planning case far easier to argue internally.

Technical Documentation — What Must Be Prepared and Maintained

Before placing a product on the EU market, manufacturers must prepare and maintain technical documentation demonstrating conformity with the CRA's essential requirements. This documentation must be made available to market surveillance authorities on request and must be kept for a minimum of ten years after the product is placed on the market. The required content includes:

• A general description of the product and its intended use
• The cybersecurity risk assessment used to inform the design and development of the product
• A list of the harmonised standards, technical specifications, or other measures applied in meeting the essential requirements — and where those standards have not been fully applied, a description of the solutions adopted
• The EU declaration of conformity (the formal statement that the product meets the CRA requirements)
• An SBOM covering at minimum the top-level dependencies of the product
• Vulnerability handling procedures and the coordinated vulnerability disclosure policy
• Security test results and records of remediation activity

The documentation burden is significant for organisations without established product security practices. It is not something that can be assembled quickly at the point of conformity assessment. The risk assessment, test records, and remediation history must be accumulated throughout the product's development and maintained through its supported life.

The CE Marking

Once a product has undergone the applicable conformity assessment procedure and the manufacturer has drawn up the EU declaration of conformity, the product may bear the CE marking indicating CRA compliance. Without the CE marking, a product with digital elements may not be placed on the EU market from December 2027. Market surveillance authorities in each member state will have powers to inspect products, require documentation, restrict market access, and order recalls where products are found to be non-compliant.

Penalties for non-compliance reach up to €15 million or 2.5% of global annual turnover, whichever is higher. For less serious infringements — such as administrative failures or failure to cooperate with market surveillance — the cap is €10 million or 2% of turnover. Australian manufacturers exporting to the EU should verify whether their cyber insurance policies extend to cover European regulatory investigation and enforcement costs — most domestic policies do not explicitly address this.

The Harmonised Standards Gap

Harmonised standards — technical standards developed by recognised European Standards Organisations that manufacturers can use to demonstrate conformity — are not yet finalised. The European Commission formally requested CEN, CENELEC, and ETSI to develop 41 harmonised standards in February 2025: 15 horizontal standards aligned with each of the essential cybersecurity requirements, and 26 vertical standards for specific product categories. ETSI published its first draft European Standards for public consultation in September 2025. These standards will, when finalised, provide a documented path from Annex I requirement to technical implementation. Until they are available, manufacturers must use alternative technical measures and document their reasoning.

This means that waiting for harmonised standards before beginning CRA work is not a viable strategy. Manufacturers who delay risk compressing the time available to complete gap remediation, conduct conformity assessment, and prepare documentation — all against a fixed December 2027 deadline.

Where to Start

For most manufacturers, the practical sequence is: classify your products correctly, perform a structured gap assessment against the Annex I essential requirements for each product, identify what evidence and documentation you already have and what needs to be built, and prioritise remediation by product risk and classification.

The gap assessment step is where the most useful work happens. A systematic review of each product against the CRA's requirements — covering security by design, technical security properties, vulnerability handling processes, incident reporting readiness, documentation state, and conformity assessment pathway — translates a complex regulatory text into a gap register and a prioritised remediation plan. It also starts building the documented evidence record that will ultimately underpin the declaration of conformity.

For Australian manufacturers, the CRA's technical security requirements map well against the ASD's Essential Eight — organisations that have implemented these controls have addressed many of the CRA's baseline secure-by-design expectations. The 2024 Privacy Act reforms are also relevant for products that collect personal data of Australians — CRA compliance and APP 11 obligations overlap significantly on encryption, access controls, and data minimisation.

For organisations with multiple products, the picture is more complex: a portfolio-level view is needed to identify which gaps are systemic (and can be addressed once at the organisational level) versus which are product-specific, and to sequence remediation work across a product range without duplicating effort.

The September 2026 vulnerability reporting deadline is the more immediate operational challenge — it requires organisations to have a functioning coordinated vulnerability disclosure programme, a relationship with the relevant national CSIRT, and a process for assessing and reporting incidents against the 24-hour, 72-hour, and 14-day cascade before the first event occurs. Building that capability takes months, not weeks.