The CRA Readiness Gap: Why Most Organizations Aren’t Ready for December 2027 — and What to Do About It

The clock is running, and most teams haven’t started

There’s a hard deadline on the horizon that a surprising number of software organizations are sleepwalking toward. The EU’s Cyber Resilience Act (CRA) brings its main obligations into force in December 2027. That sounds far away. It isn’t — not when you account for how long it takes to inventory your software, fix your processes, and bring an entire portfolio of products and dependencies into compliance. The Linux Foundation’s 2026 CRA Awareness and Readiness Report makes the situation plain: we are at a critical juncture, the deadline is rapidly approaching, and readiness is stagnating.

‍

The three numbers that define the gap

Three findings from the report capture the problem. First, awareness is alarmingly low: 66% of respondents are unfamiliar with the CRA. Two out of three people working in and around the software ecosystem can’t act on a regulation they don’t know exists. You can’t prepare for what isn’t on your radar, and right now it isn’t on most teams’ radar.

Second, the financial stakes are invisible to the people who’ll pay them: 56% of organizations are unaware of the non-compliance fines. The CRA carries serious penalties, and more than half of organizations don’t know they’re exposed. That’s not a risk that’s been weighed and accepted — it’s a risk nobody has priced. Third, readiness isn’t improving fast enough to close the gap before the deadline. Awareness that stays low while the clock runs down is how organizations end up scrambling in 2027 to fix what could have been handled calmly in 2026.

‍

What the CRA actually asks of you

At its core, the CRA says that products with digital elements sold in the EU must be secure by design and stay secure across their supported lifecycle. In practice, that means knowing what’s in your software, handling reported vulnerabilities responsibly and on a defined timeline, providing security updates for the life of the product, and being able to document all of it for regulators and customers.

For modern software, knowing what’s in your software is the hard part — because nearly every product is built on a deep stack of open source components, each with its own maintainers, its own release cadence, and its own end-of-life date. The CRA effectively makes the security and supportability of your open source dependencies a regulatory question, not just an engineering preference. An organization that doesn’t have a clear inventory of its open source, doesn’t know which components are still maintained, and doesn’t have a plan for the ones that have gone end-of-life is not a few tweaks away from compliance. It has real work to do, and a shrinking window to do it in.

‍

Why “we’ll deal with it in 2027” is a trap

It’s tempting to treat a 2027 deadline as a 2027 problem. Three things make that a mistake. Inventory takes longer than you think: most enterprises genuinely don’t know everything they’re running, because the average commercial codebase pulls in thousands of components, many introduced indirectly as dependencies of dependencies. Building an accurate, current picture is a project in itself.

Remediation has lead time: once you find unsupported or end-of-life components, you have to do something about them — update, replace, or secure them — and if your plan is to migrate off every outdated library before the deadline, you’re committing to months of engineering work that competes directly with your product roadmap. And the market will move before the regulator does: customers, procurement teams, and partners will start asking for CRA evidence well ahead of December 2027, so being able to answer “yes, here’s our documentation” becomes a sales advantage long before it becomes a legal requirement.

‍

Closing the gap without derailing your roadmap

The 2026 CRA Awareness and Readiness Report recommends shifting from compliance workarounds toward sustainable practices, investing in implementation, and supporting the open source projects and foundations you depend on. Here is how that translates into a practical sequence.

Start with visibility. You cannot comply with a regulation about your software if you can’t see what your software contains. The first move is an honest inventory: every open source component, its version, its maintenance status, and its end-of-life date — so you have a clear map of what’s supported, what’s abandoned, and what’s about to be.

Triage by risk and exposure. Not every component carries equal weight. Prioritize the libraries that stand up critical systems and the ones that are already unsupported — those are your compliance liabilities and your security liabilities at the same time. Then secure the end-of-life components without halting the roadmap: a drop-in replacement — a secured, supported, and compliant version of the same library that swaps in within minutes — lets you close the gap on your timeline instead of interrupting feature work to chase every dependency. Finally, make support a standing guarantee rather than a one-time project; the CRA requires ongoing security maintenance across a product’s supported life, which favors a model where someone is contractually on the hook, with SLAs, to keep your dependencies secure and supported.

‍

The bottom line

The CRA readiness gap isn’t a knowledge problem you can close the week before the deadline. It’s an inventory problem, a remediation problem, and a sustainability problem — and each of those has lead time measured in months, not days. The organizations that come through December 2027 calmly will be the ones that started in 2026: building visibility into what they run, securing what’s gone end-of-life, and putting real support behind the open source their products depend on. The deadline isn’t moving. The smart move is to start now, while you still have the luxury of doing it deliberately.

 Read the full 2026 CRA Awareness and Readiness Report from the Linux Foundation.