For decades the software industry revolved around two things: speed and shipping ever more new functionality. Systems were brought to market as a 'Minimum Viable Product' (MVP), bugs and vulnerabilities included. The risks? They were covered in the End User License Agreement (EULA) as the user's problem. With the Cyber Resilience Act, the European Union finally puts this market on a par with the market for physical products.
The End of the EULA (the PLD)
The Product Liability Directive (PLD) has existed since 1985, but never clearly applied to software. The revised PLD changes that: software is now legally a product. And the burden of proof is eased for the injured party — for technically complex or poorly documented products a defect is readily presumed, after which it is up to you to prove otherwise.
This is how the two laws interlock: the CRA defines what 'secure enough' means. Fail to meet it and your product is readily deemed defective under the PLD (civil damage claims) — while under the CRA you also risk steep fines and an immediate EU-wide sales ban.
Does the CRA apply to you?
Almost every product with digital elements placed on the European market falls under the CRA — from mobile apps and desktop software to smart devices. Pure SaaS services and sectors with their own legislation (such as medical devices) are excluded. Around 90% of all software lands in the default category and may self-assess; critical products and security software need an external audit.
Not sure whether you're in scope?
Determine your risk class with the decision tree, or test your compliance readiness right away with the free Quickscan.
The 5 Fundamental Pillars of the CRA
On paper the Cyber Resilience Act sounds abstract, but in practice it is crystal clear. Every requirement comes together in Annex I of the law and can be summarised in five pillars. Together they determine how you design, document, ship and maintain software for years — from the first design to the formal CE marking. Walk through them one by one below:
Security-by-Design
Security is no longer an afterthought. Software must be demonstrably designed to be safe (e.g. through threat modeling) and delivered securely (secure-by-default).
Transparency (the SBOM)
The manufacturer must map exactly which (open-source) building blocks the application is made of. Every release ships with a machine-readable ingredient list.
Read more about the SBOMThe 24-Hour Reporting Obligation
Is a vulnerability being actively exploited in your product? Then you are obliged to inform ENISA (the EU authority) within a strict 24 hours with an "Early Warning".
The Multi-Year Patch Obligation
The manufacturer must keep the software secure for its expected lifetime (with a guideline of at least 5 years). You provide these updates free of charge.
Burden of Proof & CE Marking
Before a product may go to market, you deliver the technical evidence file (Docs-as-Code) and sign the EU Declaration of Conformity. Depending on the risk class (e.g. critical products) this file must first be approved by an external auditor (Notified Body) before the CE mark may be applied.
The timeline to compliance
Waiting is not an option. Automating a secure CI/CD pipeline and building a watertight technical file takes 12 to 18 months on average. Count back from the first deadline and it is clear: 2026 is not a distant prospect but today's planning.
11 September 2026: The Reporting Obligation
Legal deadlineFrom this date you are required to report actively exploited vulnerabilities (zero-days) to ENISA within 24 hours.
11 December 2027: CE Marking
Full legislationThe day your software products must officially bear a CE mark before they may enter the European market.
From the law to your situation
You now know the requirements. Test in two minutes how far your organisation is with the free Quickscan, or build it step by step in the 4-week Survival Challenge.