The EU Cyber Resilience Act has entered into force, and that is not a ceremonial footnote. It is the European Union saying, in regulatory language, that insecure software and hardware are no longer a tolerable cost of doing business.
For years, product security lived in the familiar swamp of “we’ll patch it later,” “the dependency is fine,” and “nobody reads that documentation anyway.” The CRA is what happens when a regulator gets tired of that excuse economy. The law now puts mandatory cybersecurity requirements on products with digital elements sold in the EU, from software to hardware and the supply chain glue in between.
And yes, that includes the boring stuff. Especially the boring stuff.
The Real Change Is Not The Headline
The headline is easy: the CRA is in force. The harder part is what it means in practice.
This is the EU’s first horizontal cybersecurity regime for products with digital elements. That means the regulatory perimeter is not limited to one industry or one class of vendor. It reaches across the stack: operating systems, browsers, password managers, VPN software, routers, modems, network interfaces, and more. In other words, if your product ships with code, ships with components, or ships with assumptions, the CRA has opinions about it.
That is the point. The EU is no longer content to ask whether a product works. It wants to know whether it works securely by design, whether the manufacturer can support it responsibly, and whether vulnerabilities are handled like a real operational process instead of an e-mail thread with a sense of urgency.
SolarWinds and Log4Shell were not abstract lessons. They were the market’s way of learning, repeatedly, that the modern software supply chain is not “just engineering.” It is governance. It is risk management. It is, in many cases, the product.
SBOMs Are No Longer Nice-To-Have Paperwork
Let’s talk about the acronym everybody loves to mention and nobody loves to maintain: SBOM.
A software bill of materials is, at bottom, a formal inventory of what is inside a product and where those components came from. That sounds obvious until you ask a product team to produce one that is current, accurate, and actually usable under pressure.
The CRA makes SBOMs part of the compliance conversation. The regulation explicitly contemplates that market surveillance authorities can request SBOMs generated under the law, and it empowers the Commission to specify their format and elements. Translation: dependency transparency is not a hobby project anymore.
This is where a lot of companies discover they have two separate problems:
- They do not know their own dependencies as well as they think they do.
- Even if they do, they have not linked that information to vulnerability handling, release processes, and technical documentation.
That is why SBOM work is never just a spreadsheet exercise. It is dependency analysis, component governance, and evidence collection all at once. If that sounds like the kind of thing that belongs in a Privacy, Security & Compliance engagement, it does. SBOM generation and EU CRA readiness are not glamorous, but they are very much the difference between a product that can defend itself and one that hopes the fire stays on someone else’s floor.
Five Years Is A Long Time In Software
The CRA also forces a question many teams prefer not to ask: how long are you supporting this product?
Under the regulation, the support period is not a vague promise buried in a marketing page. It is a defined part of the product’s security lifecycle, and the support period must reflect how long the product is expected to be in use. The law’s baseline is blunt enough to be useful: the support period is at least five years, unless the expected product lifetime is shorter.
Five years sounds simple until you map it onto the actual world of software.
Five years is several product cycles, several framework migrations, at least one “replatforming” initiative, and usually a few moments where somebody asks whether the old codebase can be “modernized” by optimism. It is also long enough that the support plan must survive personnel changes, vendor churn, dependency decay, and the annual corporate ritual of forgetting what was promised last quarter.
So the support-period question is not, “Can we say we support it?” The question is, “Can we actually patch it, track it, and prove it, for the period the law requires?” That is a very different standard. It is also a very expensive standard if you are discovering it after launch.
Vulnerability Reporting Is Now A Process, Not A Panic
The CRA also brings vulnerability reporting into sharper focus.
That matters because a lot of organizations still treat vulnerability response as a crisis-only behavior: someone spots a problem, a Slack channel lights up, people begin muttering the word “severity,” and eventually the issue gets closed once the adrenaline runs out. The CRA is not interested in adrenaline. It wants a repeatable process.
Manufacturers are expected to handle vulnerabilities across the product lifecycle and to report actively exploited vulnerabilities and severe incidents through the law’s reporting framework. In plain English: if a serious issue is burning in the wild, burying it in internal ticketing is not a strategy. It is a delay.
And that leads to the practical question: do you have a single, defensible path from discovery to triage to notification to remediation? Or do you have a pile of tools and hope?
That is exactly where product security, legal coordination, and operational discipline collide. It is also why due diligence teams should be paying attention. A product with weak vulnerability handling is not just a security liability. It is a valuation problem waiting for the wrong day.
What Companies Should Do Now
If you sell software or connected products into the EU, the right response is not panic. It is inventory.
Start with the product catalog. What is in scope? What components are embedded? What third-party code ships in the box? What do you actually know about your transitive dependencies, build systems, and update mechanisms?
Then move to the documentation stack. Can you produce a usable SBOM? Can you trace components to release versions? Can you show how vulnerabilities are tracked, triaged, patched, and communicated? Can you define a support period that is real, not aspirational?
Then look at governance. Who owns CRA readiness? Who signs off on support-period decisions? Who receives vulnerability notices? Who can make the call when a product needs to be updated, recalled, or re-documented?
That work is where compliance gets real, and where a lot of teams benefit from a focused sprint on SBOM generation, dependency analysis, and EU CRA compliance readiness rather than a vague “let’s all be more secure” meeting series. The law rewards evidence, not vibes.
The New Baseline
The Cyber Resilience Act is not saying that every product will be perfect. That would be both unrealistic and, frankly, suspicious.
It is saying something more useful: if you want to sell digital products into the EU, you need to know what is in them, how they are supported, and how you respond when something goes wrong. That is not radical. It is what responsible engineering already looks like when nobody is trying to avoid paperwork.
The difference now is that the paperwork has teeth.
And that is the part the market should take seriously. Not because Brussels likes forms, but because the cost of pretending not to know what is inside your software has become too high to ignore.
Related posts
Delve and the 494 Fake SOC 2 Reports: What the Compliance Industry Should Learn
A Y Combinator-backed compliance startup allegedly fabricated 494 SOC 2 reports with auditor conclusions pre-written before clients submitted any evidence.
Read moreFive Supply Chain Attacks in Twelve Days: March 2026 Broke Open Source Trust
In twelve days, attackers compromised Trivy, Checkmarx, LiteLLM, Telnyx, and Axios — and the supply chain security model most organizations rely on did not survive.
Read moreThree More States, Three More Privacy Laws: 2026 Compliance Starts Now
Indiana, Kentucky, and Rhode Island all went live on January 1, 2026, which means privacy compliance just got a little less optional.
Read more