The Cyber Resilience Act is coming: Is your software ready?

The Cyber Resilience Act (CRA) is a new European Union regulation that introduces mandatory cybersecurity requirements for products with digital elements, including both software and connected devices.

In practice, this means that any product with digital elements placed on the EU market will need to be secure by design, properly documented, and maintained throughout its lifecycle.

In simple terms: software is being treated more like a regulated product, not just code.

Why now?

Because the way we build and use software has fundamentally changed, but security hasn’t kept up.

European organisations are already among the most targeted globally when it comes to cyber attacks, with global cybercrime costs expected to reach $10.5 trillion annually.

The rapid advancement of AI systems, including tools like Anthropic’s Claude Mythos, capable of identifying and exploiting vulnerabilities at scale, highlights how exposed modern software has become.

At the same time, the number of connected devices continues to grow rapidly, projected to exceed 30 billion by 2030. Security has stayed a footnote for too long. The CRA is here to make it the headline.

The roadmap: Key dates to circle

The clock is already ticking. While the regulation entered into force in December 2024, there are two milestones you need to prepare for:

• September 11, 2026: Strict reporting obligations begin. You'll need to report incidents and exploited vulnerabilities within hours, not weeks.
• December 11, 2027: Full compliance becomes mandatory. No CE mark? No EU market.

What actually changes?

The Cyber Resilience Act requirements cover the entire product lifecycle. In practice, this comes down to three key shifts:

1. Security is no longer optional, it’s built in

Security must be addressed from the very beginning.

This includes:

• Risk analysis based on how the product will be used
• Secure architecture decisions
• Strong authentication and access control
• Data protection by default

This is what “secure by design and by default” really means. It’s not just implementing security features, but designing with security in mind from day one.

2. You need to know what’s inside your software

Under the CRA, you are responsible not only for the code you write, but also for the components you use.

This means:

• Keeping track of all third-party libraries and dependencies
• Monitoring known vulnerabilities in those components
• Being ready to act when issues are discovered

In practice, this often translates into maintaining a Software Bill of Materials (SBOM) or equivalent visibility.

3. Responsibility doesn’t end at release

One of the biggest changes is what happens after launch.

Meeting CRA expectations requires more than quick fixes, it demands a structured approach to security. In practice, this means:

• Define a product lifecycle and support period
• Provide security updates and patches throughout that period
• Have a process for handling vulnerabilities (internally and externally reported)
• Be ready to monitor, detect, and report incidents and actively exploited vulnerabilities within strict timeframes

In most cases, this means supporting a product for at least five years, unless its expected lifetime is shorter.

The shift is simple, but significant: from “build and ship” to “build, secure, and maintain”

What does CRA compliance actually look like?

To meet CRA requirements, companies need to move beyond principles and put concrete practices in place.

More importantly, the CRA makes it clear that these practices cannot be added later. They must be integrated into the design and development process from the start, embedding security into the foundation of the product, not layering it on afterwards.

In practical terms, this includes:

• Conducting risk assessments based on product use and lifecycle
• Ensuring secure configuration by default
• Minimising attack surfaces and eliminating known vulnerabilities
• Implementing access control and identity management
• Protecting data through encryption and secure storage
• Enabling data deletion and portability
• Monitoring systems and ensuring resilience against incidents
• Establishing processes for continuous vulnerability management
• Preparing and maintaining technical documentation
• Defining and committing to a clear support and update policy

It’s less about ticking boxes and more about building a structured, repeatable approach to security.

What do sausages have to do with software?

Not a fan of more regulations? Neither were we, until we looked at it through the lens of a humble sausage.

Find out more

Where most companies are not ready

Despite the upcoming regulation, many teams are still operating in ways that won’t meet these expectations.

And it’s not just about meeting requirements at a single point in time. The CRA introduces a long-term commitment, requiring products to be supported, monitored, and secured throughout their lifecycle, often for years after release. In practice, this typically means providing security support for at least five years, unless the product’s expected lifetime is shorter.

Common gaps include:

• Limited visibility into dependencies
• No formal vulnerability management process
• Missing or outdated documentation
• No clear ownership after release
• Security treated as a secondary concern

These are not edge cases, they’re the norm.

Why a technical partner matters

For many organisations, the biggest challenge is operationalising CRA.

Compliance requires more than isolated fixes. It demands a shift in how software is designed, built, and maintained over time. However, this is difficult to achieve alongside day-to-day delivery.

That’s why many turn to experienced technical partners – to embed security into the development process, not add it later.

At Vega IT, we see this shift clearly: the teams that succeed are those that treat security as part of how they build from the start.

This isn’t just a regulatory shift, it’s a shift in expectations.

The organisations that start early won’t just meet the requirements. They’ll be better positioned to build resilient products and long-term trust.

If you’re preparing for the CRA and not sure where to start, let’s talk.