EU Cyber Resilience Act: What software and product companies need to do in 2026–2027

For many companies, the Cyber Resilience Act still sounds like a 2027 problem. 

It is not. 

The EU Cyber Resilience Act (CRA) introduces mandatory cybersecurity requirements for hardware and software products made available on the EU market. While its main requirements apply from 11 December 2027, one important deadline arrives much sooner: from 11 September 2026, manufacturers must begin reporting actively exploited vulnerabilities and severe security incidents affecting their products. 

For manufacturers, software development companies and businesses developing connected products, that makes 2026 the year to move from understanding the CRA to preparing for it operationally. 

The question becomes “Can we prove how our product is secured, maintained and supported throughout its lifecycle?” 

What does the Cyber Resilience Act cover? 

The CRA applies broadly to “products with digital elements” made available on the EU market. This includes both hardware and software, as well as components that are sold separately. 

That can include applications, connected devices, embedded software, industrial systems, networking products and many of the software components behind them. 

The regulation shifts cybersecurity closer to the product itself. Security is no longer something considered only at the infrastructure or corporate IT level. Manufacturers are expected to consider cybersecurity during planning, design, development, production, delivery and maintenance. 

In other words, releasing the product is not where the responsibility ends. 

Manufacturers must also manage vulnerabilities, provide security updates and maintain appropriate cybersecurity throughout the product’s defined support period. 

There are exceptions and sector-specific interactions, particularly for products already covered by other EU regulatory frameworks. Companies should therefore confirm the exact classification of their products with qualified legal or compliance advisors. 

The first important deadline: 11 September 2026 

From 11 September 2026, manufacturers must report actively exploited vulnerabilities and severe incidents affecting the security of products with digital elements. 

An early warning must generally be submitted within 24 hours of becoming aware of the issue, followed by a more complete notification within 72 hours. Further reporting follows depending on whether the event concerns an exploited vulnerability or a severe incident. 

Reporting will take place through the EU’s Single Reporting Platform operated by ENISA. 

For an engineering organization, this creates practical questions that cannot be solved by writing a policy the week before the deadline. 

Who detects the vulnerability? Who determines which versions are affected? Who has access to the relevant logs? Who contacts security, management and compliance? Can the team reconstruct what changed in the latest release? Is there a clear owner responsible for starting the reporting process? 

If answering those questions requires several days of internal investigation, the problem is operational, not legal. 

What changes in December 2027? 

Manufacturers will need to demonstrate that cybersecurity risk has been considered throughout the lifecycle of the product. 

That includes principles such as secure-by-design development, secure default configurations, access control, protection of confidentiality and integrity, vulnerability handling, secure updates and appropriate protection against unauthorized access. 

For development teams, many of these ideas are already familiar. 

The difference is that practices previously treated as engineering best practices increasingly become part of a formal product-compliance framework. 

A product that works correctly is therefore not necessarily a product that is ready for the CRA. 

The engineering organization also needs to understand its dependencies, know how vulnerabilities are handled, maintain appropriate technical documentation and be able to provide evidence of the decisions and controls behind the system. 

What should product companies start doing now? 

Waiting until 2027 to introduce these processes creates unnecessary pressure. 

A practical CRA-readiness effort should begin with the engineering foundations: 

• identify which products and versions may fall within the CRA 
• map software components and dependencies 
• establish vulnerability monitoring and escalation procedures 
• make development and production access traceable 
• document architectures and security-relevant decisions 
• establish repeatable patching and update processes 
• make releases traceable and recoverable 
• define ownership for incidents and reporting 
• review logging, monitoring, backup and recovery procedures 
• integrate cybersecurity risk assessment into product development 

The objective is not to create documentation for the sake of documentation. 

It is to make the system understandable enough that when a vulnerability, customer questionnaire, audit or regulator raises a question, the engineering team can answer with evidence instead of reconstructing the story afterwards. 

Where a software development partner such as Ascendro fits 

For companies relying on external engineering capacity, CRA readiness also changes how software partners should be evaluated. 

Technical capability remains important, but it is no longer the whole picture. 

A development partner should be able to explain who can access your systems, how that access is controlled, how code changes are tracked, how dependencies are managed, how production incidents are handled and what documentation exists behind the product. 

This is where Ascendro’s existing way of working becomes relevant. 

We develop and operate software in industries including automotive, manufacturing, fintech and healthcare, where security, traceability and controlled processes have already been part of client requirements for years. 

Ascendro holds ISO 27001, ISO 9001 and TISAX certifications. That means documented processes, information-security controls, controlled access and auditable ways of working are not practices we are introducing because the CRA is approaching. They are already part of the environment in which our teams deliver software. 

When we build or upgrade a product, that discipline extends into architecture documentation, development environments, deployment processes, dependency management, monitoring, backup and recovery, and long-term software operations. 

We are not a legal advisor or CRA certification body. Questions such as whether a specific product falls within the CRA or which conformity procedure applies should be answered with the appropriate legal and regulatory specialists. 

Our role is the engineering side: helping build software so that security, traceability and maintainability are part of the product from the beginning rather than something that has to be reconstructed before an audit. 

This article is published for informational purposes and does not constitute legal or regulatory advice. CRA obligations depend on the specific product, role and circumstances involved. Companies should consult qualified EU legal or compliance specialists regarding their individual obligations.