Cyber Resilience Act: New Rules for Secure Software and Digital Products

For companies that develop software, operate digital products, or provide them to customers, this is a fundamental change. The CRA makes a simple point: a digital product launched on the European market must be designed from the outset to be cyber-secure.

This isn’t just about large corporations or critical infrastructure. The regulation may also affect everyday mobile apps, web platforms, SaaS products, smart appliances, IoT devices, enterprise software, or custom-developed systems. If a product contains a digital element and is available on the EU market, it must comply with the CRA.

What is the main change?

Until now, cybersecurity was often addressed primarily at the company, process, and operational levels. The CRA shifts the focus directly to the product. It is therefore not enough to simply have a security policy documented somewhere. It is crucial that the software or device itself be designed, developed, and maintained securely.

A manufacturer or supplier will need to know what their product consists of. What libraries it uses. What external services are connected. How vulnerabilities are addressed. Who is responsible for updates. What happens when a security flaw is discovered.

In practice, this is a major issue, especially with software. Modern applications often rely on tens to hundreds of components, frameworks, open-source libraries, and cloud services. The CRA expects companies to maintain an overview of these components. There is talk of a so-called software bill of materials—that is, a list of the components that make up the product.

When will the CRA take effect?

The regulation has already been approved, but its implementation is divided into several phases. The full requirements will primarily apply to products placed on the market after December 11, 2027.

However, that doesn’t mean it’s time to wait. Obligations related to reporting vulnerabilities and serious security incidents will take effect earlier. Companies will therefore need to have processes in place for monitoring, risk assessment, incident response, and communication with the relevant authorities.

In other words: anyone who waits until the end of 2027 to address the CRA will likely be too late.

Why should companies address this now?

Because product security cannot simply be “patched on” at the end of development. For software to comply with the CRA, security must be factored in from the very beginning—during architecture design, technology selection, work with suppliers, and the setup of the development process.

Companies should ask themselves several fundamental questions right now:

• Are we bringing software or a digital product to market?
• Are we the manufacturer, supplier, distributor, or just an integrator?
• What components and libraries does our product use?
• Do we have a process for addressing security vulnerabilities?
• Do we know who is responsible for updates and patches?
• Can we demonstrate that we develop the product securely?

These questions will become increasingly important in the coming years—not only because of regulation, but also because of customer trust.

What should we take away from this?

CRA isn’t just another legal obligation. It’s a clear signal that software security is becoming a standard part of product quality. Just as physical products are expected not to endanger the user’s health, digital products will be expected not to compromise the user’s data, privacy, or operations.

For us at Railsformers, this is a topic that makes perfect sense. Secure development, oversight of components, vulnerability management, and responsible architecture aren’t just a one-time checklist. They are habits that must be part of the entire software lifecycle.

And that’s exactly where the CRA will hit hardest for those who have long put off addressing security.