Europe’s Cyber Resilience Act will not become fully applicable until December 2027, but its first operational obligations arrive much sooner. From 11 September 2026, manufacturers must be ready to report actively exploited vulnerabilities and severe product-security incidents within demanding regulatory deadlines.

For many companies, the Cyber Resilience Act still appears to sit somewhere in the regulatory future. The main requirements covering product security, conformity assessment, technical documentation and vulnerability management become fully applicable on 11 December 2027, and that date has understandably dominated much of the implementation discussion.

The first live test of CRA readiness, however, arrives fifteen months earlier.

From 11 September 2026, manufacturers of products with digital elements will be required to report actively exploited vulnerabilities and severe incidents affecting the security of their products. An early warning must be submitted within 24 hours of the manufacturer becoming aware of the issue, followed by a fuller notification within 72 hours. Additional reporting requirements then apply as the investigation progresses and the manufacturer develops a clearer understanding of the event.

This timetable changes the immediate nature of CRA preparation. Companies may still be working towards full product conformity, but they will already need a functioning process for recognising reportable events, determining which products are affected and moving reliable information through the organisation quickly enough to meet the deadline.

The first deadline arrives before full compliance

The CRA entered into force in December 2024 and introduced a European cybersecurity framework covering the design, development, production and maintenance of hardware and software products placed on the EU market.

Most of its provisions become applicable in December 2027. The vulnerability and incident-reporting obligations were deliberately brought forward, creating an implementation sequence in which manufacturers must become operationally capable of responding before every element of their wider compliance programme has been completed.

That distinction matters. A company may still be improving its secure development processes, updating technical documentation or preparing for conformity assessment while simultaneously facing an obligation to report an exploited vulnerability affecting an existing product.

The reporting requirements are also relevant to products already available on the European market. They are not limited to products introduced after the CRA becomes fully applicable. Manufacturers may therefore need to account for legacy products, established product families and software versions that have been operating in customer environments for several years.

This significantly expands the practical scope of the September deadline. Product-security reporting cannot be treated solely as a requirement for future development programmes. It must also include the products, components and software versions already in circulation.

A 24-hour deadline depends on product visibility

The reporting clock begins when the manufacturer becomes aware of the vulnerability or incident. In a modern industrial organisation, identifying that precise moment may be more difficult than the legal language suggests.

Information can enter the company through many different routes. A vulnerability may be discovered by an internal security team, reported by a customer, disclosed by an external researcher or communicated by a software supplier. It may affect a single product version or a component used across multiple product families.

The organisation must then determine whether the issue falls within the CRA reporting threshold and establish the likely scale of the exposure. That requires a reliable connection between vulnerability information and the products, components and versions in which the affected technology is deployed.

Manufacturers with incomplete product inventories or limited software supply-chain visibility may struggle to answer even the most basic questions within the available timeframe. They may know that a vulnerable component exists somewhere inside the organisation without being able to identify which products contain it, which customers are affected or whether the vulnerability is being actively exploited.

The first notification does not require every technical detail to have been resolved. The early-warning mechanism exists because complex investigations cannot be completed within 24 hours. The manufacturer must nevertheless recognise that a potentially reportable event has occurred and initiate the correct regulatory process without delay.

Preparation for September therefore begins well before anyone opens the reporting platform. It sits inside product inventories, software bills of materials, vulnerability-management systems, supplier relationships and internal escalation procedures. These are the mechanisms that allow technical information to become an accountable regulatory decision.

The reporting platform does not remove operational responsibility

Reports will be submitted through the Single Reporting Platform being established by the European Union Agency for Cybersecurity, ENISA.

The platform is intended to provide manufacturers with a central electronic entry point for CRA notifications. Reports will be routed to the relevant national Computer Security Incident Response Team and made available to ENISA, with information shared more widely where other countries or authorities are affected.

This should simplify the submission process and reduce the need for manufacturers to notify multiple authorities separately. It does not remove the work required inside the company before a meaningful report can be submitted.

The platform cannot determine whether a vulnerability meets the legal reporting threshold. It cannot identify which products contain the affected component, establish when the organisation first became aware of the issue or decide who has the authority to approve the notification. Those responsibilities remain with the manufacturer.

ENISA has indicated that the platform will become operational by 11 September, with testing expected before the reporting obligations take effect. That testing period will be important, but technical familiarity with the portal will address only one part of the challenge.

The more difficult question is whether the organisation can produce accurate, defensible and timely information for the platform when a serious event occurs. A well-designed reporting interface will be of limited value if the underlying product, security and decision-making information remains fragmented.

The CRA will expose organisational seams

Product security often crosses several parts of a company without belonging entirely to any one of them.

Engineering teams may understand the vulnerability and its technical implications but lack authority to classify it as a regulatory event. Legal and compliance teams may understand the CRA obligation but have limited visibility into product versions, embedded software and supplier dependencies. Corporate cybersecurity teams may be responsible for incident response while product-security teams manage vulnerabilities affecting customer-facing technologies.

These organisational divisions are common, but they become difficult to sustain when the reporting window is measured in hours.

Meeting the CRA deadline requires manufacturers to define how information moves between product engineering, security, legal, compliance and senior management. The process must identify who evaluates the event, who decides whether a report is required and who is authorised to submit it.

The company will also need a defensible record of its response. That includes documenting when the issue was first identified, which information was available at each stage and why the organisation reached a particular reporting decision.

This does not automatically require another layer of compliance bureaucracy. It requires a clear operational structure that allows product-security information to move from technical discovery to regulatory action without becoming trapped between departments.

The CRA is therefore beginning to turn compliance into an engineering and workflow problem. The legal obligation remains important, but the ability to meet it depends on systems, ownership and information architecture.

CRA and NIS2 will meet inside the organisation

The CRA and the NIS2 Directive address different parts of Europe’s cybersecurity framework. The CRA focuses on the security of products with digital elements and the responsibilities of the companies placing those products on the market. NIS2 addresses cybersecurity risk management and incident-reporting obligations across organisations operating in covered sectors.

The legal distinction is clear. The operational distinction may be less convenient.

A serious cybersecurity event could affect a manufacturer’s internal systems, disrupt production, compromise a connected product and expose customers using that product. The same incident may therefore involve organisational resilience, product security, supplier dependencies and regulatory reporting under more than one framework.

Companies should not assume that an existing NIS2 incident-response process will automatically satisfy CRA requirements. The thresholds, reporting routes and information requirements are different. Building entirely separate systems, however, could create duplication and confusion where both regimes depend on the same technical evidence and many of the same people.

The practical objective should be a coordinated response structure that can distinguish between the legal obligations while sharing the operational intelligence required to support them.

For industrial manufacturers, this means developing a common view of incidents across corporate systems, production environments and connected products. It also requires clarity around which obligations have been triggered and which authority or reporting platform must be engaged.

As European cybersecurity regulation becomes more interconnected, compliance teams will need to understand the differences between individual frameworks without allowing those differences to fragment the organisation’s response.

September is the first live test of compliance engineering

The September deadline will not reveal whether every manufacturer has completed its full CRA conformity programme. It will reveal whether companies have built the operational machinery needed to recognise and respond to product-security events.

That machinery includes the ability to identify affected products and software components, determine which versions remain in use and establish who is responsible for supporting them. It also includes procedures for receiving vulnerability information, evaluating its significance and escalating decisions through the organisation.

Internal simulations could play an important role during the remaining preparation period. Manufacturers can test whether a vulnerability report reaches the correct teams, whether affected products can be identified quickly and whether the organisation can assemble the information needed for an early warning within 24 hours.

Such exercises may expose gaps that remain hidden in policy documents. A company may discover that product ownership is unclear, component inventories are incomplete or reporting authority has never been formally assigned. These weaknesses are easier to address during a simulation than during an actively exploited vulnerability affecting customers.

The broader CRA requirements will continue to demand substantial work between now and December 2027. Manufacturers will need to strengthen secure development practices, technical documentation, conformity assessment and vulnerability management throughout the product lifecycle.

September brings the first point at which that preparation becomes operationally visible. The deadline moves the CRA beyond interpretation and into execution, where systems, responsibilities and evidence must work together under pressure.

Europe’s product-security regime is beginning to move from policy into practice, and the manufacturers that treat reporting readiness as part of product engineering rather than a final compliance exercise will be better placed for what follows.