September 11, 2026 marked the first major operational milestone of the EU Cyber Resilience Act: manufacturers are now required to report actively exploited vulnerabilities and serious security incidents affecting products with digital elements. Most of the Act’s broader obligations will apply from December 11, 2027. But the deeper change has already begun: cybersecurity is becoming a formal part of the digital product lifecycle. And that could have significant consequences for a software market increasingly shaped by AI-assisted development and “vibe coding”.
The Cyber Resilience Act is not fully applicable yet
The Cyber Resilience Act, or CRA, has become one of the most important pieces of European cybersecurity legislation.
Regulation (EU) 2024/2847 entered into force on December 10, 2024, but its provisions are being introduced progressively.
September 11, 2026 represents one of the first major operational milestones: the reporting obligations covering actively exploited vulnerabilities and serious incidents affecting products with digital elements became applicable on that date.
Most of the regulation’s obligations will become applicable on December 11, 2027.
That distinction matters.
It would therefore be technically inaccurate to say that “the Cyber Resilience Act entered into force on September 11”.
The regulation entered into force in 2024.
September 11, 2026 is the date on which its mandatory vulnerability and incident reporting regime became operational.
Source: European Commission – Cyber Resilience Act
https://digital-strategy.ec.europa.eu/en/policies/cyber-resilience-act
Source: European Commission – CRA Implementation Timeline
https://digital-strategy.ec.europa.eu/en/factpages/cyber-resilience-act-implementation
What changed on September 11, 2026?
The first operational change concerns the way certain vulnerabilities and security incidents must be handled.
When a manufacturer becomes aware of an actively exploited vulnerability, it must submit a notification through the European reporting platform operated by ENISA.
The system requires an early warning within 24 hours, followed by a full notification within 72 hours, with subsequent reporting according to the timelines established by the regulation.
The same platform is used for reporting serious incidents affecting the security of the product.
The objective is to avoid forcing manufacturers to report the same event separately to multiple national authorities.
ENISA has therefore established the CRA Single Reporting Platform, providing a single reporting channel for the obligations introduced by the regulation.
Source: European Commission – CRA Reporting Obligations
https://digital-strategy.ec.europa.eu/en/policies/cra-reporting
Source: ENISA – CRA Single Reporting Platform
https://www.enisa.europa.eu/topics/product-security/vulnerability-services/eu-incident-response-and-cyber-crisis-management/single-reporting-platform-srp
The bigger change comes in 2027
The most significant part of the CRA, however, is not the reporting procedure.
The deeper change concerns how European legislation defines responsibility surrounding software.
The regulation introduces cybersecurity requirements that must be considered throughout design, development, production, distribution and maintenance.
A software product is therefore no longer evaluated solely on whether it performs the function for which it was developed.
Its manufacturer must also address cybersecurity risks, assess vulnerabilities and establish appropriate processes for dealing with security problems throughout the product lifecycle.
That represents a significant shift.
For years, software development and cybersecurity have often been treated as partially separate activities, with security testing performed later in the development process or after vulnerabilities had already been discovered.
The CRA moves security into the development lifecycle itself.
Source: European Commission – CRA Summary
https://digital-strategy.ec.europa.eu/en/policies/cra-summary
From “it works” to “it was designed to be secure”
This may be the simplest way to describe the change.
A professional software product should not be evaluated solely according to its functionality.
The CRA introduces requirements covering cybersecurity risk assessment, vulnerability management, security updates and information provided to users.
Manufacturers must also document relevant security aspects and update the cybersecurity risk assessment where appropriate.
Cybersecurity therefore stops being merely an additional feature of a product.
It becomes part of the product itself.
Source: EUR-Lex – Regulation (EU) 2024/2847
https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32024R2847
The support period could be one of the most important changes
One of the less discussed aspects of the CRA could also become one of the most significant for the software market.
Manufacturers must establish a support period, during which they are responsible for ensuring that vulnerabilities are handled effectively.
As a general rule, the regulation requires a support period of at least five years, unless the expected lifetime of the product is shorter. Where a product is reasonably expected to remain in use for longer, the support period should reflect that expected lifetime.
This changes the traditional logic of many software products.
A product cannot simply be delivered and considered finished.
The manufacturer must consider what happens when a vulnerability is discovered.
Who investigates it?
Who develops the patch?
How is the update distributed?
For how long?
Through which process?
And who is ultimately responsible?
The concept of “software delivery” therefore increasingly gives way to the concept of the product lifecycle.
Source: EUR-Lex – Regulation (EU) 2024/2847
https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32024R2847
This is where “vibe coding” enters the picture
It is impossible to discuss the current evolution of software development without discussing AI.
AI coding assistants, automated code-generation tools and vibe coding platforms have dramatically lowered the barrier to software development.
Today, someone with relatively limited technical knowledge can describe what they want in natural language and generate, within minutes, a web application, plugin, data-management system or small software platform.
The phenomenon should not be demonised.
AI is already increasing the productivity of experienced developers while simultaneously enabling people with less technical expertise to build applications that previously would have required a professional development team.
The problem begins when ease of creation is confused with the ability to design and maintain a professional software product.
Generating code does not necessarily mean knowing how to design a secure system.
And producing a working application does not necessarily mean checking:
- authentication and authorization;
- session management;
- input validation;
- API exposure;
- secrets management;
- software dependencies;
- library vulnerabilities;
- logging;
- error handling;
- updates;
- backup and recovery;
- attack surfaces;
- data protection;
- system behaviour under abnormal conditions.
This is where the CRA could have one of its most interesting indirect effects.
Not because it bans vibe coding.
It does not.
And not because it requires software to be developed by someone holding a specific professional qualification.
Instead, the regulation focuses on the digital product placed on the market and on the economic operator responsible for that product.
That distinction is fundamental.
The CRA does not certify the developer. It puts responsibility on the product.
A superficial reading of the regulation might lead to the idea that Europe is introducing some form of “developer licence”.
It is not.
The CRA does not say that only a qualified professional can write software.
It says something very different: when a digital product falls within its scope and is placed on the EU market, certain cybersecurity requirements must be met.
The regulator is therefore not primarily interested in determining who wrote every line of code.
It is interested in determining who is responsible for the product and whether that product has been designed, documented, maintained and managed according to defined cybersecurity requirements.
This approach does not prevent the use of AI in software development.
A company can use AI to generate code.
It can use automated development tools.
It can use software agents.
It can automate significant parts of the development lifecycle.
But automation does not remove responsibility for the final product.
That may be one of the most important principles to understand in the age of vibe coding.
Source: EUR-Lex – Regulation (EU) 2024/2847
https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32024R2847
Who is actually affected by the CRA?
The scope is broader than it might initially appear.
The CRA applies to “products with digital elements”, covering software and hardware products and their remote data-processing solutions, including software or hardware components placed on the market separately.
Potentially affected products therefore include connected devices, software, applications, separately marketed software components and many other categories of digital products.
In July 2026, the European Commission published its first practical guidance to help manufacturers, developers and businesses of all sizes understand and implement the CRA.
Source: EUR-Lex – Regulation (EU) 2024/2847, Article 3
https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32024R2847
Source: European Commission – CRA Implementation Guidance, July 27, 2026
https://digital-strategy.ec.europa.eu/en/library/commission-publishes-new-guidance-support-timely-cyber-resilience-act-implementation
Not all software automatically falls under the CRA
This is another important distinction.
It would be incorrect to claim that:
“From 2027 every website will need CRA certification.”
Or that:
“Every freelance developer will have to become a cybersecurity company.”
The reality is more nuanced.
The regulation distinguishes between different situations and imposes different obligations on manufacturers, importers, distributors and other economic operators.
Open-source software also receives specific treatment.
The Commission has introduced the concept of open-source software stewards: legal entities that provide sustained support for the development of specific free and open-source software intended for commercial activities and play a role in ensuring its viability.
The CRA provides a specific and tailored regulatory regime for these actors.
Source: European Commission – Cyber Resilience Act and Open Source
https://digital-strategy.ec.europa.eu/en/policies/cra-open-source
The real issue for the market: responsibility
This is where the regulation could create a significant cultural change.
Imagine a company purchasing a software product from a small supplier.
Until now, in many situations, the relationship could be reduced to a relatively simple question:
“Does the software work?”
Yes.
“Was it delivered?”
Yes.
“There is a problem?”
Let’s fix it.
The model introduced by the CRA is different.
The manufacturer must have a vulnerability-management process.
Cybersecurity must be considered during design.
Relevant aspects must be documented.
Security updates must be managed.
The support period must be defined.
And, under specific circumstances, vulnerabilities and serious incidents must be reported.
Software increasingly becomes a product that carries an ongoing security responsibility.
Source: European Commission – CRA Summary
https://digital-strategy.ec.europa.eu/en/policies/cra-summary
Dependencies become a governance issue too
This is particularly important in modern software development.
Applications are rarely composed only of code written directly by their developer.
They may rely on:
- frameworks;
- libraries;
- open-source packages;
- APIs;
- external components;
- cloud services.
A vulnerability in a dependency can become a vulnerability in the final product.
The CRA therefore pushes the market towards a much more structured approach to software-component and vulnerability management.
It becomes increasingly difficult to simply say:
“The problem is in the library we use.”
From a product-security perspective, the question becomes:
Who is responsible for identifying it, assessing its impact and taking action?
This represents an important shift from responsibility for individual code to responsibility for the technology chain that makes up the product.
Source: EUR-Lex – Regulation (EU) 2024/2847
https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32024R2847
What if the software was generated by AI?
This may be one of the most interesting questions of the next few years.
The CRA does not distinguish between manually written code and AI-generated code.
From a cybersecurity perspective, code is code.
If an application contains a vulnerability, knowing that a specific section was generated by ChatGPT, Claude, Copilot or another AI system does not remove the manufacturer’s responsibility.
In fact, increasing automation may make verification processes even more important.
AI can generate thousands of lines of code in minutes.
That does not mean those lines have necessarily been:
- threat-modelled;
- tested against known vulnerabilities;
- checked for vulnerable dependencies;
- penetration-tested;
- properly integrated;
- documented;
- designed for long-term maintenance.
The paradox of AI-assisted coding is therefore clear:
The easier software becomes to produce, the more important it becomes to verify the quality and security of what is produced.
The economic consequences could be significant
The CRA is not merely a technical regulation.
It also establishes a sanctions framework.
For non-compliance with the essential cybersecurity requirements and the obligations under Articles 13 and 14, the regulation provides for administrative fines of up to €15 million or, for undertakings, up to 2.5% of total worldwide annual turnover for the preceding financial year, whichever is higher.
Lower maximum levels apply to other categories of infringement.
These are, of course, maximum penalties, not automatic fines.
Actual penalties will be established and applied under national rules and according to the circumstances of each case.
The important point is the principle:
cybersecurity becomes a responsibility with a tangible economic dimension.
Source: EUR-Lex – Regulation (EU) 2024/2847, Article 64
https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32024R2847
This does not mean that “amateur developers” will disappear
That would be an unjustified conclusion.
The market will continue to include freelancers, small development studios, startups, independent developers and people using AI tools to build applications.
The CRA does not eliminate that reality.
It may, however, make it progressively harder to argue that the ability to produce working software is by itself sufficient to sell that software as a professional product, when the product falls within the scope of the regulation.
That is a substantial difference.
The barrier is no longer necessarily:
“How much code can you write?”
It increasingly becomes:
“How capable are you of governing the product you are putting on the market?”
That is a very different kind of professional barrier.
A possible form of market selection
This may be the most interesting effect to observe over the coming years.
The CRA will not necessarily eliminate small developers.
It could, however, increase the distance between:
those who develop software as a structured professional activity
and
those who produce applications without adequate security, maintenance and vulnerability-management processes.
For companies purchasing software, this could become increasingly important when selecting suppliers.
Instead of asking only:
“How much does it cost?”
they may increasingly ask:
- What is the support period?
- How do you handle vulnerabilities?
- How are security updates managed?
- How do you monitor dependencies?
- Do you have a vulnerability disclosure process?
- How do you perform cybersecurity risk assessments?
- What documentation is available?
- Who is responsible for product security?
These questions are already common in enterprise environments.
The CRA could help move them into a much broader part of the software market.
The relationship with NIS2
The Cyber Resilience Act does not exist in isolation.
It is part of a broader European cybersecurity framework that also includes NIS2, the Cybersecurity Act and other EU initiatives.
The fundamental distinction is that NIS2 focuses primarily on the cybersecurity of organisations and covered sectors, while the CRA focuses on the security of products with digital elements.
The two frameworks may therefore apply to different actors and, in some circumstances, overlap.
The broader direction is nevertheless clear:
cybersecurity is no longer treated exclusively as an internal IT issue.
It is becoming a requirement that extends across products, organisations, supply chains and technology lifecycles.
Source: European Commission – Cyber Resilience Act
https://digital-strategy.ec.europa.eu/en/policies/cyber-resilience-act
The real test will come in 2027
September 11, 2026 is therefore a starting point, not the finish line.
The real test will arrive on December 11, 2027, when most of the regulation becomes applicable.
In the meantime, standardisation work, Commission guidance, ENISA’s activities and the availability of conformity-assessment bodies will all be important.
The Commission published its first set of practical implementation guidance on July 27, 2026.
Source: European Commission – CRA Implementation
https://digital-strategy.ec.europa.eu/en/factpages/cyber-resilience-act-implementation
Source: European Commission – CRA Implementation Guidance
https://digital-strategy.ec.europa.eu/en/library/commission-publishes-new-guidance-support-timely-cyber-resilience-act-implementation
The question is no longer “who wrote the code?”
The evolution of the software industry is bringing us to an interesting point.
Artificial intelligence is progressively turning code into a commodity.
Generating a function, an interface, a database or even a small application is becoming increasingly easy.
Professional value may therefore shift further towards everything that comes before and after the code:
analysis, architecture, security, integration, governance, testing, maintenance, accountability and the ability to manage the product lifecycle.
In this sense, the Cyber Resilience Act could represent an important transition.
Not because it will eliminate vibe coding.
Not because it will prevent non-programmers from creating applications.
And not because it will automatically turn every developer into a cybersecurity expert.
Rather, it introduces a different logic:
A professional digital product is not simply something that works. It is something whose risks someone must be capable of governing.
That may be the point that ultimately changes the market.
As AI makes software increasingly easy to produce, the ability to guarantee its security, maintenance and reliability could become one of the clearest distinctions between a prototype generated in a few hours and a genuine technology product.
The Cyber Resilience Act introduces a principle that is likely to have significant consequences:
Cybersecurity is no longer simply a technical feature that can be added to a product. It becomes part of the responsibility attached to the product itself.
September 11, 2026 marked the beginning of the first operational phase, with mandatory reporting requirements.
December 11, 2027 will bring the broader application of the regulation.
For the software market, the coming period will be particularly interesting.
At the same time that AI continues to make software easier to generate, the industry will have to answer a much harder question:
When anyone can create software, who is actually capable of making it secure?
That may prove to be more important than the ability to write code itself.
