Cyber Resilience Act: the software industry's 'September reset'
In September 2026 the EU Cyber Resilience Act takes full effect. Here is what it actually requires, and how to get your stack ready.
Every so often a law gets passed in one jurisdiction and quietly reshapes the entire global IT industry. Remember 2018, when GDPR took effect and rewrote how every website on the planet handled cookies, consent and user data.
September 2026 is shaping up to be that kind of moment again. The European Union’s Cyber Resilience Act (CRA) — the bloc’s first comprehensive cybersecurity law for digital products — comes fully into force.
It will not stop at the EU border. If your product, SaaS, API, or hardware ends up in the hands of European customers — no matter where your company is incorporated, no matter where your servers run — you are on the hook. Industry estimates put the directly affected universe at more than 600,000 software and technology companies worldwide.
In developer terms: the “works on my machine, ship it” era is officially over. Let’s walk through what the law actually says, what it demands in technical terms, and how to bring an existing stack into compliance without panicking.
What CRA is, and why it is global
CRA is an EU regulation that sets mandatory cybersecurity requirements for any product “with digital elements” — both hardware and software — placed on the European market.
Its guiding philosophy is simple: security by design and by default. A product must be demonstrably secure at the code level, the architecture level, and across its supply chain before it ships, not patched up afterwards.
Extraterritorial reach
Like GDPR, CRA reaches far past Europe’s borders:
- It applies if your company sits in the US, Asia or the Middle East.
- It applies if your project is cloud-native and your servers live on another continent.
- The moment an EU citizen or company buys or uses the end product, you are legally accountable.
Classification: which tier are you in?
CRA does not treat every product the same. Risk decides scrutiny, and products fall into three tiers. Knowing your tier is the first step in budgeting time and money for compliance.
| Tier | Examples | How compliance is checked |
|---|---|---|
| Standard (low risk) | Consumer apps, text editors, simple games and visualisation tools | The vendor performs a self-assessment and signs a declaration of conformity. |
| Class I (medium risk) | Identity and password managers, browsers, antivirus tools, network interfaces | Either an independent auditor or strict adherence to harmonised international cybersecurity standards. |
| Class II (high risk) | Operating systems, routers and firewalls, cryptographic chips, router firmware | Mandatory third-party certification by a notified body. |
The three hardest requirements
What is actually keeping software architects and DevSecOps leads up at night is the technical implementation. CRA puts three demands at the centre:
Mandatory SBOM (Software Bill of Materials)
You have seen ingredient lists on restaurant menus — salt, sugar, allergens. An SBOM is the same idea, applied to software.
What open-source libraries does your application pull in? Which NPM, NuGet, or Pip packages does it depend on, transitively? CRA requires that this list be produced automatically, in a standard machine-readable format (JSON or XML), and kept in sync on every deploy.
Continuous vulnerability management
The “ship it and forget it” era is over. Under CRA you are responsible for the full lifecycle of the product — a minimum of 5 years, or the actual support lifetime of the product — and any CVE that surfaces in that window must be tracked, triaged and patched.
24-hour incident disclosure
If a serious cyberattack or active vulnerability hits your product, you no longer have the option of “fixing it quietly”. Within 24 hours you must notify the EU’s cybersecurity agency (ENISA) and your customers in writing.
The fines. Non-compliance is priced to hurt: up to €15 million or 2.5% of global annual turnover, whichever is higher. And on top of the fine, regulators can pull your product from the EU market entirely.
The open-source question — and the answer
When the first drafts of CRA leaked, the open-source world (Linux Foundation, Apache, the Python Software Foundation) raised the alarm: would individual maintainers be liable for million-euro fines on code they give away for free?
The final text made the cut clean:
- Non-commercial open source. If you publish a project on GitHub and derive no commercial benefit from it, CRA does not apply to you.
- Commercial integration. The moment a company takes your free code and bundles it into a paid SaaS or commercial product, the legal responsibility shifts entirely to the company shipping the product.
Predictably, this is making large companies a lot pickier about which third-party libraries they pull in.
A practical playbook: bring your CI/CD up to CRA
Panic and code-freezes are the wrong response. The right one is to automate security — to actually adopt DevSecOps instead of just putting it on a slide. Most of the teams ahead of the curve are converging on the same pipeline:
[Write code] → [SAST scan] → [SCA / SBOM generation] → [DAST scan] → [CRA-compliant deploy]Step 1: automate SBOM generation
Add a tool that emits a standardised SBOM on every build. CycloneDX and SPDX plugins exist for almost every ecosystem — wire one in and your conformity document gets produced for free on every CI run.
Step 2: add SCA (Software Composition Analysis)
Catch outdated and vulnerable packages before they ship. Plug Snyk, Trivy or OWASP Dependency-Check into your CI. If a new dependency drags in a known vulnerability, the build should fail loudly — not get patched in production at 2 AM.
Step 3: layer in SAST and DAST
Use SonarQube, GitHub Advanced Security or Veracode to scan the code your engineers actually write. SQL injection, hardcoded secrets, misconfigured crypto — none of it should make it past CI.
Closing: CRA is a floor, not a ceiling
On first read CRA looks like a mountain of bureaucracy. But the winners in any regulatory shift are always the ones who adapted first.
If your team starts wiring up SBOMs, vulnerability scanning and incident playbooks today, then by September 2026 — while competitors are still printing out the regulation and highlighting it — you will already be selling into the European market as a credible, “CRA-ready” vendor.
Don’t postpone security. Build it into the code, now.