If you're shipping products to the EU and using open source components, you have until September 2026 to comply with the European Cyber Resilience Act (CRA). Here's the issue: 66% of organizations aren't aware of the CRA, and the rest aren't sure how it affects their engineering practices.
This checklist will help you prepare. Each item has a clear pass/fail state and defines what "done" looks like.
What This Checklist Covers
The CRA imposes new legal obligations for companies using open source software in products sold in the EU. You can't just use open source libraries and assume someone else will maintain them. The regulation defines specific roles (manufacturer, distributor, importer) and assigns responsibility for security throughout the product lifecycle.
This checklist focuses on practical steps your compliance and engineering teams need to take before September 2026.
Prerequisites
Before starting this checklist, ensure you have:
- A complete software bill of materials (SBOM) for products sold in the EU
- Identified ownership for each open source dependency in your codebase
- Executive buy-in for open source contribution as a compliance activity
Checklist Items
1. Map your CRA role for each product
Determine whether you're a manufacturer, distributor, or importer under the CRA for each product line. If you're developing software and selling it in the EU, you're likely a manufacturer with the highest compliance burden.
✓ Done when: You have documented role assignments for every product, reviewed by legal counsel familiar with EU regulations.
2. Identify critical open source dependencies
List every open source component in your production systems. Flag which ones are security-critical, such as authentication libraries and cryptographic functions.
✓ Done when: You have a prioritized list of dependencies ranked by security impact.
3. Assess maintenance status for each critical dependency
For your top 20 critical dependencies, document: last commit date, number of active maintainers, security response process, and vulnerability disclosure policy.
✓ Done when: You can answer "who fixes a critical CVE in this library and how fast?" for each component.
4. Establish contribution capacity
Calculate how many engineering hours per quarter you can dedicate to open source contribution. The CRA requires you to participate in keeping projects secure.
✓ Done when: You have a quarterly budget (in hours) for engineers to contribute patches, security reviews, or testing to upstream projects.
5. Connect with open source stewards
Identify which of your dependencies are managed by organizations like OpenSSF or Linux Foundation. These stewards can provide infrastructure and guidance for CRA compliance.
✓ Done when: You have contact points at relevant steward organizations and understand their security processes.
6. Document your vulnerability response plan
Define how you'll respond when a critical vulnerability appears in an open source dependency. Include notification channels, patch testing process, deployment timeline, and customer communication.
✓ Done when: You can run a tabletop exercise simulating a zero-day in a core library and complete it within your SLA.
7. Review your fork vs. contribute strategy
If you're maintaining private forks of open source projects, calculate the cost. Isolated codebases can be expensive when you factor in backporting patches and testing.
✓ Done when: You have a written policy on when to fork vs. when to contribute upstream, with cost justification.
8. Establish security disclosure channels
Make it easy for security researchers to report vulnerabilities in your products. This includes issues in your own code and in the open source components you use.
✓ Done when: You have a security.txt file deployed, a monitored security email address, and documented response SLAs.
9. Train engineering teams on CRA implications
Your developers need to understand that choosing an open source library now carries compliance weight, not just technical considerations.
✓ Done when: Engineers can explain the CRA role definitions and know where to check a dependency's maintenance status before adding it.
10. Set up compliance monitoring
Create alerts for changes in your critical dependencies: new maintainers, archived repositories, transfer of ownership, and changes to security policies.
✓ Done when: You receive automated notifications within 24 hours of significant changes to your top 20 dependencies.
Common Mistakes
Treating this as a legal-only problem. Your lawyers can't write the patches. Compliance teams need to work directly with engineering to build contribution capacity.
Waiting for official guidance. The September 2026 deadline won't move because you're waiting for clearer documentation. Start with what you know.
Assuming your vendors handle it. If you're integrating open source components into your product, you're responsible under the CRA regardless of where you got them.
Forking everything. Private forks feel like control, but they're expensive and isolate you from security patches. Contribute upstream instead.
Ignoring the 66% who don't know. If your competitors aren't preparing, that's your competitive advantage. Use it.
Next Steps
Start with items 1-3 this quarter. You need to know your role, your dependencies, and their health before you can plan contributions.
By Q2 2025, complete items 4-7. This builds your contribution muscle and reduces your fork burden.
By Q4 2025, finish items 8-10. You need monitoring and training in place well before the enforcement deadline.
The CRA isn't just about avoiding fines. It's about recognizing that open source isn't a free vending machine. If you depend on it, you need to help maintain it. That's not charity, it's risk management.
