The software industry has operated under a comfortable fiction for decades. Build the product, ship it to customers, disclaim liability in the license agreement, move on to the next release. Security vulnerabilities? That's someone else's problem.

The EU Cyber Resilience Act ends that fiction. And the ramifications extend far beyond Europe.

A major shift in liability

When EU legislators drafted the CRA, they started with a simple observation: the people who create software security problems aren't the ones who pay for them.

The numbers are stark. Cybercrime costs the global economy an estimated EUR 5.5 trillion annually, with the EU absorbing a disproportionate share. Connected devices ship with default credentials. Critical vulnerabilities sit unpatched for months because vendors prioritize new features over security updates. Open-source libraries with known exploits remain embedded in production software because upgrading them would break things.

Consumers and businesses bear these costs. They lack the technical expertise to evaluate product security at purchase time, and they lack the leverage to demand fixes after the sale. The economic incentives point vendors toward features, not security.

The CRA rebalances those incentives through liability. Starting December 2027, manufacturers are legally responsible for the cybersecurity of their products throughout the entire product lifecycle, minimum five years. Not at the point of sale. Throughout.

That single word, throughout, changes everything.

What "throughout" actually means

Under the CRA, manufacturers must provide free security updates for the entire support period. When they discover a vulnerability, they must remediate it "without delay." When they learn of an actively exploited vulnerability, they have 24 hours to report it to authorities.

This isn't compliance theater. Market surveillance authorities can order immediate product recalls and market withdrawals. Penalties reach EUR 15 million or 2.5% of global annual turnover, whichever is higher. For a company with EUR 10 billion in revenue, that's a potential EUR 250 million fine.

But the penalties aren't the real story. The real story is the operational transformation this requires.

Consider what continuous vulnerability management actually demands. Modern software applications contain hundreds or thousands of dependencies—open-source libraries, commercial components, transitive dependencies nested several layers deep. Every one of those components can introduce vulnerabilities. Every vulnerability needs to be tracked, assessed, and potentially remediated.

The CVE program registered nearly 50,000 new vulnerabilities in 2024 alone. That's over 130 new vulnerabilities every day. For an organization with a complex software supply chain, the monitoring and triage workload is staggering.

And here's the part that keeps CISOs awake at night: you're responsible for all of it. Not just the code your developers write. Every third-party component. Every transitive dependency. Every open-source library someone added three years ago and forgot about.

The challenge of open source under the CRA

Modern commercial software consists of 70-80% open-source components. This isn't a secret. It's the foundation of how software gets built today. But it creates a specific problem under the CRA.

Open-source maintainers aren't liable. The regulation explicitly protects "open-source software stewards", the individuals and foundations that maintain open-source projects without commercial motivation. They can't be fined for security vulnerabilities.

But the moment you ship that open-source code in a commercial product, the liability transfers to you. You're now responsible for vulnerabilities in code you didn't write, maintained by people you've never met, funded by donation buttons most companies ignore.

The CRA doesn't just require you to monitor these components. It requires you to know what you're shipping. Manufacturers must maintain a Software Bill of Materials (SBOM) documenting every component in their products. Not just top-level dependencies. Everything.

This creates a documentation burden that most organizations aren't prepared for. Manual SBOM creation doesn't scale. Automated tooling produces SBOMs, but they're often incomplete or inconsistent. The real challenge is maintaining SBOMs across hundreds of products, each with their own dependency trees, each evolving with every release.

The prioritization problem

Even if you know what's in your software, you still need to decide what to fix. And this is where most organizations hit a wall. Traditional security tools take a simple approach: flag every known vulnerability. If a CVE exists for any component in your dependency tree, it appears in your vulnerability report. For complex applications, this produces thousands of findings.

Most of these findings are noise. A vulnerability in a function you never call poses no real risk to your users. A vulnerability in a test dependency that never ships to production is irrelevant. A vulnerability that requires specific configuration options your product doesn't use can't be exploited.

But traditional tools don't know any of that. They report everything, leaving security teams to manually investigate each finding. The result is alert fatigue. Teams can't keep up with the volume, so they start ignoring findings. The vulnerabilities that matter get lost in the noise.

The CRA doesn't care about your alert fatigue. It cares about whether your products are secure. And "we had too many findings to investigate" isn't a valid defense when an exploited vulnerability leads to an enforcement action.

This is why the security industry is shifting toward reachability analysis, techniques that examine whether vulnerable code is actually executable in a specific application context. If a vulnerability exists in a function your code never calls, it's not exploitable in your product. That finding can be deprioritized.

Organizations using reachability-based approaches report 80-90% reductions in actionable findings. That's the difference between a manageable workload and an impossible one.

The challenge of remediating “without delay”

Identifying vulnerabilities is only half the challenge. You also need to fix them.

Under the CRA, "without delay" is the operative standard. The regulation doesn't specify exact SLAs, but industry practice suggests 24-72 hours for critical vulnerabilities. That timeline assumes you can actually ship a fix in that window.

For vulnerabilities in your own code, this is manageable. For vulnerabilities in dependencies, it's complicated.

Upgrading a dependency sounds simple. In practice, it often isn't. Major version upgrades can introduce breaking changes. A security fix in one library might conflict with version requirements in another. Upgrading a foundational dependency might require changes across dozens of files.

Development teams face a choice: ship a risky upgrade that might break things, or delay the fix while they validate compatibility. Neither option is good. The first creates reliability problems. The second creates compliance problems.

This is driving interest in alternative approaches like backported security patches, fixes that address specific vulnerabilities without requiring major version upgrades. The security community has been doing this for years in operating systems. Now the technique is extending to application dependencies.

The business model implications

Let's be direct about what the CRA means for software economics: security is now a cost of doing business, not an optional feature.

Product management teams need to budget for continuous security support. Not just bug fixes, active vulnerability monitoring, assessment, and remediation for years after initial release. The support period can't end when a product becomes unprofitable. It ends when you've met your minimum obligations.

For many organizations, this changes the calculation on whether to enter the EU market at all. Smaller vendors may conclude that compliance costs exceed potential EU revenue. Some products may be withdrawn from EU distribution.

For larger vendors, the CRA creates competitive dynamics. Companies that invest in security infrastructure, automated SBOM generation, reachability analysis, streamlined remediation, will be able to move faster and more efficiently. Companies that treat compliance as a manual, reactive exercise will struggle with the workload and the timelines.

The market will reward companies that get this right. The CRA creates visible evidence of security maturity: conformity declarations, CE markings, documented vulnerability handling processes. Customers who previously couldn't evaluate product security will now have regulatory signals to guide purchasing decisions.

The global ripple effect

The CRA applies to the EU market, but its effects extend globally. Any company selling into the EU, regardless of where they're headquartered, must comply. That includes U.S. companies, Asian manufacturers, anyone with EU customers. The regulation is explicitly extraterritorial.

And the EU isn't alone. The United States has executive orders on software supply chain security with similar requirements. SBOM requirements are spreading. Vulnerability disclosure timelines are tightening. The CRA is the leading edge of a global regulatory trend.

Organizations that treat CRA compliance as a Europe-specific burden are missing the point. The capabilities you build for CRA compliance, supply chain visibility, vulnerability prioritization, remediation velocity, are the same capabilities you'll need for emerging regulations in other jurisdictions.

The bottom line

The EU Cyber Resilience Act represents the most significant shift in software liability in decades. It ends the era of "ship and forget." It makes manufacturers responsible for the security of their products throughout the product lifecycle. And it applies these requirements uniformly, regardless of where manufacturers are located.

For security leaders, the implications are clear. You need processes and tooling that can:

• Maintain continuous visibility into your software supply chain
• Identify which vulnerabilities actually affect your products
• Remediate issues within aggressive timelines
• Document everything for regulatory evidence

December 2027 sounds like a comfortable runway. It isn't. Organizations that start now will have time to build the capabilities they need. Organizations that wait will find themselves scrambling to meet requirements they can't satisfy.

The software industry's free ride on security liability is over. The question now is whether you'll be ahead of the curve or behind it.