For organizations offering products with digital elements in the EU, the next major Cyber Resilience Act (CRA) deadline arrives on 11 September 2026. From that date, organizations covered by the reporting obligations must be ready to assess actively exploited vulnerabilities and severe security incidents, coordinate an internal response and submit notifications within the required timelines.
Yet many organizations may not know whether they need to report. The 2026 CRA Awareness and Readiness Report found that 66% of respondents had little or no familiarity with the CRA. Even among those familiar with it, 41% had not determined whether the regulation applied to them.
Image Source: 2026 CRA Awareness and Readiness Report
When an actively exploited vulnerability or a severe incident is discovered, can your organization identify the affected products or projects, involve the right teams and coordinate the appropriate response?
Open Source Program Office (OSPO) professionals are helping both, manufacturers and open source software steward organizations close these practical gaps. Drawing on industry examples from TODO Group’s member organizations, with OpenSSF and OpenChain resources, this post explores three ways they support CRA implementation and how your organization can get started.
When no one coordinates open source management, CRA implementation can quickly become fragmented:
These gaps are especially dangerous during an incident. Teams lose critical time validating component versions, locating owners and reconstructing how a dependency entered a product.
OSPO professionals move that work earlier:
This does not take responsibility away from legal, product or engineering. Instead, these teams give them the reliable open source information and relationships they need to do their jobs.
The Linux Foundation's 2025 State of OSPOs and Open Source Management found that, among 116 organizations with a formal or informal OSPO, 92% involved it in open source security: 42% said the OSPO made security-risk decisions and 50% said it advised the responsible team.
OpenSSF has already translated the different obligations for manufacturers, open source software stewards and contributors into accessible guidance. Its CRA Brief Guide for Open Source Software Developers explains which products and activities the CRA covers and what changes when an organization is a manufacturer or an open source software steward. OpenSSF and Linux Foundation Education also offer the free 90-minute course Understanding the EU Cyber Resilience Act (LFEL1001).
For more detailed implementation, the OpenSSF OSS Stewards Obligations Checklist turns Article 24 of the CRA (which establishes the obligations for open source software stewards) into questions about cybersecurity policies, reporting, cooperation and corrective action. The CRA Stewards Playbook helps a steward identify its projects, security contacts, CSIRT, development infrastructure and reporting process. For individual maintainers and developers, the CRA Readiness Guide for Maintainers and Developers provides voluntary security and transparency practices that can help projects support downstream users without transferring CRA obligations or liability to maintainers.
For manufacturers and product-security teams, the OpenSSF PSIRT Obligations Checklist focuses on the processes and evidence needed for vulnerability and incident reporting. The OpenChain CRA Requirements and Checklist RC1 helps organizations map their existing activities and evidence to 182 review points covering governance, SBOM quality, vulnerability handling, open source stewardship and technical documentation.
CRA preparation does not always require new processes. For many organizations, it begins by mapping established open source, security and quality-management practices to CRA requirements, documenting what is already in place and identifying the remaining gaps.
This does not require a new regulatory department or complex structure. Think of an OSPO as the people, skills and practices that enable an organization to manage open source effectively. In a multinational company, this may involve a dedicated team. In a smaller organization, it may be one person coordinating open source responsibilities alongside other work.
Many OSPOs already maintain software inventories or generate SBOMs for open source license compliance. CRA preparation can build on this work, but generating an SBOM is not enough.
ENISA’s SBOM Adoption State of Play 2026 found that although 78% of surveyed organizations had started adopting SBOMs, only 9% had reached mature, fully automated implementation. Most respondents did not know whether or how SBOMs were being consumed within their organizations.
To support vulnerability handling, component information must be connected across the product portfolio and development lifecycle (including released versions, internal modifications, product owners and support periods) and remain accessible to the teams that need it. OSPO professionals can help establish this shared view and resolve gaps such as unidentified packages, private forks and unclear ownership.
When a vulnerability is actively exploited, product security and legal need rapid answers: Is the component present? Is the affected functionality used? Did the organization modify it? Who can contact upstream securely?
The OSPO supplies components and community context, while PSIRT assesses security impact and determines regulatory action. The OpenSSF PSIRT Obligations Checklist helps identify the processes and evidence product security teams need. Organizations should test the complete 24-hour workflow through a tabletop exercise rather than waiting for a real incident.
These exercises can also reveal where agentic workflows could reduce manual work. For example, by collecting component evidence, identifying owners and preparing vulnerability cases for human review.
“Agentic workflows can help OSPOs when sufficient automation is already in place and reliable, high-quality data is available through APIs.”
– Cornelius Schumacher, DB Systel
It is also important to note that data quality alone is not enough. As Oscar Valenzuela (formerly of Amazon's OSPO) emphasized in his compliance-automation presentation to the TODO Group's Agentic AI to Empower OSPOs Working Group, AI automation depends on correct data. Human approval, traceable sources and deterministic policy checks therefore remain essential. The working group is exploring reusable workflows, evaluation and human-in-the-loop boundaries for this work.
The CRA should not result in hundreds of manufacturers sending overlapping questionnaires to the same volunteer maintainers. OSPO professionals can consolidate requests, reuse public project information, coordinate responsible disclosure and help engineering teams contribute fixes upstream.
“OSPOs can also help identify the open source projects behind critical dependencies that are strong candidates for financial support.”
– Jeff Luszcz, GitHub OSPO
This gives manufacturers better evidence and more maintainable software, while protecting the limited capacity of open source communities. Shared, machine-readable approaches developed across the ecosystem will scale better than separate company-by-company processes.
Here are a few examples of initiatives being led by OSPO professionals within their organizations.
At Nokia, more than two decades of open source compliance work and a decade of OSPO experience provide a foundation for CRA implementation. Nokia launched a dedicated CRA compliance program in 2024. Gergely Csatari, Nokia's OSPO team member focused on open source policy, has helped turn software transparency into practical work.
“Nokia’s OSPO is helping the organisation achieve CRA compliance in three additional areas: automating open source due diligence, coordinating vulnerability fixes with upstream communities and identifying which published projects Nokia stewards.”
– Gergely Csatari, Nokia OSPO
At Cisco, the OSPO describes its role as stewarding the company's open source efforts, including contribution and compliance. Natali Vlatko, Cisco Open Source Lead Architect, has emphasized the importance of involving OSPOs in open source security "from the outset" as organizations respond to the CRA. Early involvement prevents component ownership and upstream relationships from becoming emergency questions later.
Deutsche Bahn has a public Open Source Manifesto, policies, projects and contacts. These practices give the organization a foundation for CRA preparation by connecting project governance, internal teams and upstream communities. They help DB determine which open source projects it supports, document how those projects are managed and direct security issues to the appropriate people.
Another example is Samsung SDS, which provides a concrete example of open source processes relevant to CRA implementation. Since 2023, the company has automatically generated, stored and managed SBOMs for its solutions, using them to identify software supply-chain relationships and analyze security vulnerabilities. In 2024, it also announced conformance with OpenChain ISO/IEC 18974, which requires processes for identifying known vulnerabilities in open source components, assessing their risk and documenting remediation, helping support CRA requirements for component documentation and ongoing vulnerability handling.
Every organization can apply OSPO practices without creating a large department. The urgent requirement is to name the responsible people, give them a mandate and connect their work with legal, security, engineering and product leadership, and organizations do not need to design every part of this work alone:
An organization that has already mapped its products, components and upstream relationships can answer a reporting question in hours. One that has not will be assembling that map while the clock runs.
About TODO Group
TODO Group is an open, vendor-neutral community of OSPO practitioners sharing best practices for open source management and emerging AI governance in real-world organizational contexts. Hosted by the Linux Foundation, TODO Group creates shared resources and guidance to support practical adoption, alignment, and collaboration across organizations.
About OpenSSF
The Open Source Security Foundation (OpenSSF) brings together people and organizations working to improve the security of open source software. Hosted by the Linux Foundation, it develops practical guidance, training, tools and shared security standards.
About OpenChain
The OpenChain Project develops open source compliance and security-assurance specifications, reference materials and adoption resources for software supply chains. Its specifications underpin ISO/IEC 5230 and ISO/IEC 18974, and it is hosted by the Linux Foundation.
Contributors to this article: