The European Cyber Resilience Act (CRA) became enforceable in December 2024, yet awareness is declining. A recent survey found that 66% of respondents remain unfamiliar with the CRA—up from 62% earlier in 2025. For compliance teams managing software supply chains, this knowledge gap represents immediate legal and financial exposure.
If your organization manufactures or distributes software products in EU markets, the CRA creates direct liability for security vulnerabilities in every component you ship—including open source dependencies. The regulation eliminates the "we just use it" defense that has defined open source consumption for decades.
What Changed Under the CRA
The CRA shifts legal responsibility for software security from end users to manufacturers and distributors. Under Articles 13 and 20, you must:
- Identify and document all components in your products, including open source libraries.
- Actively monitor for vulnerabilities throughout the product lifecycle.
- Implement security updates within defined timeframes.
- Maintain evidence of due diligence in component selection and maintenance.
Non-compliance triggers penalties up to €15 million or 2.5% of global annual turnover, whichever is higher. The regulation applies to "products with digital elements" placed on the EU market, which covers most software products and connected hardware.
Key Findings: Where Organizations Stand
The awareness problem is getting worse. With 66% of organizations still unfamiliar with CRA requirements, most compliance teams haven't started the operational changes needed. North American organizations show particularly low awareness despite significant EU market exposure.
Private forks are bleeding budget. Organizations maintaining private forks of open source projects spend an average of $258,000 in labor costs every release cycle. This approach—forking a project, applying internal patches, and maintaining it separately—creates a maintenance burden that scales with every upstream release. When the original project releases security fixes, your team must manually merge, test, and redeploy.
Current practices won't satisfy CRA requirements. The CRA demands continuous monitoring and timely patching. Private forks introduce lag between upstream security fixes and your deployed versions. During that lag, you're shipping known vulnerabilities into EU markets with your name on the liability.
SMEs face disproportionate burden. Small and medium enterprises lack dedicated open source program offices. They're consuming open source at scale but contributing nothing back—no security reviews, no patch submissions, no funding. Under CRA, this passive consumption model becomes legally risky.
Documentation gaps create compliance blockers. Most organizations can't produce a complete software bill of materials (SBOM) for their products. The CRA requires this documentation as evidence of due diligence. Without it, you can't demonstrate compliance even if your security practices are sound.
What This Means for Your Team
Your current open source strategy probably assumes that using widely-adopted libraries transfers security responsibility to "the community." The CRA explicitly rejects this assumption. When you ship a product containing Log4j, you're liable for Log4j vulnerabilities—regardless of who wrote the code.
This changes your relationship with every dependency. Before CRA, selecting a library meant evaluating its features and license. Now you're evaluating:
- The maintainer's security response time and track record.
- The project's funding and sustainability.
- Your ability to patch critical vulnerabilities if maintainers are unavailable.
- The cost of maintaining your fork versus contributing upstream.
The $258,000-per-cycle cost of private forks reflects this new calculus. That figure covers the engineering time to track upstream changes, merge security patches, resolve conflicts, and validate that your modifications still work. For organizations maintaining forks of multiple projects, the costs compound.
Contributing patches upstream costs less than maintaining private forks. When you submit a security fix to the original project, future releases include your change automatically. You eliminate the merge-and-test cycle for that fix. The OpenSSF has published guidance on structuring upstream contributions to satisfy CRA due diligence requirements.
Action Items by Priority
Immediate (Next 30 Days):
Inventory your EU market exposure. List every product you sell or distribute in EU markets. Include SaaS products—the CRA covers software accessed by EU customers, not just software installed in EU data centers. For each product, identify the decision-maker responsible for CRA compliance.
Generate SBOMs for in-scope products. Use tools like Syft, SPDX, or CycloneDX to create machine-readable component lists. The CRA accepts multiple SBOM formats, but you need complete dependency graphs—including transitive dependencies. If your build process can't produce accurate SBOMs, that's your first technical blocker.
Short-term (Next 90 Days):
Assess your ten most critical dependencies. For each library, document the maintainer's security disclosure process, typical response time for CVEs, and funding model. OpenSSF Scorecards provide automated security health metrics for open source projects. If a critical dependency scores poorly or lacks active maintenance, you need a mitigation plan.
Calculate your private fork costs. Track engineering hours spent maintaining internal forks over the last two release cycles. Include time for merging upstream changes, resolving conflicts, testing, and deployment. Compare this to the cost of contributing patches upstream. For most organizations, upstream contribution costs 30-40% less than fork maintenance.
Establish vulnerability monitoring. Implement automated scanning for your dependencies using tools like Dependabot, Snyk, or Grype. Configure alerts for critical and high-severity CVEs. The CRA requires "timely" patching—the specific timeline depends on severity, but critical vulnerabilities typically require updates within days, not weeks.
Medium-term (Next 6 Months):
Build upstream contribution workflows. Create internal processes for submitting security patches to upstream projects. This requires legal review of contribution agreements, training for engineers on project-specific submission processes, and tracking to ensure your contributions get merged. Document these workflows as evidence of CRA due diligence.
Support critical dependencies financially. If your product depends on an undermaintained project, fund its development. The CRA creates liability for using insecure components—paying a maintainer to improve security is cheaper than paying EU fines. Organizations can pool resources through initiatives like GitHub Sponsors or OpenSSF.
Train SMEs on CRA requirements. Small and medium enterprises need targeted guidance on minimum viable compliance. The OpenSSF has developed CRA-specific resources for organizations without dedicated security teams. If you're an SME, start with SBOM generation and vulnerability scanning—these provide the documentation trail the CRA requires.
Conclusion
To navigate the CRA's requirements, your team must shift from passive use of open source to active engagement and investment in security. Begin by assessing your exposure, generating SBOMs, and evaluating your dependencies. By contributing to and supporting open source projects, you can reduce costs and improve compliance.
