Vibecoding under EU Cybersecurity Legislation: a breakfast thought

In light of the recent Microsoft 365 outage, a random breakfast thought came up about cybersecurity and vibecoding: can software written largely by AI comply with EU cybersecurity law? In our opinion, it can, but only if the company behind it still understands, reviews and maintains the code within a secure software development lifecycle (SDLC). However, SDLC is also under attack as good SDLC practices risk eroding as coding becomes ever easier. 

"Vibecoding" means that developers describe what they want and AI tools write the code. In its purest form, nobody reads the code and the software is immediately deployed. Developers have warned about the risks for years as AI-generated code often works but is not necessarily secure, and some developers tend to trust it too much. 

What is new is that EU law attaches legal obligations to those risks. The Cyber Resilience Act covers manufacturers of software and connected products. Cloud providers, such as the one behind Microsoft 365, mainly fall under the NIS 2 Directive. Both legal sources require secure development and vulnerability handling. NIS 2 already applies in most Member States. The CRA's reporting obligations apply as well, and its other obligations follow in December 2027. 

EU Cybersecurity Legislation does not care who wrote the code 

The CRA attaches its obligations to the product and to the manufacturer, not to the way code is produced. Nothing in the Regulation requires human authorship. The essential cybersecurity requirements in Annex I are largely outcome-based. A product must, for example, be placed on the market without known exploitable vulnerabilities and with a secure default configuration. AI-generated code that achieves those outcomes meets the requirements just as well as handwritten code. 

NIS 2 leaves even more room. Article 21 requires cloud providers to take appropriate and proportionate security measures, including in development and maintenance, but largely leaves the choice of those measures to them. That freedom cuts both ways as providers must be able to explain and justify the practices they chose. 

In both instances, responsibility stays entirely with the manufacturer or cloud provider, not with the provider of the AI coding tool. 

Compliance without knowledge 

Both regimes ask not only for security, but also for proof of how that result was achieved. That is where pure vibecoding runs into trouble. 

• Risk assessment. Both regimes are risk-based. Under the CRA, every manufacturer, whatever its product's category, must take cybersecurity risks into account during planning, design, development, production, delivery and maintenance. No manufacturer or provider can meaningfully assess the attack surface of code that nobody understands. 

• Documentation. The CRA requires technical documentation describing the system architecture and how the software components build on each other. NIS 2 also implicitly expects important and essential entities to understand their products and services. Such is required among others for documented security policies and procedures. Someone has to understand the code to write either of those credibly. 

• Dependencies and supply chain. AI tools pull in third-party packages, sometimes nonexistent or malicious ones with lookalike names. They may also copy open-source snippets directly into the code, where the snippets escape the software bill of materials (SBOM) and the supply chain controls that both the CRA and NIS 2 require. Developers commercialising their products and services must account for the component's security. 

• NIS 2 accountability. The management body of a cloud provider must approve the security measures, oversee their implementation and can be held liable. Approving development practices that nobody can explain is hard to defend. 

Vulnerability handling with your eyes closed 

A vibecoded product may pass initial testing and still be impossible to maintain. The CRA requires manufacturers to handle vulnerabilities throughout its support period. NIS 2 likewise requires cloud providers to handle and disclose vulnerabilities. The CRA makes these requirements explicit and sets out that it involves. 

• Finding vulnerabilities. Security tools match declared packages against vulnerability databases. Open-source code that an AI copied inline carries the original project's flaws, but they may not be flagged. 

• Fixing them without delay. AI-generated code often repeats logic instead of reusing it. The same flaw may then appear in dozens of slightly different places, so fixing the reported instance does not fix the problem. • Separate security updates. Under the CRA, where technically feasible, security fixes must be delivered separately from new features. Fixing code by re-prompting the AI tends to produce broad changes that mix both and may even introduce new bugs. 

• Informing users. Once a vulnerability is fixed, manufacturers must publicly disclose its description, impact and severity. A team that never understood the flaw cannot do this accurately. 

Reporting with no time to start learning your own code 

Both regimes require fast reporting: 

• Under the CRA, manufacturers report actively exploited vulnerabilities and severe incidents affecting their products. Under NIS 2, entities report significant incidents. 

• The deadlines are largely the same: an early warning within 24 hours, a notification within 72 hours and a final report afterwards. Such short deadlines put considerable pressure on whoever has to report, especially in the middle of an incident. 

• The clock starts when the company becomes aware of the problem, which requires an immediate initial assessment. Dawdling is not an option. 

In practice, reporting and vulnerability handling run in parallel. While the reports go out, the same team must analyse the flaw, contain it and prepare a fix. A team that first has to learn its own code will struggle to do both on time, and its slow analysis will not postpone the deadlines. The lack of understanding is self-inflicted because under both regimes, failing to report on time can lead to substantial fines. 

Don't stray from the basics 

The legal question is not whether AI writes the code, but whether the manufacturer or cloud provider keeps control of it. A secure SDLC is how it does that. The CRA does not use the term, but requires cybersecurity risks to be taken into account from planning to maintenance. For cloud providers, the NIS 2 implementing rules expressly require a secure development life cycle. 

For AI-assisted development, the key elements are clear rules on which AI tools may be used and who is accountable, a threat model and architecture description before code is generated, human review of security-sensitive changes, automated security testing, an internal SBOM for every release, and a ready procedure for patching and reporting vulnerabilities.

Note that on the other side AI tools can also strengthen security work, for example by triaging reports or finding variants of a known flaw. However, even though they support the manufacturer's responsibility, they do not replace it. 

Timelex assists manufacturers and cloud providers with CRA and NIS 2 scoping, secure development processes, technical documentation, vulnerability handling policies and reporting procedures. Contact Niels Vandezande or Pedro Demolder to discuss how the CRA and NIS 2 apply to your development practices.