Your company probably isn't ready for the Cyber Resilience Act (CRA). According to recent research, 66% of the global software community hasn't heard of the CRA, with North American teams hitting 72% unawareness. When December 2027 rolls around and enforcement begins, many teams will discover they've been making expensive mistakes for years.
Here's what goes wrong, why it keeps happening, and how to fix it before it costs you.
Why These Mistakes Keep Happening
The CRA's scope surprises teams because it applies to any product with digital elements sold in the EU market. That includes your SaaS platform, IoT devices, and even internal tools white-labeled for a European client. Most teams assume regulatory compliance is someone else's problem until procurement blocks a deal or legal sends an urgent email.
Another issue is treating open source dependency management as purely technical, not a compliance concern. Your developers have been forking libraries and maintaining private patches for years, without calculating costs or regulatory exposure.
Mistake 1: Assuming the CRA Doesn't Apply to You
Why it happens: Your sales team focuses on North American customers. Your product roadmap doesn't mention Europe. Your legal team hasn't flagged it.
The consequence: The CRA doesn't care about your target market. If a single customer in the EU can purchase your software, you're in scope. During a compliance audit or customer security questionnaire, you'll face a choice: abandon the customer, rush through compliance, or risk penalties.
The fix: Run a product inventory now. List every software product your company sells or distributes. For each one, answer: Can someone in the EU buy it, download it, or use it? If yes, you're manufacturing a product with digital elements under the CRA. Start your compliance planning today, not in 2027.
Mistake 2: Maintaining Private Forks Without Counting the Cost
Why it happens: Your team finds a bug in an open source library. The upstream maintainer hasn't merged your fix yet, or you need a custom feature. Forking feels faster than waiting. You do this a few times, and suddenly you're maintaining a dozen private forks across different repositories.
The consequence: Each private fork costs an average of $250,000 per release to maintain. You're paying engineers to rebase patches, resolve merge conflicts, backport security fixes, and test compatibility. Multiply that across multiple forks and multiple releases per year. A mid-sized company with five active forks could be spending over $1 million annually on maintenance that adds zero product value.
The fix: Before forking, calculate the total cost of ownership. Include engineering time for initial fork, ongoing maintenance, security patch backports, and testing. Compare that to the cost of contributing upstream or working with the maintainer. In most cases, paying a developer to improve the upstream project costs less than maintaining a private fork for a single year. When you must fork, set a sunset date. Treat it as technical debt with a mandatory payoff timeline.
Mistake 3: Confusing Manufacturers and Stewards
Why it happens: The CRA introduces a new legal distinction most teams haven't encountered. You've heard about "open source stewards" and assume that's what you are because you use open source software.
The consequence: Under the CRA, manufacturers bear full compliance responsibility for products they sell. Stewards are open source foundations or projects that meet specific criteria and have lighter obligations. If you're a commercial software company that uses open source components, you're a manufacturer, not a steward. Misunderstanding this means you'll underprepare for your actual compliance requirements.
The fix: Determine your role explicitly. Are you selling a product? You're a manufacturer. Are you maintaining an open source project through a recognized foundation with no commercial product? You might qualify as a steward. For manufacturers, your compliance obligations include vulnerability disclosure, security updates, and documentation for every component in your product. Budget and plan accordingly.
Mistake 4: Treating Awareness as Someone Else's Job
Why it happens: Developers assume compliance teams know about the CRA. Compliance teams assume legal is tracking it. Legal assumes the business has flagged it as a priority. Everyone's waiting for someone else to raise the alarm.
The consequence: With 72% of North American teams unaware of the CRA, you're probably not alone in your organization. This awareness gap means no budget allocation, no project timeline, no assigned owners. When the deadline approaches, you'll scramble to retrofit compliance into existing products instead of building it in from the start.
The fix: Schedule a cross-functional meeting this month with representatives from engineering, compliance, legal, and product. Share the CRA timeline: compliance obligations start December 2027. Assign an owner for CRA readiness. Create a Slack channel or wiki page for tracking progress. Make it someone's actual job, with goals and accountability.
Mistake 5: Ignoring Upstream Collaboration Benefits
Why it happens: Contributing to open source projects feels like charity work or a nice-to-have. Your team is measured on feature velocity and bug fixes in your own product, not on commits to external projects.
The consequence: When you don't collaborate upstream, you lose the security and maintenance benefits that come from active participation. Other contributors won't test your use cases. Security researchers won't examine the code paths you depend on. You'll discover vulnerabilities later, patch them yourself, and pay for the privilege.
The fix: Change how you measure developer productivity. Track upstream contributions as a positive metric. When a developer needs to modify an open source dependency, make "contribute the fix upstream" the default path, not the exception. Set a team goal: reduce private forks by 50% this year through upstream collaboration. Allocate 10% of each developer's time to open source maintenance. That's cheaper than paying $250,000 per release for private forks.
Prevention Checklist
Use this checklist quarterly to catch compliance mistakes before they compound:
- Product inventory complete with EU market exposure assessment
- Private fork count documented with per-fork maintenance costs calculated
- Legal classification confirmed: manufacturer vs. steward status
- Cross-functional CRA working group meeting monthly
- Upstream contribution metrics tracked in team dashboards
- Compliance budget allocated for 2025-2027 timeline
- Vulnerability disclosure process documented and tested
- Security update delivery mechanism defined for each product
- Developer training scheduled on CRA requirements and upstream collaboration
- Executive sponsor assigned with quarterly progress reviews
The CRA isn't going away, and the costs of ignoring it compound with every release. Start fixing these mistakes now, while you still have time to do it right.
