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.

Why ad-hoc preparation creates security risk

When no one coordinates open source management, CRA implementation can quickly become fragmented:

• Legal interprets the obligation but lacks product-level dependency information or technical understanding of open source supply chain.
• Security receives an alert but cannot immediately identify every affected product.
• Engineering knows the code but may not know which legal entity or product owner is responsible for the regulatory decision.
• Procurement tracks commercial suppliers but may not see open source dependencies introduced through development pipelines.
• Teams contact upstream maintainers separately, duplicating requests and adding pressure to open source communities.

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:

• They help establish a shared map of products, components, repositories, internal owners and upstream relationships before an incident occurs.
• They also bring open source context into risk assessments, helping teams define proportionate measures without creating unnecessary compliance work.

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.

Turning a legal obligation into an operational response

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.

Three areas where OSPO professionals can start

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.

Connect products to components

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.

Test the reporting chain

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.

Coordinate upstream engagement

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.

Learnings from the industry

Here are a few examples of initiatives being led by OSPO professionals within their organizations.

Nokia

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

• Automating open source due diligence: The OSPO helps to convert the existing Nokia open source component selection criteria into a CRA compliant open source component due diligence program. Due to the high volume of the consumed open source and the velocity of the development the due diligence check is fully automated and based on Open SSF’s Scorecard project and it is integrated to Nokia’s home developed open source compliance tool. The CRA and the harmonized standards are not totally clear about all details of the due diligence, therefore among other industry experts the Nokia OSPO team is working on an industry aligned whitepaper about the due diligence in the ORC Working Group.
• Coordinating fixes with upstream projects: With the CRA Nokia will be obliged to provide a fix to the zero day vulnerabilities discovered by the company to the upstream communities. To do this in a way that helps the upstream communities instead of overstressing the maintainers is the job of the Nokia OSPO. The open source team is preparing extra training for the development and security teams about critical bug fixing in open source and will assist the process in situ.
• Identifying stewarded projects: The open source software stewards will be obliged to report actively exploited vulnerabilities in their stewarded open source projects if the vulnerability is in an area developed by the steward. For this the Nokia team is actively working on the classification of the published open source projects. The projects with active development and maintenance will be explicitly stated as Nokia stewarded projects, while the academic publications, hackathon examples and other not maintained projects will be explicitly marked as non stewarded.

Cisco

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

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.

Samsung SDS

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.

Final remarks

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:

• The OpenSSF's CRA resource hub provides a practical pathway for implementing CRA requirements.
• The Open Source Project Security Baseline offers measurable security practices for open source projects, while ORBIT focuses on interoperability and tooling that can make assessment and evidence more scalable.
• OpenChain’s CRA Requirements and Checklist RC1 turns CRA preparation into 182 review points covering governance, SBOM quality, vulnerability handling, Article 14 reporting, open source stewardship and technical documentation. RC1 is open for public review, with feedback for Version 1.0 requested by 8 September 2026. Version 1.0 is planned for 11 September with an initial focus on reporting readiness, followed by continued development toward Version 2.0 before the CRA becomes fully applicable in December 2027. Organizations can contribute through GitHub. The checklist supports readiness and evidence management; completing it does not itself constitute a conformity assessment or legal advice.
• The CRA Brief Guide and the LFEL1001 course establish a shared understanding across developers, managers and OSPO professionals.
• The TODO Group's OSPO Book chapter on managing open source security connects this security expertise to organizational practice. It was developed with OpenSSF representatives and support from the TODO Group. TODO Group members and OSPO leaders also contribute practical experience across sister projects (OpenSSF, OpenChain, CHAOSS and others), helping translate shared resources into open source management and operations.

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:

• Madalin Neag, EU Policy Advisor, OpenSSF
• Ana Jiménez Santamaría, Senior Project Manager, Linux Foundation
• Gergely Csatari, Senior Open Source Specialist, Nokia
• Meixia Wang, Executive Director of OpenChain Project
• Jeff Luszcz, OSPO, GitHub
• Cornelius Schumacher, DB
• Daniel Park, OSPO manager, Samsung