Beyond the Firmware | What the CRA misses in an AI-driven world

The EU’s Cyber Resilience Act (CRA) marks a bold step forward in digital product security. For the first time, manufacturers of connected devices and software are being held accountable for cybersecurity across the product lifecycle, from design to disposal.

But as regulatory frameworks evolve, technology moves faster still. And one disruptive force is reshaping the cybersecurity landscape more radically than most laws can keep pace with:

Artificial Intelligence isn’t just influencing products—it’s helping create them.

The new Supply Chain | Data, Code and Models

Traditionally, the CRA focuses on securing physical devices and embedded software. But modern digital products, especially in IoT, robotics and cloud-native platforms include:

• Machine learning models integrated into firmware and applications

• Auto-generated code created by large language models (LLMs)

• Dynamic behavior, influenced by continuous data ingestion and feedback loops

  
  

This creates a new kind of software supply chain, one that includes non-deterministic behavior, opaque decision-making and black-box dependencies. Can the current CRA framework address this complexity?

Three blind spots of the CRA in an AI-enhanced world

1. Accountability in Autonomous Code Generation

With generative AI now assisting in writing production code, firmware logic, and even system configurations, the human engineer becomes just one part of the pipeline. If insecure code is generated by AI—even unintentionally—who is held accountable under the CRA?

Is it the developer?

The vendor?

The AI model’s creator?

Current language in the CRA lacks clarity on this, potentially opening legal grey zones in compliance.

2. Vulnerability Reporting for Non-Human Logic

The CRA demands that vendors report actively exploited vulnerabilities. But what happens when vulnerabilities emerge from AI model behavior, not traditional software flaws?

Imagine a model behaving unpredictably due to adversarial data or unexpected edge cases. These may not trigger typical CVEs, but they still pose security risks. Should these incidents be reported under the CRA? And how?

3. Model Lifecycle and Security Updates

Models require updates, sometimes as urgent software patches. But retraining an AI model to address a security issue isn’t always straightforward, especially if it depends on third-party data or proprietary architecture.

Under the CRA, how should manufacturers handle:

• Updates to embedded ML models?

• Model versioning and rollback?

• Dependencies on cloud-hosted AI services?

Without specific guidance, manufacturers risk either overcompensating (and slowing innovation) or underdelivering (and violating CRA mandates).

We need CRA 2.0 thinking

To be clear, the CRA is a vital milestone for Europe and sets a strong example globally. But like any regulation, its success depends on its ability to adapt to the frontier of innovation. AI is no longer a future risk. It's already reshaping how products are developed, updated, and attacked.

To stay relevant, future revisions or parallel frameworks must:

• Define accountability in AI-generated code and decision-making

• Include guidance for model security, lifecycle management, and incident reporting

• Expand the concept of a “secure-by-design” product to include AI ethics and robustness

  
  

Closing thought

Cyber resilience is no longer just about hardening firmware or patching vulnerabilities. It’s about recognizing that the products we build are becoming more autonomous, more adaptive and, as a result, more unpredictable.

As AI becomes a co-pilot in both development and operation, we need to ask:

Can legislation built for deterministic systems protect us in a world built by probabilistic machines?

We should celebrate the CRA as a foundational achievement. But we also need to look ahead—and start building the next layer of resilience.