The European Union’s Cyber Resilience Act (CRA) marks a turning point for anyone building, selling, or maintaining digital products. Whether it’s enterprise software, consumer apps, IoT devices, or embedded systems, the CRA sets rigorous cybersecurity requirements that apply throughout a product’s entire lifecycle, from design and development to deployment, maintenance, and secure decommissioning.
At its core, the CRA is about security-by-design. It mandates transparency, robust vulnerability management, and secure updates backed by enforcement mechanisms such as CE marking, machine-readable Software Bills of Materials (SBOMs), and compliance documentation.
Why You Need to Start Now
The CRA fundamentally redefines how software will be built and maintained, pushing organizations to adopt more structured, transparent, and security-centered development strategies. And if you’re like most commercial software developers who incorporate open source components, you’ll need to account for your dependencies. Your team will need time to adapt development and security workflows to meet these new expectations.
The timeline for CRA compliance is already in motion:
- December 2024 – The CRA came into force. This marked the start of the transition period for all affected stakeholders.
- September 2026 – Early obligations take effect, including mandatory vulnerability reporting to EU authorities, specifically the European Union Agency for Cybersecurity (ENISA).
- December 11, 2027 – Full enforcement begins. By this point, stakeholders must be ready with machine-readable SBOMs, secure update mechanisms, and detailed compliance documentation for every applicable product.
And, it’s important to note that the consequence of non-compliance isn’t just a fine. It can mean being locked out of the EU market entirely.
Roles and Responsibilities Under the CRA
Before we jump into the actual impacts of these regulations, let’s take a moment to clarify the different roles and responsibilities in the software development process. In its latest iteration, the CRA clarifies distinct roles and who’s accountable within the open source ecosystem:
- Manufacturers: Any entity placing a product (including those built from OSS) on the EU market. They bear full legal responsibility for security throughout the software lifecycle.
- Open Source Stewards: Newly defined economic actors, such as those who systematically support an open source project as a sustained offering intended for commercial use.
- Maintainers/Contributors: Individuals or teams engaged in development. Generally, they are not directly bound by CRA obligations, unless acting as stewards or manufacturers.
This structured distinction allows the CRA to exempt casual contributors while focusing legal accountability on downstream producers. However, even though maintainers may not face direct enforcement, the realities of dependency chains mean they must adapt. For example, many manufacturers will insist on robust security hygiene, transparency, and responsiveness from upstream projects. As a result, maintainers will find themselves needing more structured workflows, clarity on vulnerability handling, and easier collaboration pathways.
Specific Obligations for Organizations Building Software
Clearly, manufacturers face the greatest burden in this scenario. But what exactly are they responsible for? Under the CRA, manufacturers of all sizes, including software publishers, must:
- Generate a machine-readable SBOM listing, at a minimum, top-level dependencies.
- Keep SBOMs updated and provide them to market surveillance authorities upon request.
- Maintain vulnerability handling frameworks, including having a public channel for reporting and a quick remediation pipeline.
- Apply secure updates, ideally over-the-air, and separate them from functional updates.
- Share patches upstream for OSS components they use, fostering better ecosystem security.
Non-compliance with the CRA can come at a high cost. Fines may reach €15 million or 2.5% of global annual turnover, whichever is higher. Some responsibilities that were previously optional, such as sharing patches with upstream projects, are now required. This shift means organizations need to reassess how they handle compliance across the software lifecycle. That includes generating and maintaining SBOMs, securing CI/CD pipelines, improving vulnerability scanning, and strengthening patch management processes.
Impact on DevOps Teams
So, what does this mean, precisely, for those of us building new software? For DevOps practitioners, the CRA’s broad and deep mandates mean applying security across both processes and toolchains. DevOps teams will need to:
- Incorporate SBOM generation and management for all PDEs (Products with Digital Elements), continually updating them.
- Establish or enhance vulnerability disclosure mechanisms and incident reporting channels, including timely communication with relevant authorities such as ENISA.
- Ensure secure, streamlined software updates, preferably separated from feature updates, and automatic where feasible.
- Conduct software risk analyses, enforce code integrity (e.g., through signing), encrypt data streams, and maintain documentation for extended periods (up to 10 years or the product’s support lifespan).
These new requirements are pushing many organizations to modernize how they build and ship software. Instead of treating the CRA as just another checklist, forward-looking teams see it as a chance to strengthen security across the entire development process. That means improving how dependencies are managed, automating SBOM generation, tightening vulnerability response, and separating security updates from new features. When done well, these changes don’t just satisfy compliance requirements. They also reduce technical debt, improve long-term resilience, and help build trust with users and partners. In many cases, preparing for the CRA can be the push teams need to develop software that is more secure and easier to maintain.
Turning to the Community for Guidance
Few regulations have created as much industry-wide urgency for practical guidance as the CRA. Small- and medium-sized enterprises (SMEs) are particularly vulnerable, as they often lack the compliance resources of their much larger counterparts.
The good news: the industry is responding. The Open Regulatory Compliance (ORC) Working Group, hosted by the Eclipse Foundation, was created to develop actionable resources and collaborate with government agencies to help organizations comply with regulations, such as the CRA.
Backed by neutral governance, strong ties to standardization bodies (CEN, CENELEC, ETSI), and liaison to the EU’s CRA experts, ORC includes more than 50 members and is rapidly growing. This diverse group brings together global technology companies like Nokia, Mercedes‑Benz, Microsoft, Red Hat, GitHub, and Google, more than 20 open source foundations, and a growing number of SMEs working together on practical solutions.
This cross-industry, open source–friendly initiative is helping developers, enterprises, and open source communities navigate this evolving regulatory landscape with clarity and confidence. ORC provides a collaborative platform to share relevant resources, including specifications, best practices, and reference materials, and serves as a trusted forum for dialogue with regulators, standards bodies, and industry stakeholders. With its depth of expertise and commitment to open source values, ORC is uniquely positioned to shape a practical, balanced path to CRA compliance.
The Time to Act is Now
With the first CRA obligations taking effect in September 2026 and full enforcement by December 2027, the window for preparation is narrowing quickly. While some regulatory details are still being finalized, the direction is clear. Now is the time to align your development workflows, build compliance into your pipelines, and contribute to the broader conversation shaping how these rules will apply in practice.
ORC is one example of how the open source community is coming together to tackle these challenges collectively. By sharing resources, expertise, and practical tools, ORC is helping organizations of all sizes prepare for CRA compliance without sacrificing agility or innovation.
The CRA is more than just another set of rules. For DevOps teams and software professionals, it’s a chance to make security a built-in part of everyday work. This isn’t only about meeting legal requirements. It’s about helping shape a software ecosystem that’s easier to trust, easier to maintain, and better for everyone involved.