Open Source Maintainers Face EU Cyber Resilience Act Deadline: What Compliance Looks Like

The Cyber Resilience Act has transitioned from a regulatory proposal into an imminent obligation for the open source ecosystem. As vulnerability reporting deadlines approach in September and the law takes full effect in December 2027, maintainers, stewards, and companies relying on open source are grappling with concrete compliance questions. The Open Source Security Foundation recently hosted a panel of three practitioners to dissect the regulation's requirements, map supply chain security practices to those obligations, and examine what manufacturers are doing to prepare.

Megan Knight, Director of Software Communities at Arm, moderated the session, which featured Roman Zhukov from Red Hat, who leads open source security strategy and engagement on EU CRA matters; John Kjell, formerly of ControlPlane and now at Docker, co-chair of CNCF's TAG Security and an OpenSSF Ambassador; and Nicole Bates from Microsoft's Azure Office of the CTO, who co-chairs both the IETF's Supply Chain Integrity Working Group and OpenSSF's Supply Chain Integrity Working Group along with the ORBIT Launchpad SIG. The recording is available on YouTube, and the presentation deck is downloadable.

Understanding the EU Cyber Resilience Act and Its Impact on Open Source

Zhukov opened with a troubling finding from the 2026 CRA Awareness and Readiness Report: 66% of respondents remained unfamiliar with the regulation despite the first reporting deadline being less than a month away. Only 41% of manufacturers expect to achieve full compliance by the December 2027 deadline, while 39% reported uncertainty about when they would reach compliance.

The CRA itself is a European regulation designed to protect consumers by establishing cybersecurity requirements for digital products sold or distributed within the EU market. Its scope encompasses source code, binaries, containers, and hardware. The law seeks to eliminate vulnerabilities and secure the entire product lifecycle beyond the point of certification. Notably, it represents the first regulation to formally acknowledge open source as a stakeholder, establishing a distinct category for open source software stewards such as foundations that manage projects without commercializing them.

For most open source contributors, the practical implications are relatively straightforward. Maintainers and contributors face no CRA obligations if they do not monetize their projects. Manufacturers—the companies that consume open source and integrate it into commercial offerings—bear the primary obligations: conducting due diligence on third-party components, submitting fixes upstream, and reporting exploited vulnerabilities and severe incidents to EU authorities.

Zhukov addressed how this reshapes the relationship between companies and maintainers. Open source consumption has traditionally been unidirectional, but the CRA is compelling manufacturers to genuinely collaborate with the projects they depend on. He contended that respectful, collaborative compliance represents the only sustainable approach without harming the ecosystem. For stewards and maintainers seeking to get ahead, OpenSSF has released a stewards' obligation checklist and a CRA readiness guide for maintainers and developers. The OpenSSF Global Cyber Policy Working Group continues producing educational materials in partnership with organizations including ORBIT Launchpad, Zephyr, and Yocto.

Implementing Practical Supply Chain Security for CRA Compliance

Kjell moved the discussion to the engineering level, framing his remarks around what responsible open source development and consumption actually entail, whether one operates as a maintainer, consumer, or manufacturer.

For projects built with an open source first approach, Kjell pointed to CNCF TAG Security best practices as a starting point: code review requirements, branch protection, and licensing hygiene all contribute to compliance in direct or indirect ways. The OpenSSF Best Practices Badge provides an additional layer by documenting practices and support policies, allowing maintainers to respond to manufacturer questionnaires with a link rather than extensive back-and-forth exchanges.

Self-assessment also matters significantly. Maintainers who understand their threat model, know who uses their project, map data flows, and identify trust boundaries can build more securely and communicate clearly when vulnerabilities fall outside that model. OpenSSF Scorecard automates much of this assessment, while joint security evaluations from CNCF's TAG Security and professional audits funded through OpenSSF, CNCF, and the Alpha-Omega project address gaps that manual review cannot scale to handle. On the supply chain front, Kjell emphasized SLSA build provenance and the importance of generating SBOMs during the build process itself rather than afterward, since post-build generation tends to be less accurate and generates more false positives.

For open source consumers, Kjell's guidance began with intentionality. Does a given dependency actually serve a purpose, or is another dependency already in use that accomplishes the same goal? A policy-driven approach that evaluates scorecard results, project health, maintainer activity, and license type helps maintain consistency in dependency decisions. However, none of the metadata generated across the supply chain proves useful without verification. Kjell referenced the left-pad incident as a cautionary tale about what occurs when a widely used dependency vanishes, and concluded with a straightforward observation: supporting upstream projects, even through simple acknowledgment, significantly helps maintain contributor motivation.

Manufacturers face heavier obligations. Understanding software contents through SBOMs, determining whether a vulnerability actually impacts their code using tools like OpenVEX, and applying patches represent only the beginning. Kjell noted that manufacturers must fix vulnerabilities in their open source dependencies for up to five years, even if the upstream project becomes unmaintained or abandoned. They must also possess the capability to rebuild affected components themselves rather than depending on others to patch them. Additionally, manufacturers must continue distributing security patches at no cost during that support window, independent of any paid subscription model.

ORBIT Launchpad and Manufacturer Support for CRA Article 13.5

Bates concentrated on the manufacturer dimension and introduced ORBIT Launchpad, an OpenSSF Special Interest Group established to help manufacturers share CRA compliance knowledge and build upon existing open source tooling rather than developing solutions from scratch.

The group's initial major contribution addresses due diligence obligations under CRA Article 13.5, which becomes effective in December 2027 but is already receiving active attention. Bates's team began with the Open Source Project Security Baseline, an existing collection of control statements previously used in events such as the CNCF/OpenSSF Security Slam, and discovered it covered approximately 35% of what the CRA requires manufacturers to demonstrate. This shortfall prompted the creation of two new catalogs: CRA Baselines for Manufacturers and a more targeted set called CRA Baselines for Open Source Consumption, currently comprising 12 requirements the community has identified as essential evidence for demonstrating due diligence on consumed open source.

These catalogs generate machine-readable, signable evidence that can be bundled, signed, and made tamper-proof for auditor review. ORBIT Launchpad is not attempting to transfer CRA obligations to maintainers; instead, the goal is providing manufacturers with a shared, practical mechanism to fulfill their own responsibilities.

Resources for CRA Readiness

The OpenSSF Global Cyber Policy Working Group functions as the central hub for ongoing CRA discussion. Community participation occurs through an active Slack channel, GitHub repository, and mailing list, with access to a comprehensive document library containing the stewards' one-pager, manufacturer guidance, and current standards updates. The ORBIT Launchpad SIG maintains its own Slack channel and conducts weekly meetings for deeper exploration. OpenSSF provides a free educational course titled "Understanding the EU Cyber Resilience Act (CRA) (LFEL1001)" to help teams navigate the regulation, alongside the complete 2026 CRA Awareness and Readiness Report available for download. The community will gather in person at the upcoming OpenSSF Community Day Europe in Prague, which will feature dedicated sessions including a CRA Lunch & Learn.