By Angelah Liu
The EU Cyber Resilience Act is no longer a distant regulatory concept. With vulnerability reporting obligations to ENISA arriving on September 11 and the full weight of the law landing in December 2027, open source maintainers, foundations, and the companies who build on top of open source all have real questions about what comes next. OpenSSF brought together three practitioners for a Tech Talk to walk through exactly that: what the CRA requires, how supply chain security practices map to those obligations, and what manufacturers are actually building to get ready.
Moderated by Megan Knight, Director of Software Communities at Arm, the session featured Roman Zhukov from Red Hat, who works on open source security strategy and engagement and is involved with the EU CRA effort; John Kjell previously 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 now live on YouTube. Download the presentation deck.
What Is the EU Cyber Resilience Act (CRA) and How Does It Affect Open Source Software?
Roman opened the Tech Talk with a sobering statistic from the newly released 2026 CRA Awareness and Readiness Report: 66% of respondents said they were still unfamiliar with the regulation, even with the first reporting deadline less than a month away. Only 41% of manufacturers expect to be fully compliant by the December 2027 deadline, and 39% said they simply don’t know when they will achieve compliance.
From there, Roman laid out what the CRA actually is: a European regulation meant to safeguard consumers by mandating cybersecurity requirements for digital products sold or placed on the EU market, covering everything from source code and binaries to containers and hardware. The law aims to reduce vulnerabilities and secure the entire product lifecycle, not just the moment of certification, and it is the first regulation of its kind to formally recognize open source as a stakeholder, including a defined category for open source software stewards such as foundations that govern projects without selling them.
The practical upshot for most open source contributors is straightforward. Maintainers and contributors have no obligations under the CRA if they are not monetizing their projects. Manufacturers, the companies who consume open source and incorporate it into commercial products, carry the bulk of the obligations: due diligence on third-party components, contributing fixes upstream, and reporting exploited vulnerabilities and severe incidents to EU authorities.Ā
Roman talked about what this means for the relationship between companies and maintainers going forward. Where consumption of open source has historically been a one-way street, the CRA is pushing manufacturers to actually engage with the projects they depend on, and he argued that respectful, collaborative compliance is the only scalable way to do that without damaging the ecosystem. For stewards and maintainers who want a head start, OpenSSF has published a stewards’ obligation checklist and a CRA readiness guide for maintainers and developers, and the OpenSSF Global Cyber Policy Working Group continues to produce educational materials alongside partners like ORBIT Launchpad, Zephyr, and Yocto.
How Can Organizations Implement Practical Supply Chain Security for CRA Compliance?
John shifted the conversation to the engineering level, framing his section of the talk around what it actually looks like to build and consume open source responsibly, whether you’re a maintainer, a consumer, or a manufacturer.
For projects starting from an open source first mindset, he pointed to the CNCF TAG Security best practices as a foundation: code review requirements, branch protection, and licensing hygiene all feed into compliance in direct or indirect ways. The OpenSSF Best Practices Badge adds a layer of documentation and support policy visibility, giving maintainers a way to answer manufacturer questionnaires with a link instead of a lengthy back and forth.Ā
Self-assessment matters too. Understanding your threat model, who uses the project, how data flows, and where the trust boundaries sit, helps maintainers both build more safely and communicate clearly when vulnerabilities are reported outside that model. Tools like OpenSSF Scorecard automate much of this checking, while joint security assessments from CNCF’s TAG Security and professional audits funded through OpenSSF, CNCF, and the Alpha-Omega project fill in the gaps that manual review can’t scale. On the supply chain side, John pointed to SLSA build provenance and the importance of generating SBOMs during the build process itself rather than after the fact, since anything generated later tends to be less accurate and produces more false positives down the line.
For consumers of open source, John’s advice started with intentionality. Do you actually need a given dependency, or are you already depending on something that does the job? From there, a policy based approach that checks scorecard results, project health, maintainer activity, and license type helps keep dependency decisions consistent, and none of the metadata generated across the supply chain is useful unless it’s actually verified. He referenced the left-pad incident as a reminder of what happens when a widely used dependency simply disappears, and closed with a simple point: supporting upstream, even just saying thank you, goes a long way toward keeping maintainers motivated.
For manufacturers, the obligations get heavier. Knowing what’s in your software through SBOMs, understanding whether a given vulnerability actually affects your code using tools like OpenVEX, and applying patches are just the starting point. John noted that manufacturers carry an obligation to fix vulnerabilities in their open source dependencies for up to five years, even if the upstream project becomes unmaintained or deprecated, and they have to be able to rebuild affected components themselves rather than waiting on someone else to patch them. There’s also a requirement to continue distributing security patches for free during that support window, independent of any paid subscription.Ā
What Is ORBIT Launchpad and How Does It Assist Manufacturers with EU CRA Article 13.5?
Nicole focused on the manufacturer side of the equation and introduced ORBIT Launchpad, an OpenSSF Special Interest Group created to help manufacturers share what they’ve learned about CRA compliance and build on existing open source tooling rather than starting from scratch.
The group’s first major output addresses due diligence under CRA Article 13.5, which takes effect in December 2027 but is already being actively worked on. Nicole’s team started with the Open Source Project Security Baseline, an existing set of control statements already used in events like the CNCF/OpenSSF Security Slam, and found that it covered only about 35% of what the CRA actually asks manufacturers to demonstrate. That gap led to two new catalogs: CRA Baselines for Manufacturers, and a more focused set called CRA Baselines for Open Source Consumption, currently made up of 12 requirements the community has identified as the core evidence needed to demonstrate due diligence on the open source a company consumes.
These catalogs produce machine readable, signable evidence, output that can be bundled, signed, and made tamper proof so that auditors have something concrete to review. The ORBIT Launchpad is not trying to shift any CRA burden onto maintainers; the goal is entirely about giving manufacturers a shared, practical way to meet their own obligations.Ā
Where Can Software Manufacturers and Maintainers Find Resources for EU CRA Readiness?
To continue exploring these topics, the OpenSSF Global Cyber Policy Working Group serves as the primary nexus for ongoing CRA discourse. Community members can engage via their active Slack channel, GitHub repository, and mailing list, or access a comprehensive document library featuring the stewards’ one-pager, manufacturer-specific guidance, and the latest standards updates. For deeper dives, the ORBIT Launchpad SIG maintains its own Slack presence and conducts weekly sessions. For additional training, OpenSSF offers a free educational course (Understanding the EU Cyber Resilience Act (CRA) (LFEL1001)) designed to help teams navigate the EU Cyber Resilience Act, alongside the complete 2026 CRA Awareness and Readiness Report available for download. For those seeking face-to-face engagement, the community is gathering at the upcoming OpenSSF Community Day Europe in Prague, featuring dedicated session opportunities including a CRA Lunch & Learn.
About the Author
Angelah Liu is the Communications & Marketing Manager at the Linux Foundation, driving marketing initiatives across multiple open source projects, including OpenSSF, the Confidential Computing Consortium, Overture Maps, and AOUSD. A creative at heart, she thrives on bridging the gap between technical communities and the wider world. As a dedicated advocate for āOpen Source for Good,ā she uses digital storytelling to ensure open source breakthroughs drive a lasting, positive influence far beyond the tech ecosystem.