Cyber Resilience Act: The 2027 Deadline Is Already the Wrong Date to Focus On

The Cyber Resilience Act is no longer a 2027 issue. Since 11 September 2026, manufacturers have been subject to mandatory reporting obligations for actively exploited vulnerabilities and severe incidents affecting product security. On the same day, ENISA launched its Single Reporting Platform (SRP), providing the reporting channel required for these notifications. This blog examines where operational readiness is still lacking, why product responsibility is often unclear, and what manufacturers, service providers, and enterprise buyers need to address.

Many companies still treat the EU Cyber Resilience Act as a compliance project with a December 2027 deadline. That view is now outdated.

Since 11 September 2026, manufacturers of products with digital elements have been subject to mandatory reporting obligations for actively exploited vulnerabilities and severe incidents affecting product security. An early warning must be submitted without undue delay, in any event within 24 hours of becoming aware of the issue, followed by a more detailed notification within 72 hours of becoming aware of it, and, subsequently, a final report.

This matters because the CRA has moved from policy to operations. Manufacturers now need to demonstrate that they can detect relevant issues, determine which products are affected, assign responsibility, and make a regulatory decision under time pressure.

Awareness is not readiness

A Bitkom survey published immediately before the reporting obligations became applicable illustrates the gap. While 67% of German companies surveyed had heard of the CRA, only 29% said they understood what it meant for their own organization. Another 38% knew of the regulation but could not assess its implications.

The real challenge goes beyond awareness. A company may have a CRA roadmap, legal guidance, and a compliance program, yet still be unable to respond effectively when a product vulnerability is actively exploited.

That is the practical test introduced by the September deadline.

The real challenge is product security operations

Manufacturers should ask a simple question:

If one of our products were affected by an actively exploited vulnerability tomorrow morning, could we assess the impact and make the right decision within 24 hours?

For many organizations, the answer depends on how well several functions work together.

• The SOC may detect suspicious activity, but lack product context
• Engineering may understand the affected component, but have no defined escalation route
• Vulnerability management may focus on corporate IT rather than embedded or shipped software
• Legal and compliance may become involved only after technical teams have already lost valuable time

The CRA therefore raises the importance of capabilities that were previously treated as security good practice rather than regulatory infrastructure.

• Product inventories need to be accurate
• Software composition data needs to reflect what is actually shipped
• Vulnerability intelligence needs to distinguish theoretical exposure from active exploitation
• Product ownership has to remain clear throughout the support lifecycle

The issue is not whether security data exists. It is whether the organization can turn it into a defensible decision quickly.

Do you actually know whether you are the manufacturer?

The second major issue is responsibility.

The CRA’s concept of a manufacturer is broader than many organizations may intuitively assume. It covers entities that develop or manufacture products with digital elements, or have them designed, developed, or manufactured, and market them under their own name or trademark.

Importers or distributors can also assume the manufacturer’s obligations if they place a product on the market under their own name or trademark, or substantially modify an existing product. The European Commission’s CRA guidance sets out the respective obligations of manufacturers, importers, and distributors and explains how responsibilities can change when products are modified or marketed under another company’s name or trademark.

This matters beyond the traditional software industry. Industrial equipment manufacturers, IoT vendors, security appliance providers, telecommunications suppliers, OEMs, and companies selling white-labelled technology may all need to reassess where responsibility sits.

Supplier contracts do not remove this problem. If an embedded third-party component contains an actively exploited vulnerability, the manufacturer still needs to determine whether its own product is affected and what obligations follow.

For industrial manufacturers in particular, this increasingly extends to firmware, embedded software, and connected assets. PAC’s analysis Accenture’s OT Security Bet: A Very Expensive Deal That Makes Strategic Sense illustrates why asset discovery, exposure management, and software supply chain visibility are becoming core elements of industrial cybersecurity.

In practice, CRA readiness therefore depends as much on product ownership and supplier governance as on regulatory interpretation.

The software supply chain is where visibility breaks down

Modern digital products are rarely self-contained. They combine open-source libraries, commercial software, firmware, cloud services, APIs, and supplier components. A single vulnerability can therefore affect multiple product lines and versions.

The relevant question is not whether an organization has an SBOM.

It is whether it can use its software composition and product data to determine, with sufficient speed and confidence:

• which products contain the affected component
• which versions are exposed
• whether the vulnerability is exploitable in the actual product configuration
• which supported products are still in use
• what mitigation is available
• who owns the technical and regulatory decision

A static inventory is insufficient if it cannot support these decisions.

Manufacturers increasingly need continuous visibility into components, linked to vulnerability intelligence, product lifecycle data, and defined escalation processes. The European Commission’s CRA guidance also makes clear that vulnerability handling covers product components throughout the support period, reinforcing the need for visibility beyond internally developed software.

This is where CRA implementation overlaps with software supply chain security, application security, and incident response.

The growing operational importance of these dependencies is examined further in PAC’s analysis Beyond the Patch Cycle: How Third-Party Exposure and AI Are Reshaping Ransomware in Europe, which looks at supplier exposure, software repositories, and vulnerability prioritization as increasingly interconnected security challenges.

Legacy products cannot be ignored

Another misconception could create significant operational problems.

The reporting requirements are not limited to products that will enter the market after the broader CRA requirements become applicable in December 2027. Article 14 reporting also applies to products within scope that were placed on the market earlier. ENISA’s guidance on the CRA Single Reporting Platform explicitly confirms that the reporting obligations also apply to products placed on the market before 11 December 2027.

That means manufacturers need sufficient visibility into their installed base, including older products.

This can be difficult when products have long support periods, fragmented version landscapes, discontinued development environments, or historical dependencies that were never documented in line with current product security standards.

For some manufacturers, the hardest CRA problem may therefore be the products they shipped years ago rather than the ones they are developing now.

What should manufacturers do now?

The immediate priority should not be another generic CRA gap analysis. Manufacturers need to test whether their operating model works under realistic conditions.

That means:

• establishing clear ownership for CRA reporting
• defining escalation paths across PSIRT, SOC, engineering, product management, legal and compliance
• ensuring that product and component data can support rapid impact assessment

Tabletop exercises are particularly useful here. A realistic scenario involving an actively exploited dependency can quickly reveal whether the organization can identify affected products, obtain the appropriate technical evidence, make a reporting decision, and coordinate remediation within the required timeframe.

This is also the right moment to examine legacy products and supplier dependencies, as both are likely to expose weaknesses that will become more consequential once the broader CRA requirements take effect in December 2027.

What does this mean for cybersecurity and IT service providers?

The CRA creates a meaningful service opportunity, but generic readiness assessments are unlikely to remain differentiated for long.

The stronger opportunity lies in helping manufacturers build operational product security capabilities:

• establishing or running PSIRT functions
• integrating vulnerability intelligence with product data
• implementing software composition analysis
• improving vulnerability disclosure processes
• embedding secure development practices
• connecting product security with incident response

Managed product security services may be particularly relevant for medium-sized manufacturers that lack the scale to maintain specialist capabilities internally.

The key distinction is between helping a customer interpret the regulation and helping them operate under it. The latter requires a combination of regulatory expertise, security engineering, product lifecycle management and incident response.

What does this mean for enterprise buyers?

Enterprise customers are not the primary target of the current manufacturer reporting obligations, but the CRA should still influence technology procurement.

Buyers should ask vendors:

• how long will products receive security support
• how vulnerabilities are monitored
• whether software components are traceable
• how quickly critical issues can be assessed and remediated
• how customers will be informed when product security incidents occur

This is especially relevant for technology deployed in critical infrastructure, manufacturing, healthcare, energy, and other environments where replacement cycles are long, and patching can be difficult.

CRA compliance should therefore not become another RFP checkbox. The more useful question is whether a supplier has a mature and demonstrable product security operating model.

PAC’s view: September 2026 is the first stress test

The significance of 11 September 2026 is not that the full CRA regime has arrived. It has not.

Its significance is that manufacturers now have to demonstrate that the foundations are already in place.

The current reporting obligations expose weaknesses that policy documents can hide:

• unclear responsibility
• poor visibility into products and software components
• weak escalation mechanisms
• fragmented coordination across security, engineering, and compliance

Manufacturers have roughly 15 months before the broader CRA requirements take effect on 11 December 2027. That period should be used to identify and fix operational weaknesses now, while the scope of mandatory obligations is still narrower.

The companies best prepared for 2027 will not necessarily be those with the most extensive compliance documentation. They will be those who can trace a vulnerability from component to product, assess its impact, assign ownership, and act before the reporting clock runs out.

Conclusion

The Cyber Resilience Act has already become an operational issue, not merely a 2027 compliance deadline. Current reporting obligations expose gaps in product security, ownership and vulnerability visibility, making the period until December 2027 a critical test of whether manufacturers can turn regulatory requirements into functioning security processes.

The more difficult readiness challenge may lie outside the traditional IT and electronics industries, with manufacturers whose core business has historically been less software-centric but whose products are increasingly connected or software-enabled. For these companies, the CRA also forces a clearer understanding of software dependencies, vulnerabilities and lifecycle responsibility. The adoption phase may improve awareness and capabilities, but it does not reduce the exposure created by poorly understood or insufficiently secured connected products in the meantime.