By Madalin Neag, Sally Cooper, and Steve Winslow

If you are a maintainer, steward, or manufacturer, you might have heard about the EU Cyber Resilience Act (CRA) and wondered how it impacts your day-to-day work. The CRA requirements for Stewards do not take effect until December 11, 2027, but the requirements for Manufacturers take effect today, on September 11, 2026.

The CRA introduces new cybersecurity requirements for products with digital elements, with responsibilities that differ across the software ecosystem. Most of the open source software community will qualify under the CRA’s Steward framework, but knowing how the CRA will impact your downstream commercial ecosystem, who will be classified as Manufacturers, will be important. For the open source community, understanding how manufacturers will interact with open source projects is an important part of preparing for the next phase of CRA implementation.

An important milestone for this shared security model is fast approaching. On September 11, 2026, the CRA’s mandatory reporting requirements apply for manufacturers. This article explains what that means for manufacturers and, importantly, how open source projects and stewards can be ready to support and collaborate with manufacturers when reported vulnerabilities involve open source components.

Why is the September 11, 2026 Deadline Important?

On September 11, 2026, manufacturers are required to begin reporting actively exploited vulnerabilities and severe incidents impacting the security of their products with digital elements.

Once a manufacturer becomes aware of such an event, it must report through the CRA Single Reporting Platform (SRP), with an early warning within 24 hours and a full notification within 72 hours. A final report is then required no later than 14 days after a corrective or mitigating measure becomes available for an AEV, and within one month of the 72-hour notification for a severe incident.

The CRA also provides for voluntary reporting under Article 15, allowing manufacturers and other persons or entities to voluntarily report vulnerabilities, cyber threats, incidents, or near misses to a coordinating CSIRT or ENISA. However, this functionality will not be available in the SRP at the September 11 launch and will be added at a later stage.

September 11, 2026 is therefore, first and foremost, a manufacturer reporting milestone. Manufacturers need to have the people, processes, and reporting channels in place to meet these obligations from day one. To help with this, we have prepared a practical CRA Manufacturer Checklist summarising the key checks and actions manufacturers should consider for September 11, 2026 obligations.

For open source projects and stewards, September 11 is therefore not a new reporting deadline. Its significance is practical: a manufacturer may identify an actively exploited vulnerability in a product and trace it to a third-party open source component. In that situation, the manufacturer is responsible, but may reach out to the project, its maintainers, or its steward for information, support, and collaboration on addressing the issue.

What Does the September 11 Milestone Mean for Open Source Maintainers?

For maintainers of open source software projects that are hosted and supported at the LF, we have published a brief summary at https://cra-lf-readiness.openssf.org with a one-page overview of the steps your project should take for its CRA readiness.

The September 11 reporting requirements apply to manufacturers, not to individual open source maintainers simply because they maintain or contribute to an open source project.

However, maintainers may increasingly hear from manufacturers and other downstream users when a vulnerability in an open source component affects their products. This broader collaboration is also reflected in Article 13(6) of the CRA. While Article 13(6) is not part of the September 11 reporting milestone, it provides a framework for how manufacturers engage with upstream maintainers when vulnerabilities are identified, including reporting the vulnerability and, where appropriate, sharing fixes or relevant documentation. Sharing the fixes will be mandatory for manufacturers, so it will be helpful for maintainers to be ready for submissions of fixes.

Being prepared to respond to those requests can help the entire ecosystem address serious vulnerabilities more effectively.

How you can prepare:

Add a security.md file: Simply placing a security policy in your repository provides a clear, private disclosure path for security researchers and a useful contact point for downstream users.
Keep your security contact current: Make sure manufacturers, researchers, and other users can quickly identify the right person or team to contact about a serious vulnerability.
Know your support network: If your project has a steward or foundation, understand how they can help facilitate communication and coordination when a manufacturer needs to engage with the project about a serious vulnerability.

The goal is not to turn maintainers into CRA reporting officers. It is to make sure that projects are reachable and ready to collaborate when a manufacturer needs their support.

For more practical guidance, see the CRA Readiness Guide for Maintainers and Developers, which outlines voluntary security practices that can help projects improve their security posture and make it easier for downstream users to assess and work with them.

What Are the CRA Obligations for Open Source Stewards?

As recently clarified by the European Commission and ENISA, September 11, 2026 does not introduce a CRA reporting obligation for open source stewards. Stewards’ reporting responsibilities under the CRA formally begin on December 11, 2027. Before that date, though, stewards can play a valuable practical role in helping their projects respond when manufacturers reach out about serious vulnerabilities in open source components.

When a manufacturer identifies an actively exploited vulnerability involving an open source dependency, it may need to work with the relevant project to understand the issue and support the development and communication of a fix. Where a project has a steward or foundation, that organization can help facilitate this collaboration and connect the manufacturer with the appropriate project contacts.

At the LF, most open source software projects that are hosted and supported by the LF will not become their own stewards. Some projects with well-established security operational processes may choose to do so, though this is not a light task to take on; see below for more details. Most LF-hosted projects will rely on the applicable LF entities to generally act as the formal steward. Those projects still have a responsibility to maintain a vulnerability reporting process, and to escalate actively exploited vulnerabilities and severe incidents via the LF’s stewardship reporting path.

How a steward can support its projects:

Establish a clear point of contact: Create or maintain a dedicated security contact so manufacturers and maintainers know where to escalate serious vulnerabilities.
Define an escalation path: Make sure the right people can be brought together quickly when a manufacturer needs to discuss an actively exploited vulnerability affecting a project.
Support collaboration: Help projects and manufacturers communicate effectively during investigation, remediation, and disclosure.
Use the playbook to prepare early: While September 11, 2026 does not introduce the CRA reporting obligations for open source stewards, it is a good opportunity to start building the processes, contacts, and capabilities that will support steward readiness ahead of the CRA obligations that apply from December 11, 2027. The LF and OpenSSF CRA Stewards Playbook can help stewards build that readiness well in advance.

The focus for stewards is preparedness, coordination, and support.

What Should the Open Source Community Be Ready for?

The September 11 milestone creates a stronger need for manufacturers to understand the open source components in their products and to know how to engage with the projects behind those components.

For open source projects and stewards, the practical response is straightforward: be reachable, be prepared to collaborate, and make it possible to move quickly when a manufacturer reports a serious vulnerability involving an open source component.

A typical response could look like this:

A manufacturer identifies an actively exploited vulnerability affecting its product.
The manufacturer reports the vulnerability through the CRA Single Reporting Platform within the applicable deadlines.
The manufacturer determines that the vulnerability involves an open source component.
The manufacturer contacts the relevant project, maintainer, or steward.
The project and manufacturer collaborate to understand the issue and, where appropriate, develop and communicate a fix or mitigation.
The manufacturer and other downstream users can apply the available remediation to their products.

This is where strong relationships between manufacturers and open source projects can make a real difference.

How Can You Get Involved in Shaping CRA Policy?

The open source community is working together to make CRA implementation as smooth and helpful as possible. Here is how you can join the conversation, get your questions answered, and help shape the future of open source security:

Read the Playbook: Dive into the full LF and OpenSSF CRA Stewards Playbook for actionable, step-by-step guidance.
Join the Working Group: Participate in the OpenSSF Global Cyber Policy Working Group to collaborate on international legislation and standardizing compliance tools.
Meet Us in Prague: Join us at OpenSSF Community Day (October 6, 2026) and Open Source Summit Europe (October 7-9, 2026) in Prague. We will be hosting a dedicated Workshop: Operationalizing the Cyber Resilience Act (Boxed Lunch Included)
Become a Member: Want a seat at the table for deeper strategy conversations? Become an OpenSSF Premier Member to participate in exclusive Chatham House Rule discussions on the CRA and global cyber policy.

Conclusion

September 11, 2026 is a CRA reporting milestone for manufacturers. From that date, manufacturers must be ready to identify and report actively exploited vulnerabilities and severe incidents affecting products with digital elements through the CRA SRP. Open source projects and their maintainers do not take on a CRA reporting obligation on that date. Neither do Stewards, whose obligations under Article 24 apply from December 11, 2027.

What changes for open source is practical. Manufacturers now have a legal clock running when they find an actively exploited vulnerability, and many of those vulnerabilities will trace to open source components. Projects that are easy to reach and that can move quickly when contacted will be the ones manufacturers learn they can work with.

Article 13(6) provides important context for this manufacturer-component maintainer collaboration, even though that provision is not itself part of the September 11 reporting milestone.

Open source projects and individual maintainers do not need to treat September 11, 2026 as a CRA reporting deadline. Instead, they can use the milestone as an opportunity to make their security contacts, vulnerability-handling processes, and collaboration channels easier for manufacturers and downstream users to find and use. When the CRA deadline for stewards comes into play in December 2027, those projects who have already established their processes will be all set.

Stewards likewise can focus on preparedness, coordination, and support, using the time before their CRA obligations apply to build the processes and relationships needed to help their projects respond effectively.

Manufacturers should be ready to report. Open source projects should be ready to respond and collaborate. Stewards can use the time ahead to build the structures that support both.

Useful Resources

https://digital-strategy.ec.europa.eu/en/policies/cra-reporting CRA Reporting Obligations
https://digital-strategy.ec.europa.eu/en/library/cyber-resilience-act-implementation-frequently-asked-questions EC CRA FAQ
https://www.enisa.europa.eu/topics/product-security/single-reporting-platform-srp ENISA SRP Resources incl. the FAQ, Assigned Representatives Guidelines, Factsheet, Glossary
https://digital-strategy.ec.europa.eu/en/library/commission-publishes-new-guidance-support-timely-cyber-resilience-act-implementation – EC Guidance
https://openssf.org/wp-content/uploads/2026/09/LF-Supported-Projects-and-CRA-Readiness-2026-09-10.pdf – LF Supported Projects and CRA Readiness

About the Authors

Madalin Neag works as an EU Policy Advisor at OpenSSF focusing on cybersecurity and open source software. He bridges OpenSSF (and its community), other technical communities, and policymakers, helping position OpenSSF as a trusted resource within the global and European policy landscape. His role is supported by a technical background in R&D, innovation, and standardization, with a focus on openness and interoperability.

Sally Cooper is a Senior Communications & Marketing Manager at OpenSSF. She helps the community share their stories and shines a light on the work that keeps open source secure for everyone.

Steve Winslow is Vice President of Legal and Policy at The Linux Foundation. He works with contributors, maintainers, counsel, and other participants in the LF’s open source communities on legal matters, regulatory compliance, and public policy topics.