The EU Cyber Resilience Act and DevOps

Living in Germany, I've watched GDPR change how every company handles personal data. The EU Cyber Resilience Act (CRA) is set to do something similar for software security. And unlike many regulations, it lands directly on the things DevOps teams do every day: dependencies, vulnerability handling, updates and build pipelines.

A quick disclaimer before we start: I'm an engineer, not a lawyer. This is my practical reading of what it means for teams. For your company's specific obligations, talk to your legal and compliance people.

What the law says, in plain words

The CRA sets cybersecurity requirements for "products with digital elements" sold in the EU. That covers a lot: software, apps, connected devices, firmware, and many components that end up in other products.

The core idea: if you put software on the EU market, you're responsible for its security for its whole lifetime, not just on release day. That means:

• Secure by design and by default: no known exploitable vulnerabilities at release, secure default configuration, protection of data, minimised attack surface.
• Vulnerability handling: a process to receive, assess and fix vulnerabilities, and provide security updates for a defined support period (generally at least five years, or the expected product lifetime if shorter).
• SBOMs: document the components in your product, at least the top-level dependencies, in a machine-readable format.
• Reporting: report actively exploited vulnerabilities and severe incidents to authorities within tight deadlines.
• Documentation and conformity: technical documentation, and for most products a self-assessment, with stricter assessment for some critical categories. Compliant products carry the CE marking.

The dates that matter

• December 2024: the CRA entered into force.
• 11 September 2026: reporting obligations apply. Manufacturers must report actively exploited vulnerabilities and severe incidents through ENISA's single reporting platform. Early warning within 24 hours, a fuller notification within 72 hours, and a final report later.
• 11 December 2027: the rest of the requirements apply, including the essential security requirements and conformity assessment.

So the reporting part is already live. The full set arrives next year.

The CRA turns "we'll patch it eventually" into a legal obligation with a deadline.

What about open source?

This was heavily debated during the drafting. The final text tries to protect open-source developers:

• Open-source software developed and shared without commercial activity is generally outside the scope.
• A new role, the open-source software steward (for example foundations that support projects used commercially), has lighter obligations.
• Companies that use open source in their commercial products are responsible for those components as part of their product. Using a library doesn't shift responsibility to its maintainers.

That final point matters most for most of us: your dependencies are now your responsibility.

What changes in my pipeline

The nice surprise: a lot of what the CRA asks for is what good DevSecOps teams already do, or should. It just becomes mandatory and documented.

• SBOM generation for every release (Syft, Trivy, CycloneDX tools), stored and versioned.
• Continuous vulnerability scanning of those SBOMs, not just at build time, so newly discovered vulnerabilities in old releases are found.
• A vulnerability disclosure policy and a way for researchers to report issues (a security.txt, a security contact, a SECURITY.md).
• A defined support period for each product version, and the ability to ship security updates quickly during it.
• Signed artifacts and build provenance, to show the integrity of what you ship.
• Secure defaults in your products: no default passwords, minimal open ports, encryption on.
• An incident and reporting process that can meet a 24-hour deadline for exploited vulnerabilities. Who decides? Who reports? Practise it.
• Documentation of all of the above.

A checklist

1. Find out whether your products are in scope, and in which category (most are in the default, self-assessment category).
2. Generate and store SBOMs for every release.
3. Set up continuous vulnerability monitoring of shipped versions.
4. Publish a vulnerability disclosure policy and security contact.
5. Define and communicate support periods.
6. Create a process to report exploited vulnerabilities within 24 hours.
7. Make security updates easy to deliver, and separable from feature updates where possible.
8. Document your secure development practices.
9. Review your dependencies: unmaintained components are a liability now.

So, should DevOps teams care?

Very much. The CRA lands right in our pipelines. The teams that already automate SBOMs, scanning, signing and fast patching will find compliance relatively easy. The teams that don't have about a year to catch up.

My take: the CRA is regulation, but most of it is just good engineering written into law. Build those habits now, and compliance becomes a by-product.

— Desly