Europe's New Software Security Law: What It Means for Your Team
The EU Cyber Resilience Act sets mandatory security rules for software and connected hardware sold in Europe. The first deadline hits in September 2026. Here is what it means in plain English and what you need to do before the clock runs out.
Europe's New Software Security Law: What It Means for Your Team
There is a new law coming for anyone who sells software in Europe. It is called the EU Cyber Resilience Act, and it is not optional.
The good news: the rules are reasonable. The bad news: the first deadline is September 2026, and most teams are not ready.
This is not a post full of legal language. It is a plain-English walkthrough of what the law asks, who it applies to, and what you can do today to avoid scrambling next year.
What is the Cyber Resilience Act?
The Cyber Resilience Act — the CRA for short — is a European Union regulation that came into force in December 2024. It sets security rules for software and hardware products sold in Europe that connect to the internet or to other devices.
Think of it like the food labeling laws that require manufacturers to list every ingredient in a product. The CRA does the same thing for software: you have to know what is inside it, keep it secure, and be transparent when something goes wrong.
It is the first time a government has made software security legally mandatory across an entire market — and it applies to everyone selling into Europe, regardless of where your company is based.
Does this apply to you?
If your product connects to a network or another device, and anyone in Europe can buy it — yes, it applies to you.
That covers a wide range of things:
- Apps (mobile, desktop, and web)
- Connected devices (smart home, industrial, wearables)
- Operating systems and security tools
- Cloud services that are a core part of a physical product
It does not matter if your company is based in the US, Japan, or anywhere else. If your product reaches EU customers, you are in scope.
There is an exception for non-commercial open source software. If you maintain an open source project as a hobby or community effort, you are not on the hook. But if your business sells or commercially supports an open source product, the rules apply to you.
Three dates you need to know
The law rolls out in stages. Here are the only three dates that matter for your planning.
September 11, 2026 — This is the first real deadline. From this date, if a security vulnerability in your product is being actively exploited in the wild, you have 24 hours to file an early warning with European authorities and 72 hours to send a full report. This is happening soon. Most teams do not have a process for this yet.
December 11, 2027 — This is when the full law kicks in. Your product needs to meet all the security requirements, carry the official CE marking, and come with proper documentation. Products that do not meet this standard cannot legally be placed on the EU market from this date.
June 11, 2026 — The date when national authorities can start officially approving the independent auditors who will certify higher-risk products. Less relevant to most teams, but it signals that the compliance machinery is now running.
September 2026 is closer than it looks. If you have not started thinking about what you would do if a vulnerability in your product were found and exploited tomorrow, now is the time.
What the law actually asks you to do
Strip away the legal language, and the CRA asks for four things.
1. Know exactly what your software is made of
Most software is built from hundreds of components — libraries, frameworks, tools — written by other people. The CRA requires you to keep a formal list of everything your product is built from, in a format that machines can read and regulators can check.
This is called a Software Bill of Materials, or SBOM. Think of it as the ingredient label for your product: every third-party piece of code that went into it, listed clearly and kept up to date.
The point is practical: if a security problem is found in one of those components, you need to know immediately whether your product is affected. Without that list, you are guessing.
2. Have a clear plan for when things go wrong
The CRA requires you to have a written, public process for receiving and handling security reports. If a researcher finds a vulnerability in your product and wants to tell you about it, there needs to be an obvious way to do that — a dedicated email address, a public policy, a named contact.
Beyond receiving reports, you need to be able to investigate them, fix them, and deliver that fix to your customers at no extra cost, for the entire supported life of the product.
3. Report problems to the right people — fast
When a vulnerability is being actively exploited, or when a serious security incident hits your product, you need to tell European regulators. The clock is strict:
- 24 hours — file an early warning
- 72 hours — send a full notification
- 14 days — submit a final report after a patch is available (for exploited vulnerabilities)
- 30 days — submit a final report for serious incidents
This is a significant change for most engineering teams. Knowing a vulnerability exists is one thing. Having a process that can produce a regulatory report within 24 hours of discovery is another thing entirely.
4. Write everything down
The CRA is, in part, a documentation exercise. You need to keep technical records that prove your product meets the security requirements. You need to define how long you will support the product with updates — the expected minimum is five years — and you need to let customers know when that support is ending so they can make informed decisions.
Think of it as the same discipline you would apply to any other serious engineering output: versioned, reviewed, and kept up to date alongside your product.
What are the penalties?
The fines are set at the same scale as GDPR, which should get people's attention.
Breaking the core security requirements can result in fines of up to €15 million, or 2.5% of your global annual revenue, whichever is higher. Smaller violations carry €10 million or 2% of revenue. Giving misleading information to regulators is fined at €5 million or 1%.
Beyond the fines, authorities can order your product to be pulled from the EU market entirely.
The €15 million / 2.5% model is the same structure as GDPR. Companies learned the hard way that regulators treat that not as a ceiling, but as the upper bound of a real range they are willing to use.
How to start preparing
You do not need to solve everything at once. Here is a sensible order of operations.
First, figure out what you have. List every product or service you offer that could be in scope. If it connects to the internet, put it on the list. Do not underestimate this step — it often reveals more scope than teams expect.
Second, categorize your risk. The CRA puts products into risk tiers. Most products fall into the lowest tier and can self-certify. A smaller number — firewalls, security tools, infrastructure software — require an independent assessment by an approved auditor. Knowing your tier early determines how much work is ahead of you.
Third, get your ingredient list in order. Start producing a Software Bill of Materials for your products. This means knowing every open-source library, every third-party tool, and every dependency that ships with your product. Tools can automate most of this — the important thing is to start doing it now rather than in 2027.
Fourth, put a reporting process in place. Publish a security contact. Write down internally who receives vulnerability reports, who investigates them, who approves fixes, and who would file a regulatory report if needed. Have this documented and tested before September 2026.
Fifth, start your documentation. Treat compliance records the same way you treat code: versioned, reviewed, and kept in sync with every release.
How Puaro helps
The CRA's core demands map closely to what Puaro already gives engineering teams.
Puaro continuously scans your repositories and tracks every component your software depends on, so you always know what is inside your product. When a security problem is found in a component you use, you know about it straight away — which is exactly what the 24-hour reporting window demands.
Because Puaro is wired into your pipeline, the evidence you need to respond fast — which version was affected, when the problem was flagged, when a fix was ready — is already captured as a natural part of your workflow. No scrambling. No manual spreadsheets the night before a deadline.
If the CRA is on your radar and you want to understand where your current setup has gaps, we are happy to walk through it with you at puaro.io.
The bottom line
The EU Cyber Resilience Act is the biggest change to software compliance in Europe since GDPR. It is not going away, and the September 2026 reporting deadline is close enough that "we will deal with it later" is no longer a safe answer.
The teams that use it as a push to get proper visibility into their software, to build real processes around security problems, and to keep good records will come out of it stronger. The ones who scramble at the end will face the same experience that unprepared GDPR companies faced: rushed audits, gaps in documentation, and regulators who are not sympathetic to "we did not know."
Start now. The work is manageable. The deadline is not.