Industry Voices: The CRA Deadline Is Closer Than You Think and Your SBOM Alone Won't Save You

There's a document sitting in a compliance folder somewhere in your organization. It lists the software components in your product. It was accurate — once. And right now, it's quietly becoming your biggest regulatory liability.

The EU Cyber Resilience Act (CRA) is not another checkbox exercise. It places binding cybersecurity obligations on manufacturers, importers, and distributors placing connected products on the EU market — and it demands something most organizations have never actually built: continuous, defensible visibility into their software supply chain.

For industries like aviation, defense, railway, and energy, where software failures carry physical consequences and regulatory scrutiny is already intense, the gap between where most organizations are and where the CRA requires them to be is not small. It's structural.

As part of our ongoing partnership with RunSafe Security, we sat down with Shane Fry, Chief Technology Officer at RunSafe, to get a direct read on what's broken, what's required, and what it will take to close the gap.

The CRA is pushing SBOMs from point-in-time artifacts to continuous lifecycle requirements. What does that actually mean in practice?

Shane Fry: The static SBOM mindset made sense when the primary use case was license auditing. Organizations could produce a document, file it, move on. The CRA is changing SBOMs from a point-in-time compliance obligation to a continuous lifecycle requirement.

Under the regulation, manufacturers are responsible for actively managing vulnerabilities throughout the supported life of a product and not just at the moment of sale. The moment your software changes — a patch, an update, a dependency bump — a static document becomes stale. And stale documentation is unhelpful if you're relying on it for security decisions.

The CRA requires you to identify vulnerabilities, address them without undue delay, and report actively exploited ones to relevant authorities. None of that is possible if your SBOM is a PDF in a compliance folder. It has to be a living artifact feeding directly into your vulnerability management and incident response processes.

"An SBOM that's a PDF sitting in a compliance folder cannot tell you whether a vulnerability disclosed today is running in your product tonight."

The CRA doesn't exist in isolation. It propagates upstream — through procurement requirements, contractual obligations, and the expectations of downstream integrators. Commercial software vendors whose components feed into regulated products are already facing increased scrutiny. And the expectation is only going to tighten.

Shane draws a direct line between regulatory pressure and some of the most damaging attacks in recent memory.

SF: The SolarWinds attack didn't compromise the end customer directly; it instead compromised the build pipeline. Log4Shell wasn't just a Log4j problem but a visibility problem. Organizations didn't know they had it until they went looking.

"The Log4Shell vulnerability wasn't just a Log4j problem but a visibility problem. Organizations didn't know they had it until they went looking."

Software supply chain visibility won't eliminate risk, but it does make response dramatically faster and reduce exposure windows. That is precisely what the CRA is trying to force.

Most organizations believe they have an SBOM practice. Most of them are wrong.

SF: Many organizations have acquired a tool that produces an SBOM and concluded the job is done. What they actually have is a list of open-source components derived from a post-build binary scan. That leaves out commercial libraries, proprietary middleware, and supplier-provided components — precisely the components carrying the highest compliance and security risk.

The second gap is build-time provenance. Most SBOM tools generate SBOMs after software has been built. By then, optimization and linking have obscured attribution. You may identify that a library is present, but tracing exactly how it entered the build — from which supplier branch, under what configuration — that information is often gone.

"That's the difference between a compliance artifact you can stand behind and one you're hoping holds up under scrutiny."

Build-time SBOMs observe the build as it happens, recording which source files, libraries, toolchains, and configurations contributed to each artifact as the software is being constructed. If a vulnerability is disclosed in a commercial library that was statically linked into your firmware six months ago, a post-build scanner may or may not surface it. A build-time SBOM knows it was there — because it was recorded when it entered the build.

The threat environment has changed. AI-driven vulnerability identification has compressed the window from disclosure to active exploitation from weeks down to hours. A reactive security posture is no longer viable — by the time you're reacting, the window is already open.

SF: A product that was compliant on its release date can become non-compliant the moment a dependency is updated or a new vulnerability is disclosed. Governance has to operate at the same cadence as software delivery.

"What the CRA is really doing is raising the cost of opacity. If you can't see your own software supply chain, you cannot meet the regulation's requirements in any meaningful way."

The organizations that treat SBOMs as living infrastructure and those that treat them as filing exercises are heading toward very different compliance outcomes. For critical industries, the stakes are existential: the CRA formalizes obligations that many have yet to operationalize, and the clock is running.

Critical Software and RunSafe Security are working together to help regulated industries move from SBOM generation to full SBOM lifecycle management — with the build-time provenance and continuous vulnerability matching that CRA compliance actually demands.

If your organization is navigating CRA readiness or reassessing your software supply chain security posture, get in touch to learn how we can support that work.