Building digital products for the Cyber Resilience Act

If you’re selling software or hardware products with software components that ship into the EU, you need to get ready for the Cyber Resilience Act (CRA). The CRA is a new EU regulation, taking effect in 2026, that raises the security bar for every digital product on the market — including apps, hardware, firmware, connected devices such as wearables, and more. The CRA was established to mitigate the risks posed by malicious actors, who are increasingly targeting the software supply chain.

The CRA mandates security by design and requires the implementation of secure code as part of the software development lifecycle. This raises a significant question for engineering, platform, and DevOps teams: how do you meet CRA requirements without compromising your delivery velocity?

Enter Chainguard.  Chainguard shares the "secure by default" design principle espoused by the CRA and quickly aligns the product build process with the CRA regulations. Chainguard addresses all work related to vulnerabilities, best practices for security, and secure build processes, eliminating a significant amount of toil and saving time.

Why the CRA matters

The CRA applies to “products with digital elements” (PDEs), which essentially encompasses anything that runs software. Whether you’re shipping a SaaS software-only product or an IoT device, if it reaches EU customers, then the CRA applies to you. Beyond the considerable brand and trust damage that comes with failing such a broad and recognizable regulation, there are serious financial ramifications tied to the CRA, ranging from €5 million to €15 million fines, or 2.5% of global annual turnover.

Enforcement phases begin in 2026 and will be fully locked in by 2027:

• Conformity assessment can be done from June 11, 2026.

• Mandatory reporting of vulnerabilities and security incidents begins on September 11, 2026.

• Full application of all requirements for new products starting December 11, 2027.

The “why” behind the CRA is what's driving the regulations to address engineering practices and not just the end product:

• 245,000+ malicious open source packages were detected in 2023.

• SolarWinds showed how a single compromised build pipeline can impact tens of thousands of organizations.

• Compromises in npm have hit billions of downloads.

• AI-enabled supply-chain attacks are rapidly increasing the scale and precision of compromise.

The CRA says that products must be designed, developed, and produced to ensure appropriate security. For many organizations, this means they must rethink how they build, update, patch, and ship software.

Before Chainguard: What CRA compliance looks like

Here’s the reality many teams face today. There is base image chaos due to the fact that engineering teams often pull unvetted public images because “it works.” Then, vulnerabilities pile up because these images weren't built with security or secure principles in mind. Tickets are filed for the remediation of these vulnerabilities, creating a significant amount of extra work in tracking down the issues, fixing them, and updating dependencies. As a result, deliverables slip and security is compromised.

To address security issues, provide information for security audits, or, especially after incidents occur, teams scramble to conduct risk assessments and root-cause analyses. The fire drills for severe CVE patches often result in inconsistent, non-reproducible builds, as developers build locally, but the CI system builds something different. The provenance of components is sketchy. Visibility into the fragmented, relatively unmanaged supply chain is limited, and assembling SBOMs after the fact is like putting Humpty Dumpty back together again.

All of this runs counter to the CRA regulations. Not to mention, engineering velocity slows to a crawl.

After Chainguard: CRA-ready secure foundations built into the workflow

Chainguard offers secure-by-default building blocks — hardened container images, VMs, and language libraries — that shift teams from reactive security to secure-by-default development.

After adopting Chainguard, DevOps has a completely different look. Instead of starting from unvetted, bloated distro images with potentially hundreds of vulnerabilities, you start with:

• A zero-CVE distroless image

• Non-root user by default

• No shell

• No package manager

In addition to starting with a secure baseline, Chainguard provides continuous patching, updating images every day with a 7-day SLA for critical CVEs. You simply rebuild your application, and you’re up to date. And your builds feature full SBOMs and attestations without extra work. Every Chainguard artifact comes with a signed SBOM with known provenance and immutable versioning.

This satisfies several CRA Annex I requirements out of the box. When regulators or security teams ask, “Where did this come from?” you have the answer.

CRA and Chainguard: Be compliant without compromising velocity

For engineering teams, the CRA doesn’t just introduce new rules; it requires teams to focus on work they often struggle with. Chainguard provides a way to meet CRA requirements without slowing down, without adding toil, and without building your own security framework from scratch.

By adopting secure-by-default building blocks, you:

• Eliminate CVE backlogs

• Reduce engineering overhead for patches and associated toil

• Improve supply-chain transparency

• Meet CRA requirements as a natural byproduct of how you build software

Chainguard provides a secure foundation for modern development, allowing you to continue shipping fast while meeting security and compliance requirements, such as CRA.

Get in touch with our team to learn more about how we can help you meet CRA requirements.