Europe Just Turned Product Security Into a Deadline
The EU’s Cyber Resilience Act is pushing connected products, software, and backend-dependent devices into a new compliance model where proof, patching, and disclosure timelines matter as much as code quality.
For years, many security teams treated vulnerability management as an internal discipline. The Cyber Resilience Act changes that posture. In the EU market, product security is becoming a legal condition of sale: vendors must know what they ship, how long it will be supported, and how quickly they can report and react when an exploited flaw appears.
Fast Facts
- The CRA is a product-security law, not just a process or certification rule.
- Exploited vulnerabilities must be reported within 24 hours, with a detailed report within 3 days.
- Most covered products require at least 5 years of free security updates.
- Pure SaaS is generally outside scope, but client software and connected devices can still fall in scope.
- Penalties can include sales restrictions, recalls, market withdrawal, and fines up to €15 million or 2.5% of turnover.
Why this law hits engineering teams first
The CRA’s sharpest shift is conceptual: it treats the finished digital product as the compliance object. That means security is no longer only about having a development checklist or an audit trail. It is about whether the product itself is designed to minimize attack surface, protect confidentiality and integrity, and keep receiving updates for a defined support period.
That model creates pressure on software supply chains. Teams need to understand dependencies, including open-source components, because a vulnerability in a library or embedded module can turn into a reporting obligation very quickly. In practice, an SBOM becomes less of a nice-to-have inventory and more of an operational tool for answering a simple question under time pressure: what is affected?
The law also matters because it broadens the conversation beyond classic desktop software. Connected appliances, network equipment, mobile apps, embedded systems, and products with backend services can all become compliance problems if they are marketed as digital products in the EU. Pure SaaS is generally treated differently, but client-side software or hardware that relies on SaaS backends may still be captured.
From a defensive perspective, the most important change is the available information clock. A team that cannot triage an exploited issue, identify impacted builds, and produce evidence on demand may be compliant in theory but exposed in practice. The CRA rewards organizations that can turn vulnerability management into a repeatable workflow: intake, assessment, disclosure, remediation, and documentation.
The broader operational lesson is that compliance and security engineering are merging. Product managers, legal teams, developers, and supply-chain owners now need the same facts at the same time: what is shipped, what is supported, what is vulnerable, and what has been reported. That is a much harder standard than a one-time checklist.
Non-commercial open source is generally outside the core market-made-available rule, but companies that incorporate open-source components still carry responsibility for the products they place on the market. The new burden is not just to consume code, but to understand and govern it.
Conclusion
The CRA is a reminder that software safety is becoming measurable, timed, and inspectable. Vendors that can prove component knowledge, support commitments, and fast vulnerability handling will adapt more easily than those still treating security as an afterthought. The lasting lesson is simple: in regulated digital markets, being secure is no longer enough if you cannot prove it on deadline.
WIKICROOK
- Cyber Resilience Act (CRA): An EU product-security regulation that makes security, support, and vulnerability handling part of market access.
- SBOM (Software Bill of Materials): A machine-readable inventory of software components and dependencies used to track exposure and supply-chain risk.
- Attack surface: The total set of entry points an attacker could try to abuse in a product or system.
- Conformity assessment: The process of proving a product meets required technical and legal standards before it is sold.
- Support period: The minimum time a manufacturer must keep security updates available for a covered product.
