Many software manufacturers view the Cyber Resilience Act solely in terms of the date the regulations come into force. This is a mistake. Although most of the obligations will come into force from December 2027, the regulation requires changes that cannot be implemented at the last minute. The CRA is not a compliance project, but a shift in the way software is developed and maintained.
The biggest change concerns the manufacturer’s responsibility. Until now, product security often ended with its launch. The Cyber Resilience Act reverses this logic. The manufacturer is to be responsible for security throughout the entire product support lifecycle – from design, through development and updates, right through to vulnerability management and incident response. In practice, security becomes an integral feature of the product, rather than an add-on offered after deployment.
This is precisely why time has become the most important resource today. The regulations can be read in a single day, but it is impossible to build an organisation within a few months that is capable of continuously monitoring vulnerabilities, securely delivering updates, maintaining technical documentation and reporting serious incidents within the required timeframes. From 11 September 2026, manufacturers will be required to report actively exploited vulnerabilities and serious security incidents, with the first report having to be submitted within 24 hours of their detection.
This means that the greatest challenge will not be preparing documentation, but rather overhauling the software development process. Secure by Design, vulnerability management, the Software Bill of Materials (SBOM), open-source component management and DevSecOps are often viewed as separate initiatives. The CRA brings them together into a single, coherent process. If a company does not currently have full knowledge of the components used in its products, it cannot quickly assess the impact of a newly discovered vulnerability or efficiently deliver security patches; the problem is not a lack of regulatory compliance. The problem is the immaturity of the software development process.
Many organisations make another mistake – they treat CRA as a task for the legal department or the cybersecurity team. Yet the regulation primarily affects product teams, architects, developers, QA and DevOps. They will be responsible for designing secure products, change control, dependency management and maintaining security throughout the solution’s entire lifecycle. For this reason, implementing CRA is a transformational project, not merely a regulatory one.
Paradoxically, this is precisely where the greatest business opportunity lies. Organisations that begin their preparations early enough will not only mitigate the risks associated with the new obligations. They will also gain better control over their own software, be able to respond more quickly to vulnerabilities, enjoy greater predictability in the development process, and build greater customer trust. When security becomes one of the criteria for selecting a supplier, it may prove to be just as important as new product features.
