Forget “best practices.” The EU’s Cyber Resilience Act makes security a legal demand. If you sell a digital product in Europe, it must be secure. Fail, and fines can hit €15 million or 2.5% of your global revenue.
The law was passed in December 2024. It replaces loose guidance with strict, enforceable rules. Software firms and gadget makers now have to prove their products are safe and report major security flaws.
This isn’t a suggestion for your team. It’s a forced rewrite of your entire development process. You have until December 2027 to comply. See what you need to do next.
Cyber Resilience Act: Key Software Compliance Insights
Before the details get technical, it helps to step back and look at what the law is really asking software teams to do.
- The Cyber Resilience Act turns secure software from best practice into legal requirement across the EU market.
- Developers must implement Secure Coding Practices, SBOM generation, vulnerability handling, and documented lifecycle support.
- Most products follow self-assessment, but Annex III and IV categories require third-party audits and stricter oversight.
What Is the EU Cyber Resilience Act and Why Does It Matter for Software?
Forget optional security guidelines. The Cyber Resilience Act makes them the law. If your “product with digital elements” is sold in the EU, it must be secure. The old voluntary standards are replaced by rules with big financial penalties.
The regulation started on December 10, 2024. Companies have a 36-month transition, with everything required by December 2027. The European Commission created this law to cut down cyber risk in our connected world.
What does this mean for us? As manufacturers, we must now prove we meet the essential requirements in Annex I. We have to run risk assessments and keep all documentation for a full ten years. Starting in September 2026, we must also report serious incidents to national teams and ENISA.
As explained in the European Commission press release, the regulation forces a lifecycle approach to cybersecurity:
“Once the Cyber Resilience Act is in place, manufacturers of hardware and software will have to implement cybersecurity measures across the entire lifecycle of the product, from the design and development, to after the product is placed on the market. … The new rules require every interconnected product sold in the EU to be cybersecure and make sure that our businesses and homes become more secure.” – European Commission
This isn’t a small change. In our projects, security cannot stay a last-minute add-on anymore. It becomes a required part of the initial design, similar to certifying a medical device.
Key dates you need:
- Law begins: December 2024
- Start incident reports: September 2026
- Full rules apply: December 2027
- Biggest fine: €15 million or 2.5% of worldwide revenue
Three years look long in a memo. For engineering teams, it’s a very short clock.
Which Software Products Fall Under the CRA Scope?
The law’s reach is wide. It covers regular software, embedded systems, IoT gadgets, and even open source software you sell commercially in the EU. Many teams first try to understand EU cyber resilience act requirements by mapping which products count as “digital elements” under the regulation.
They use the term “products with digital elements.” That means connectable hardware, remote data processing, and some SaaS parts. Hobbyist open source is fine, but if you make money from it, the rules apply.
Based on regulatory summaries, about 90% of products will follow a simpler path. You do a self-assessment and apply a CE mark. But products labeled “Important” (Annex III) or “Critical” (Annex IV) are different. They need a full check by an official third-party auditor.
This classification is everything. It decides your project’s budget, how much paperwork you need, and who checks your work.
Product Classification Tiers
| Category | Examples | Assessment Type |
| Standard Products | Most commercial software (~90%) | Self-assessment + CE mark |
| Important (Annex III) | Firewalls, identity systems | Third-party conformity check |
| Critical (Annex IV) | Operating systems, core infrastructure | Mandatory third-party audit |
For teams building things like smart home devices, this table tells you if an outside auditor will be part of your release plan.
We tell our students to classify their product early. A wrong guess here can delay your CE marking and keep your product off the market. We’ve seen it happen.
What Are the Core Compliance Requirements for Software Manufacturers?
Credits: OWASP Netherlands
The rules are specific and strict. Software makers must build security into the design from the start. Many teams reviewing a cyber resilience act summary quickly realize that SBOM generation, update mechanisms, and vulnerability handling are now mandatory parts of product engineering.
They need to create a machine-readable list of all software components (an SBOM). They have to provide automatic security updates. And they must report serious incidents fast, within 24 to 72 hours.
The main requirements in Annex I cover things like strong logins, encrypted data, and managing known weaknesses. The European Commission’s timeline for reporting is tight:
- An early alert within 24 hours
- A full notification within 72 hours
- A final report in 14 to 30 days
We also have to keep all technical documents for 10 years and issue an official EU Declaration of Conformity before using the CE mark.
In our work, the SBOM rule has changed how we talk about architecture. It forces teams to see every dependency, including big upstream projects like the Linux kernel or Python libraries.
When we guide teams through CRA preparation, the core jobs usually become:
- Doing a pre-market security risk check
- Creating a machine-readable Software Bill of Materials
- Turning on automatic security updates by default
- Setting up a clear process for handling vulnerabilities
- Reporting vulnerabilities through official CSIRT channels
That secure coding training? It’s useful here. Bake security in from the start, and compliance gets easier. An audit then just reviews your normal work, instead of forcing a frantic proof-gathering session.
How Does the CRA Impact Software Development Workflows?
The CRA makes DevSecOps mandatory. It pushes security into every part of building software, aligning with the broader CRA overview and purpose of enforcing secure design across the entire product lifecycle. This raises initial costs but cuts down the huge risk of a major breach.
Before, many companies handled vulnerabilities only after they were found, often by a separate security team. Now, the entire process must be planned, written down, and ready for an auditor to inspect.
Analysis from Harvard Business Review shows that these kinds of regulatory shifts do increase early development spending. But they save money over time by preventing catastrophic losses.
From our own projects, the hardest part is supply chain clarity. Automating SBOM creation across GitHub repos and internal code requires new tools, updated policies, and training for developers.
The big workflow changes are:
- Security is a legal demand, not a nice-to-have.
- SBOM generation gets built into continuous integration pipelines.
- Vulnerability management becomes a continuous, tracked activity.
- Lifecycle documentation is part of product compliance.
Workflow Shift Comparison
| Before CRA | After CRA |
| Secure design was optional | Essential security rules are mandatory |
| Dependencies tracked manually | SBOMs are generated automatically |
| Irregular, manual updates | Defined support periods with automatic updates |
When we help IoT teams prepare for CRA audits, we see the same pattern: systems must support remote patching from the beginning. In our experience, that engineering effort often costs more than the official audit itself.
What Are the Business and Financial Implications?
The fines are huge. Break the rules, and you could pay up to €15 million or 2.5% of your company’s total global revenue. This puts the issue right in front of the board.
It’s not just about money. If you can’t get your CE mark on time, you can’t sell your product in the EU at all. Companies outside Europe must also appoint a legal representative inside the EU, which adds more cost and complexity.
Research from the National Institute of Standards and Technology shows that good risk management lowers long-term business instability. The CRA makes this kind of management a legal must for digital products.
The main costs businesses will face are:
- Audit fees for “Important” or “Critical” products
- New software for SBOMs and automation
- Hiring or training compliance staff
- Checking the security of your software suppliers
Smaller companies get a little more time, but the rules are the same.
For leaders, the math is clear. Pay to build a compliant process now, or pay much more later in fines and lost reputation. Early preparation is cheaper.
How Does the CRA Affect Open-Source Software Ecosystems?
Pure hobbyist open source is fine. But if you sell open source software or are a major project “steward,” the rules change. You need formal cybersecurity policies and a way to report vulnerabilities.
Stewards must document how they handle security flaws and work with authorities. They won’t be fined directly under this law, but a new layer of responsibility is created around the ecosystem.
Industry analysis from the Red Hat security discussion on the CRA highlights why the regulation puts pressure on commercial users of open source:
“As commercial entities increasingly integrate open source into their products, they’ve often overlooked security at the source (i.e., upstream), instead opting to bolt on fixes only at product release. … Now the CRA has arrived, aiming to address these very issues from a top-down perspective. This legal framework mandates cybersecurity requirements for hardware and software with digital elements placed on the EU market. In particular, it requires ‘manufacturers’ to prioritize security throughout a product’s lifecycle.” – Red Hat
The main impacts on open source are:
- More careful checks of the components you use (SBOMs)
- Official channels for reporting security holes
- Better coordination with national CERT teams
- Clearer lines of who is responsible in the supply chain
We’ve trained teams in projects that adopted secure coding years ago as a best practice. Now, under the CRA, that same work counts as proof of compliance. This alignment helps. It means good development practice and meeting the law aren’t fighting each other.
The open source world will figure this out. It always does.
What Does the CRA Mean for Importers and Distributors?
If you import or distribute software in the EU, you have a new job. You must check that products have a valid CE mark and that all the required compliance paperwork exists before you can sell them.
You didn’t build the software, but you share the legal risk. Market surveillance authorities in EU countries can hold you accountable alongside the manufacturer.
| Who | Main Job | Their Risk |
| Manufacturers | Do risk assessments, create SBOMs, and report incidents | Full legal liability |
| Importers | Verify the CE mark and documentation | Shared responsibility |
| Distributors | Make sure the product is compliant before selling it | Facing market surveillance checks |
Different EU countries will coordinate their oversight. For higher-risk products, official bodies will do the checks.
This turns distributors into a new kind of gatekeeper. They become the last stop for checking if a product follows the law before it reaches customers.
How Should Software Teams Prepare Before December 2027?
Start now. The three-year transition will go fast, especially if you need to change how your product is built.
Your team should find the gaps in your current process, set up automatic SBOM creation, write down your vulnerability reporting steps, and make sure your development workflow matches the law’s security rules by December 2027.
A Simple Preparation Roadmap
- Run an internal check against the CRA rules.
- Figure out if your product is Standard, Important, or Critical.
- Get automated SBOM generation running.
- Define exactly how long you’ll support the product with updates.
- Set up a workflow to report serious incidents within 24 hours.
- Test your readiness for the final CE marking.
From our training sessions, we know the most effective step is baking secure coding into your platform from the start. When security is built in early, the official audit just confirms what you’re already doing. It’s not a frantic scramble to fix things.
Remember, you have to start reporting incidents in September 2026. Your process for handling vulnerabilities needs to be ready and working well before that date arrives.
FAQ
What does the Cyber Resilience Act mean for my software?
The Cyber Resilience Act is a law in the European Union that sets clear cybersecurity requirements for digital products and products with digital elements. If you develop software, apps, or IoT devices, you must follow CRA requirements before selling in the EU market.
You must provide security updates, manage vulnerability handling, and prepare complete technical documentation. You also need CE marking and an EU Declaration of Conformity to show compliance.
Do open source projects face CRA requirements?
Open source and open source software can be affected by CRA requirements in certain cases. If open source software is included in commercial products with digital elements, the rules may apply.
Software developers must support vulnerability management and provide clear vulnerability reports when risks appear. The European Commission issues guidance, and market surveillance authorities review compliance across Member States.
How will conformity assessment work for my product?
Some digital products must go through a conformity assessment procedure before entering the EU market. This process checks essential cybersecurity requirements listed in Annex I and Annex III. Critical products may require review by a notified body or other conformity assessment bodies.
You must prepare detailed technical documentation and meet recognized cybersecurity standards. After approval, you apply the CE mark and issue the EU Declaration of Conformity.
What must I do about security updates and incidents?
You must establish strong vulnerability handling processes and release timely security updates. If severe incidents or major cyber threats occur, you must report them without delay.
Vulnerability Reporting rules help protect users and reduce harm. Supply chain security and a Software Bill of Materials improve cyber risk management. Market surveillance authorities may review how you respond to security vulnerabilities.
How does CRA affect small software businesses?
A small or medium enterprise must meet the same cybersecurity requirements as larger companies. The law applies to software development, cloud solutions, and remote data processing solutions sold in the EU market.
It also covers Internet of Things devices and connectable hardware such as baby monitors and smart home devices. Clear compliance strategies and proper Product Compliance steps help businesses meet technical standards and reduce risk.
Preparing Software Teams for the Cyber Resilience Act Era
The Cyber Resilience Act is a signal. Software teams can ignore it for now, or they can start building safer code today. The teams that act early often move faster later. They build trust. They ship with fewer surprises. Security stops being a last-minute fix and starts becoming part of how good software is made.
If you want hands-on practice, you can Join the Secure Coding Practices Bootcamp. It shows developers how to write safer code with real labs, simple steps, and tools they use every day. No heavy theory. Just practical skills that help teams ship stronger software from day one.
References
- https://ec.europa.eu/commission/presscorner/detail/en/ip_23_6168
- https://www.redhat.com/en/blog/eu-cyber-resilience-acts-impact-open-source-security